System Engineering

System Engineering

Emergence of Systems Engineering as a Distinct Discipline

The systems engineering discipline has matured from

an operational birth in the governmental procurement process based on systems acquisitions, operational analysis and value engineering

toa multifaceted (many-sided) commercial discipline that can be used to address any type of complex system development.

.

Systems Engineering History

• First mention of the term "systems engineering" appears to have been by Bell Labs in the US, c.1941.

• 1960’s– Intercontinental Ballistic Missile Programs– Polaris submarine - AFSCM 375 -5– Apollo - NASA procedures– MIL-STD-499 - 25 pages - validate contractor’s process– US Army FM 770-78 - less forms, more organization

• 1970’s– Defense Systems Management College handbook– Formal software requirements analysis & design

• 1980s– Computer tools start to emerge (RDD-100, etc)

• 1990– INCOSE (International Council On System

Engineering) established·• 1995

– Replace MIL-STD-499 with IEEE-1220 and EIA-IS 632·– Interim SE Capability Maturity Model·

• 1996– Draft Commonwealth policy on SE

• 1999– EIA-632, EIA 731

of 23

What is a System?

– A system is a construct or collection of interrelated elements, attributes and relationships that together produce outputs not obtainable by the elements alone.

– The outputs include system level qualities, properties, characteristics, functions, behavior and performance.

Example: Air Traffic Control System

of 23

Data comms.system

Transpondersystem

Radarsystem

Aircraftcomms.

Telephonesystem

Flight plandatabase

Backupposition

processor

Positionprocessor

Comms.processor

Backup comms.processor

Aircraftsimulation

system

Weather mapsystem

Accountingsystem

Controllerinfo. system

Controllerconsoles

Activity loggingsystem

Figure: ATC system architecture

S ystem Elements

• System is composed of elements that satisfy one or more requirements.• System Elements

– People• Personnel

– Products• Hardware • Software• Facilities• Data• Materials

– Processes• Services• Techniques

of 23

Figure: System

Example: A News System’s Elements

CNN news system may include the following

Products:• cameras, monitors (hardware)• schedule management tools, video compression algorithms (software)• studio, broadcasting tower (facilities)• script, program guide (data)• video, pictures, stories (materials)

People:• camera operators, news anchor (personnel)

Processes:• transportation of reporters to the scene, telephone (services)• presentation method, editing procedures (techniques)

of 23

Figure: CNN news system

S ystem Lifecycle

The period extending from inception of development activities, based on an identified need or objective, through decommissioning and disposal of the system.

There is no single life cycle model. The system life cycle is different for different industries, products and customers.

of 23

Systems Approach to Problems

• Understand and define the problem before attempting to solve it as a system• Identify the system boundaries, inputs and outputs to a system• Decompose the system to lower levels (subsystems) with more detail• Understand the functions that the systems perform to convert inputs to outputs • Identify and rank all possible solutions prior to selecting an answer• Looking for hybrid solutions to add to the set of alternatives• Select a solution, capture the analysis and formulate the subsequent problem or

implementation of the solution

What is Systems Engineering?

Systems engineering is a robust approach to the design, creation, and operation of systems.

The approach consists of:

• identification and quantification of system goals • creation of alternative system design concepts • performance of design trades• selection and implementation of the best design • verification that the design is properly built and integrated, and• assessment of how well the system meets the goals

This approach is iterative, with several increases in the resolution of the system baselines (which contain requirements, design details, verification plans and cost and performance estimates).

What System Engineering includes ?

• Integrates all the disciplines and specialty groups into a team effort forming a structured development process that proceeds from concept to production to operation.

• Structured technical management and control process used in the design, development, production and operation of large-scale complex systems.

• Interdisciplinary approach and means to enable the realization of successful systems.

• Defining customer needs and required functionality early in the development cycle, documenting requirements, then proceeding with design synthesis and system validation.

• System Engineering considers both the business and the technical needs of all customers with the goal of providing a quality product that meets the user needs.

of 23

Motivation for Systems Engineering:

There is tremendous potential for wasted effort on large projects, since their development requires that many subsystems be developed in parallel.

Without a clear understanding of what must be done for each subsystem the development team runs the risk of inconsistent designs, conflicting interfaces or duplication of effort.

Systems engineering provides a systematic, disciplined approach to defining, for each member of the development team, which must be done for success.

Function of System Engineering:

The systems engineering process is a top-down, comprehensive, and iterative problem-solving process, applied through all stages of development that is used to:

Transform needs and requirements into a set of system product and process descriptions (adding value and more detail with each level of development)

Generate information for decision makers, and Provide input for the next level of development. To guide the engineering of complex systems.

Focus of Systems Engineering

Need– What needs are we trying to fill?– What is wrong with the current situation?– Is the need clearly articulated?

Operations Concept– Who are the intended users?– How will they use our products?– How is this different from the present?

Functional Requirements– What specific capability will we provide?– To what level of detail?– Are element interfaces well defined?

System Architecture– What is the overall plan of attack?– What elements make up the overall approach?– Are these complete, logical, and consistent?

of 23

Allocated Requirements– Which elements address which requirements?– Is the allocation appropriate?– Are there any unnecessary requirements?

Detailed Design– Are the details correct?– Do they meet the requirements?– Are the interfaces satisfied?

Implementation– Will the solution be satisfactory in terms

of cost and schedule?– Can we reuse existing pieces?

Test & Verification– What is our evidence of success?– Will the customer be happy?– Will the users’ needs be met?

Main Principles of Systems Engineering

Another paradox of Systems Engineering is that there is no perfect or unique SE process, but there are common elements – the fundamentals of Systems Engineering

Systems Engineer ’s Responsibilities

of 23

Activities

• Analyze and specify system requirements• Define system operational concept• Define system external interfaces• Define system and subsystem architecture

– Allocate performance requirements– Model system performance

• Perform design trade studies• Develop system and subsystem design• Define system test requirements• Manage system technical baseline• Support design/development and I&T• Orchestrate specialty engineering support• Integrate technical discipline processes• Ensure system acceptability/usability

Contract Deliverable Items

• Operational Concept• Systems Engineering Management Plan• System and segment specifications• Software Requirements Specifications• Subsystem Requirements Specifications• Trade Study Reports• Systems Requirements Review (SRR)• System Design Review (SDR)• System Design Description (SDD)• Software Specification Review (SSR)• Preliminary Design Review (PDR)• Plans (training, test, deployment)• Performance requirements allocation• User manuals• Other data deliverable items

of 23

The “Vee” Model of System Development

Systems Engineering Contributions

Systems engineering brings two elements to a project that are not usually present

– A disciplined focus on the • end product , • its enabling products, and • its internal and external operational environment

(i.e., a System View)

– A consistent vision of stakeholders’ expectations independent of daily project demands (i.e., the System’s Purpose)

Building Blocks of Systems Engineering

of 23

• Math & Physical Sciences

– Qualitative modeling– Quantitative modeling– Physical modeling– Theory of Constraints– Physical Laws

• Management Sciences

– Economics– Organizational Design– Business Decision Analysis– Operations Research

• Social Sciences

– Multi-disciplinary Teamwork– Organizational Behavior– Leadership

• Body of Knowledge

– Problem definition• Concept of operations• System boundaries• Objectives hierarchy• Originating requirements

– Concurrent engineering• System life cycle phases• Integration/Qualification

– Architectures• Functional/Logical• Physical/Operational• Interface

– Trades• Concept-level• Risk management• Key performance parameters

Ethical Considerations

of 23

Achieving balance between inherent conflicts

– System Functionality and Performance– Development Cost and Recurring Cost– Development Schedule

(Time to Market)– Development Risk (Probability of Success)– Business Viability and Success

System Optimization

– Subsystems often suboptimal to achieve best balance at system level– Ultimate system purpose must prevail against conflicting considerations– Long-term considerations (e.g., disposal) may drive technical decisions

• Customer Interface

– Often must act as “honest broker” – Carries burden of educating

customer on hard choices– Must think ahead to the next

customer and next application– Must “challenge” all requirements

Two Perspectives on System Engineering

• SE is a way of thinking

– Practiced by senior engineers with OJT– Is unique to the product/industry of the engineering firm– Should be taught within other engineering disciplines– Scientific foundations and body of knowledge have commonality across

product/industry but are not unique to SE– SE team has engineers of all disciplines

• SE is a discipline of engineering

– Has scientific foundations that cross many other engineering disciplines– Has body of knowledge separate from other disciplines– Can be taught separately from other disciplines in an engineering school– Separate roles exist on the SE team for a specific product

Definition of Stakeholder

of 23

• The stakeholders include all the people, organizations and institutions that are a part of the system environment because the system provides some benefit to them and they have an interest in the system. This includes end users, operators, bill payers, owners, regulatory agencies, victims, sponsors, maintainers, architects, managers, customers, etc.

• Example: Definition of Stakeholder for Boeing 777– Users: passengers that fly on the airplane – Operators: fight crews and mechanics– Bill payers: airline companies– Owners: stockholders of these companies – Regulators: FAA– Victims: people living near the airports and competing manufactures– Sponsor: corporate headquarters

The 17 Common Technical Processes to Manage the Technical Aspect of the Project Life Cycle - NASA Model

There are three sets of common technical processes in NASA Systems Engineering Processes and Requirements: system design, product realization, and technical management. The processes in each set and their interactions and flows are illustrated by the NPR (NASA Systems Engineering Processes and Requirements) systems engineering “engine” shown in Figure.

The processes of the SE (System Engineering) engine are used to develop and realize the end products. Steps 1 through 9 indicated in Figure represent the tasks in execution of a project. Steps 10 through 17 are crosscutting tools for carrying out the processes.

of 23

Figure: The System Engineering Engine

System Design Processes

Purpose: The four processes in this group are used to define and baseline stakeholder expectations, generate and baseline technical requirements, and convert the technical requirements into a design solution that will satisfy the baselined stakeholder expectations.

1. Stakeholder Expectation Definition2. Technical Requirements Definition3. Logical Decomposition4. Design Solution Definition

of 23

Stakeholder Expectation Definition

• The Stakeholder Expectation Definition Process is used to:– Elicit and define use cases, scenarios, operational concepts, and stakeholder

expectations– This includes requirements for such things as:

• Operational products• Expected skills and capabilities of operators and users• Expected number of simultaneous users• System and human performance criteria• Technical Authority, standards, regulations, and laws• Factors such as safety, quality, security, reliability, availability,

maintainability, electromagnetic compatibility, interoperability, testability, transportability, supportability, usability, and disposability

• Local management constraints on how work will be done (e.g. operating procedures)

• The baselined stakeholder expectations are used for validation of the system during product realization.

Technical Requirements Definition

The Technical Requirements Definition Process is used to transform the baselined stakeholder expectations into unique, quantitative, and measurable technical requirements expressed as “shall” statements that can be used for defining a design solution for the system.

Logical Decomposition

The Logical Decomposition Process is used to:– Improve understanding of the defined technical requirements and the

relationships among the requirements (e.g. functional, behavioral, and temporal)

– Transform the defined set of technical requirements into a set of logical decomposition models and their associated set of derived technical requirements for input into the Design Solution Definition Process

Design Solution Definition

of 23

• The Design Solution Definition Process is used to translate the outputs of the Logical Decomposition Process into a design solution definition.

• This includes:– Transforming the defined logical decomposition models and their associated

set of derived technical requirements into alternative solutions– Analyzing each alternative to be able to select the preferred alternative– Fully defining the selected alternative into a design solution definition that

will satisfy the technical requirements• The design solution definition will be used for:

– Generating end products either by using the Product Implementation Process or the Product Integration Process as a function of the position of the WBS model in the system structure and whether there are additional subsystems that need to be defined

• The output end product design solution definition will be used for conducting product verification

– Design Solution Outputs

– The output of the design solution process is the descriptive documentation for buying, building, coding or assembling & integrating end products.

– The specific documentation is a function of life-cycle phase and location of the model in the system product breakdown structure (PBS)

– This documentation is in the form of specifications, drawings, sketches, parts list, etc.

– Documentation includes initial specifications for subsystems for development of the next lower level PBS models

Technical Management Processes

Purpose: The Technical Management Processes are used to establish and evolve technical plans for the project, to manage communication across interfaces, to assess progress against the plans and requirements for the system products or services, to control technical execution of the project through to completion, and to aid in the decision making process.10. Technical Planning Technical Control11. Requirements Management12. Interface Management13. Technical Risk Management14. Configuration Management

of 23

15. Technical Data Management16. Technical Assessment17. Decision Analysis

Technical Planning

• The technical planning process is used to:– Identify, define, and plan the technical effort – Plan for the application and management of each common technical

process • A key document generated by this process is the SEMP(Systems Engineering

Management Plan).

Requirements Management

• The requirements management process is used to:– Manage the requirements identified, baselined, and used in the definition of

the system design– Provide bidirectional traceability back to the top system requirements; and– Manage the changes to established requirement baselines over the life cycle

of the system

Interface Management

• The interface management process is used to:– Establish and use formal interface management to assist in controlling

system product development efforts– Maintain interface definition and compliance among the end products and

enabling products that compose the system as well as with other systems with which the end products and enabling products must interoperate

– Interface Control Document (ICD) defines and controls the detailed interface between two or more system elements or configuration items.

– Interface Working Groups (IWGs) establish communications between those parties responsible for interface activities.

Technical Risk Management

of 23

• The technical risk management process is used to: – Examine on a continuing basis the risks of technical deviations from the

project plan – Identify potential technical problems before they occur so that risk-

mitigation activities can be planned and invoked as needed• Methods for identifying potential failure modes are:

– Failure Modes, Effects, and Criticality Analysis (FMECA)– Fault Tree Analysis

Probability Risk Management

• Probability Risk Assessment (PRA) is a risk assessment technique that quantifies the likelihood of various possible undesired scenarios and their consequences, as well as the uncertainties in the likelihoods and consequences.

• A risk matrix is a means of managing and communicating risk.

Configuration Management

• The configuration management process for end products, enabling products, and other work products placed under configuration control is used to:

– Identify the configuration of the product or work product at various points in time;

– Systematically control changes to the configuration of the product or work product;

– Maintain the integrity and traceability of the configuration of the product or work product throughout its life; and

– Preserve the records of the product or end product configuration throughout its life cycle

of 23

Technical Data Management

• The technical data management process is used to:– Provide the basis for identifying and controlling data requirements– Collect, store and distribute required technical data– Manage the databases to maintain proper data quality and integrity– Confirm that the technical data is secure and is available to those with

authority to have access– Provide access and availability to an information library

Technical Assessment

• The technical assessment process is used to help monitor progress of the technical effort and provide status information for support of the system design, product realization and technical management processes.

• Methods include:• Reviews, Audits and Key Decision Points• Measures of Performance

Decision Analysis

• The decision analysis process is used to evaluate uncertainties in support of decision making involving technical decision issues and technical alternatives.

• The decision analysis process includes the collection of data, such as engineering performance data, quality data and reliability data.

• Decision analysis is used throughout all the common technical processes to evaluate the impact of decisions on performance, cost, schedule and technical risk.

• Typical evaluation methods include influence diagrams, decision trees, Multi-Criteria Decision Analysis (MCDA), and Analytic Hierarchy Process (AHP)

Product Realization Processes

Purpose: The five processes in this group are used to realize the design solution for each end product and to verify, validate, and transition products that satisfy their design solutions and meet stakeholder expectations as a function of the applicable life cycle phase

1. Product Implementation2. Product Integration3. Product Verification4. Product Validation5. Product Transition

Product Implementation

of 23

• The product implementation process is used to generate an end product through – buying – making or – reusing

• Regardless of the source the realized product must satisfy the design solution definition specified requirements (e.g., drawings, specifications)

Product Integration

The product integration process is used to transform the design solution definition into the desired end product through assembly and integration of lower level validated end products in a manner that satisfies the design solution definition requirements (e.g., drawings, specifications)

Product Verification

• The product verification process is used to demonstrate that an end product generated from product implementation or product integration conforms to its design solution definition requirements.

• “Did I build the system right?” • Product verification can be accomplished by test, analysis, demonstration or

inspection.

Product Validation

• The product validation process is used to confirm that a verified end product fulfills (satisfies) its intended use when placed in its intended environment.

• Validation is done against the set of baselined stakeholder expectations.• “Did I build the right system?”• Product verification can be accomplished by test, analysis, demonstration or

inspection. • The type of product validation is a function of the form of the product, product-line

life-cycle phase and applicable customer agreements• Any anomalies discovered during validation must be appropriately resolved prior to

delivery of the product or prior to integration with other products into a higher level assembled product.

Product Transition

• The product transition process is used to transition to the customer at the next level in the system structure a verified and validated end product that has been generated by product implementation or product integration for integration into an end product.

• For the top level end product, the transition is to the intended end user

of 23

• Planning for transition includes preparation of packaging, handling, transporting, storing, training or certification activities and operations, and user or installation manuals as appropriate.

Short Question: Why an NPR?

Answer:

NPR stands for NASA Systems Engineering Processes and Requirements

• To establish a core set of common Agency-level technical processes and requirements needed to define, develop, realize, and integrate the quality of the system products created and acquired by or for NASA.

• To build upon and apply best practices and lessons learned from NASA, other government agencies, and industry to clearly delineate a successful model to complete comprehensive technical work, reduce program and project technical risk, and improve mission success.

Example of Using the SE Engine

To help in understanding how the SE engine is applied, an example will be posed and walked through the processes.

Use of the different phases of a life cycle allows the various products of a project to be gradually developed and matured from initial concepts through the fielding of the product and to its final retirement.

During Phase A, the recursive use of the SE engine is continued. During this phase, key areas of high risk might be simulated or prototyped to ensure that the concepts and requirements being developed are good ones and to identify verification and validation tools and techniques that will be needed in later phases.

During Phase B, the SE engine is applied recursively to further mature requirements for all products in the developing product tree, develop ConOps (Concept of Operations) preliminary designs, and perform feasibility analysis of the verification and validation concepts to ensure the designs will likely be able to meet their requirements.

of 23

Phase C again uses the left side of the SE engine to finalize all requirement updates, finalize ConOps, develop the final designs to the lowest level of the product tree, and begin fabrication.

Phase D uses the right side of the SE engine to recursively perform the final implementation, integration, verification, and validation of the end product, and at the final pass, transition the end product to the user.

The technical management processes of the SE engine are used in Phases E and F to monitor performance; control configuration; and make decisions associated with the operations, sustaining engineering, and closeout of the system.

Any new capabilities or upgrades of the existing system would reenter the SE engine as new developments.

Phase Purpose Typical Output

Form

ulat

ion

Pre-Phase A Concept Studies

To produce a broad spectrum of ideas and alternatives for missions from which new programs/projects can be selected. Determine feasibility of desired system, develop mission concepts, draft system-level requirements, and identify potential technology needs.

Feasible system concepts in the form of simulations, analysis, study reports, models, and mockups

Phase A Concept and Technology Development

To determine the feasibility and desirability of a suggested new major system and establish an initial baseline compatibility with NASA’s strategic plans. Develop final mission concept, system-level requirements, and needed system structure technology developments.

System concept definition in the form of simulations, analysis, engineering models, and mockups and trade study definition

Phase B Preliminary Design and Technology Completion

To define the project in enough detail to establish an initial baseline capable of meeting mission needs. Develop system structure end product (and enabling product) requirements and generate a preliminary design for each system structure and product.

End products in the form

of mockups, trade study results, specification and interface documents, and

Impl

emen

tati

on Phase C

Final Design and Fabrication

To complete the detailed design of the system (and its associated subsystems, including its operations systems), fabricate hardware, and code software. Generate final designs for each system structure end product.

End product detailed designs, end product component fabrication, and software development

of 23

Phase D System Assembly, Integration and Test, Launch

To assemble and integrate the products to create the system, meanwhile developing confidence that it will be able to meet the system requirements. Launch and prepare for operations. Perform system end product implementation, assembly, integration and test, and transition to use.

Operations-ready system end product with supporting related enabling products

Phase E Operations and Sustainment

To conduct the mission and meet the initially identified need and maintain support for that need. Implement the mission operations plan.

Desired system

Phase F Closeout

To implement the systems decommissioning/disposal plan developed in Phase E and perform analyses of the returned data and any returned samples.

Product closeout

of 23

System Engineering

Documents

Transcript of System Engineering