8.1systems engineering hand outs

Introduction to Systems Engineering - Session 2

1

Introduction toSystems Engineering

Brad Yelland (BEng, Aero)

Systems Engineering Manager,Missile Programmes,

BAE SYSTEMS Australia

Why do we Need Systems Engineering ?

3

Introduction to Systems Engineering

Simplification of Complex Systems

Control Design Process

Flow down of System Requirements to Component Level

Facilitate Progressive Testing (flow up)

Produceability and cost

ENSURE FINAL PRODUCT MEETS REQUIREMENTS

Part 1: - Definitions

What is Systems Engineering?

5


Part 1 : - Definitions

Basic concepts and definitions systems, systems engineering, systems engineers a brief history and context

System Lifecycle developing a system the basic process why its important

6


What do we mean by SYSTEM

A set or assemblage of things connected, associated or interdependent, so as to form a complex unity; a whole composed of parts in orderly arrangement according to some scheme or plan; rarely applied to a simple or small assemblage of things. Shorter OED, 3rd Ed.


2

7


What do we mean by SYSTEM (2)

A system is a composite of people, products and processes that provide a capability to satisfy stated needs. A complete system includes the facilities, equipment (hardware and software), material, services, data, skilled personnel and techniques required to achieve, provide and sustain system effectiveness. (MIL STD 499B)

A system is an aggregate of end products and enabling products to achieve a given purpose. (EIA-632)

8


9


10


11


12


Characteristics of a SYSTEM

A complex set of interrelated elements working together to fulfill some designated need must be functional and able to respond to that need

Sub-systems can be equipment, materials, software, people, and other systems A system is contained within some form of hierarchy Sub-systems are not necessarily technology-based


3

13


Hierarchy of systems

Vehicular System

Booking System

Propulsion System Fuel System

Technicians Supply System

Maintenance System

Airplane System Baggage Handling System

Airline System Railroad System

Transportation System

14


Unprecedented and Precedented Systems

Precedented system One for which an experience base exists

Unprecedented system One for which no experience base exists

What is unprecedented for one person may be precedented for another complexity is not an absolute

15


What is Systems Engineering?

Engineering is contriving, designing, inventing

things characterised by Size and complexityDependence on diverse technological and non-

technological disciplines Satisfying a stated need

16


What is Systems Engineering?(2)

the contractors organised, creative, technical and management processes for translating a customers need into a clear definition of a solution, and the production, test, delivery, and integration ofcomponents of that solution (on time, on schedule and within budget). - Grady, J.O.

an interdisciplinary approach to evolve and verify an integrated and life-cycle balanced set of system product and process solutions that satisfy customer needs. - MIL-STD-499B

integrate related technical parameters and assure compatibility of all physical, functional and program interfaces in a manner that optimises the total system design and definition

17


What is Systems Engineering?(3)

The design of the whole as distinct from the design of the parts Simon Ramo

A structured way of handling complexity The best way to maximise probability of a successful

outcome But it is not.

A silver bullet A cookbook approach to success An excuse to stop thinking

18


What is a Systems Engineer?

A Systems Engineer is a person who engineers systems with the professional engineering dimension

introducing elements of judgement and competence No discipline prefix

crosses many disciplines The term is used in other ways elsewhere


4

19


History of systems engineering

1960s Polaris submarine - AFSCM 375 -5 Apollo - NASA procedures MIL-STD-499 - 25 pages - validate contractors

process US Army FM 770-78 - less forms, more

organization 1970s

DSMC handbook Formal software requirements analysis & design

20


History of systems engineering (2)

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

1990 NCOSE 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

21


Concept Exploration

System Definition Engineering

Development

System Qualification

Deployment

Operation & Maintenance

Production

Disposal

System Development

System lifecycle

22


Vehicular System

Booking System

Propulsion System Fuel System

Technicians Supply System

Maintenance System

Airplane System Baggage Handling System

Airline System Railroad System

Transportation System

Recall the Hierarchy?

23


Design Airplane

Design Propulsion

System

Design Fuel

System

Design Maintenance

System

Design Pressure Regulator

Design Fuel

Pump

Design Fuel

Storage

Acquire Pump

Components

Integrate Fuel

Pump

Integrate Fuel

System

Pres

sure

Re

gula

tor

Fuel Storage

Integrate Airplane

Prop

ulsi

on

Syst

em

MtceSystem

Integrate Airline System

Airline System

Contract Boundary

Emergent properties - properties which are not present in any of the

individual parts, but which become apparent as the parts

come together

Developing the Airplane System

24


SystemDesign

Design

Implement

IntegrateDesign

Implement

IntegrateDesign

Implement

IntegrateDesign

Implement

IntegrateFirst Sub-system Tier

SystemIntegration

Contract Boundary

Verification

Design

Implement

Integrate

Tier n

ConceptDefinition

OperationalEvaluation

Developing Any System


5

25


Requirements Analysis

Design Loop

Requirements Loop

Verification

System Analysis & Control

Functional Analysis/Allocation

Synthesis

Inputsfromprevious tier

Outputsto next tier

System Decomposition

26


Whats doesnt the V-diagram show?

There are other perspectives Iteration Text Book Life Cycles

Grand Design (waterfall), Incremental, Evolutionary Change Process Documentation View Configuration Baselines

Cant show everything on one diagram KISS

All models are wrong; some models are useful

27


Hard or Soft?

This is great for hard systems Performance of the parts is deterministic and

predictable Works well for todays technological systems

Not so good for soft systems Societal, Political, Organisational systems Adaptive, evolving Soft Systems Methodology, System Dynamics, etc

Creative Problem Solving, Flood & Jackson (Wiley)

28


Understanding Why is more importantthan knowing How

Divide and Conquer

What has to be decided? Not too much, not too little

When does it have to be decided? Not too soon, not too late

Who does it? The engineer capability continuum

How does one reach a decision? Processes, methods and tools

29


Design of Components

The design of a Component is not effected by the size or complexity of the System it is used in.

The design of a component is driven by three requirements; Form Fit Function

Physical-Size-Shape-Weight-CG-Inertia

Interfacing-Mechanical Interfacing (fixing)-Electrical Interfacing-Communication / Data Interfacing- Effect of function

What it does &How it does it-Performance-ilities-Environment

30


Exercise - Design of Components

Consider 2 components from vastly different systems:

System 1. An electronic automatic garage door.Component: Actuator to open and close the door.

System 2. A Ship Based Theatre Air Defence SystemComponent: Actuator to move the missile control fins

Q1. What information is required to design or select an appropriate actuator for each case?

Q2. How do you determine that information?


6

Part 2: - Defining the System

32


Part 2 : - Defining the System

Where do needs come from? Explicit needs and implied expectations Expression of customer needs The engineering prerequisites for starting system

design

Followed by syndicate work

During this session we will examine

33


The Systems Engineering Front End

SystemDesign

Design

Implement

IntegrateDesign

Implement

IntegrateDesign

Implement

IntegrateDesign

Implement

Integrate

SystemIntegration

ConceptDefinition


Tier 0

Tier 1

Tier 2Int

egrat

ion

Decomposition

The Front End

34


Characteristics of system lifecycle

0

20

40

60

80

100

% of Lifecycle cost

Life cycle cost effectively rendered

unchangeable for a given

design Life cycle cost

actually expended

Tier O: Concept Established 70%

Tier 1: System Design 85%

First Article Proven 95%

Production Complete

Operation and

Maintenance

35


System Development

Whither Customer needs?

Concept Exploration


Development


Deployment


ProductionDisposal

36


Whither customer needs (2)

IndustryDoD

DefenceAcquisition

OCD

Prime Contractor

SOR

Sub Contractor(s)

Eng Spec

Capability Development

CTDs,

Studies

Field

Strategy/ Policy

DSTO Staff

Reqt


7

37


A system, or just shalls?

Understanding the customers problem is the key to meeting his needs

Technical and personal issues are involved Understanding customer needs leads to system

designs that will satisfy those needs Meeting needs is the essence of success Ultimately much cheaper than just delivering shalls

38


Capturing the need

Understand the customers problem Understand the operational concept Understand the system context Identify major states and modes of the system Understand other unstated needs

THEN you can begin to design the system

39


Understanding the Customers problem

Methods as varied as problems and customers Talk to the customer

Which includes all stakeholders in his organisation Market intelligence

Starts well before contract Domain knowledge and expertise

Think like the customer

40


The Operational Concept document

May comprise one or more physical objects Customer version may or may not be released

May require further elaboration Contractor may be asked to prepare OCD Contractor may volunteer its preparation

Expresses users need in user-speak Not design solution definition Evolution must be managed carefully

Aids satisfaction of fitness for purpose obligation

30/03/2001 41


The Operational Concept document (2)

Describes operational scenariosUse graphics, pictures, videos, etcDescribe how the system will be used

No shalls Scenarios identify essential states and modes Scenarios used as basis for system evaluation

30/03/2001 42


What is the System Context?

Represents position of system in the greater world Identifies constraints imposed by that world

Define the system boundary wrt other systems andorganisations Operation, management and support

Interactions with other systems physical, functional, environmental, cultural

reduce soft interactions as far as possible

Interfaces with other systems Identified, characterised


8

30/03/2001 43


Why define the System Context ?

Provides view of system interactions with the external world high-level, simple, diagrammatic

Provides basis for agreement of system boundary and environment

Identifies all external systems and interfaces

Triggers questions and raises issues concerning user functions

Provides guidance in developing system specifications30/03/2001 44


The Context Diagram

System

Environment Interfacing Systems

Organic System

30/03/2001 45


The Context Diagram

Automatic Garage

DoorEnvironment

Garage

Operator

30/03/2001 46


The Context Diagram

STAD System

Environment Ship Platforms

Other AssetsTarget

30/03/2001 47


Products of Context Analysis

Context diagram(s) Interface list Description of transactions for each interface

Initial data dictionary (for data-oriented systems)Control and other eventsHuman and physical interactions Include timing information (where relevant)

30/03/2001 48


States and Modes

States are the highest level grouping of alternative characteristics

Modes are lower level groupings of non-simultaneous capabilities. Each mode usually may apply to one or more states.

There is no absolute definition of state or mode If none are obvious, dont invent them!


9

30/03/2001 49


Example of States and Modes

The combat system shall have three states as determined by fault conditions and network management: normal operation; degraded operation; non-operation

The weapon system shall operate in automatic or manual mode in normal operation and only in manual mode in the event of degraded operation.

50


Other Needs OCD captures customers expressed needs Fitness for purpose Prime contractor may have needs Customers implied needs

Safety in all likely scenarios Cultural suitability Economical through-life supportability Legislative compliance etc

Whether or not

they are in the

contract

Now Lets Develop the Systems

Part 3: - Requirements Analysis

52


Part 3: - Requirements Analysis

This Part will provide an overview of requirements analysis by presenting: Why requirements analysis is important What are requirements The types of requirements The attributes of good requirements Requirements capture Outputs of requirements analysis

53


Concept Exploration


Development


Deployment


ProductionDisposal

System Development

System lifecycle

54


SystemDesign

Design

Implement

IntegrateDesign

Implement

IntegrateDesign

Implement

IntegrateDesign

Implement

IntegrateFirst Sub-system Tier

SystemIntegration

Contract Boundary

Verification

Design

Implement

Integrate

Tier n

ConceptDefinition


System Development V


10

55



Design Loop

Requirements Loop

Verification



Synthesis


Outputsto next tier

System Design

56


Why Requirements Analysis is Important

57


Risk Perspective on Requirements

Customer/Contractor mutual agreement on the meaning of the requirement

Expenditure on non feasible requirements Requirements that cannot be proven Moving goal posts

new/changing requirements or new/changing interpretations

58


What is a Requirement ?

A capability needed by a user to achieve an objective(IEEE Standard Glossary of Software Engineering terminology)

A positive statement specifying something which is to be verifiably present in a final product(Lockheed Space and Missiles Co. Inc. 1991)

Something that governs what, how well, and under what conditions a product will achieve a given purpose (EIA-632, 1999)

59


What is Requirements Analysis ?

Requirements analysis transforms the inputs into the Systems Engineering process into: A black box description of the requirement The criteria to be used to verify that the requirements

have been met

It also produces an understanding and consensus of the need to assist in the remaining activities

60


What is a Black Box Description ?

A Black Box Description is not concerned with the internal workings

It provides the following types of requirements: Functional Requirements

- What has to be done Performance Requirements

- How well it must be done Constraints

- External bounds or limiting factors It does not describe How it is done

fInputs

Constraints

DesiredOutput


11

61


Examples of Types of Requirements

What type of requirement (Functional, Performance or Constraint) are the following? The system shall display the target position within 1

second of detection. The system shall provide wireless data communications

between sites. All AC power wiring shall conform to AS3000. The radar system shall detect both fixed and rotary

wing aircraft. The MTBF shall be greater than 20,000 hours.

62


Sources of Requirements

Customer Requirements Contract documents and standards Operational Concept Descriptions (OCD) etc.

Derived Requirements To correct ambiguity or incomplete requirements Implied or transformed from higher-level requirements

Allocated Requirements Divided or allocated to multiple lower level

requirements

63


Examples of Derived Requirements

What requirements could be derived from the following?1 Flight data shall be stored in a database.2 The supervisor shall be able to access and display

flight data.3 Flight data shall be be used in the simulator.4 The trainer shall have a facility to edit all simulator

parameters.5 The training facility shall be installed in the existing

classroom.

64


Examples of Allocated Requirements

What requirements could be derived from the following system requirements?1 The system shall report built in test after power-up.2 The system shall operate from a single 10A GPO.3 A LAN shall be used to interconnect all equipment.

PrinterHardware

ComputerHardware

ComputerSoftware

65


Attributes of Good Requirements

A good requirement is Achievable Verifiable Unambiguous Complete Consistent Traceable Expressed in terms of need not solution Appropriate for the level of system hierarchy

66


Examples of Poor Requirements

What is wrong with each the following requirements? The ship shall carry enough short range missiles. The computer shall process and display the radar

information instantly. The power supply output shall be 28 volts. The transmitter power shall be adjustable to allow the

antenna side-lobe performance to be met. The power connector shall conform to RS-232. The aircraft shall use stainless steel rivets.


12

67


Traceability Requirement

Traceable path to a Customer need (or Contract Requirement)

Traceable path from test requirements to source requirements

Minimises redundant and unnecessary design activities

ContractDocuments

UserNeed

OperationalConcept

ExistingSystems

ReferencedStandards

DevelopmentSpec(s)

LegalObligations

TestSpec(s)

Lower LevelTest Spec(s)

Lower LevelDev Spec(s)

68


Requirement Database

Used to capture and manage requirements Requirement Management tools:

manage and track requirements capture changes & rationale control process

Part 4: - Functional Analysis, Allocation and Synthesis

70


Where does it fit ?


Design Loop

Requirements Loop

Verification



Synthesis


Outputsto next tier

71


Part 4: - Functional Analysis & Synthesis

This part will cover, processes products documentation standards (briefly) basic examplesmethods

72


Functional Analysis & Synthesis

But first, lets see where this session fits into the big picture, by going back and briefly look at, the overall system life cycle the development part of the life cycle alternative (& equivalent) nomenclature


13

73


Production

Development

Deployment

Operations

Support

Disposition

74


ConceptAnalysis

SystemDefinition

Tier N

SubsystemDefinition

(tier 1)

SubsystemDefinition

(tier n)

SubsystemImplement

SystemInt & Valid

CustomerInt & Valid

SubsystemInt & Valid

(tier 1)


(tier n)

75


Functional Analysis & Synthesis

How do these processes fit within the bigger picture? Lets assume that each tier (of the evolving system

design) is described by a black box and white box view.Consider the Requirements Analysis process as one

which addresses the black box behaviour of a system. So what process is used to describe the white box

behaviour of a system?

76


White Box Behaviour

White box behaviour is defined using the, Functional Analysis process Synthesis process

Process outputs, Functional Analysis output => Functional Model Synthesis output => Physical Model

77


What is a Black Box and White Box view?

Black Box view, description of the system in response to interactions

with external agents without regard to implementation details.

White Box view, description of the systems internal behaviour and

construction in meeting the requirements defined by the black box view to a level sufficient for further subsystem identification.

78


Tier N

WhiteBox

BlackBox

SubsystemDefinition

(tier 1)

WhiteBox

BlackBox

SubsystemDefinition

(tier N)

WhiteBox

BlackBox

SystemDefinition

WhiteBox

BlackBox

ConceptAnalysis

WhiteBox

BlackBox

SubsystemIntegration

(tier N)

WhiteBox

BlackBox


(tier 1)

WhiteBox

BlackBox

SystemIntegration

WhiteBox

BlackBox

CustomerIntegration


14

79


Black &White View

White BoxFunctionalDescription

White BoxPhysical

Description

Black BoxDescription

EIA-IS-632View

FunctionalAnalysis

Synthesis

RequirementsAnalysis

What &How View

HowDescription

WhatDescription

80


Tier N

WhiteBox

BlackBox

SubsystemDefinition

(tier 1)

WhiteBox

BlackBox

SubsystemDefinition

(tier N)

WhiteBox

BlackBox

SystemDefinition

WhiteBox

BlackBox

ConceptAnalysis

Contractual Boundary(in theory)

Supplier

Customer

CustomerBusiness

CustomerComponent(existing)

SYSTEM(to be acquired)



SUB-SYSTEM1

SUB-SYSTEM2

SUB-SYSTEMN

SUB-SYSTEM2-1

SUB-SYSTEM2-2

SUB-SYSTEM2-N

SW Subsystem2-2-1

HW Subsystem2-2-2

HW Subsystem2-2-3

81


Tier N

WhiteBox

BlackBox


(tier N)

WhiteBox

BlackBox


(tier 1)

WhiteBox

BlackBox

SystemIntegration

WhiteBox

BlackBox

CustomerIntegration

CustomerBusiness


SYSTEM(to be acquired)



SUB-SYSTEM1

SUB-SYSTEM2

SUB-SYSTEMN

SUB-SYSTEM2-1

SUB-SYSTEM2-2

SUB-SYSTEM2-N

SW Subsystem2-2-1

HW Subsystem2-2-2

HW Subsystem2-2-3

Validate incrementallyintegrated white boxelements.

Validate black boxbehaviour.

82


Before Functional Analysis & Synthesis

Tip A detailed elaboration of the requirements should be

concentrated within the Functional Analysis & Synthesis processes.

Because these processes make use of, a relatively well defined graphical notation. a relatively rigorous description language

(having a well defined syntax and semantics). This leads to a more rigorous description of the design

(less risky to understand & verify).

83


Functional Analysis & Allocation

Process accomplished by, defining the functions required tracing the functions to requirements defining the I/O for all functions defining how control operations order the functions budgeting time durations to functions (if important) budgeting system accuracy requirements to functions executing the behaviour to establish correctness

examine time lines, examine magnitude of I/O, ...

84


Functional Analysis & Allocation (cont)

Whats the & Allocation component ? It represents the allocation of performance

requirements onto the appropriate functional elements.


15

85


Functional Analysis & Allocation (cont)

Ultimately performed or accomplished by, equipment personnel facilities software combination of the above

86


Synthesis

Process accomplished by, defining real world objects subject to design constraints assigning attributes to the objects allocating behaviour to the objects budgeting performance values to attributes executing the behaviour with the objects examining the interface traffic between objects

87


Functional Analysis & Synthesis Solutions

There may well be multiple architectures, This sets the stage for trade studies. Trade studies select the most practical solution from

the candidate architectures. System effectiveness measures are the criteria used to

make the trade study decisions.Effectiveness measures are the small subset of reqs that

are so important that the system will fail if they are not met and will be a huge success if they are met.

88


F FF

F

F

F

F

F

FF

F

F

F

F

F

F

F

White Box

P1

P2

P3

BlackBox

WhiteBox

BlackBox

WhiteBox

BlackBox

WhiteBox

BlackBox

WhiteBox

Process repeats for eachsubsystem identified inthe tier above.

Tier N

Tier N+1

89


Major O/Ps - Eng Technical Processes

Major outputs from the white box stage are a version of, System Design Description capturing,

Functional & Physical Models (includes I/Fs) Effectiveness MeasuresResults of Trade Studies & Requirements Assessment

Subsystem Integration Description capturing, Phasing of subsystem integration Functionality per phase Additional testing requirements

90


Major O/Ps - Eng Technical Processes (cont) Subsystem Integration Results (integration leg)

Test results. Problem reports. Limitations & deficiencies.


16

91


Major O/Ps - Eng Management Processes*

(* Just to put things into context) Major outputs from each stage are an

version of, Plans Risk Register (Identification, Remediation) Milestones Cost and Time Schedules Work Breakdown Structure Work Packages

92


F FF

F

F

F

F

F

FF

F

F

F

F

F

F

F

White Box

P1

P2

P3

BlackBox

WhiteBox

BlackBox

WhiteBox

BlackBox

WhiteBox

BlackBox

WhiteBox

Process repeats for eachsubsystem identified inthe tier above.

Tier N

Tier N+1

93


Tier N

Tier N+1

BlackBox

WhiteBox

SSS

SSDD

BlackBox

WhiteBox

SSS

SSDD

BlackBox

WhiteBox

SSS

SSDD

BlackBox

WhiteBox

SSS

SSDD

Cut & PasteCut & PasteCut & PasteCut & Paste

The non-value addingapproach performs no otheractivities except cutting textfrom a parent SSS directlyinto a subordinate SSS.The normal value addingpath is by-passed.

94


Where to stop ?

How far do you decompose the functional model ? Down to the point where any function can uniquely map

onto a physical subsystem. If a function cant map uniquely then it must be

decomposed further until it can. In summary,

Many functions can map onto a single subsystem. A single function cannot map onto multiple subsystems.

95


TrackTarget

Position(3D)

RadarSystem

A

WeaponDeliverySystem

Command& Control

System

Option A

RadarSystem

B

WeaponDeliverySystem

Command& Control

System

Option B

TrackTarget

Position

TrackTarget

Position(x&y)

TrackTarget

Position(z)

Turns out that thissystem tracks the targetin elevation (z plane)using optical techniques(which includes theoperator)

This system is cuedautomatically by theCommand & ControlSystem using the 3Dposition dataestablished by theRadar System.

96

Introduction to Systems EngineeringTarget

Magnify& Focus

Light

EstOptimalImage

Position

ChangeLook

Directn

EstLaunch

Posn

DispatchMissile

GuideMissile

TrackMissile

ExternalEnv

MonitorMissile

LookDirection

LaunchPosn

Wind

MissileAway

LookDirection

MissileMissileAbort

MissileCharacteristic

MissileMovement

MissileMovement

MissileGuidance

LookDirection

VisibleImage

TargetReflectedLight

DeltaPosn

LensSystem

GimbalSystem

OrganicSystem

(Operator)

Supports

Safe OperatingEnvelope/Area


17

97

Introduction to Systems Engineering Radar SystemAttributes:-MTBF : 200 hoursMTTR : 2 hoursSize : 3m x 2m x 2mColour : Army GreenWeight : 2 man liftRF : radio frequency, 9500MHzPRF : pulse repetition freq, 800HzPW : pulse width, 2.0usecsARP : angular rotation period, 1.4secsPpk : peak power, 110KWattsOpMode : (Idle, Passive, Radiating)Data I/F : RS-422, 9.6Kbits/sec

Services:-

TargetIdentity

Target

Search

Identify

TargetData

TargetCharacteristic

TargetIllumination

IFFResponse

IFFRequest

HealthCheck

HealthReply

HealthRequest

InternalSubsystems

* Not a complete description.

Consumer

98


ConceptAnalysis

SystemDefinition

Tier N

SubsystemDefinition

(tier 1)

SubsystemDefinition

(tier n)

SubsystemImplement

SystemInt & Valid

CustomerInt & Valid


(tier 1)


(tier n)

TenderResponseSlice ofDevelopmentStage.

99


Synthesis - Modular Design

Desirable attributes of modular system components, Low Coupling High Cohesion

100


Synthesis - Modular Design (cont)

Definition, Coupling - a measure of the relative interdependence

between subsystems. Simple connectivity among subsystems results in a

system that is easier to understand and less prone to a ripple effect when errors or changes occur in another part of the system.

Cohesion - a measure of the relative functional strength of a subsystem. A cohesive subsystem performs a task with little

interaction with other parts of the system.

101


Synthesis - Modular Design (cont)

In summary, develop subsystems with, single-minded function. an aversion to excessive interaction with other

subsystems.

102


Abstract Example (covering software)

The following example looks at, A Subsystem model. A CSCI model - one element of the subsystem model is

a software item. A Hardware architecture - defining the solution for the

Subsystem and CSCI models.


18

103


ExternalAgent 1

F1

F2 F3F4

F5 F6 F7

F8

DS1

ExternalAgent 2

DS1

Subsystem Functional Model(white box)

HWCI 3(derived)

HWCI 1=F2 +F3

HWCI 2=F6 +F7

+DS2

CSCI 1=F1 +F5+F4 +F8

+DS1

ExternalAgent 1

ExternalAgent 2

Subsystem Physical Model(white box)

104


ExternalAgent 1

F1

F2 F3F4

F5

F6

F7

F9

SWDS1 External

Agent 2

SWDS2

CSCI Functional Model(white box)

CSC 3=F6 +F8

CSC 2=F3 +F4

CSC 4=F7 +F9

CSC 1=F1 +F2

+F5

ExternalAgent 1

ExternalAgent 2

CSCI Physical Model(white box)

F8

CSC 5(derived)

=SW-DS1+SW-DS2

If using a multi-tasking, messagepassing executivethen this interfacebecomes a message

If using a multi-tasking, messagepassing executivethen a CSCbecomes a task.

This CSC is aDataStore Manager.Its derived (exists aspart of the design).

105


COMMON BUS

HARD DISK

=SW-DS1+SW-DS2

I/O CARD

= externalinterfaces

Processor 3

=CSC4 +CSC5HWCI 2

HWCI 1HWCI 3+ CSCI 1

External Agent 1External Agent 2

Processor 1

=CSC1 +CSC3

Processor 2

=CSC2

High Speed Bus

106


Methods

There are many different Methods/Tools that can be employed to assist with step. Structured Analysis Structured English Object Oriented Methods Functional Flow Block Diagrams Schematic Block Diagrams

107


Methods Summary

Methods required to support the following (white box) processes, Functional Modelling

Static & Dynamic descriptions Physical Modelling

Static & Dynamic descriptions Simulation

108


At the End of the Day

There are no silver bullets, no panaceas, and no miracle cures that will automatically increase an engineers effective productivity by a factor of 10.

Even knowing all the theory, Engineering is still, 95% hard work 5% inspiration

Its an advantage to understand all of the theory, Just so you can go back and break it,

*BUT* with the full understanding of the risk involved. Living with risk is a fact of life.


19

109


Exercise - Design of Components

Consider 2 components from vastly different systems:

System 1. An electronic automatic garage door.Component: Actuator to open and close the door.

System 2. A Ship Based Theatre Ballistic Missile Air Defence SystemComponent: Actuator to move the missile control fins

Q1. What information is required to design or select an appropriate actuator for each case?

Q2. How do you determine that information?

110


Further Reading

System Engineering Fundamentals, October 1999, Defense Systems Management College (DSMC). a more mature version of the traditional systems

engineering approachmethod sections need significant updating & expanding

to bring it up to speed words are enlightening; worth a read

System Engineering Handbook, rel 1.0, Jan 1998, INCOSE.a monsterdefinite bedtime reading

111


Further Reading (cont)

IEEE Std 1220, Trial-Use Standard for Application and Management of the Systems Engineering Process.

has been around since about 1994 last half describes processes in reasonable detail

MIL-STD-499B, Systems Engineering, Draft, Sept 1993 never officially seen the light of day.

EIA-IS-632, Systems Engineering, Dec 1994. originally just 499B in disguise

(mil speak and shalls removed) official release has been watered down

BAeA Systems Thinking Guidebook, Issue H, Nov99 same philosophy as this presentation (~250 pgs).

Part 5: - Integration, Verification and Validation

113


Part 5: - Integration, Verification and Validation This Part will examine the integration activities of a

system and the associated verification: The implementation side of the V model How verification fits in with integration Verification vs validation The inputs required for success

114


Definitions

Integration: The merger or combining of two or more lower level elements into a functioning or unified higher level element with the logical and physical interfaces satisfied. (EIA/IS 632)

Verification: Confirmation by examination and provision of objective evidence that the specified requirements to which an end product is built, coded or assembled have been fulfilled. (EIA 632)

Validation: Confirmation by examination and provision of objective evidence that the specified intended use of an end product or aggregation of end products is accomplished in an intended usage environment. (EIA 632)


20

115


Require mentsAnal ysis

Functi ona l Ana l ysis/Allocation

Synthes is



Synthes is



Synthes is



Synthes is

Component Implementation



Synthes is



Synthes is



Synthes is

UnitVerification

Sub-systemVerification

SystemVerification

Integrate Correct

Integrate Correct

Integrate Correct

VerificationCriteria



Design

Impl

emen

t

The Implementation Leg

116


Design for Integration

Multiple levels of integration and verification Each level corresponds to the design hierarchy The interfaces between all components must be

defined The interfaces between the system and external

systems must be defined Engineering models and prototypes can assist the

design and implementation process

117


Verification

Verification requirements result from requirements analysis

Functional - Does it do what it has to do Performance - Does it do it as well as it has to Physical - Does it meet the constraints and

external interfaces

118


Verification Methods

Test Demonstration Analysis Inspection

119


The system shall display the target position within 1 second of detection.

The system shall provide wireless data communications between sites.

All AC power wiring shall conform to AS3000. The radar system shall detect both winged and rotor

aircraft. The MTBF shall be less than 20,000 hours.

Examples of Verification Methods

What verification methods could be used for the following?

120


Golden Rules for Verification

Verify at as low a level as possible Verify as early as possible Balance verification by analysis with testing Address problems as soon as possible Ensure design is testable Verify test and simulation tools

Success is highly dependent on the effort applied during the design process


21

121


Design and Product Verification

Design verification ensures that the design meets the requirements if manufactured correctly Full functional and performance verification Detects non-conformance between the product and its

specification Product verification ensures that the system has been

manufactured correctly Inspection Production controls Acceptance testing

122


Integration and Verification Problems

Plans must cover what to do if integration problems or verification failures occur

Corrected at the next level down or design where necessary

Dealing with COTS Undocumented features Not developed for the environment Defined behaviour and interfaces Support

123


Installation and Validation

Installation into the operational environment Interfaces to external systems may require simulation Uncontrolled environment - validate in phases May involve user training Validation of user manuals May be used to verify operational requirements such

as availability Must be well planned

Part 6: - System Analysis and Control

125



Design Loop

Requirements Loop

Verification

System Analysis & Control(Balance)


Synthesis

Objectives of this Session


Design Loop

Requirements Loop

Verification


(Balance)Functional

Analysis/Allocation

Synthesis

126



This Session provide an overview of the management of the Systems Engineering process: Technical reviews and audits Trade studies Technical performance measures Specialty engineering integration Decision database Management of risk, requirements, configuration and

data


22

127


Technical Reviews and Audits

Used to measure design progress and maturity Key development milestones Confirmation of completed effort and readiness to

proceed Depth of review based on complexity of system, sub-

system or CI being reviewed

128


Conducting Reviews

Event driven Be well prepared - there shouldnt be any surprises Establish success criteria beforehand Review material includes:

specifications, drawings, design and test data, trade studies, risk analysis, schedules, engineering models, mock ups and prototypes ...

Follow up review actions quickly

129


Types of Reviews and Audits

System Requirements Review (SRR) System Design Review (SDR or SFR) Software Specification Review (SSR) Preliminary Design Review (PDR) Critical Design Review (CDR) Test Readiness Review (TRR) Production Readiness Review (PRR or PAR) Functional Configuration Audit (FCA or SVR) Physical Configuration Audit (PCA)

130


Analysing Alternatives

Alternative solutions always exist to every decision Identify the alternatives Select the alternative that is best for the system Best can be defined in terms of measures of

effectiveness for the system

131


Trade Studies

Required to support design decisions Supports functional analysis and allocation Evaluate alternative functional and physical

architectures Document make/buy and material selection decisions Evaluate environmental factors

132


Trade Study Basics

Establish the study problem:- Develop a problem statement- Identify requirements and constraints- Establish analysis level of detail

Review inputs:- Check requirements and constraints for completeness and conflicts- Develop customer-team communication

Select and setup methodology:- Choose trade-off methodology- Develop and quantify criteria, including weights where appropriate

Identify and select alternatives:- Identify alternatives- Select viable candidates for study

Analyse results:- Calculate relative value based on chosen methodology- Evaluate alternatives- Perform sensitivity analysis- Select preferred alternative- Re-evaluate results

Measure performance:- Develop models and measurements of merit- Develop values for viable candidates

Document process and resultsTaken from the DSMC SystemsEngineering Handbook


23

133


Typical Trade Studies

System design alternatives: Solar power vs mains power Valve vs solid state transmitters

Trades one system performance measure against another: Cost/weight Cost/power consumption Reliability/life cycle cost Redundancy/life cycle cost BIT/level of support

134


Technical Performance Measures

Parameters of critical importance or risk Provides early warning of design deficiency or excess

Achievementto date

PlannedProfile

Tolerance Band

Milestones

Threshold

ContractCompletion

CurrentEstimate

Variation

PlannedValue

TechnicalParameter

Values

eg. MTBF

135


Specialty Engineering

Identify specialty requirements in the system Assign specialty requirements responsibility Specialty engineers help the Systems Engineer

understand the requirements Assists with the ilities

136


Specialty Disciplines

Human factors Survivability Reliability/maintainability/availability Supportability Electromagnetic compatibility Producability Safety engineering Value/cost engineering Logistics engineering ...

137


Decision Database

The decision database is all of the documentation and data that supports the design solution: Trade studies and analyses Requirements traceability Models and simulations Alternative solutions Supporting data

138


Engineering Management

Risk management Configuration management Data management Requirements management Technical personnel management Cost and schedule management Technical review and audit program management


24

Part 7: - Conclusion

Importance of Planning

140



This Session provides an overview of the planning that supports the System Engineering process: System Engineering Management Plan (SEMP) Test & Evaluation Master Plan (TEMP) Technical Review and Audit Plan (TRAP) Configuration Management Plan (CMP) Work Breakdown Structure (WBS)

Wrap up of the course

141


Why Plan

Why is Systems Engineering planning so important?:

Agreement with customer Documents how the BAeA processes will be applied Breaks the work into comprehendible packages Provides guidance to the project team Early warning of problems

142


SEMP

Systems Engineering Management Plan (SEMP) Documents the SE methods and organisation to be

applied to the project Living document reflecting the current stage of the

design life-cycle DID provided in MIL-STD-499B, IEEE 1220, and

EIA/IS 632 Must be in accordance with BAeA standard

procedures

143


TEMP

Test and Evaluation Master Plan (TEMP) Documents the planning of all test and trials activities

Where, when, how and with what resources Establishes the verification methods for customer

agreement Identifies long lead resources such as specialised test

equipment and test houses Establishes customer involvement for supply of GFE

and witnesses References subcontractor and Software Test Plan(s)

where necessary144


TRAP

Technical Review and Audit Plan (TRAP) Documents the technical reviews and audits to be

applied to the project: Applicability Scheduling Entry and completion criteria Standards to be used

Often incorporated into the SEMP


25

145


CMP

Configuration Management Plan (CMP) Documents the standards and techniques to be use

to manage the configuration of all project data Applies to internal documents as well as deliverable

documents, hardware and software Fully defines the change control process

146


WBS

Work Breakdown Structure (WBS) Documents all activities required to complete the

contracted requirements Links directly to cost and schedule management Breaks the work into manageable pieces

147


System Engineering Dos and Donts Do:

Ensure Common Approach Make Maximum Use of Tools Tailor the SE approach to optimize the effort versus

benefit equation

Dont Forget the broader picture Ignore the cascade effect of change Spend all your effort on SE Put off the SE effort

148


Further Reading

EIA 632 - Process for Engineering a System -Electronic Industries Alliance

IEEE Std 1220 - Trial-use Standard for Application and Management of the Systems Engineering Process

System Engineering Handbook - INCOSE 1998 BAeA Systems Thinking Guidebook, Issue H Nov 99

149


Further Reading cont.

System Engineering Fundamentals - Defense Systems management College (DSMC), 1999

Systems Engineering - coping with complexity, Stevens et al, 1998

Creative Problem Solving - Total Systems Intervention, Flood & Jackson, 1991

8.1systems engineering hand outs

Documents

systems engineeringwhat

definitions systems

systems engineeringpart

systems engineering

bae systems australiawhy

unprecedented system

form of hierarchy subsystems

system requirements