Aerospace Systems Engineering

Chapter 1- Overview of the Engineering of Systems

1

Aerospace Systems Engineering

ByDr. Sartuk KARASOY

Middle East Technical [email protected]


The viewgraphs are mainly courtesy of Dr. Dennis Buede.


2

Engineering of Systems

• Broad perspective, not deep

• What must be done, how well it must be done, how it should be tested before what it is

• Clear focus on system's objectives

• Design: start with supersystem, migrate towards subsystems and components

• Integration: start with pieces and build to system in its real environment


3

System Life Cycle

ConceptDefinition

Identificationof Need

Refinement

PreliminarySystem Design

DetailedConfigurationItem Design

SystemIntegration

Production &Manufacturing

Deployment

Operation

Retirement/Disposal

Maintenance

Time

Training

Figure 1.1


4

Cost

Time

100%

80%

60%

40%

20%

0%

Conceptual& Preliminary

Design

DetailedDesign &

Integration

Constructionor

Production

Use,Refinement& Disposal

Cost Committed

Cost Incurred

Reason Why

Engineering a System Needs To Be Done

Well Early

Figure 1.2


5

Definitions• Engineering: discipline for transforming

scientific concepts into cost-effective products through the use of analysis and judgment

• Engineering of a System: engineering discipline that develops, matches, and trades off requirements, functions, and alternate system resources to achieve a cost-effective, life-cycle balanced product based upon the needs of the stakeholders


6

Understand UserRequirements, Develop

System Concept andValidation Plan

Develop SystemPerformance Specification

and SystemValidation Plan

Expand PerformanceSpecifications into CI

“Design-to” Specificationsand CI Verification Plan

Evolve “Design-to”Specifications into

“Build-to” Documentationand Inspection Plan

Fab, Assemble andCode to “Build-to”

Documentation

Inspect“Build-to”

Documentation

Assemble CIs andPerform CI Verification

to CI “Design-to”Specifications

Integrate System and Perform SystemVerification to

Performance Specifications

Demonstrate andValidate System to

User Validation Plan

Decom

position

and

Definition

Inte

grat

ion

and

Qua

lific

atio

n

DesignEngineering

Systems Engineering

. . . . . .

Time

Vee Model of Design and Integration

Figure 1.3


7

Vee Model with Onion PeelsUnderstand User

Requirements, DevelopSystem Concept and

Validation Plan

Develop SystemPerformance Specification

and SystemValidation Plan

Expand PerformanceSpecifications into CI

“Design-to” Specificationsand CI Verification Plan

Evolve “Design-to”Specifications into

“Build-to” Documentationand Inspection Plan

Fab, Assemble andCode to “Build-to”

Documentation

Inspect“Build-to”

Documentation

Assemble CIs andPerform CI Verification

to CI “Design-to”Specifications

Integrate System and Perform SystemVerification to

Performance Specifications

Demonstrate andValidate System to

User Validation Plan

Decom

position

and

Definition

Inte

grat

ion

and

Qua

lific

atio

n

DesignEngineering

Systems Engineering

. . . . . .

Time

Peels of the Onion


8

“g-g” Design Region for a Racecar (from [Milliken and Milliken, 1995])

Race Car Example of

Requirements and Tests

Operational Need or Mission Requirements - Partially Validated by Operational Test (Proven by Real-World Experience)

System Level Requirements - Verified by System-Level Tests

Component Level Requirements - Verified by Component-Level Tests

Win the Indianapolis 500 Pretrial average speed of 215 mph Average speed in the 500 of 190 mph

Top speed of X mph· Acceleration in all directions, g-g space Average standard pit time of Y seconds

Engine horsepower of x Btu Body’s drag coefficient of y Range per tank of gas of z miles

Figure 1.4


9

Development Phase Examples of Decisions in Systems Engineering Conceptual design Should a conceptual design effort be undertaken?

Which system concept (usually a mixture of technologies) should be the basis of the design? Which technology for a given subsystem should be chosen? What existing hardware and software can be used? Is the envisioned concept technically feasible, based on cost, schedule and performance

requirements? Should additional research be conducted before a decision is made?

Preliminary design Should a preliminary design effort be undertaken? Which specific physical architecture should be chosen from several alternatives? To which physical resource should a particular function be allocated? Should a prototype be developed? If so, to what level of reality? How should validation and acceptance testing be structured?

Full-scale design Should a full-scale deign effort be undertaken? Which configuration items should be bought instead of manufactured? Which detailed design should be chosen for a specific component given that one or more

performance requirements are critical?

Integration and qualification

What is the most cost-effective schedule for implementation activities? What issues should be tested? What equipment, people, facilities should be used to test each issue? What models of the system should be developed or adapted to enhance the effectiveness of

integration? How much testing should be devoted to each issue? What adaptive (fallback testing in case of a failure) testing should be planned for each issue?

Product refinement Should a product improvement be introduced at this time? Which technology or technologies should be the basis of the product improvement? What redesign is best to meet some clearly defined deficiency in the system? How should the refinement of existing systems be implemented given safety, performance and cost

criteria?

Table 1.3


10

Management

SEProcess

Domain/Stakeholders

Technology(EngineeringDisciplines)

Modeling,Simulation,Analysis

Expertise Required on the Systems Engineering Team

Figure 1.5


11

Waterfall Model

SystemsRequirements

SoftwareRequirements

PreliminaryDesign

Detailed Design

Coding andDebugging

Integrationand Testing

Operations andMaintenance

Figure 1.6


12

2ndPrototype

1stPrototype

3rdPrototype

OperationalPrototype

BenchmarksModelsSimulations

Risk Analysis

Risk Analysis

Risk Analysis

Evaluate Alternatives;Identify and Resolve Risks

Progressthrough phases

Cumulative Cost

Determine Objectives,Alternatives, and

Constraints

CommitmentPartition

ReviewRequirements

Plan

DevelopmentPlan

Integrationand Test Plan

Plan NextPhases

OperationalConcept Software

Requirements

RequirementsValidation

SoftwareProductDesign

Design Validationand Verification

DetailedDesign

Code

Unit Test

Integrationand Test

AcceptanceTest

ImplementationDevelop and VerifyNext Level Product

Spiral Model

Figure 1.7


13

Designing for Concurrency & Risk Mitigation


14

Vee: Evolutionary

& Incremental

DevelopmentIncremental Development: Single Delivery

Evolutionary DevelopmentIncremental Development: Incremental Delivery

SE Models


15

Operational Concept

SE Architectures

FunctionalArchitecture

PhysicalArchitecture

Operational Architecture

Interface Architecture

Figure 1.9 (modified)


16

F-22 Weapon System

Vehicle Training Support

AvionicsSystems

Utilities &Subsystems

CockpitSystems

VehicleManagement

System

ElectronicWarfare

Navigation,Identification

Processing

Controls&

Displays

StoresManagement

InertialReference

SystemRadar

Sample Physical Architecture

Figure 1.10


17

Design & IntegrationSystem

XYZ Weapon System

OperationalSystem

TrainingSystem

RetirementSystem

AvionicsSystems

Utilities &Subsystems

CockpitSystems

VehicleManagement

System

ElectronicWarfare

Navigation,Identification

Processing

Controls&

Displays

StoresManagement

InertialReference

SystemRadar

ManufacturingSystem

DeploymentSystem

RefinementSystem

Life-Cycle Physical Architecture

Figure 1.11


18

Another View of the Design Process

OperationalNeed

System Design SegmentDesign

Element Design ComponentDesign

OperationalRequirement

SystemOperationalArchitecture

Segment SpecsSegment

OperationalArchitectures

Element SpecsElement

OperationalArchitecturesComponent

SpecsComponentOperational

ArchitecturesCI Specs

Figure 1.12


19

Document Titles Document ContentsProblem Situation orMission Element NeedStatement and SystemsEngineering ManagementPlan (SEMP)

Definition of stakeholders and their relationships Stakeholders’ description of the problem and its context Description of the current system Description of major objectives in general terms Definition of the systems engineering management

structure and support tools that will be responsible fordeveloping the system

Operational Need orOperational Requirement(ORD)

Definition of the problem needing solution by the system(including the context and external systems with whichthe system must interact)

Definition of the operational concept on which the systemwill be based

Creation of the structure for defining requirements Description of the requirements in the stakeholders’

language in great breadth but little depth Trace of every requirement to a recorded statement or

opinion of the stakeholders Description of trade-offs between performance

requirements, including cost and operational effectivenessSystem Requirements(SRD)

Restatement of the operational concept on which thesystem will be based

Definition of the external systems in engineering terms Restatement of the operational requirements in

engineering language Trace of every requirement to the previous document Justification of engineering version of the requirements in

terms of analyses, expert opinions, stakeholder meetings Description of test plan for each requirement

System RequirementsValidation

Documents analyses to show that the requirements in theSRD are consistent, complete and correct, to the degreepossible

Demonstrates that there is at least one feasible solution tothe design problem as defined in the SRD

TypicalRequirement

sDocuments

Table 1.4


20

Comparison of the Relative Costto Fix Software

in Various Life Cycle Phases [from Davis]

Phase of Life Cycle Relative Cost of Repair Given the Fix Is Found in this Phase Requirements 2 (1, 3) Design 5 (3, 6) Coding 10 Unit Test 20 (15, 50) Acceptance Test 50 (20, 80) Maintenance 200 (40, 400)

Table 1.5


21

Development Period

Stakeholders

People & Tools

Documents& Money

Design &IntegrationDocuments

DevelopmentSystem

DevelopSystem

ABC

Guidance & Approvals

Figure 1.13


22

Period of Pre-Initial Operational CapabilityStakeholders

Documents

People & Tools

Facilities, People, & Equipment

Specifications

Manufactured, Deployed & Tested Items

DevelopmentSystem

ManufacturingSystem

DeploymentSystem

TrainingSystem

Train O/Mof System

ABC

DeploySystem

ABC

ManufactureSystem

ABC

DevelopSystem

ABC

Guidance& Approvals

Documents& Money

Figure 1.14


23

Period of Operational Use and Refinement

Stakeholders

Documents

People & Tools

Specifications

Deployed ItemsNeeds

Trained O/M

ManufactureSystem

ABC

Documents& Money


ManufacturingSystem

TrainingItems

ManufacturedItems

DeploySystem

ABC


DeploymentSystem Training

System

RefinementSystem

Train O/Mof System

ABC

UseSystem

ABC

RefineSystem

ABC

Guidance& Approvals

Figure 1.15


24

Retirement Period

Stakeholders

ABC

Needs

People & Tools

-

-

Transported,DecommissionedABC’s

DecommissionedABC’s

UseSystem

ABC

DeploySystem

ABC

RetireSystem

ABC

WasteMaterials

Laws &Regulations

DeploymentSystem

RetirementSystem

People& Tools

Specifications

Figure 1.16


25

Cycle Model

form, fit, function

fit, function

form, function

CUSTOMER

Determination ofCustomer Desire

1

Delivery& Sales

Realization

1

Translation intoManufacturable

Solution

Translation ofRequirements into

Abstract Specs

Modeling

Prototyping

2Pilot Tests

Creation ofAbstract Solution

Profitability?Feasibility?

Effort? Risks?

Improvement ofTechnologies &

External Resources

Coordination ofExternal

Resources

3

OrderProcessing

3

ContolDocument

ContolDocument

ContolDocument

Verification Cycles

4

Controlling Cycles

StrategicCheck

5

Design and Integration Cycles

1. Core cycle: Realization of stakeholder needs, followed by requirements development, design, manufacturing and product delivery2. Verification cycle: Analysis, simulation, prototyping, integration, and testing

Management Cycles3. Technologies and external resources cycle: Insertion of the appropriate technologies and resources into the systems engineering process4. Controlling cycle: Configuration management of the design process and multiple product releases and updates5. Strategic check cycle: Management assessment and approval of product development

Figure 1.17


26

DevelopFunctional

Architecture

DesignPhysical

Architecture

DevelopOperationalArchitecture

ObtainApproval &Document

Define the Design

Problem Five Major Functions of Systems Engineering Design

Figure 1.18


27

Higher LevelRequirements &Constraints from

Approved Baseline

Define theproblem, the

system/segment/CIBoundary, & the

objectives

Develop theOp’l Concept

for the Sys,Seg,CIunder analysis

Define the required

behavior ina functionalinteraction

diagram

Define therequired functional

performanceby quantitative

analysis

Allocaterequirementsto functions

Definecandidatephysicalsolutions

Evaluatecandidatephysical solutions& select

best basedupon objectives& requirements

Allocatefunctionsto Seg/CIs

DevelopinterfacesbetweenSeg/CIs

Plan test& integrationof Seg/CIs

Obtainapproval

of boundary,objectives,

concept of ops,requirements,

physical solution,& test plan

DocumentSeg/CIdesign

as approvedbaselinefor next

lowest level

yes

no

Define the Design Problem

Develop Functional Architecture

DevelopPhysical

Architecture

Develop Operational Architecture

Obtain Approval & Document

Detailed Functions of Systems Engineering Design

Figure 1.19


28

Functions of the Systems Engineering Integration Process

Verification Requirements andConstraints from Approved Baseline

Inspect and testto verification

requirements toprove readiness for

integration withnext assembly

CI to beverified

Deficiencies

Integrate withnext CI and

repeatverification

process

CorrectableIdentify and

fix correctabledeficiencies

Documentuncorrectabledeficiencies

For uncorrectabledeficiencies, confirm

no impact tointegration and getdeviation approval

from buyer

Modify approvedtechnical baseline

to incorporatedeviation

Redesign

Yes

No

No

Yes

No

Yes

Figure 1.20