1. Mod I Georgia Tech Aerospace Systems Engineering CC04264466.ppt Aerospace Systems Engineering Synthesis

2. Mod I Georgia Tech Aerospace Systems Engineering 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

3. Mod I Georgia Tech Aerospace Systems Engineering 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 Process Per 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 specifications and 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 System analysis and control (balance) Control loop

4. Mod I Georgia Tech Aerospace Systems Engineering 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)

5. Mod I Georgia Tech Aerospace Systems Engineering 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

6. Mod I Georgia Tech Aerospace Systems Engineering 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

7. Mod I Georgia Tech Aerospace Systems Engineering 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

8. Mod I Georgia Tech Aerospace Systems Engineering 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)

9. Mod I Georgia Tech Aerospace Systems Engineering CC04264474.ppt Decomposing a Fighter Fuel Engines Hydraulics Landing Gear Ejection Radar Avionics Weapon

10. Mod I Georgia Tech Aerospace Systems Engineering 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

11. Mod I Georgia Tech Aerospace Systems Engineering 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 requirements Additions in italics

12. Mod I Georgia Tech Aerospace Systems Engineering 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

13. Mod I Georgia Tech Aerospace Systems Engineering 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

14. Mod I Georgia Tech Aerospace Systems Engineering 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

15. Mod I Georgia Tech Aerospace Systems Engineering 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

16. Mod I Georgia Tech Aerospace Systems Engineering 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

17. Mod I Georgia Tech Aerospace Systems Engineering 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

18. Mod I Georgia Tech Aerospace Systems Engineering 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)

19. Mod I Georgia Tech Aerospace Systems Engineering CC04264484.ppt Abstraction and Information Hiding Abstraction is the summarizing of the most important properties describing each module while delaying description of the unnecessary details Information Hiding is the technique of hiding all the details of an element 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 module relative 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 of design (which are probably not even designed yet)

20. Mod I Georgia Tech Aerospace Systems Engineering CC04264485.ppt Developing the System’s Physical 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)

21. Mod I Georgia Tech Aerospace Systems Engineering CC04264486.ppt Developing the System’s Physical 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

22. Mod I Georgia Tech Aerospace Systems Engineering CC04264487.ppt Developing the System’s Physical 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 techniques adding 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

23. Mod I Georgia Tech Aerospace Systems Engineering CC04264488.ppt CWS - Physical Decomposition CWS Radar Receiver Central Computer Operator Panel Radar Transmitter

24. Mod I Georgia Tech Aerospace Systems Engineering CC04264489.ppt CWS - Description of Subsystems Radar Transmitter - Needed for the transmission of RF self-test Radar Receiver - Necessary for the reception of reflected RF energy pulses during the detection of hazardous objects and self-test Central Computer - Used to control pulsing, compute distance vs speed, control testing, and fault detection Operator Panel - Provides interface to driver by receiving test requests, indicating faults, and cautioning/warning of hazards

25. Mod I Georgia Tech Aerospace Systems Engineering CC04264490.ppt CWS - Top-Level Architecture CWS Objects Radar Transmitter Radar Receiver Central Computer Operator Panel RF_Pulses Driver Vis_Warn Aud_Warn Vis_Caut Fault_Note Driver Tes_Req Confirmations Test_CMD Fault Veh_Elect Power Ind Speed Data OVJ_Data Detection Reference Table Pulse_CMDS Scale_SEL SYNC Self_Test_RF Objects Echo_RF

26. Mod I Georgia Tech Aerospace Systems Engineering CC04264491.ppt 5 Minute Workout #2 Identifying 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

27. Mod I Georgia Tech Aerospace Systems Engineering CC04264492.ppt 5 Minute Workout #2 (cont) EWS Printer Fault_ Messages Alarm Alarm_Out Sensor Signals Operator Mem_ Cartridge_In Operator Commands Operator Mem_Cartridge_Out Warning_Messages

28. Mod I Georgia Tech Aerospace Systems Engineering CC04264493.ppt Allocating Functionality to the Next Level of Design Assign each function from the functional architecture to a particular 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)

29. Mod I Georgia Tech Aerospace Systems Engineering Allocating Functionality to the Next 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

30. Mod I Georgia Tech Aerospace Systems Engineering CC04264495.ppt Additional Considerations for Functional 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

31. Mod I Georgia Tech Aerospace Systems Engineering 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