mod g gt aerospace systems engineering cc04264377.ppt aerospace systems engineering functional...

Mod G

GT AerospaceSystems Engineering

CC04264377.ppt

Aerospace Systems Engineering

Functional Analysis

Mod G


CC04264378.ppt

Functional analysis/allocation• Decompose to lower-level functions• Allocate performance and other limiting requirements

to all functional levels• Define/refine functional levels• Define/refine functional interfaces (internal/external)• Define/refine/integrate functional architecture

Process input• Customer needs/

objectives/requirements

– Missions– Measures of

effectiveness– Environments– Constraints

• Technology base• Outputs from prior phase• Program decision

requirements• Requirements applied

through specificationsand standards

• Trade-off studies• Effectiveness analyses• Risk management• Configuration management• Interface management• Data management• Performance based

progress measurement– SEMS– TPM– Technical reviews

Synthesis• Transform architectures (functional to physical)• Define alternative system concepts, configuration

items and system elements• Define/refine physical interfaces (internal/external)• Select preferred product and process solutions

Verification Loop

Design loop

Requirements loop

Process output• Phase dependent

– Decision support data– System architecture– Specifications and baselines

Requirements analysis• Analyze missions and environments• Identify functional requirements• Define/refine performance and design

constraint requirements

Systemanalysis

and control(balance)

Control loop

The Systems Engineering ProcessPer INCOSE Systems Engineering Handbook

Mod G


CC04264379.ppt

Functional Analysis

• A structured approach for describing how a system might be used

• Defines a functional architecture for which system products and services can be designed

• Performed to a depth needed to support synthesis

• Identifies and arranges lower-level functions needed to accomplish parent requirements

• Arranges function in a traceable, logical sequence

Mod G


CC04264380.ppt

Functional Analysis (cont)

• Includes all contractually specified usage modes

• Includes functions necessary for the product or service to operate properly

• Used to analyze time-critical requirements

• Involves iterations

Performance requirements identified in functional analysis serve as design criteria for the system

Mod G


CC04264381.ppt

Functional Flow Decomposition

Number One tool for systems engineers

• Understanding how products and services might be used

• Discovering innovative solutions

• Focusing attention away from what the product looks like (stop designing)

• Overcoming design road blocks

Mod G


CC04264382.ppt

Elements of Functional Analysis

• Functional decomposition

• Functional sequencing

• Information/data flow

• Interface definition

Mod G


CC04264383.ppt

How Products Might Be Used

• Key word is used - not do

– Do tends to evoke current (and limited) functionality

– Successful products often have uses not anticipated by initial developers

Mod G


CC04264384.ppt

What Are Functions?

• Functions describe how users use a product or service

• A functional statement begins with a verb and follows with a direct object

– Fly airplane

– Surf internet

– Enter password

– Pay debts

Mod G


CC04264385.ppt

What Are Functions? (cont)

• As one moves away from user-interface level and into lower levels of detail, functional descriptions become statements about what the system does

– Compute coordinates

– Sense hydraulic pressure

– Track target

Mod G


CC04264386.ppt

Functional Decomposition

• Top-level functions at some common level are identified

• Top-level functions are composed oflower-level functions that describe top-level functions in more detail

Mod G


CC04264387.ppt

Functional DecompositionPrimary Steps

• Brainstorm functions performed

• Pick out the five to ten truly top level functions and arrange in sequence (if appropriate)

• Place the other functions below thetop-level functions

Mod G


CC04264388.ppt

Naming Functions• Function name should identify the action or transformation

accomplished by the function• Avoid the pitfalls of “provide” and “accept” functions• Functions are usually identified in the verb-noun syntax:

e.g., monitor status

Poor• Provide diagnostics• Provide utility power• Provide aircraft position• Accept pre-flight data• Accept status• Accept crew inputs

Good• Perform bit• Control utility power distribution• Compute aircraft position• Store pre-flight data• Monitor system status• Interpret crew inputs

Mod G


CC04264389.ppt

Functional Flow Block DiagramsCar Example

Drive car

• Accelerate car

• Decelerate car

• Turn car

• Start car

• Stop car

Mod G


CC04264390.ppt

Functional Flow Block Diagrams (cont) Car Example

Drive car

Start car

Accelerate car

Turncar

Decelerate car

Stopcar

Mod G


CC04264391.ppt


Drive car

Start car

Accelerate car

Turncar

Decelerate car

Stopcar

Selectdrive

Place gearshiftin park

Turn onignition

Mod G


CC04264392.ppt


Drive car

Start car

Accelerate car

Turncar

Decelerate car

Stopcar

Selectdrive

Selectreverse

Place gearshiftin park

Turn onignition

Mod G


CC04264393.ppt

Functional Decomposition Practical Approach

• Post-it notes are very useful

• Write functions on post-it notes

• Insist on the verb-noun format

• Let the team arrange post-it notes

– 5 to 9 top-level functions

– Create additional top-level functions, if appropriate

Mod G


CC04264394.ppt

Functional Decomposition (cont)Practical Approach

• If there is contention about where a function belongs, make a duplicate post-it note and put both places

• There may be different decompositions depending upon the context

• Discourage premature allocation to physical architecture

• When you get uncomfortable about further decomposition, it is usually time for trade studies

Mod G


CC04264395.ppt

Other Uses of Functions

• Operational concepts– All about how a system is used

• Scenarios – Supply the contexts in which the functions

are performed

Mod G


CC04264396.ppt

Innovation via Reallocation

Traditional viewDetect target

Track target

Shoot missile

Guide missile

Illuminate target

Shoot missile

A different viewDetect target

Track target

Guide missile

Illuminate target

Mod G


CC04264397.ppt

Triad of an Evolving Concept

• Joint development and evolution of:

– Functional decomposition

– Operational concept

– Functional allocation

Mod G


CC04264398.ppt

Overcoming Design Roadblocks

• Problem:

– How to design a set of files used by operations analysts to set up a simulation

• Two alternate flows or scenarios

– A B C D E F G

– A B D C E F G

• The functional view changed the engineers’ view of the problem

Mod G


CC04264399.ppt

There Is No “Right Way”Command centered view

Balance major components of the system at the top level functions

Ship center view

Turn Go straight Accelerate Decelerate

Increasepower

Increasepower

Decreasepower

Reversescrews

Deflectrudder

AccelerateTurn on airconditioning

Mod G


CC04264400.ppt

Other Significant Benefits

• Explaining why your design makes sense

• Developing functional requirements

• Controlling the level of detail

• Helps with team building

And a caution:

Functional decomposition is a tool, and tools have limitations

Mod G


CC04264401.ppt

Variations With Life-Cycle Phase

• Pre-concept exploration - identify top-level functions of your system and others with which your system must work (no designs)

• Concept exploration - develop and analyze benefits of alternate functional decompositions and allocations (multiple alternative design concepts)

• Risk reduction and EMD - decompose and allocate functions to lower levels of design (single design)

Mod G


CC04264402.ppt

An EMD Example for Electronics

• Assumptions– Feasibility is established– Conceptual designs exist– Specifications exist

• Task– Develop a system that meets

the specifications

Mod G


CC04264403.ppt

Electronics Functions

• Functions transform a given set of inputs into a set of outputs in the performance of useful activity

• Functions are enabled through the use of hardware and software in the system’s physical architecture

Mod G


CC04264404.ppt

Scoping the System Design

• Establish general information about the system• Extract general design requirements from the

specification• Summarize a written description of the system

(appropriate to the defined level of detail) in terms that an outsider can understand– Application– Functionality– Interfaces– Behavior

Mod G


CC04264405.ppt

Scoping the System Design (cont)

• Establish and summarize the main system functions in a list

• Identify a first pass functional hierarchy

• Iterate the function list and hierarchy as the design matures

– Decompose to lower level functions

– Allocate performance and other limiting requirements to all functional levels

Mod G


CC04264406.ppt

Specification for a Collision Warning System1. General - A Collision Warning System (CWS) for service in an automobile shall provide the

driver with notifications of impending collision

2. Operation - The CWS shall come on automatically with the application of vehicle power

2.1 Responsiveness - The CWS shall provide prompt alarm to the driver within a time sufficient to avoid an accident when a closing probability of collision is detected. False alarms shall be minimized

2.2 Hazard Warnings - Warning in the form of audio and visual indications shall be made available to the driver when a hazardous condition is detected. The same warning indicators shall be used a s indicators for build-in-testing

2.2.1 Audible Warning - The audible warning shall consist of a pulsing tone with a pulse frequency proportional to the proximity from the hazard. A faster pulse rate shall indicate a closer distance to the hazard

2.2.2 Visual Warning - The visual warning shall consist of a continuously displayed red lamp on the instrument panel while the hazard exists

2.3 Fault Conditions - A fault in any part of the CWS shall be indicated on a front panel lamp

2.3.1 Fault Notification - The fault notification shall consist of a continuously displayed while lamp on the instrument panel while the CWS fault exists

2.4 Built-In-Testing - The CWS shall be capable of performing both Power-up Built-In-Test (PBIT) as well as operator-initiated testing (OBIT) for the detection of CWS faults

Mod G


CC04264407.ppt

CWS Functional Hierarchy

1.1 Sense objects

1.1.1 Detect objects

1.1.2 Compute parameters

1.1.3 Warn/caution driver

1.2 Test unit

1.2.1 Initiate tests

1.2.2 Compute status

1.2.3 Advise driver

1 CWS functions

Mod G


CC04264408.ppt

Scoping the System Design (cont)

• Determine the location of the system under design in the overall system

– Establish the system in its environment

– Describe the environmental systems (externals)

• Write a general description of the interfaces between the system and the environmental systems

– Short description of the interface between each environmental system and the system (1-4 lines of text)

– General description of the major signals in each flow

Mod G


CC04264409.ppt

Define the System in Its Environment (SIE)• Draw the boundary of the system in its environment

• Draw the external systems from which inputs are received

• Draw the inputs from the external systems to the system under design

• Draw the external system to which outputs are sent

• Draw the output from the system under design to the external systems

• Detailed descriptions should be updated incrementally throughout development

External system 1

External system N

Majorinputs

Systemunderdesign

External system 1

External system M

Majoroutputs

••

••

Mod G


CC04264410.ppt

CWS in Its Environment

ECHO_RF

CollisionWarningSystem

POWER_IND

SPEED_DATA

TEST_REQ

Objects

Driver

Veh_Elect

RF_PULSES

FAULT_LOG

VIS_WARN

AUD_WARN

AVIS_CAUT

FAULT_NOTE

Objects

Driver

Veh_Elect

Mod G


CC04264411.ppt

Design Data Descriptions for CWSCollision Warning System (CWS) - The system under design; a physical unit to be installed into an automobile to warn the driver of impending collision with objects

Objects - Any physical body (moving or stationary) that may be considered a harmful threat to the vehicle and its passengers. Receivers RF_PULSES and emits ECHO_RF

Veh_Elect - Automobile electrical system. Provides an indication of applied power and vehicle speed information; receives fault information from CWS for recording in a centralize diagnostic location

Driver - Consumer of CWS warning notifications. Makes test requests for initiated CWS built-in-testing

ECHO_RF - Radio frequency signals reflected from objects

POWER_IND - Signal to CWS that power has been applied to vehicle electrical system

SPEED_DATA - Continuous present speed of automobile

TEST_REQ - Test request signal from driver to CWS for initiating build-in-testing

RF_PULSES - Radio frequency pulses transmitted by CWS to the environment (specifically, objects)

FAULT_LOG - Record of faults detected and isolated by CWS built-in-testing

VIS_WARN - Visual warning to driver of impending collision with an object

AUD_WARN - Audible warning to driver of impending collision with an object (work in conjunction with VIS_WARN)

VIS_CAUT - Visual caution to driver of potential impending collision with an object

FAULT_NOTE - Notification to driver of fault in CWS

Mod G


CC04264412.ppt

5 Minute ExerciseIdentifying a System in Its Environment

Using the specification paragraph below, list the external environmental elements for the System in Its Environment. Then draw their representative boxes (externals only) along with simple data flows to and from the EWS. Label each box and data flow with appropriate names.

1.0.1 The Early Warning System (EWS) shall receive signals from an external sensor. The EWS shall examine the signals via a status processor and check if the calculated values are within specified ranges stored in system memory. If the value of a processed signal is out of range, the system shall issue a warning message on its operator terminal and post an audible alarm at a central alarm facility. If the operator does not respond to this notice within one minute, the system shall record the event on its removable mass storage cartridge, print a fault message on a printing facility, and stop monitoring the particular signal.

Environmental Elements EWS

Mod G


CC04264413.ppt

Structured Analysis and Design Technique (SADT)

• SADT provides a strong graphical representation of system requirements coupled to a disciplined structured design technique

• SADT can be used to– Define/refine interfaces (internal and external, functional

and physical)– Define/refine/integrate architectures (functional and physical)– Communicate system design information among analysts and users– Document the satisfaction of requirements– Review, approve, and control design documentation

• SADT consists of two principal parts– Structured analysis - a graphical box-and-arrow diagramming

language– Design technique - the discipline of thought and action that must be

learned and practiced for the graphics to be used effectively

Mod G


CC04264414.ppt

Basic SADT Design Technique• Each diagram tells a story

• Whenever certain data become available, boxes become active and perform their functions

• A box activation is a way in which a box can operate using some of its inputs and controls to produce some of its outputs

– Note: for any specific activation• At least one input must be used

• At least one output (different from the input) must be produced

• Decomposition means breaking a subject (box) into pieces (several boxes in a diagram)

• SADT provides an iterative and a hierarchical process

Mod G


CC04264415.ppt

Example of a SADT Functional Flow DiagramAir traffic identification system

Control tower

Air traffic

External scan signal characterization data

Detection flag

Take another snapshot of signal

Identified traffic

Info transmissions out

Detect traffic

Air traffic

Identify traffic

Report info

Mod G


CC04264416.ppt

SADT: Information Flow AnalysisAn information flow is a construct which can contain grouped data items, events, conditions and other information flows, alltreated as a single entity

• Every output to the environment must be produced by at least one function

• Every input from the environment enters into at least one of the functions

• Every output from a function must be produced by one of the subsystem functions

• Every input to the logical subsystem should enter into at least one of the subsystem functions

–The names of the inputs should differ from the names of the outputs (unless there is a reason that they remain the same)

• Every intermediate input (those not obtained from the environment) to a function must be produced by one of the other functions

Mod G


CC04264417.ppt

SADT: Information Flow Analysis (cont)The information can be used in two ways

(A) Elemental items can be grouped together into an information flow

(B) Information flows can be broken down into more detailed element items

Case A Case B

Radar status

Comm status

Nav status

Radar BIT commands

Comm BIT commands

Nav BIT commands

Equipment status

BIT commands

or

Mod G


CC04264418.ppt

Hierarchical Decomposition of Flows

• General

– The quantity of variables flowing in the diagrams is often large

– Variables must be grouped into meaningful information flows

• Ease the load of data in the diagrams

• Ease the readability of the diagrams and their understanding

– Rule of thumb: where possible, all data uniquely flowing between two modules should be grouped into a single information flow

Mod G


CC04264419.ppt

Hierarchical Decomposition of Flows (cont)

• Characterization of variable in a new system

– Define the main logic flows between the system and its environment using information flows

– Identify the elements of the main logic flows

• Define every flow as an information flow (requires writing a description for each component)

• List the contained elements in form for the information flow

– Example: Built-in-test status contains

• Module ID

• Fault ID

• Failed test numbers

Mod G


CC04264420.ppt

Hierarchical Decomposition of Flows (cont)

• Draw the main flows from the external modules inward toward the internal modules

– If all the components of an information flow are connected to a single module, draw the flow directly to this module

– If the components of the information flow are connected to a number of modules, draw a connector and connect to it the corresponding component flows

Mod G


CC04264421.ppt

Hierarchical Decomposition of Flows (cont)• Draw the main flows from the external modules inward

toward the internal modules

– If all the components of an information flow are connected to a single module, draw the flow directly to this module

– If the components of the information flow are connected to a number of modules, draw a connector and connect to it the corresponding component flows

Mod G


CC04264422.ppt

Steps for Completing the Top-Level SystemFunctional Architecture

• Use the system in its environment as a starting point

• Draw and label the top-level system function boxes

• Connect the function boxes to the relevant inputs and outputs of the environment (and to each other, where appropriate)

Mod G


CC04264423.ppt

CWS in Its Environment

ECHO_RF

CWSTop Level Functions

POWER_IND

SPEED_DATA

TEST_REQ

Objects

Driver

Veh_Elect

RF_PULSES

FAULT_LOG

VIS_WARNAUD_WARNAVIS_CAUT

FAULT_NOTE

Objects

Driver

Veh_Elect

Sense objects

Test units

VIS_WARNAUD_WARNVIS_CAUT

Mod G


CC04264424.ppt

CWS in Its EnvironmentClarity and Simplicity Are Important

ECHO_RF

CWSTop Level Functions

POWER_IND

SPEED_DATA

TEST_REQ

Objects

Driver

Veh_Elect

RF_PULSES

FAULT_LOG

VIS_WARNAUD_WARNAVIS_CAUT

FAULT_NOTE

Objects

Driver

Veh_Elect

Sense objects

Test units

VIS_WARNAUD_WARNVIS_CAUT

Mod G


CC04264425.ppt

Steps for Completing the Detailed SystemFunctional Architecture (cont)

• Collective experience and expertise is required to adequately partition a functional design

• Guidelines for finding the required depth of design:– Design simplicity should be maintained as much as possible at

any level of detail– Postpone design details to the lower levels– Perform the system design for only that level of detail required to

fully satisfy (and test, if computer-based simulation tool is available) requirements

– Use another design drawing, if necessary, to develop lower level details of the design (e.g., another design drawing for each subsystem)

Mod G


CC04264426.ppt

Steps for Completing the Detailed SystemFunctional Architecture (cont)

• Create a diagram for each top-level system function– Include only the environmental elements relevant to the

particular function– Include any elements that use data from or produce data for

the top-level function– Include only the data/information flows used and produced by

the particular function• Connect the function together using SADT techniques, adding

appropriate labels to each data/information flow• Modify the function list and hierarchy of the lower-level• functions required to consume input an produce outputs of each

top-level system function• Iterate the above steps to fully define required system functionality

Mod G


CC04264427.ppt

CWS Detailed List of Functions

Sense Objects Test Unit

Detect objectsCompute parametersWarn/caution driverRequire pulseGenerate pulsesDetect echoesScreen echoesDetect closingWarn driverCaution driver

Initiate testsCompute statusAdvise driverRequest pulseGenerate pulsesDetect echoesScreen echoesDetect closingWarn driverCaution driverDetect test requirementsGenerate testsScale signalsSense faultIndicate fault

Mod G


Warndriver

Detectclosing

CC04264428.ppt

CWS Sense-Object Function

ECHO_RF

Sense Object

POWER_IND

SPEED_DATA

DIG_SIGS

ObjectsRF_PULSES

Reference_Table

VIS_WARNAUD_WARN

Driver

Requestpulse

Generatepulse

PULSE_CMDS

Detectechoes

Screenechoes

Cautiondriver

SYNC

SYNC

SYNC

DETECTIONS CONFIRMATIONS

VIS_CAUT

OBJ_DATA

Objects

Veh_Elect

Mod G


Warndriver

CC04264429.ppt

CWS Test-Unit FunctionTest Unit

POWER_IND

SPEED_DATA

DIG_SIGS

ObjectsRF_PULSES

VIS_WARNAUD_WARN

Driver

Requestpulse

Generatepulse

PULSE_CMDS

Cautiondriver

SYNC

SYNC

DETECTIONS

CONFIRMATIONS

VIS_CAUT

Driver

Veh_Elect

Scalesignals STRF

Sensefault

FAULT

FAULT_LOG

PI

Detectclosing

Reference_Table

Detectechoes

Screenechoes

SYNCOBJ_DATA

STRF

Generatetests

Invoketests

Detect testsrequest

TS

TEST_SELTEST_CMD

TS

SELF_TEST_RF

PI

Indicatefault

FAULT_NOTE

Veh_Elect

SCALE_SEL

RF_PULSE

SPEED_DATA

TEST_REQ

Mod G


CC04264430.ppt

CWS - Description of Functions and Data Flows

Request Pulse - Upon receiving POWER_IND signal from Veh_Elect it issues PULSE_CMDS to the function Generate Pulses

Generate Pulses - Upon receiving specific pulse commands for the Request Pulse function, it broadcasts RF_PULSES into the environment

Detect Echoes - Senses ECHO_RF energy in the environment. Upon the detection of signals, it produces digital representation of the signals as DIG_SIGS

Screen Echoes - Filters potential objects (synchronized with the Generate Pulses function) from hack ground noise. It produces confirmed DETECTIONS based on a comparison of DIG_SIGS (digital signals) with OBJ_DATA (object data) in the Reference_Table data store

Detect Closing - Compares DETECTIONS to vehicle’s SPEED_DATA to resolve likelihood of collision. Produces CONFIRMATIONS based on closure thresholds (object range vs. vehicle speed)

Warn Driver - Upon exceeding threshold for a warning from Detect Closing function, produces visual warning (VIS_WARN) and audible warning (AUD_WARN) to Driver

Caution Driver - Upon falling within threshold range for a caution from Detect Closing function, produces visual caution (VIS_CAUT) to Driver

Reference Table - Data store for object signatures used in the filtering of digitally encoded detections from background noise and erroneous echo detections

Mod G


CC04264431.ppt

N2 Diagram

• Maps interfaces between all functions

• Pinpoints areas where conflicts may arise between functions

Mod G


CC04264432.ppt

N2 Diagram

Blank entry indicates no interface

OutputOutput

Input

Input

F1

F2

F3

F4

F5

F6

F2 F4

F3 F5

F1 F2

F2 F5

F3 F6

F1 F5

Mod G


CC04264433.ppt

N2 Diagram for CWS Sense-Object Function

• Simple in this case

• Quickly becomes large and complex

• Not particularly good for presentations

• Spread sheets work well

Requestpulse

PULSECMDS

Generatepulse

Detectechoes

Screenechoes

Detectclosing

Warndriver

Cautiondriver

DIGSIGS

DET

CONF CONF

Mod G


CC04264434.ppt

Summary of Functional Analysis

• Structured approach to describing how a system is used and what is does

• Function name should identify the action or transformation accomplished by the function using verb-noun syntax

• Functional analysis helps develop

– Functional requirements

– Functional allocations

– Functional architecture

Mod G


CC04264435.ppt

Summary of Functional Analysis (cont)

• Functional decomposition helps

– Develop operational concepts

– Develop functional sequences

– Break design roadblocks

– Develop innovative solutions

– Explaining a design

– Controlling the level of detail

– Serves as a team-building activity

Mod G


CC04264436.ppt

Summary of Functional Analysis (cont)

• Functional analysis tools

– Tools are aids, not the process nor a substitute for thinking

– Modify the tool to fit your needs

– Tools have limitation

mod g gt aerospace systems engineering cc04264377.ppt aerospace systems engineering functional...

Documents