Introduction to Complex System Engineering

Emmanuel FUCHS

Slides available soon at www.elfuchs.fr

Information Systems

ComplexSystem Examples

System ProblemsExamples

System Problems Examples

System definition (Eberhardt Rechtin 1926-2006)

• A system is a construct or collection of different elements that together produce results not obtainable by the elements alone.

• The elements, or parts, can include people, hardware, software, facilities, policies, and documents; that is, all things required to produce systems-level results.

• The results include system level qualities, properties, characteristics, functions, behavior and performance.

• The value added by the system as a whole, beyond that contributed independently by the parts, is primarily created by the relationship among the parts; that is, how they are interconnected.

Systemic

The whole is greater than the sum of the parts;

The part is greater than a fraction of the whole.Aristotle

System: another definition

• A system is any set (group) of interdependent or temporally interacting parts.

• Parts are generally systems themselves and are composed of other parts, just as systems are generally parts of other systems.

System Definition

SubSystem

SubSystem

SubSystem

SystemUsers

Mission

EnvironmentStakeholders

Border

System Meta Model

From INCOSE

SE Bodies

• http://www.afis.fr/– Association Française d'Ingénierie Système

• http://www.incose.org/– International Council on Systems Engineering

(INCOSE)

System Engineering Definition

“an interdisciplinary approach encompassing the entire technical effort to evolve and verify an integrated and balanced set of system, people, product, and process solutions that satisfy customer needs…..”

System Engineering (SE)

• SE focuses on defining customer needs and required functionality early in the development cycle, documenting requirements, then proceeding with design synthesis and system validation while considering the complete problem

• Systems engineers deal with abstract systems, and rely on other engineering disciplines to design and deliver the tangible products that are the realization of those systems.

• Systems engineering effort spans the whole system lifecycle.

Systemic Approach

• One + One > two

• Aristotle : The whole is more than the sum of its parts.– Parts (Components)– Connections

System Engineering Meta Model

From INCOSE

System engineer/architect

• Works with system abstraction.– It is impossible to master everything

• Requirements Management

• System Model

Design the right system

Design the right system

As proposed bythe project sponsor

Design the right system

As proposed bythe project sponsor

As specified in the project request

Design the right system

As proposed bythe project sponsor

As specified in the project request

As designed bythe project analyst

Design the right system

As proposed bythe project sponsor

As proposed by the programmers

As specified in the project request

As designed bythe project analyst

Design the right system

As proposed bythe project sponsor

As proposed by the programmers

As specified in the project request

As designed bythe project analyst

As installed at the users’ site

Design the right system

As proposed bythe project sponsor

As proposed by the programmers

As specified in the project request

As designed bythe project analyst

As installed at the users’ site

What the customer really want

Process Definition

• Set of interrelated of interacting activities which transforms inputs to outputs

P

Inputs Outputs

A Process

Process: V cycle

Sequential V cycle drawbacks

DocumentationAnd mock-up

Phase

Sequential V cycle drawbacks

DocumentationAnd mock-up

Phase

Iterative and Incremental

Incremental

Iterative

Barry W. Boehm

Iterative and Incremental

• The Systems Engineering Process is not sequential. It is parallel and iterative.

• The complex interrelationship between creating and improving models throughout the process of developing and selecting alternatives is a good example of the dynamic nature of the systems engineering process.

Process Standardization

• NASA• DOD (US Departement Of Defense):

– Documentation Model

• IEEE• ISO (International Organization for

Standardization) • IEC (International Electrotechnical Committee).

– ISO/IEC 15504 / SPICE (Software Process Improvement and Capability dEtermination)

• SEI (Software Engineering Institute)

Capability Maturity Model - Integration

• CMMI defines the essential elements of effective processes for engineering disciplines based on best industry experiences.

• CMMI models provide guidance when developing and evaluating processes.

• CMMI models are not actually processes or process descriptions.

CMMI Maturity Levels

Level Identified as Status

5 optimizing focus on process improvement

4quantitatively managed process measured and controlled

3 definedprocess characterized for the organization and is proactive

2 managedprocess characterized by projects and often reactive

1 initialprocess uncontrolled poorly managed and reactive

Process Documentation and Review

• SSS: System/Segment Specification • SSDD : System/Segment Design Document • IRS : Interface Requirement Specification• ICD : Interface Control Definition

• SRR : System Requirement Review• SDR : System Design Review• TRR : Test Readiness Review

Process Activities

What is a requirement ?

• A requirement is a condition to be satisfied in order to respond to:– A contract– A standard– A specification – Any other document and / or model imposed.

Requirements

• User’s Requirements– Statements in natural language of the system

services.– Described by the user

• System Requirements– Structured document setting out detailed

description of system services. – Part of the contract

User’s Requirements example

• A customer must be able to abort a transaction in progress by pressing the Cancel key instead of responding to a request from the machine.

• The washing machine will be used in the following countries: UK, USA, Europe, Eastern Europe

Process

System Requirements

• The System shall provide ........ • The System shall be capable of ........ • The System shall weigh ........ • The Subsystem #1 shall provide ........ • The Subsystem #2 shall interface with .....

Requirement Quality

• A good requirement states something that is necessary, verifiable, and attainable

• To be verifiable, the requirement must state something that can be verified by:– analysis, inspection, test, or demonstration

(AIDT)

Requirement analysis

• User Requirement– Minimum levels of noise and vibration

are desirable.

• System Requirement– Requirement 03320: The noise

generated shall not exceed 60 db

Requirement Types

• Functional requirements– Functional requirements capture the intended

behavior of the system. – This behavior may be expressed as services,

tasks or functions the system is required to perform

• Non-Functional requirements– All others

• Constraints

Process

System Architecture

• The System Architecture identifies all the products (including enabling products) that are necessary to support the system and, by implication, the processes necessary for development, production/construction, deployment, operations, support, disposal, training, and verification

Architecture Modeling

• System : Abstraction– Functional model– Dynamic model– Semantic Model– Object model– Physical Model– Interfaces Model

• Model Views

Architecture Meta Model

From IEEE

Architecture and Components Assembly

Example of Architecture Views

• The Functional Architecture – identifies and structures the allocated

functional and performance requirements.

• The Physical Architecture– depicts the system product by showing how it

is broken down into subsystems and components

Functional To Physical Model

• Functional : Discover the system functions

• Washing Machine– What it does ?

• Washes

– How it does ?• Agitates

– Physical Component : Agitator

Functional VS physical Model

• How to fly ?

• Look at birds: Physical Model• So I need: Legs, Eyes, Brain, and Wings.• But I can not fly !!!

• Why ?• I have to find the flight functional model !

Flying functional model

• Functional decomposition of flying function:– Produce horizontal thrust,– Produce vertical lift. – Takeoff and land, – Sense position and velocity, – Navigate,

Example Birds physical for flying

• Physical decomposition: – physical components that birds used to fly:

Legs, Eyes, Brain, and Wings.

• But can not be applied to system directly

Function Airplane Physical

Component Bird Physical

Component

Takeoff and land Wheels, Legs

Sense position and velocity Vision or radar Eyes

Navigate Brain or computer Brain

Produce horizontal thrust Propeller or jet Wings

Produce vertical lift Wings Wings

Bird and Airplane Functional to Physical architecture

Multi-criteria decision

Trade Off

• Multi-criteria decision-aiding techniques are available to help discover the preferred alternatives.

• This analysis should be repeated, as better data becomes available.

Washing Machine example

Context Diagram

Washing Machine Functional Breakdown

Washing Machine Data Flows

Washing Machine Physical Model

agitator

tube

draining

hand-operated washer

plungers

Washing Machine Physical Modelagitator

Outer tube

draining

top loading

US

Washing Machine Physical Model

top loading

Washing Machine Physical Model

agitator

Outer tube

draining

Inner tube = drum

front loading

Europe

Washing Machine Physical Model

front loading

Washing Machine Physical Model

front loading

Process

Integration

• Integration means bringing things together so they work as a whole.

Spaghetti Plate Syndrome

Spaghetti Plate Syndrome

Spaghetti Plate Syndrome

Spaghetti Plate Syndrome

Spaghetti Plate Syndrome

Spaghetti Plate Syndrome

Spaghetti Plate Syndrome

Spaghetti Plate

Spaghetti Plate Syndrome

Spaghetti Plate

System Architect

Spaghetti Plate Syndrome

Spaghetti Plate

System Architect System Integrator

Encapsulation Analogy

Implementation Interface

A driver doesn't care of engine's internal working.He only knows the interface

Process

IVVQCA

• Integrate : – Build the system

• Verification : – Ensures that you built it right

• Validation : – Ensures that you built the right thing

• Certification : – Ensure that the system is safe

• Acceptance : – Ensures that the customer gets what he wants and

the company get paid.

Ensure that the system is safe

Conclusion

Thank You For Your Attention

Questions are welcome

Contacts : emmanuel.fuchs@thalesraytheon-fr.com

Slides Available soon at www.elfuchs.fr