systems engineering 1version 1.0 – october 18, 2005 systems architecting an introduction
Post on 27-Mar-2015
217 Views
Preview:
TRANSCRIPT
Systems Engineering
2Version 1.0 – October 18, 2005
Agenda
• Evolution of Systems
• Relating Systems Engineering & Architectures
• Representing an Architecture
• Using Architectures
• Summary
Systems Engineering
6Version 1.0 – October 18, 2005
Evolution of Systems
Systems are becoming increasingly large and complexSystems are becoming increasingly large and complex
Systems Engineering
7Version 1.0 – October 18, 2005
No Easy Answer
Modern Systems:– Ill-Structured– Involve New & Untested
Ideas– Complex
Systems Engineering
8Version 1.0 – October 18, 2005
Overcoming these Problems
How will we:– Manage uncertainty– Manage complexity– Manage technological
change
Maybe he doesn’t want to be in charge of the next customer review
Systems Engineering
9Version 1.0 – October 18, 2005
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
Systems Engineering
10Version 1.0 – October 18, 2005
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…
Systems Engineering
11Version 1.0 – October 18, 2005
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.
Systems Engineering
12Version 1.0 – October 18, 2005
ProcessOutputs• “Best Value” System Architecture• System Architecture Models and Specifications
Requirements Analysis• Analyze Missions and Environments• Identify Functional Requirements• Define/Refine Performance and Design Constraints• Identify Quality Attributes• Validate Requirements
Functional Analysis & Allocation• Decompose to Next-Lower Level Functions• Define/Refine Functional Interfaces (Internal/External)• Define/Refine/Integrate Functional Architecture• Allocate Performance & Other Requirements
Synthesis• Transform Each Level’s 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
System Analysis• Modeling & Simulation• Trade Studies• Effectiveness Analysis
System Management• Risk Management• Data Management• Configuration Management• Progress Measurement
IMP/IMS & TPMs Technical Reviews
ProcessInputs• 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
Requirements Loop
Design Loop
Verification Loop
Iteration Loop(Derived Requirements for the Next Level of Decomposition)
Goal/MissionAnalysis/Validation
FunctionalArchitecture
Analysis
PhysicalArchitecture Analysis
Architecting in the Systems Engineering Process
Systems Engineering
13Version 1.0 – October 18, 2005
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
Systems Engineering
14Version 1.0 – October 18, 2005
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
Systems Engineering
15Version 1.0 – October 18, 2005
Describing the Architecture
Physical Descriptions
Behavioral Descriptions
Operational Expectations
Many perspectives: physical, functional, operational, technical…
Systems Engineering
16Version 1.0 – October 18, 2005
Physical View to an Architecture
Front Elevation View
Plan View
Perspective View
Building CodesTechnical Standards View
Front Elevation View
Plan View
Perspective View
Building CodesTechnical Standards View
Systems Engineering
17Version 1.0 – October 18, 2005
Functional View to an Architecture(Example Based on Unified Modeling Language)
Provide Access & Mobility
Provide Space
Provide Living Space
Provide Vehicle Storage
Provide Storage
Provide Object Storage
Provide Food & Drink
Provide Nurishment
Provide Waste Disposal
Provide Physical Security
Provide Protection
Provide Physical Protection
Provide Sleeping
Provide Personal Cleaning
Provide Seating
Provide Comfort
Provide Climate
Provide Video Entertainment
Provide Audio Entertainment
Provide Computing Entertainment
Provide Telephony
Provide Human Habitat
Provide Communications & Entertainment
Systems Engineering
18Version 1.0 – October 18, 2005
Mission plan completed in planning system, encrypted, and ready for transfer
Display menu for selecting method of transfer of mission plan to Air Vehicle
Radio mission plan to Air Vehicle
Transfer mission plan to data transfer cartridge
Choose appropriate mission plan transfer method
Carry data transfer cartridge to Air Vehicle
Put data transfer cartridge in Air Vehicle
Air Vehicle powered up, checked out and ready for mission plan
Radio receive mission plan
Receive data transfer cartridge
Request decryption key
Display confirmation of mission plan & pilot acceptance
Air Vehicle ready for taxi and operational use
See Mission Plan & Pilot Authentication Use Case
: PSS Air Vehicle : PSS Pilot : Planning System
Piloted Strike System & SoS Aggregations with System of System Classes in green
Air Operations Commander Mission Area Commander
Operation Commander
Combat Air Operations Group
11 0..n0..n
Operation Group
11
1..n1..n
Mission Commander
Small Diameter BombPSS Air Vehicle JDAM
Flight Package
1..n1..n
11
PSS Pilot
Piloted Strike System
0..n0..n11 0..n0..n
1..n1..n
11
Perform Final Pre-Flight Tests
Taxi Solo to Point
Enter Solo Flight Holding Pattern
Take Off Solo Air Vehicle
Enter Solo Landing Approach
Taxi Solo to Taxi Hold-Point
Taxi Solo to Take Off Hold-Point
<<extend>>
<<extend>>PSS Pilot
Air Traffic Controller
Land/ Taxi Solo Air Vehicle
<<include>>
<<include>>
Operation CommanderReceive Solo Mission Start
Clearance
Taxi/ Take Off Solo Air Vehicle
<<include>>
<<include>>
<<include>>
<<include>>
<<include>>
: PSS Pilot : PSS Air Vehicle
: Airborne Tanker
: Refueling Specialist
Initiate Fuel Flow Through Fuel Boom
Display Fuel Level,Report Fuel Level
Visually Monitor Tanking Operation,Monitor Fuel Level
5: Radio Relay Fueling Anomaly Report(Verbal Anomaly Report : Data)
4: Report Fueling Anomaly Status(Anomaly Scene : View, Anomaly Fuel Level
Data : Data)
1: Flow Fuel to Air Vehicle(Initiate Fuel Flow :
Command)
3: Monitor Fueling Situation Display(Fuel Level : Data,
Fueling Operation Scene : View)
6: Audio Message Fueling Anomaly Report(Verbal Anomaly Report : Data) 7: Monitor for Fueling
Anomaly Reports(Verbal Anomaly Report : Data)
Display Fueling Progress,Display Interlock Locked Status
Seq's 3, 7, and 8 are concurrent2: Update Fueling Progress
Display(Fuel Level : Data)
8: Automatically Monitor for Fuel Level and Emergencies( )
Class DiagramsUse Case Diagrams
Activity & State DiagramsSequence Diagrams
Product Diagrams of the Systems Architecture
Systems Engineering
19Version 1.0 – October 18, 2005
DoDAF – DoD Architecture FrameworkCustomer Defined Views of the Model
Systems Engineering
20Version 1.0 – October 18, 2005
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)
Systems Engineering
21Version 1.0 – October 18, 2005
System View (SV)Relates Systems and Characteristics to Operational Needs
System Interface Description (SV-1)
System Functionality Description (SV-4) UML Version
System – Systems Matrix (SV-3)
System Functionality Description (SV-4)
Systems Engineering
22Version 1.0 – October 18, 2005
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)
Systems Engineering
23Version 1.0 – October 18, 2005
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
25 Views Integrated Together
Systems Engineering
24Version 1.0 – October 18, 2005
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.
Systems Engineering
25Version 1.0 – October 18, 2005
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
Systems Engineering
26Version 1.0 – October 18, 2005
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 PracticesStevens Institute of Technology, March 15, 2004
Systems Engineering
27Version 1.0 – October 18, 2005
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
Systems Engineering
28Version 1.0 – October 18, 2005
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
Systems Engineering
29Version 1.0 – October 18, 2005
The Risks of Architecting
• Early Identification of Problems
• Perception of Program Delay
• Inconsistent Application of Methodologies
• Limited Numbers of Skilled Creators/ Reviewers
Systems Engineering
30Version 1.0 – October 18, 2005
Risks of Not Architecting
• Late Identification of Problems
• Lack of Unified Design
• Issues of Complexity Management
Systems Engineering
31Version 1.0 – October 18, 2005
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 LawsuitThere 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.
Systems Engineering
32Version 1.0 – October 18, 2005
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
Systems Engineering
34Version 1.0 – October 18, 2005
References
• Boeing Systems Architecture Development Guidebook• “The Art of Systems Architecting”, Eberhardt Rechtin, Mark W.
Maier• DoD Architecture Framework (DoDAF)
Systems Engineering
37Version 1.0 – October 18, 2005
Evolving Architectures: Impact of Spiral Development
Continuous User Assessment & Collaboration; Sustainment & CONOPSContinuous User Assessment & Collaboration; Sustainment & CONOPS RefinementRefinement
CollaborativeSpirals
OCA = Ops Capability Assessment Spiral Definition / Requirements
System Technology Demo
Fieldable Prototype DemoOCA
Integrated Acquisition
Team•• UsersUsers•• AcquirersAcquirers•• TestersTesters•• ResearchersResearchers•• LogisticiansLogisticians
OCA
Production
Spiral 2
Spiral 3OCA
OCASpiral 1 Development
FY02 FY03 FY04 FY05 FY06 FY07 FY08 FY09 FY10 FY11 FY12
TraditionalFY13
Development
Production
FY01FY99-00Concept Demo
Continuous User Assessment & Collaboration; Sustainment & CONOPSContinuous User Assessment & Collaboration; Sustainment & CONOPS RefinementRefinement
CollaborativeSpirals
OCA = Ops Capability Assessment Spiral Definition / Requirements
System Technology Demo
Fieldable Prototype DemoOCA
Integrated Acquisition
Team•• UsersUsers•• AcquirersAcquirers•• TestersTesters•• ResearchersResearchers•• LogisticiansLogisticians
OCA
Production
Spiral 2
Spiral 3OCA
OCASpiral 1 Development
FY02 FY03 FY04 FY05 FY06 FY07 FY08 FY09 FY10 FY11 FY12
TraditionalFY13
Development
Production
FY01FY99-00Concept Demo
Systems Engineering
38Version 1.0 – October 18, 2005
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
top related