system engineering overview

7/29/2019 System Engineering Overview

1/72

illah nourbakhsh | CMURobotics Institute | SysEng

Motivation: The Problem


2/72



I dont understand why it doesnt work.


3/72




This is the first time Im trying it all.


4/72




It worked fine last night.


5/72




My part is fine. Its a problem with anotherpart of the system.


6/72


Our Goal

1 Examine systems from many perspectives

2 Attain system engineering skills

plan, management, analysis, design,

implementation, evaluation, validation


7/72

DavidWettergreen | Systems

Engineering 7

Defining System

Systems can contain subsystems, components,

subcomponents, and parts, each engineered

and complex


8/72

Wettergreen & Nourbakhsh |CMU Robotics Institute |

SysEng

Terms for hierarchy

[Supersystem]

Systems

Subsystems

Components

Subcomponents

Parts


9/72

Wettergreen & Nourbakhsh |CMU Robotics Institute |

SysEng

Terms for hierarchy

[Supersystem]

Systems: perform a service with the aid of human operatorsand standard infrastructures

Subsystems

Components

Subcomponents

Parts


10/72

Wettergreen & Nourbakhsh |

CMU Robotics Institute |

SysEng

Terms for hierarchy

[Supersystem]

Systems

Subsystems: major portion of system that is aclosely related subsetof overall system function

Components

Subcomponents

Parts


11/72



SysEng

Terms for hierarchy

[Supersystem]

Systems

Subsystems

Components: a middle level of system elements

often used in multiples

hah. What does that mean??

Subcomponents

Parts


12/72



SysEng

Terms for hierarchy

[Supersystem]

Systems

Subsystems

Components

Subcomponents:perform elementary functions and are composed ofseveral parts

Parts


13/72



SysEng

Terms for hierarchy

[Supersystem]

Systems

Subsystems

Components

Subcomponents

Parts: no significant function except in combination with otherparts; usually off-the-shelf.


14/72



SysEng

Actors in hierarchy

[Supersystem]

Systems

Subsystems

Componentstop ofindustrial design specialist; floor of systemsengineers knowledge

Subcomponents

Parts


15/72



SysEng

Actors in hierarchy

[Supersystem]

Systems

Subsystems

Componentstop ofindustrial design specialist; floor of systemsengineers knowledge

Subcomponents

Parts

Caveat: systems engineer drills deep for critical issues (e.g.Challenger failure)


16/72

David

Wettergreen | Systems

Engineering 16

Defining Systems Engineering

The function of systems engineering is to

guide the engineering of complex systems

Guide = to lead based on experience

Engineering = application of scientific principles to

practical ends

[Kossiakoff]


17/72

David


Engineering 17

Unique Perspective

Focused on the system as a whole

Concerned with stakeholder needs and

operational environment

Grounded in system conceptual design

Bridges traditional engineering disciplines

Requires qualitative judgments


18/72

David


Engineering 18

Specialization

Complex systems configured of components Each must be specified, developed, tested

Each must interface to the system

Each has unique properties Engineering specialties emerge

Making it fit Standards develop to abstract specialization

Modularity and interchangeable parts, everything mustfit

Somebody needs to make it all fit


19/72

David


Engineering 19

Complex Systems

Automobiles

Aircraft

Spacecraft

Robots

Navigation Equipment

Appliances

Cameras

Industrial Processes

Air Traffic Control

Power Plants

Railroads

Telephone Switching

Network

Communication Stock Exchange


20/72

David


Engineering 20

Embedded Systems

When the computational element exists

within a system to achieve desired

functionality it is said to be embedded

Many systems have computing components

embedded within them (even toasters)


21/72

David


Engineering 21

Complex Real-Time Systems

Properties

Timeliness = meets timing requirements (performance)

Responsiveness = reacts to events

Concurrency = can synchronize multiple activities

Predictability = can accurately model performance

Reliability = responds as required in all known conditions

Robustness = responds safely in unknown conditions


22/72

David


Engineering 22

Timeliness

The system has the ability to respond to some

event, often, but not limited to events that are

external to the system

When the response is timely the system is said

to be reacting in real time

Failure to be timely will result in failure of the

system


23/72

David


Engineering 23

Responsiveness

A system in which the components forprocessing information (data, signals) arrivingare permanently ready so that results will be

available within predetermined periods oftime

[Halang92]


24/72

David


Engineering 24

Concurrency

Real events of the world proceed in parallel.

A concurrent system is one that simultaneously

responses to multiple events (and thus has multiple

chains of action) Concurrency issues:

Scheduling

Arrival patterns

Rendezvous patterns

Shared resources


25/72

David


Engineering 25

Predictability

The extent to which system response

characteristics can be known in advance

Affected by:

Physical environment

System behavior


26/72


27/72

David


Engineering 27

Reliability

A system is reliable when it does the right

thing when predictable events or faults occur

Events - environmental conditions

Faults - anomalous components behavior


28/72


29/72

David


Engineering 29

Best System

Cost

Performance

Acceptable

Desired

60

80

100


30/72

David


Engineering 30

Balanced System

Cost

P

erformance/Cost

1

2

3

Desired Performance

Acceptable Performance


31/72

David


Engineering 31

Balanced Judgment

Multidisciplinary knowledge allows balance

Qualitative judgment comes from experience

Quantitative decisions enabled by approximate

calculations (back of the envelope)

Systems engineers need to be inquisitive


32/72

Wettergreen &

Nourbakhsh | Systems

Engineering 32

Systems Engineering Phases

Concept Development Needs Analysis

Concept Exploration

Concept Definition

Engineering Development Advanced Development

Engineering Design

Integration and Evaluation

Post-Development Production

Operation and Maintenance


33/72


34/72

Wettergreen &


Engineering 34

Use Cases

Actors are things that exist outside of the system

but influence system behavior

Use Case is what is performed by the system

System

BoundaryActor

Use Case Interaction


35/72


36/72

Wettergreen &


Engineering 36

Developing Use Case

For each Use case identify:

Role of actors and system in each scenario

Interactions necessary for the scenario

Sequence of events and data

Possible variations


37/72

Wettergreen &


Engineering 37

Documenting Use Cases

Name - Name for each case Summary - Brief description Dependency - Includes/extends

other use case Actors - Name the actors Preconditions - True at start of use

case Description - Prose narrative of use

case sequence of interactions Alternatives - Narrative of

alternative branches Postcondition - True at end of use

case


38/72

Wettergreen &

Nourbakhsh | SystemsEngineering 38

Use Case - Elevator

Ride

Select Floor

Request

Hold Door

Service

Service Personnel

Passenger

Potential Passenger

Alarm

[Douglass98]


39/72

Wettergreen &


Identifying Scenarios

Scenarios:

Specific instances of use cases

Model order-dependent behavior of objects

Scenarios indicate differing system behaviors

If the behavior in various scenarios the same,

generalize to one scenario


40/72

Wettergreen &


Functional Analysis

What function?and What design?are closely

coupled


41/72

Wettergreen &


Functional Analysis: a recipe

1 Media (signals, data, material, energy)

2 Elements (electronic, electro-optical,

electromechanical, mechanical, thermomechanical,

software)


42/72

Wettergreen &


Functional Analysis: a recipe

1 Media (signals, data, material, energy)

2 Elements (software, networking, firmware,

embedded h/w, computers, sensors, actuators,

other) 3 Performance requirements to elements

4 Configuration

5 Analysis & integration with outside world


43/72

Wettergreen &


Hardware / Software allocation

A lesson on an important tradeoff

Build a balancing robot that has a human aspect ratio

or narrower


44/72

Wettergreen &



Credit TRI: Ben Brown, Illah Nourbakhsh


45/72

Wettergreen &



Credit TRI: Garth Zeglin, Ben Brown


46/72

Wettergreen &


Concept Selection Strategy

1 Start w/ predecessor system, if it exists

2 Consider enough alternatives early

3 Winnow out outliers

4 Play a pro/con game with lots of numbers


47/72


48/72

Concept Validation Strategy

1 Design the right critical experiments

2 Run the experiments!

3 Iterate on as much as needed


49/72

Wettergreen & Nourbakhsh | Systems Engineering 49

Whole System Integration & Evaluation

Where dreams and reality diverge


50/72


51/72


52/72


Stages

1. Test Planning & Preparation

2. System Integration

3. Developmental System Testing

4. Operational Test and Evaluation


53/72


Stages

1. Test Planning & PreparationFirst review unforeseen changes: requirements, technologies

Test and Evaluation Master Plan (TEMP) DoD programs

This step mirrors System Development:

System Concept Test ConceptFunctional Design Test Plan

Detailed Design Test Procedures





54/72


Stages


Operational Environment Demo considerations early phases: developer tests system

late phases: customer or test agent does testing,no bias





55/72


Stages


2. System Integration Proceeds linearly, adding a couple of components at a time

Add subsystems intelligently to avoid complex input generators Therefore, start with components that have external inputs

Hard part: matching subsystem outputs to expected values

how do we determine realistic expectations?




56/72


Stages


2. System Integration Common Problem: the error is in error!

3. Developmental System Testing4. Operational Test and Evaluation


57/72


Student Exercise 1

System Integration: for yourproject, list the order in which

you ought to test and add components or subsystems to the

system, two or so at a time. Explain where the inputs will

come from during testing of each added pair or so of

components.


58/72


Stages



3. Developmental System Testing: the First Time Entire-system testing for performance vis a vis specifications

Also use this as a last-ditch chance to check against user needs

The customer often doesnt know what they need

Specify test conditions as completely as possible

Generate and use many test scenarios



59/72


Stages



3. Developmental System Testing Dealing with Discrepancies

1: Is it really broken consistently? Try again.

2: Is it really a problem? Think.

3: How do we fix it.

4: How comprehensively must we test the fix?

The law of unintended consequences can bite!



60/72


Student Exercise 2

Development System Testing: for yourproject, imagine the

first whole-system prototype. Just how will you test it what

*suite* of test scenarios will you try? How will you measure

its performance?


61/72


Stages




4. Operational Test and Evaluation Validation of system design to operational requirements

NOT verification of system performance wrt specifications

(huh?)


62/72


Stages




4. Operational Test and Evaluation Validation of system design to operational requirements

NOT verification of system performance wrt specifications

(huh?)

Translation: the customer takes the system for a test drive and makes sure that,

operationally, the system does what he/she needs. (the specs could be wrong, andnow it doesnt matter any longer)


63/72


Stages




4. Operational Test and Evaluation Key areas of testing:

User interface (interface usability)

Environmental testing


64/72


Stages




4. Operational Test and Evaluation Test Plan (part of TEMP)

- directions for conducting the operational test

- critical operation issues to be examined; metrics

- how much testing is enough? answer this question


65/72


Design to Minimize Failure

1. Minimalist Design: KISS

Toys: Furby

PPRK


66/72




Toys: Furby

PPRK

2. Minimize weight

Space Shuttle


67/72




Toys: Furby

PPRK

2. Minimize weight

Space Shuttle

3. Maximize ease of replacement / repair

The mighty razor

PER servoes


68/72



Chassis / Housing

4. Minimize body stress

Trikebot

5. Minimize fatigue

DLP Projectors


69/72



Mechanical / Kinematic

6. Capture every nut/bolt/screw (Loctite, wire, etc.)

Robinson R-22 helicopter

7. Joints: minimize number, service

maximize strength, expected life


70/72



Electrical

8.Minimize connectors Nomad Scout ground short

9. Minimize wires

Fatigue results on PER IR wires

10. RF and Magnetics Aviary Raven story


71/72



Computational

11. Minimize number of processors

USAR robot

12. Avoid operating systems The Trikebot II story

13. Write damn good code & characterize it

- Memory and time profiling

- Memory leak duty testing


72/72

What Not to Do

1 Never fix the same thing twice.

2 Dont assume single point of failure.

3 Never use a connector / crimp design without extensive testing.

4 Do not trust theoretical dynamics calculations.

5 Never leave out a diagnostic port. 6 Never check in code without cleanly recompiling.

7 Never malloc unnecessarily. Neverforkunnecessarily.

8 Never assume the world is kind (your robot will get kicked).

9 Never live withfeature creep.

system engineering overview

Documents