design synthesis - middle east technical...

Chapter 6 Design Synthesis

57

Figure 6-1. Design Synthesis

• Outputs:– Physical Architecture (Product Elements and Software Code)– Decision Database

• Inputs:– Functional Architecture

• Enablers:– IPTs, Decision Database, Automated Tools, Models

• Controls:– Constraints; GFE, COTS, & Reusable S/W; System concept

& subsystem choices; organizational procedures

• Activities:– Allocate functions and constraints to system elements– Synthesize system element alternatives– Assess technology alternatives– Define physical interfaces– Define system product WBS– Develop life cycle techniques and procedures– Integrate system elements– Select preferred concept/design

Controls

Enablers

OutputsInputsDesign

Synthesis

CHAPTER 6

DESIGN SYNTHESIS

and restructure hardware and software componentsin such a way as to achieve a design solutioncapable of satisfying the stated requirements.During concept development, synthesis producessystem concepts and establishes basic relation-ships among the subsystems. During preliminaryand detailed design, subsystem and componentdescriptions are elaborated, and detailed interfacesbetween all system components are defined.

The physical architecture forms the basis fordesign definition documentation, such as, speci-fications, baselines, and work breakdown struc-tures (WBS). Figure 6-1 gives an overview of thebasic parameters of the synthesis process.

6.1 DESIGN DEVELOPMENT

Design Synthesis is the process by which conceptsor designs are developed based on the functionaldescriptions that are the products of FunctionalAnalysis and Allocation. Design synthesis is a cre-ative activity that develops a physical architecture(a set of product, system, and/or software elements)capable of performing the required functions withinthe limits of the performance parameters pre-scribed. Since there may be several hardware and/or software architectures developed to satisfy agiven set of functional and performance require-ments, synthesis sets the stage for trade studies toselect the best among the candidate architectures.The objective of design synthesis is to combine

Systems Engineering Fundamentals Chapter 6

58

Characteristics

Physical architecture is a traditional term. Despitethe name, it includes software elements as well ashardware elements. Among the characteristics ofthe physical architecture (the primary output ofDesign Synthesis) are the following:

• The correlation with functional analysisrequires that each physical or software compo-nent meets at least one (or part of one) func-tional requirement, though any component canmeet more than one requirement,

• The architecture is justified by trade studies andeffectiveness analyses,

• A product WBS is developed from the physicalarchitecture,

• Metrics are developed to track progress amongKPPs, and

• All supporting information is documented in adatabase.

Modular Designs

Modular designs are formed by grouping compo-nents that perform a single independent functionor single logical task; have single entry and exitpoints; and are separately testable. Grouping re-lated functions facilitates the search for modulardesign solutions and furthermore increases thepossibility that open-systems approaches can beused in the product architecture.

Desirable attributes of the modular units includelow coupling, high cohesion, and low connectiv-ity. Coupling between modules is a measure of theirinterdependence, or the amount of informationshared between two modules. Decoupling mod-ules eases development risks and makes later modi-fications easier to implement. Cohesion (also calledbinding) is the similarity of tasks performed withinthe module. High cohesion is desirable because itallows for use of identical or like (family or se-ries) components, or for use of a single componentto perform multiple functions. Connectivity refers

to the relationship of internal elements within onemodule to internal elements within another mod-ule. High connectivity is undesirable in that it cre-ates complex interfaces that may impede design,development, and testing.

Design Loop

The design loop involves revisiting the functionalarchitecture to verify that the physical architecturedeveloped is consistent with the functional andperformance requirements. It is a mapping betweenthe functional and physical architectures. Figure6-2 shows an example of a simple physical archi-tecture and how it relates to the functional archi-tecture. During design synthesis, re-evaluation ofthe functional analysis may be caused by the dis-covery of design issues that require re-examinationof the initial decomposition, performance alloca-tion, or even the higher-level requirements. Theseissues might include identification of a promisingphysical solution or open-system opportunities thathave different functional characteristics than thoseforeseen by the initial functional architecturerequirements.

6.2 SYNTHESIS TOOLS

During synthesis, various analytical, engineering,and modeling tools are used to support anddocument the design effort. Analytical devices suchas trade studies support decisions to optimizephysical solutions. Requirements Allocation Sheets(RAS) provide traceability to the functional andperformance requirements. Simple descriptionslike the Concept Decription Sheet (CDS) help visu-alize and communicate the system concept. Logicmodels, such as the Schematic Block Diagram(SBD), establish the design and the interrelation-ships within the system.

Automated engineering management tools such asComputer-Aided Design (CAD), Computer-Aided-Systems Engineering (CASE), and theComputer-Aided-Engineering (CAE) can help or-ganize, coordinate and document the design effort.CAD generates detailed documentation describ-ing the product design including SBDs, detailed


59

Figure 6–2. Functional/Physical Matrix

Function Performed

Preflight check X X X X X

Fly

Load X

Taxi X X X

Take-off X X

Cruise X X X X

Recon X X X X

Communicate X

–

–

Surveillance

–

–

FUNCTIONAL

ARCHITECTURE

Communi-cations

NavSystem

FireControl

AirFrame

Engine

Aircraft

PHYSICAL ARCHITECTURE

drawings, three dimensional and solid drawings,and it tracks some technical performance measure-ments. CAD can provide significant input for vir-tual modeling and simulations. It also provides acommon design database for integrated designdevelopments. Computer-Aided Engineering canprovide system requirements and performanceanalysis in support of trade studies, analysis re-lated to the eight primary functions, and cost analy-ses. Computer-Aided Systems Engineering canprovide automation of technical managementanalyses and documentation.

Modeling

Modeling techniques allow the physical productto be visualized and evaluated prior to designdecisions. Models allow optimization of hardware

and software parameters, permit performancepredictions to be made, allow operational se-quences to be derived, and permit optimumallocation of functional and performance require-ments among the system elements. The traditionallogical prototyping used in Design Synthesis is theSchematic Block Diagram.

6.3 SUMMARY POINTS

• Synthesis begins with the output of FunctionalAnalysis and Allocation (the functional archi-tecture). The functional architecture is trans-formed into a physical architecture by definingphysical components needed to perform thefunctions identified in Functional Analysis andAllocation.


60

• Many tools are available to support thedevelopment of a physical architecture:

– Define and depict the system concept (CDS),

– Define and depict components and theirrelationships (SBD), and

– Establish traceability of performancerequirements to components (RAS).

• Specifications and the product WBS are derivedfrom the physical architecture.


61

Figure 6-3. Concept Description Sheet Example

SteeringCommands

Missile

Radio

Computer

MissileTracking

Radar

Target

TargetTracking

Radar

External Command Guidance System

SUPPLEMENT 6-A

CONCEPT DESCRIPTIONSHEET

The Concept Description Sheet describes (in tex-tual or graphical form) the technical approach orthe design concept, and shows how the system will

be integrated to meet the performance and func-tional requirements. It is generally used in earlyconcept design to show system concepts.


62

Figure 6-4. Schematic Block Diagram Example

Inert GasPressurization

Subsystem

OxidizerStorage

Subsystem

FuelStorage

Subsystem

SolenoidValve

(Oxidizer)

SolenoidValve(Fuel)

ElectricalPower

Subsystem(Ref) Manual Control and

Display Subsystem(Ref)

MSRV Guidanceand Navigation

Subsystem(Ref)

Rocket Engine Nozzle Assemblies

PitchThrust

RollThrust

YawThrust

LongitudinalVelocity

Increments

Inert Gas PressurantOxidizer Remaining Indication

Fuel Remaining Indication

OxidizerFuel

Command Signals

Command Signals

Command Signals

Command Signals

Attitude andNavigational

Signals

Moon Station Rendezvous Vehicle

Attitude Control andManeuvering Subsystem

SUPPLEMENT 6-B

SCHEMATIC BLOCKDIAGRAMS

between components and their functional origin;and provide a valuable tool to enhance configura-tion control. The SBD is also used to developInterface Control Documents (ICDs) and providesan overall understanding of system operations.

A simplified SBD, Figure 6-4, shows how compo-nents and the connection between them are pre-sented on the diagram. An expanded version isusually developed which displays the detailed func-tions performed within each component and a de-tailed depiction of their interrelationships. Ex-panded SBDs will also identify the WBS numbersassociated with the components.

The Schematic Block Diagram (SBD) depicts hard-ware and software components and their interrela-tionships. They are developed at successively lowerlevels as analysis proceeds to define lower-levelfunctions within higher-level requirements. Theserequirements are further subdivided and allocatedusing the Requirements Allocation Sheet (RAS).SBDs provide visibility of related system elements,and traceability to the RAS, FFBD, and other sys-tem engineering documentation. They describe asolution to the functional and performance require-ments established by the functional architecture;show interfaces between the system componentsand between the system components and othersystems or subsystems; support traceability


63

Figure 6-5. Requirements Allocation Sheet (Example)

Requirements Functional Flow Diagram Title and No. 2.58.4 EquipmentAllocation Sheet Provide Guidance Compartment Cooling Identification

Function Name Functional Performance and Facility Nomenclature CI or Detailand No. Design Requirements Rqmnts Spec No.

2.58.4 Provide The temperature in the guidance Guidance Compart- 3.54.5Guidance compartment must be maintained ment CoolingCompartment at the initial calibration tempera- SystemCooling ture of +0.2 Deg F. The initial cal-

ibration temperature of the com-partment will be between 66.5and 68.5 Deg F.

2.58.4.1 Provide A storage capacity for 65 gal of Guidance Compart- 3.54.5.1Chilled Coolant chilled liquid coolant (deionized ment Coolant(Primary) water) is required. The temperature Storage Subsystem

of the stored coolant must bemonitored continuously. The storedcoolant must be maintained withina temperature range of 40–50 DegF. for an indefinite period of time.The coolant supplied must be freeof obstructive particles 0.5 micronat all times.

SUPPLEMENT 6-C

REQUIREMENTS ALLOCATIONSHEET

The RAS initiated in Functional Analysis andAllocation is expanded in Design Synthesis todocument the connection between functionalrequirements and the physical system. It providestraceability between the Functional Analysis and

Allocation and Synthesis activities. It is a majortool in maintaining consistency between functionalarchitectures and the designs that are based onthem. (Configuration Item (CI) numbers match theWBS.)


64