mod i georgia tech aerospace systems engineering cc04264466.ppt aerospace systems engineering...

Mod I

Georgia Tech AerospaceSystems Engineering

CC04264466.ppt

Aerospace Systems Engineering

Synthesis

Mod I


CC04264467.ppt

System Synthesis*

• Defines and designs system products and process solutions• Defines and integrates a physical architecture that satisfies the

functional architecture• Conducted to a level of detail required to satisfy contract

requirements• Conducted iteratively with Functional Analysis & Allocation and

Requirements Analysis• Produces configuration items and system elements• Defines internal and external physical interfaces• Selects the preferred set of product and process solutions• Enables verification of contractual requirements

Synthesis results in the definition and integration of the system as a physical architecture or configuration

*ANSI/EIA-632, Processes for Engineering a System

Mod I


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

CC04264028.ppt

The Systems Engineering ProcessPer INCOSE Systems Engineering Handbook

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

Mod I


CC04264469.ppt

Objective of Synthesis

• Create an architecture (system elements plus their characteristics and arrangement) that meets the following:– Satisfies the requirements– Satisfies the external interfaces– Implements the functional architecture– Acceptably close to the true optimum– Consistent with the technical maturity and acceptable risks of

available elements– Is extensible (accommodates growth)– Provides the basis for subsequent development to proceed– Is robust (provides for detailed design with minimal

backtracking)

Mod I


CC04264470.ppt

Synthesis: A Critical Part of the Iterative Design Process

• In the analysis of the system during the Requirements Analysis and Allocation phase, a functional architecture is needed to satisfy the requirements

• In the analysis of the system during the Functional Analysis and Allocation phase, a physical architecture is needed to embody the functionality

• In the analysis of the system during the Synthesis phase, one of more physical architectures (usually containing subsystems) are defined

• Each subsystem at any given level of detail may be considered a system in its own environment at the next lower level of detail (with its own set of requirements, functional architecture, and physical architecture)

• Consequently, synthesis (as well as requirements and functional analysis and allocation) can and should be applied at all levels of the system

Mod I


CC04264471.ppt

Synthesis Activity by Development Phase

• Pre-concept exploration– Little to no synthesis

– Provide meaning to top-level functions and performance

• Concept exploration– Concept descriptions to:

• Assess technical feasibility• Assess cost, performance, and effectiveness

• Product definition and risk reduction thru EMD– Detailed system definition

Mod I


CC04264472.ppt

Physical Decomposition

• Decomposition is the act of partitioning the system into its components– Components are represented by subsystems

– It is an iterative process

• Why decomposition?– Reduces complexity

– Creates manageable chunks of design for distribution and detailed design

– Allows for a more complete design

Mod I


CC04264473.ppt

Practical Decomposition Considerations

• Try to use known decomposition of previously developed systems

• Each subsystem should be capable of being developed and tested independently of the other subsystems

• Design with a goal to limit the effects of the future changes to individual subsystems

• The specified subsystem can be used for the development of a product family (systems, hardware, software)

• Prefer to achieve minimum interaction and interdependence between subsystems

• Check for the need to reallocate functions in each decomposition level based on a consideration for the next level of decomposition (N+1 consideration)

Mod I


CC04264474.ppt

Decomposing a Fighter

Fuel

Engines

Hydraulics

Landing Gear

Ejection

Radar

Avionics

Weapon

Mod I


CC04264475.ppt

Alternatives for Concept Exploration

• Provide concrete design concepts for:

– Examining technical feasibility

– Examining costs (development, procurement, operations and support)

– Examining risk (technical roadmap, not program execution)

– Developing and understanding of relationships between requirements, implementation, costs, risks, etc.

– Performing trade studies

– Evaluating operational effectiveness

Mod I


CC04264476.ppt

System Synthesis for Concept Exploration

• Defines and designs candidate system products and process solutions

• Defines and integrates a physical architecture that satisfies the various functional architecture

• Conducted to a level of detail required to satisfy contract requirements answer questions about feasibility, cost, schedule, and design relationships

• Conducted iteratively with Functional Analysis & Allocation and Requirements Analysis

• Produces configuration items and system elements

• Defines internal and external physical interfaces

• Selects the preferred set of candidate product and process solutions

• Enables verification of contractual requirementsAdditions in italics

Mod I


CC04264477.ppt

Alternatives for Concept Exploration (cont)

• Selecting alternatives

– Identify requirements that compete for scarce system resources

– Emphasize certain combinations of requirements in one alternative and others combinations in other alternatives

– Don’t worry about design consistency

Mod I


CC04264478.ppt

Example of Competing Requirements

• Very stealthy

• Supersonic

• Landing weight less than 40,000 lb

• Combat radius of 800 NM

• Weapon payload of 8,000 lb

• Unit fly away cost less than $40M in U.S. dollars

Mod I


CC04264479.ppt

Examples of Alternatives

1) Subsonic, very stealthy design that goes 800 NM with a payload of 8,000 lb

2) Supersonic, moderately stealthy design that goes 500 NM with a payload of 5,000 lb

3) Low cost, supersonic, minimally stealthy design that carries 8,000 lb of payload

4) ???

Purpose is to understand relationships

Mod I


CC04264480.ppt

Guiding Principle for Concept Exploration

The purpose of synthesis during Concept Exploration is to support answering questions about requirements, cost, risk, and technical feasibility;

Not to develop a design

Mod I


CC0426481.ppt

Products of System Synthesis

• Synthesis produces the fundamental sources of data for developing completing:

– The system, configuration item, and critical item specifications

– Interface control documents

– Consolidated facility requirements

– Procedural handbooks and other forms of instructional data

– Task loading of personnel

– Operation computer programs

– Specification trees

– Dependent elements of the WBS

Mod I


CC04264482.ppt

Modularity Principle

• The goal of modular decomposition is to reduce the cost of the system by allowing modules to be designed and revised independently

• A decomposition is modular when:– Each module’s structure is simple enough to be understood

fully– The interfaces between the modules are well defined and

concise (to minimize cost of future changes)– All modules are independent. Not assumptions need to be

made about other modules for the design to proceed

Mod I


CC04264483.ppt

Decomposition Balance Considerations

• Decomposition balance is the appropriate distribution of elements across sensible groupings

• A physical decomposition is balanced when:– The functions have been sensibly distributed across the subsystems

– Ideally, no subsystem has a majority of the allocated functions

– Each subsystem has at least one function allocated to it

• Good decompositions balance results in a more manageable and understandable design

• Poor decomposition balance results with overly complex interfaces

• Decomposition balancing must be performed in consideration of system constraints (e.g., previously designed system functions that are carried over to the present design)

Mod I


CC04264484.ppt

Abstraction and Information Hiding

• Abstraction is the summarizing of the most important propertiesdescribing each module while delaying description of theunnecessary details

• Information Hiding is the technique of hiding all the details of anelement that do not contribute to its essential external characteristics

• Based on object-oriented design principles, abstraction and information hiding focus on the essential characteristics of a modulerelative to the viewer– Significant system details are emphasized to the reader/user while

other details are described in the lower level decompositions– Comprehension of the information within each decomposition level

is simplified, without the need to understand the lower levels ofdesign (which are probably not even designed yet)

Mod I


CC04264485.ppt

Developing the System’sPhysical Architecture

• Derive and list the subsystems needed to produce each major output and consume each major input of the system in its environment– Subsystems are used to represent a thing, or a collection of

things, that together embody functionality for the system being designed

– A subsystem can either:• Represent components of a known system design

• Be derived to embody a logical grouping of functions to support the system being designed

• Create a physical hierarchy diagram (decomposition)

Mod I


CC04264486.ppt

Developing the System’sPhysical Architecture (cont)

• Describe each subsystem with a short sentence– 1-4 lines– detailed description can be in an appendix to a

spec or design document• Describe each subsystem with a short sentence

– 1-4 lines– Detailed description can be in an appendix to a

spec or design document– Modify the descriptions as the design evolves

Mod I


CC04264487.ppt

Developing the System’sPhysical Architecture (cont)

• Draw the subsystems in the system architecture diagram using the system in its environment– Each subsystem is detailed in later steps to show specific

functionality

• Connect the subsystems together using SADT techniquesadding appropriate labels to each data/information flow or interface

• Write a short description for each subsystem and information flow or interface drawn

• Iterate the above steps as necessary to fully define the system’s physical architecture

Mod I


CC04264488.ppt

CWS - Physical Decomposition

CWS

RadarReceiver

CentralComputer

OperatorPanel

RadarTransmitter

Mod I


CC04264489.ppt

CWS - Description of Subsystems

• Radar Transmitter - Needed for the transmission of RFself-test

• Radar Receiver - Necessary for the reception of reflectedRF energy pulses during the detection of hazardous objects and self-test

• Central Computer - Used to control pulsing, computedistance vs speed, control testing, and fault detection

• Operator Panel - Provides interface to driver by receiving test requests, indicating faults, and cautioning/warning ofhazards

Mod I


CC04264490.ppt

CWS - Top-Level Architecture

CWS

ObjectsRadar Transmitter

Radar Receiver

Central Computer

Operator Panel

RF_Pulses

Driver

Vis_WarnAud_WarnVis_Caut

Fault_Note

DriverTes_Req

Confirmations

Test_CMD

Fault

Veh_Elect Veh_Elect

Power Ind

Speed Data

OVJ_DataDetection

Reference Table

Pulse_CMDS

Scale_SELSYNCSelf_Test_RF

ObjectsEcho_RF

Mod I


CC04264491.ppt

5 Minute Workout #2Identifying Subsystems and Developing a Systems Physical Architecture

Using the specification paragraph below (same as in Workout #1), list the subsystems which are internal to the EWS. Then draw their representative boxes and simple data flows inside the EWS system box for the diagram on the next page. Label each box and internal 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, an stop monitoring the particular signal.

Subsystems

Mod I


CC04264492.ppt

5 Minute Workout #2 (cont)

EWS

Printer

Fault_Messages

AlarmAlarm_Out

SensorSignals

Operator

Mem_ Cartridge_In

Operator Commands

Operator

Mem_Cartridge_Out

Warning_Messages

Mod I


CC04264493.ppt

Allocating Functionality to theNext Level of Design

• Assign each function from the functional architecture to aparticular subsystem– Recall any inherent allocation constraints imposed by the

specification or other governing entity

• Decompose the functions down into more functional resolution, if necessary, to spit the functionality between subsystems (recalling the modularity principle)

• Draw a functional representation of each one of the subsystem modules which require further decomposition (functional and physical)

Mod I


Allocating Functionality to theNext Level of Design (cont)

• Draw the outputs and the inputs to the functions. Maintain the functional relations/data flows established at the higher level of the design– Select an output from the subsystem and connect it to the subsystem

function which produces it– Determine what inputs internal to the system are required to produce that

output an connect them to the functions that produce them– Determine what inputs external to the system are required to produce the

output and connect them to the external elements that produce them– Continue this effort for all remaining subsystems outputs

• Recognize that the process of functional allocation and synthesis may be continued to lower and lower levels of design as required to fulfill as specification requirements

CC04264494.ppt

Mod I


CC04264495.ppt

Additional Considerations forFunctional Analysis and Synthesis

• Trade studies should be conduced where necessary to determine the best design between tow or more competing physical architectures– Compare and contrast different solutions for satisfying requirements

(and embodying the functional architecture)

– Evaluate hardware vs software solutions

• Systems may be design from perspectives beyond just functions and physical elements, including:– Behavior

– Processes (collections of functionality)

– Weight

– Performance

Mod I


CC04264496.ppt

Summary of Synthesis

• The objective of synthesis during Concept Exploration is to support understanding

• The objective of synthesis during later phases is designing the product or service

• Functional analysis, synthesis, and requirements analysis are all interrelated

• The key to good system design is iteration with solid trade studies

• Functional and physical architectures document the identification and allocation of elements needed in a system

mod i georgia tech aerospace systems engineering cc04264466.ppt aerospace systems engineering...

Documents