System Engineering Overview

Motivation: The Problem
illah nourbakhsh | CMU Robotics Institute | SysEng

I dont understand why it doesnt work.

I dont understand why it doesnt work. This is the first time Im trying it all.

I dont understand why it doesnt work. It worked fine last night.

I dont understand why it doesnt work. My part is fine. Its a problem with another part of the system.
Our Goal
1 Examine systems from many perspectives 2 Attain system engineering skills
plan, management, analysis, design, implementation, evaluation, validation
Defining System
Systems can contain subsystems, components, subcomponents, and parts, each engineered and complex
David Wettergreen | Systems Engineering 7
Terms for hierarchy

[Supersystem] Systems
Subsystems
Components
Subcomponents Parts
Wettergreen & Nourbakhsh | CMU Robotics Institute | SysEng
Terms for hierarchy

[Supersystem] Systems: perform a service with the aid of human operators
and standard infrastructures
Subsystems
Components
Subcomponents Parts
Terms for hierarchy

Subsystems: major portion of system that is a closely related subset
of overall system function
Components
Subcomponents Parts
Terms for hierarchy

Subsystems
Components: a middle level of system elements
often used in multiples hah. What does that mean?? Subcomponents Parts
Terms for hierarchy

Subsystems
Components
Subcomponents: perform elementary functions and are composed of
several parts
Parts
Terms for hierarchy

Subsystems
Components
Subcomponents Parts: no significant function except in combination with other
parts; usually off-the-shelf.
Actors in hierarchy
Subsystems
Components top of industrial design specialist; floor of systems
engineers knowledge Subcomponents Parts
Actors in hierarchy
Subsystems
Components top of industrial design specialist; floor of systems
engineers knowledge Subcomponents Parts
Caveat: systems engineer drills deep for critical issues (e.g. Challenger failure)
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]
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
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 must fit Somebody needs to make it all fit
Complex Systems
Automobiles Aircraft Spacecraft Robots Navigation Equipment Appliances Cameras Industrial Processes Air Traffic Control Power Plants Railroads Telephone Switching Network Communication Stock Exchange
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)
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
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
Responsiveness
A system in which the components for processing information (data, signals) arriving are permanently ready so that results will be available within predetermined periods of time
[Halang92]
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
Predictability
The extent to which system response characteristics can be known in advance Affected by: Physical environment System behavior
Correctness
In real-time systems the correctness of the system depends not only on the logical result of the computation but also on the time at which the results are produced.
[Stankovic88]
A system is correct when it does the right thing all the time.
Reliability
A system is reliable when it does the right thing when predictable events or faults occur
Events - environmental conditions Faults - anomalous components behavior
Robustness
A system is robust when it does the right thing when faults and errors occur (and novel circumstances are encountered).
Faults - system components fail Error - design flaws
Best System
100 80 Performance 60 Desired Acceptable
Cost
Balanced System
3
Acceptable Performance
Performance/Cost
Desired Performance
Cost
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
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
Wettergreen & Nourbakhsh | Systems Engineering 32
Use Cases
A use case diagram shows the general cases of interaction between the system and external objects Use case diagrams capture a broad view of the primary functionality of a system in a manner that is easily understood by a non-technical audience
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 Actor Boundary

Use Case
Interaction
Developing Use Cases

Typical approach to developing Use Cases is iterative and interactive
1. 2. 3. 4. 5. Identify system behaviors Identify the actors Generalize the common behaviors into use cases Identify relationships between actors and use cases Start running through actors and system behaviors and capture what things the system should do when they interact 6. Add new use cases and relationships as needed
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
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
Use Case - Elevator

Passenger Ride
Select Floor
Hold Door Service Personnel Alarm Potential Passenger Request Service [Douglass98]
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
Functional Analysis
What function? and What design? are closely coupled
Functional Analysis: a recipe

1 Media (signals, data, material, energy) 2 Elements (electronic, electro-optical, electromechanical, mechanical, thermomechanical, software)
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
Hardware / Software allocation

A lesson on an important tradeoff Build a balancing robot that has a human aspect ratio or narrower

Credit TRI: Ben Brown, Illah Nourbakhsh

Credit TRI: Garth Zeglin, Ben Brown
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
Concept Validation Strategy

1 Design the right critical experiments 2 Run the experiments! 3 Iterate on as much as needed
Whole System Integration & Evaluation
Where dreams and reality diverge
Wettergreen & Nourbakhsh | Systems Engineering
49
Activities & Roles

System Engineering What do we need to test?
How do we evaluate test results?
Design Engineering What test equipment do we need to buy/build? Test Engineering Lets conduct the test
Lets analyze the resulting data
50
Scope of testing
System Real operational environment demonstration
Simulated environment compliance Integration facility first whole-system check
Subsystem Component
Test and integrate pieces in small groups
51
Stages
1. 2. 3. 4.
Test Planning & Preparation System Integration Developmental System Testing Operational Test and Evaluation
52
Stages
1. Test Planning & Preparation
First review unforeseen changes: requirements, technologies Test and Evaluation Master Plan (TEMP) DoD programs This step mirrors System Development:
System Concept <-> Test Concept Functional Design <-> Test Plan Detailed Design <-> Test Procedures
2. System Integration 3. Developmental System Testing 4. Operational Test and Evaluation
Stages
1. Test Planning & Preparation Operational Environment Demo considerations
no bias early phases: developer tests system late phases: customer or test agent does testing,
1. System Integration 2. Developmental System Testing 3. Operational Test and Evaluation
54
Stages
1. Test Planning & Preparation 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?
3. Developmental System Testing 4. Operational Test and Evaluation
Stages
1. Test Planning & Preparation 2. System Integration
Common Problem: the error is in error!
3. Developmental System Testing 4. Operational Test and Evaluation
56
Student Exercise 1
System Integration: for your project, 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.
57
Stages
1. Test Planning & Preparation 2. System Integration 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
4. Operational Test and Evaluation
Stages
1. Test Planning & Preparation 2. System Integration 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!
4. Operational Test and Evaluation
Student Exercise 2
Development System Testing: for your project, 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?
60
Stages
1. 2. 3. 4. Test Planning & Preparation System Integration Developmental System Testing Operational Test and Evaluation
Validation of system design to operational requirements NOT verification of system performance wrt specifications (huh?)
61
Stages
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, and now it doesnt matter any longer)
Stages
Key areas of testing: User interface (interface usability) Environmental testing
63
Stages
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
64
Design to Minimize Failure

1. Minimalist Design: KISS Toys: Furby
PPRK
65

PPRK
2. Minimize weight Space Shuttle
66

PPRK
2. Minimize weight Space Shuttle 3. Maximize ease of replacement / repair

The mighty razor PER servoes

Chassis / Housing
4. Minimize body stress
Trikebot
5. Minimize fatigue
DLP Projectors
68

Mechanical / Kinematic
6. Capture every nut/bolt/screw (Loctite, wire, etc.)
Robinson R-22 helicopter
7. Joints:
minimize number, service maximize strength, expected life
69

Electrical 8. Minimize connectors
Nomad Scout ground short
9. Minimize wires
Fatigue results on PER IR wires
10. RF and Magnetics

Aviary Raven story

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
71
What Not to Do
1 2 3 4 5 6 7 8 9 Never fix the same thing twice. Dont assume single point of failure. Never use a connector / crimp design without extensive testing. Do not trust theoretical dynamics calculations. Never leave out a diagnostic port. Never check in code without cleanly recompiling. Never malloc unnecessarily. Never fork unnecessarily. Never assume the world is kind (your robot will get kicked). Never live with feature creep.
72

System Engineering Overview

Uploaded by

Document Information

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

System Engineering Overview

Uploaded by

Copyright:

Available Formats

Motivation: The Problem

illah nourbakhsh | CMU Robotics Institute | SysEng

Motivation: The Problem

illah nourbakhsh | CMU Robotics Institute | SysEng

Motivation: The Problem

illah nourbakhsh | CMU Robotics Institute | SysEng

Motivation: The Problem

illah nourbakhsh | CMU Robotics Institute | SysEng

Motivation: The Problem

illah nourbakhsh | CMU Robotics Institute | SysEng

illah nourbakhsh | CMU Robotics Institute | SysEng

David Wettergreen | Systems Engineering 7

Terms for hierarchy

Wettergreen & Nourbakhsh | CMU Robotics Institute | SysEng

Terms for hierarchy

Wettergreen & Nourbakhsh | CMU Robotics Institute | SysEng

Terms for hierarchy

Wettergreen & Nourbakhsh | CMU Robotics Institute | SysEng

Terms for hierarchy

Wettergreen & Nourbakhsh | CMU Robotics Institute | SysEng

Terms for hierarchy

Wettergreen & Nourbakhsh | CMU Robotics Institute | SysEng

Terms for hierarchy

Wettergreen & Nourbakhsh | CMU Robotics Institute | SysEng

Wettergreen & Nourbakhsh | CMU Robotics Institute | SysEng

Wettergreen & Nourbakhsh | CMU Robotics Institute | SysEng

Defining Systems Engineering

David Wettergreen | Systems Engineering 16

David Wettergreen | Systems Engineering 17

David Wettergreen | Systems Engineering 19

David Wettergreen | Systems Engineering 20

Complex Real-Time Systems

David Wettergreen | Systems Engineering 21

David Wettergreen | Systems Engineering 22

David Wettergreen | Systems Engineering 24

David Wettergreen | Systems Engineering 25

David Wettergreen | Systems Engineering 26

David Wettergreen | Systems Engineering 27

David Wettergreen | Systems Engineering 28

Systems engineers need to be inquisitive

David Wettergreen | Systems Engineering 31

Systems Engineering Phases

System Actor Boundary

Developing Use Cases

Developing Use Case

Wettergreen & Nourbakhsh | Systems Engineering 36

Documenting Use Cases

Use Case - Elevator

Wettergreen & Nourbakhsh | Systems Engineering 38

Wettergreen & Nourbakhsh | Systems Engineering 39

Wettergreen & Nourbakhsh | Systems Engineering 40

Functional Analysis: a recipe

Wettergreen & Nourbakhsh | Systems Engineering 41

Functional Analysis: a recipe

Wettergreen & Nourbakhsh | Systems Engineering 42

Hardware / Software allocation

Wettergreen & Nourbakhsh | Systems Engineering 43

Hardware / Software allocation

Wettergreen & Nourbakhsh | Systems Engineering 44

Hardware / Software allocation

Wettergreen & Nourbakhsh | Systems Engineering 45

Concept Selection Strategy

Wettergreen & Nourbakhsh | Systems Engineering 46

Concept Validation Strategy