Systems Engineering
Systems Architecting
An introduction
Version 1.0 – October 18, 2005
1
Systems Engineering
Agenda
• Evolution of Systems
• Relating Systems
Engineering & Architectures
• Representing an Architecture
• Using Architectures
• Summary
Version 1.0 – October 18, 2005
2
Systems Engineering
Evolution of Systems
Version 1.0 – October 18, 2005
3
Systems Engineering
Evolution of Systems
Version 1.0 – October 18, 2005
4
Systems Engineering
Evolution of Systems
Version 1.0 – October 18, 2005
5
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
7
Systems Engineering
Overcoming these Problems
Maybe he doesn’t 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
8
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 team’s 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
 MOE’s
 Environments
 Constraints
 Capability-Based
Acquisition
 Quality Attributes
 Interoperability
 COTS/GOTS/BOTS
 Re-Use and Legacy
• Technology Base
• Prior Phase Results
• Applied Standards
Goal/Mission
Analysis/Validation
Requirements Analysis
• Analyze Missions and Environments
• Identify Functional Requirements
• Define/Refine Performance and Design Constraints
• Identify Quality Attributes
• Validate Requirements
Functional
Architecture
Analysis
• Modeling & Simulation
• Trade Studies
• Effectiveness Analysis
System
Management
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
Design Loop
Verification Loop
System Analysis
• Risk Management
• Data Management
• Configuration Management
• Progress Measurement
 IMP/IMS & TPMs
 Technical Reviews
Physical
Architecture Analysis
Synthesis
• Transform Each Level’s Architecture from Functional to Physical
Iteration Loop
(Derived Requirements for the
Next Level of Decomposition)
• 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 Protection
Provide Comfort
Provide Communications &
Entertainment
Provide Space
Provide Food & Drink Provide Waste Disposal
Provide Access & Mobility
Provide Living Space
Provide Seating
Provide Sleeping
Provide Video Entertainment
Provide Telephony
Provide Audio Entertainment
Provide Storage
Provide Vehicle Storage
Provide Climate
Provide Physical Security Provide Physical Protection
Provide Computing Entertainment
Provide Personal Cleaning
Provide Object Storage
Version 1.0 – October 18, 2005
17
Systems Engineering
Product Diagrams of the Systems Architecture
Piloted Strike System
& SoS Aggregations
with System of System
Classes in green
Receive Solo Mission Start
Clearance
Operation Commander
<<extend>> Taxi Solo to Taxi Hold-Point
<<include>>
Combat Air
Operations Group
1
Taxi Solo to Point
Air Operations Commander
<<extend>>
<<include>>
Air Traffic Controller
Taxi/ Take Off Solo Air Vehicle
Taxi Solo to Take Off Hold-Point
<<include>>
Perform Final Pre-Flight Tests
Operation Group
1
Mission Area Commander
1..n
Operation
Commander
<<include>>
0..n
1..n
<<include>>
PSS Pilot
Flight Package
Take Off Solo Air Vehicle
<<include>>
1
1..n
Land/ Taxi Solo Air Vehicle
Mission Commander
Piloted Strike System
Enter Solo Flight Holding Pattern
<<include>>
1
Enter Solo Landing Approach
PSS Pilot
Use Case Diagrams
: Planning System
: PSS Pilot
JDAM
0..n
Small Diameter Bomb
Class Diagrams
: PSS Air Vehicle
Choose appropriate mission
plan transfer method
: PSS Pilot
Radio mission plan to
Air Vehicle
Transfer mission plan to
data transfer cartridge
0..n
Air Vehicle powered up,
checked out and ready for
mission plan
Mission plan completed in
planning system, encrypted,
and ready for transfer
Display menu for selecting method of
transfer of mission plan to Air Vehicle
1
PSS Air Vehicle
Radio receive
mission plan
Visually Monitor
Tanking Operation,
Monitor Fuel Level
: PSS Air
Vehicle
Display Fuel Level,
Report Fuel Level
: Airborne
Tanker
Display Fueling
Progress,
Display Interlock
Locked Status
1: Flow Fuel to Air
Vehicle(Initiate Fuel Flow :
Command)
2: Update Fueling Progress
Display(Fuel Level : Data)
Carry data transfer
cartridge to Air Vehicle
Put data transfer
cartridge in Air Vehicle
: Refueling
Specialist
Receive data
transfer cartridge
See Mission Plan &
Pilot Authentication
Use Case
5: Radio Relay Fueling
Anomaly Report(Verbal
Anomaly Report : Data)
Display confirmation of mission
plan & pilot acceptance
Air Vehicle ready for
taxi and operational
use
Seq's 3, 7, and 8 are
concurrent
3: Monitor Fueling Situation
Display(Fuel Level : Data,
Fueling Operation Scene : View)
4: Report Fueling Anomaly
Status(Anomaly Scene :
View, Anomaly Fuel Level
Data : Data)
Request
decryption key
Initiate Fuel Flow
Through Fuel Boom
6: Audio Message Fueling
Anomaly Report(Verbal
Anomaly Report : Data)
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 Node Connectivity Diagram (OV-2)
Operational Exchange Matrix (OV-3)
Organizational Relationships Chart (OV-4)
Version 1.0 – October 18, 2005
20
Systems Engineering
System View (SV)
Relates Systems and Characteristics to Operational Needs
System – Systems Matrix (SV-3)
System Interface Description (SV-1)
System Functionality Description (SV-4) UML Version
System Functionality Description (SV-4)
Version 1.0 – October 18, 2005
21
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 designer’s
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
Traditional
Development
Production
System Technology Demo
Collaborative
Spirals
Fieldable Prototype Demo
OCA
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