Systems Engineering

Systems Architecting An introduction

Version 1.0 October 18, 2005

Systems Engineering

Agenda
Evolution of Systems Relating Systems Engineering & Architectures Representing an Architecture Using Architectures Summary

Version 1.0 October 18, 2005

Systems Engineering

Evolution of Systems

Version 1.0 October 18, 2005

Systems Engineering

Evolution of Systems

Version 1.0 October 18, 2005

Systems Engineering

Evolution of Systems

Version 1.0 October 18, 2005

Systems Engineering

Evolution of Systems

Systems are becoming increasingly large and complex

Version 1.0 October 18, 2005 6

Systems Engineering

No Easy Answer

Modern Systems:
Ill-Structured Involve New & Untested Ideas Complex

Version 1.0 October 18, 2005

Systems Engineering

Overcoming these Problems

Maybe he doesnt want to be in charge of the next customer review

How will we:

Manage uncertainty Manage complexity Manage technological change

Version 1.0 October 18, 2005

Systems Engineering

Systems Engineering: the Process

A process that transforms an operational need or market opportunity into a system description to support detail design. Requirements Analysis Functional Analysis Synthesis Systems Analysis / Management
Version 1.0 October 18, 2005 9

Systems Engineering

Systems Architecture: a Product

The design teams interpretation / implementation of customer requirements communicated thru:
System Usage Scenarios (i.e., Use Cases)

Functional Components & Interrelationships

Physical Subsystems & Interfaces

Etc

Version 1.0 October 18, 2005

10

Systems Engineering

Systems Architecting: a Methodology

A Segment of the Systems Engineering Process Which Facilitates the Identification of:

System Elements Relationships Design Principles

That Collectively Satisfy Customer Requirements and Meet User Needs.

Version 1.0 October 18, 2005

11

Systems Engineering

Architecting in the Systems Engineering Process

Process Inputs
Stakeholder Inputs Operational Requirements MOEs Environments Constraints Capability-Based Acquisition Quality Attributes Interoperability COTS/GOTS/BOTS Re-Use and Legacy Technology Base Prior Phase Results Applied Standards

Requirements Analysis
Analyze Missions and Environments
Identify Functional Requirements Define/Refine Performance and Design Constraints Identify Quality Attributes Validate Requirements

Goal/Mission Analysis/Validation

System Analysis
Modeling & Simulation
Trade Studies Effectiveness Analysis

Functional Architecture Analysis

Requirements Loop Functional Analysis & Allocation

Decompose to Next-Lower Level Functions
Define/Refine Functional Interfaces (Internal/External) Define/Refine/Integrate Functional Architecture Allocate Performance & Other Requirements

System Management
Risk Management Data Management Configuration Management Progress Measurement IMP/IMS & TPMs Technical Reviews Physical Architecture Analysis

Design Loop Verification Loop Iteration Loop

(Derived Requirements for the Next Level of Decomposition)

Synthesis
Transform Each Levels Architecture from Functional to Physical
Define Alternative System Concepts & Configuration Items Define/Refine Physical Interfaces (Internal/External) Identify Candidate Architecture Styles Select Best Value Design

Process Outputs
Best Value System Architecture System Architecture Models and Specifications

Version 1.0 October 18, 2005

12

Systems Engineering

The Two Primary Methods of Architecting

Structured Analysis and Design Technique (SADT) Graphical Representation of System Requirements Boxes and Arrows Logical Flows Object-Oriented Analysis (OOA) and the Unified Modeling Language (UML) Structure Diagrams Behavior Diagrams Interaction Diagrams
Version 1.0 October 18, 2005 13

Systems Engineering

Goals of Systems Architecting

Take into account the whole picture
Life cycle phases, boundaries, external elements Users, builders, benefactors, supporters, environments Affordability, safety, availability, survivability, security, etc.

Communicate clearly the components and their inter-relationships from user and engineering perspectives
for customer validation for use in analysis and design by all engineering disciplines

Version 1.0 October 18, 2005

14

Systems Engineering

Describing the Architecture

Physical Descriptions

Operational Expectations

Behavioral Descriptions Many perspectives: physical, functional, operational, technical

Version 1.0 October 18, 2005 15

Systems Engineering

Physical View to an Architecture

Perspective View

Plan View

Front Elevation View

Version 1.0 October 18, 2005

Building Codes Technical Standards View

16

Systems Engineering

Functional View to an Architecture

(Example Based on Unified Modeling Language)
Provide Human Habitat

Provide Nurishment Provide Space

Provide Protection

Provide Comfort

Provide Communications & Entertainment

Provide Food & Drink Provide Waste Disposal Provide Access & Mobility Provide Living Space Provide Sleeping

Provide Seating

Provide Video Entertainment Provide Audio Entertainment

Provide Telephony

Provide Storage

Provide Climate Provide Physical Security Provide Physical Protection Provide Personal Cleaning

Provide Computing Entertainment

Provide Vehicle Storage

Provide Object Storage

Version 1.0 October 18, 2005

17

Systems Engineering

Product Diagrams of the Systems Architecture

Operation Commander <<include>> <<include>> PSS Pilot <<include>> Taxi Solo to Take Off Hold-Point <<include>> Perform Final Pre-Flight Tests Taxi Solo to Point <<extend>> Receive Solo Mission Start Clearance <<extend>> Taxi Solo to Taxi Hold-Point

Piloted Strike System & SoS Aggregations with System of System Classes in green 1 Air Operations Commander

Combat Air Operations Group

1..n Operation Group

0..n Mission Area Commander

Air Traffic Controller

Taxi/ Take Off Solo Air Vehicle

1 Operation Commander

1..n Flight Package

<<include>> Take Off Solo Air Vehicle <<include>> Land/ Taxi Solo Air Vehicle

1 Mission Commander

1..n Piloted Strike System

Enter Solo Flight Holding Pattern <<include>>

1
Enter Solo Landing Approach

1 PSS Air Vehicle

0..n JDAM

PSS Pilot

0..n Small Diameter Bomb

Use Case Diagrams

: Planning System : PSS Pilot : PSS Air Vehicle

Class Diagrams
: PSS Pilot : PSS Air Vehicle Display Fuel Level, Report Fuel Level : Airborne Tanker Display Fueling Progress, Display Interlock Locked Status : Refueling Specialist Initiate Fuel Flow Through Fuel Boom Seq's 3, 7, and 8 are concurrent

Mission plan completed in planning system, encrypted, and ready for transfer Display menu for selecting method of transfer of mission plan to Air Vehicle Choose appropriate mission plan transfer method

Air Vehicle powered up, checked out and ready for mission plan

Radio mission plan to Air Vehicle Transfer mission plan to data transfer cartridge Carry data transfer cartridge to Air Vehicle

Radio receive mission plan

Visually Monitor Tanking Operation, Monitor Fuel Level

1: Flow Fuel to Air Vehicle(Initiate Fuel Flow : Command) 2: Update Fueling Progress Display(Fuel Level : Data)

Put data transfer cartridge in Air Vehicle

Receive data transfer cartridge

Request decryption key See Mission Plan & Pilot Authentication Use Case Display confirmation of mission plan & pilot acceptance Air Vehicle ready for taxi and operational use

4: Report Fueling Anomaly Status(Anomaly Scene : View, Anomaly Fuel Level Data : Data) 5: Radio Relay Fueling Anomaly Report(Verbal Anomaly Report : Data) 6: Audio Message Fueling Anomaly Report(Verbal Anomaly Report : Data)

3: Monitor Fueling Situation Display(Fuel Level : Data, Fueling Operation Scene : View)

7: Monitor for Fueling Anomaly Reports(Verbal Anomaly Report : Data) 8: Automatically Monitor for Fuel Level and Emergencies( )

Activity & State Diagrams Sequence Diagrams

Version 1.0 October 18, 2005 18

Systems Engineering

DoDAF DoD Architecture Framework

Customer Defined Views of the Model

Version 1.0 October 18, 2005

19

Systems Engineering

Operational View (OV)

What needs to be done & Who does it

High Level Operational Concept Graphic (OV-1)

Operational Exchange Matrix (OV-3)

Operational Node Connectivity Diagram (OV-2)

Organizational Relationships Chart (OV-4) 20

Version 1.0 October 18, 2005

Systems Engineering

System View (SV)

Relates Systems and Characteristics to Operational Needs

System Interface Description (SV-1)

System Systems Matrix (SV-3)

System Functionality Description (SV-4) UML Version

System Functionality Description (SV-4) 21

Version 1.0 October 18, 2005

Systems Engineering

Technical View (TV)

Prescribes Standards and Conventions

System Products Associated With Standards (TV 1) Template for Time Records (TV-1)

Technical Standards Profile Template (TV-1) Version 1.0 October 18, 2005 22

Systems Engineering

25 Views Integrated Together

AV 1 Overview & Summary Information AV 2 Integrated Dictionary OV 1 High Level Operational Concept OV 2 Op. Node Connectivity Description OV 3 Op. Informational Exchange Matrix OV 4 Org. Relationships Chart OV 5 Activity Model OV 6a Operational Rules OV 6b Operational State Transition OV 6c Op. Event Trace Description OV 7 Logical Data Mode SV 1 Systems Interface Description SV 2 Systems Communication Description

SV 3 Systems Matrix
SV 4 System Functionality Description SV 5 Op. Activity to Systems Function Traceability Matrix SV 6 System Data Exchange Matrix SV 7 System Performance Parameters SV 8 System Evolution Description SV 9 System Technology Forecast

SV 10a System Rules Model

SV 10b System State Transition Description SV 11 Physical Data Model TV 1 Technical Architecture Profile TV 2 Standards Technology Forecast

Version 1.0 October 18, 2005

23

Systems Engineering

DoDAF Summary
DoDAF is a way of describing a system. DoDAF represents a number of different views of the architecture. DoDAF is a required output to our customers. DoDAF is NOT a methodology or process. DoDAF is NOT a UML based set of views.

Version 1.0 October 18, 2005

24

Systems Engineering

Benefits of Architecting
Identifies All System Elements Earlier vs. Later Matches Function to Requirements Capture & Communicate Key concepts Results in ONE design Manages Increasing Complexity Allows Modular Design

Version 1.0 October 18, 2005

25

Systems Engineering

Users of the Architecture

Systems Architect: Translate Client Needs into Builder Requirements System Designers: Design Guidance Program Managers: Program Performance Measurement and Guidance Customers: Validation of Requirements and Design Other Stakeholders: Various Views of the System* Manufacturers - Trainers Testers - Users Purchasers - Logistics Personnel Handlers - Maintainers
* Adapted from: Agile Systems Engineering Architecting: Methods, Processes, and Practices Stevens Institute of Technology, March 15, 2004
Version 1.0 October 18, 2005 26

Systems Engineering

Architecture Used In
Analysis of Alternatives (AoA) Business and Technical Planning Communications among Organizations Internal to Internal Internal to External Input to Subsequent System Design and Development Criteria for Certifying Conformance of Implementations Development, Maintenance, and Reuse Repositories Review, analysis, and evaluation of the system across the life cycle Basis for incremental/spiral development

Version 1.0 October 18, 2005

27

Systems Engineering

Characteristics of a Systems Architect

Analytical Attention to Detail Visionary Generalist Common Sense Know-How Drive Critical Attitude Multi-tasking Teamwork Communicator/Documenter Flexible Process Insight Political Insight/Negotiation

Version 1.0 October 18, 2005

28

Systems Engineering

The Risks of Architecting

Early Identification of Problems Perception of Program Delay Inconsistent Application of Methodologies Limited Numbers of Skilled Creators/ Reviewers
Version 1.0 October 18, 2005 29

Systems Engineering

Risks of Not Architecting

Late Identification of Problems Lack of Unified Design Issues of Complexity Management

Version 1.0 October 18, 2005

30

Systems Engineering

Example Architecture Issues

Audi 2006 A8, A8 L, and A8 L W12 Passenger Vehicles
On certain passenger vehicles, a wiring harness condition exists that may deactivate the passenger side frontal air bag even under circumstances when it should remain activated.

Starbucks Coffee Company Recall of Ceramic Teapots

The teapots are labeled safe for microwave use, but the handles can become hot in the microwave oven. This poses a possible burn hazard to consumers.

Microsoft Xbox 360 Class Action Lawsuit

There may be a design flaw which causes the console's power supply and CPU to overheat, causing the whole system to seize up. Complaints of similar freezing problems began to surface almost as soon as the Xbox 360 went on sale November 22.
Version 1.0 October 18, 2005

31

Systems Engineering

Summary
Increasingly complex systems drive a need for better, clearer design descriptions

Architectures convey the system designers interpretation of the requirements

Architectures may be presented by a variety of views which collectively describe the system As part of the systems engineering process, systems architecting defines and manages development of a system
Version 1.0 October 18, 2005

32

Systems Engineering

Version 1.0 October 18, 2005

33

Systems Engineering

References
Boeing Systems Architecture Development Guidebook The Art of Systems Architecting, Eberhardt Rechtin, Mark W. Maier DoD Architecture Framework (DoDAF)

Version 1.0 October 18, 2005

34

Systems Engineering

Recommended Use of DoDAF Products

Version 1.0 October 18, 2005

35

Systems Engineering

DoDAF View Extraction

Version 1.0 October 18, 2005

36

Systems Engineering

Evolving Architectures: Impact of Spiral Development

FY99-00 FY01 FY02 FY03 FY04 FY05 FY06 FY07 FY08 FY09 FY10 FY11 FY12 FY13
Concept Demo Development

Traditional
Production

System Technology Demo Fieldable Prototype Demo OCA

Collaborative Spirals
Production

Integrated Acquisition Team

Users Acquirers Testers Researchers Logisticians

Spiral 1 Development OCA Spiral 2 OCA Spiral 3 OCA

Continuous User Assessment & Collaboration; Sustainment & CONOPS Refinement

OCA = Ops Capability Assessment Spiral Definition / Requirements Version 1.0 October 18, 2005

37

Systems Engineering

Model-Based Architecture
Why Model-Based Architectures?
Help to Explain How Things Work Broaden Our Perspective Provide a Common Conceptual Frame of Reference Express Rules More Simply Clarify Relationships, Identify Key Elements, and Consciously Eliminate Confusion Factors
From: Forsbert, Kevin; Visualizing Project Management, Pg. 14
Version 1.0 October 18, 2005

38