Download as PDF, PPTX
More Related Content
Jeff.robinson
- 1. MBSE ARCHITECTURE MODELING METHODOLOGY Project Management Challenge 2010 Jeff Robinson Special thanks to Scott Lukens Used with Permission
- 2. Agenda A. Overview Arcitecture Modeling Methodology B. Architecture Methodology (Physical) 1. Context Diagram 2. Decompose Physical Elements C. Architecture Methodology (Operational & Functional) 1. Architecture Modeling Activities (with examples) D. Use Models to Help Derive Requirements 1. Architecture Methodology Requirement Types 2. Characterization List 3. Derive Operational and Performance Requirements 4. Interface Requirements 5. Trace Derived Requirements to Model Elements E. Model-Based Output 2
- 3. Arcitecture Modeling Methodology A. Overview 3
- 4. Model-Based Systems Engineering (MBSE) Requirements Gathering & Functional Behavior Analysis System Architecture Analysis Arcitecture Modeling Methodology Operational Analysis • Identify Source Material, Operational • Operational Scenarios • System Structure (i.e., Hierarchy of Context, Use Cases, Scenarios, • Integrated Behavior Models System Elements) Information Exchange • Derive Functional / Performance • Interfaces between System • Establish Initial Requirements Set Requirements Elements • Establish Design Constraints • Define I/O • Allocate Functional Behavior and • Capture Issues / Risks / Decisions • Define Effectiveness Measures Non-Functional Requirements Requirements Model Functional Models System Architectures R1 F3 F4 System of Systems R1.1 R1.2 F1 F5 Trade F2 R1.2.1 Issue Equipment List Advantages of MBSE over Document Centric Approach Shows Complete full picture of Architecture/Stakeholder Problem. Generates executable artifacts. MBSE Allows requirements conformance and consistency checking to be assessed and validated. Document Approach Centric Orchestrates understanding of a design in all phases of the development lifecycle. Approach 4
- 5. Part 1 –Develop Hierarchical Architecture Model (1) Identify Life (5) Develop Arcitecture Modeling Methodology Cycle Phase Mission Operation for Each Scenario (6) Decompose Mission (2) Identify DRM Operation Mission Phase (ConOps) (7) Develop Top- (3) Develop Level System Mission Sub- Functions phases (4) Model Nominal (8) Decompose & Off-Nominal Functions Activities (Operational Scenarios) 5
- 6. Part 2 –Use Architecture Models to Help Derive Requirements Model Characterize Requirement(s) Arcitecture Modeling Methodology Complete Model Develop Requirements Characterization List for using Characterization List 3 Each Model Element 2 Operational/ Capability Requirements External Interface Perform Hierarchal Requirements 1 Architecture Modeling Trace/Link Requirements to 4 Model Element Use Model Element (with Output 5 linked requirements) to generate Requirements Model-Based Systems Document Engineering 6
- 7. Arcitecture Modeling Methodology B. Architecture Methodology (Physical) 7
- 8. Develop Boundary (Context)Diagram The context diagram illustrates the physical elements outside the system. Arcitecture Modeling Methodology P-IC-ISS P-IC-LPRP P-IC-NOAA P-IC-ISS-Cx P-IC-Cx-ISS Interface Interface P-IC-Cx-LPRP Interface P-IC-NOAA-Cx Interface P-IC-LPRP-Cx Interface P-IC-GPS-Cx P-IC-GPS Interface P-IC-USSTRATCOM-Cx P-IC-CTN-Cx Interface Interface P-IC-USSTRATCOM P-IC-Cx-CTN P-IC-DDMS-Cx Interface Interface P-IC-C&T Network P-IC-Cx-DDMS P-IC-Constellation P-IC-DDMS P-IC-Foreign-Cx P-IC-Cx-Foreign Interface Interface Interface Architecture P-IC-AFSCN-Cx P-IC-Cx-SOMD Interface Interface P-IC-Foreign Government Landing and Recovery P-IC-Cx-AFSCN P-IC-SOMD-Cx P-IC-Cx-ER P-IC-ER-Cx Interface Interface Interface Interface P-IC-AFSCN P-IC-SOMD P-IC-Eastern Range System Boundaries and External Interfaces Knowing your system boundaries will guide the designer with interfaces to external systems. 8
- 9. Decompose Physical Elements Context Diagram Decompose the physical elements. Arcitecture Modeling Methodology Include decomposition of external and internal interfaces. System of System (SoS) Level P-IC-Cx-ISS Interface P-IC-Orion-PEPC P-IC-LIDS/APAS Interface Adapter P-IC-ISS-Cx Interface P-IC-Orion-LIDS/APAS Adapter Launch Vehicle Interface P-IC-GS Inter System Level P-IC-GPS-Cx P-IC-LIDS/APAS Interface P-IC-Orion Adapter-Orion P-IC-Orion-Ares Interface Interface P-IC-Orion-MS P-IC-MS-Orion Interface Interface P-IC-Ares-Orion P-IC-GS-Ares Interface Interface P-IC-GPS P-IC-AFSCN-Cx Interface P-IC-Ares-MS Interface P-IC-Cx-AFSCN Interface P-IC-LPRP Launch P-IC-LPRP-Cx P-IC-C Interface Inter Vehicle P-IC-ER-Cx P-IC-MS-Ares Interface Interface P-IC-Cx-ER Interface P-IC-Cx-Foreign P-IC-Mission Interface 9
- 10. Arcitecture Modeling Methodology C. Architecture Methodology (Operational & Functional) 10
- 11. (1) Identify LifecyclePhase The ‘System Lifecycle Phase’ may be modeled as a Process Flow Diagram (PFD). Arcitecture Modeling Methodology SoS Level II System Level III Element Level IV Integrate Integrate Manufacture Each Lifecycle phase will have a Operational Transport Transport Test System Test Component Test unique set of missions, stakeholders, Train Sustain Train interfaces and constraints Operate Dispose Applicable to Integrate Operational Train - SoS Level - SoS Test SoS Operate AND AND *4* 1 2 3 Input Input Applicable to Integrate Transport System Train - System Level - System - System Test System 5 6 7 8 Input Input Applicable to Transport Component Element Level Manufacture Sustain Dispose - Element Test 9 12 13 10 11 11
- 12. (2) Identify DRMMission Phase (ConOps) The ‘DRM Mission Phase (ConOps)’ PFD is decomposed from the ‘DRM Mission Phase’ Arcitecture Modeling Methodology DRM-1 ISS OR OR 1 Lunar DRM-2 Surface *2* Lunar DRM-3 Habitat 3 DRM-4 Mars 4 ‘Operate’ Lifecycle Phase 12
- 13. (3) Develop MissionSub-Phases The ‘Mission Sub-Phase’ PFD is decomposed from the Arcitecture Modeling Methodology ‘DRM Mission Phase (ConOps)’. Low Earth Trans Pre-Launch Launch Ascent Orbit Lunar (LEO) Orbit *1* 2 3 4 5 Lunar Lunar Lunar Low Lunar Surface Ascent Descent Orbit Operations 9 7 6 8 Trans Earth Earth Earth Post-Landing Descent Landing Orbit 13 11 12 10 ‘Lunar Surface’ Mission Phase 13
- 14. (4) Model Nominal& Off-Nominal Activities (Operational Scenarios) The ‘Nominal & Off-Nominal Activities (Operational Arcitecture Modeling Methodology Scenarios)’ PFD is decomposed from the ‘Mission Sub- Phase’. Scenario 1 LS Explore OR OR Operations Activities modeled Scenario 2 for the Scenario Lunar Golf Scenario 3 LS Mining Operations ‘Lunar Surface Operations’ 14
- 15. (5) Develop MissionOperation for Each Scenario The ‘Mission Operations for Each Scenario’ PFD is Arcitecture Modeling Methodology decomposed from the ‘Nominal & Off-Nominal Activities (Operational Scenarios)’ Define a Swim Lane (row) for each system component. CxP Exit Transition to Hit Golf Return to Enter AND AND Habitat Driving Range Balls Habitat Habitat Define Operations for that system component. Start Stop Video Feed Video Feed Elementary Video Feed Schools Define the Data Flows (interface ‘Lunar Golf’ messages) for that system component. 15
- 16. Mission Operation SwimLanes The Swim Lanes (‘CxP’ and ‘Elementary Schools’) represent the internal or external elements of the Physical Architecture that the PFD Arcitecture Modeling Methodology operations are associated to for the current level (SoS Level). Elem. Schools CxP System(s) (External Sys.) Current Level CTN Mission Crew Habitat EVA Rover Crew (Comm) Systems Equipment Next Level CxP Exit Transition to AND Habitat Driving Range Start Video Feed Elementary Vid Schools 16
- 17. (6) Decompose MissionOperation The ‘Mission Operation’ PFD is Arcitecture Modeling Methodology decomposed from the ‘Mission Operations for Each Scenario’. Crew Enter Turn Power Drive to Golf Turn Power AND Exit Rover AND Rover On Range Off Rover On Maneuver Rover Off Command Commands Command Rover Rover Power Maneuver Rover On Rover Power Off ‘Transition to Driving Range’ 17
- 18. Decomposed Mission OperationSwim Lanes The Swim Lanes (‘Crew’ and ‘Rover’) represent the internal and external elements of the Physical Architecture that the PFD operations Arcitecture Modeling Methodology are associated to at the current level (System Level). Elem. Schools CxP System(s) (External Sys.) CTN Mission Crew Habitat EVA Rover Crew (Comm) Systems Equipment Current Level Crew Enter AND Rover R C Rover 18
- 19. (7) Develop Top-LevelSystem Functions The ‘Top-Level System Functions’ enhanced Functional Arcitecture Modeling Methodology Flow Block Diagram (eFFBD) is decomposed from the ‘Mission Operation’ PFD. Until Destination Reached Disengage Engage Accelerate Brake I AND OR OR AND I Brake Vehicle System System Rover Move Distance Accelerator Release Apply (Odometer) Pedal Brake Brake Decelerate Vehicle Move Brake Pedal Change Vehicle Direction Move Steering System ‘Maneuver Rover’ 19
- 20. (8) Decompose Functions The ‘Decompose Functions” FFBD is decomposed from Arcitecture Modeling Methodology the Top-Level System Functions’ FFBD. Translate Change Rotation to Motor RPM Wheels Move Rover Accelerator Distance Pedal (Odometer) ‘Accelerate Vehicle’ 20
- 21. Arcitecture Modeling Methodology D. Use Models to Help Derive Requirements 21
- 22. Architecture Methodology Requirement Types Various types of requirements are represented in this architecture methodology. Arcitecture Modeling Methodology Mode Architecture Modeling l No. Activity Requirement Types System of System (SoS) Level 1. Identify Lifecycle Phase Operational/Capability Requirements 2. Identify DRM Mission Phase External Interface Requirements (ConOps) 3. Develop Mission Sub-Phases 4. Model Nominal & Off-Nominal Activities (Operational Scenarios) 1 5 5. Develop Mission Operation for Each Scenario System Level 2 6 6. Decompose Mission Operation Operational/Capability Requirements 7. Develop Top-Level System Functions Functional/Performance Requirements 3 7 Internal Interface Requirements (System to System) 4 8 Element Level 8. Decompose Functions Functional/Performance Requirements External Interface Requirements Internal Interface Requirements (Element to Element) Physical Architecture (All Levels) ~ Define Physical Architecture Physical Interface Requirements 22
- 23. Characterization List Complete a standard Characterization List for each of the modeled element which assists in developing associated system requirements. Arcitecture Modeling Methodology For Operational Models For Functional Models Description of each Operation Description of each Function <Describe the operation for the model element.> <Describe the model element’s function.> Inputs/Outputs Inputs/Outputs <Identify the operational inputs and outputs for the <Identify the functional inputs and outputs for the model element.> model element.> Desired Capability (level across scenarios) Desired Performance (level across scenarios) <Describe operation capability> Describe the performance required for the function (rate, time, weight, etc.)> Pre Conditions <Describe condition needed to enter/activate Pre Conditions operation.> <Describe condition needed to enter/activate function.> Post Conditions <Describe condition when operation complete.> Post Conditions <Describe condition when function complete.> Operating Context (Environment) <Identify the environmental conditions that the Operating Context (Environment) modeled element sees during its operation. > <Identify the environmental conditions that the modeled element sees during its function. > Off-Nominal Behavior and Recovery <Identify credible off-nominal behaviors or scenarios Off-Nominal Behavior and Recovery and suggested recovery operations to mitigate the <Identify credible off-nominal behaviors or scenarios behavior. Identify a worst case scenario and 2 to 3 and suggested recovery operations to mitigate the lesser severe behaviors.> behavior. Identify a worst case scenario and 2 to 3 lesser severe behaviors.> 23
- 24. (1) Derive OperationalRequirements Example - Derive Operational Requirement using Characterization List Arcitecture Modeling Methodology for ‘Transition to Driving Range’ operational model element. Operational No. Characterization Item Characterization Text Requirement 1. Operation Description Transition two crew members and Transition to Driving golf equipment between lunar Range habitat and lunar golf driving range. Lunar Rover shall safely 2. Inputs ~ secure two crew members and crew equipment for 3. Outputs ~ transit between lunar habitat and the lunar golf 4. Pre and Post Conditions Decision authority. driving range with a TBD 5. Operating Context 24 hr weather predicted. maximum travel distance (Environment) and a TBD maximum Desired Capability(level TBD maximum travel distance. continuous operation time. 6. across scenarios) Safe travel speed of TBD mph. 7. Off-Nominal Behavior Rover fails to operate. 8. Off-Nominal Recovery Don’t not use rover; Attempt to repair rover; Contingency return to habitat (limit rover distance to safe EVA walk). 24
- 25. (2) Derive PerformanceRequirements Example - Derived Performance Requirement using Characterization Arcitecture Modeling Methodology List for the ‘Accelerate Vehicle’ functional model element. Performance No. Characterization Item Characterization Text Requirement 1. Function Description Able to change rover acceleration. Change Vehicle Acceleration 2. Inputs Move Accelerator Pedal Lunar Rover acceleration Outputs ~ changes shall be manually 3. controlled by EVA crew so 4. Pre and Post Conditions Decision authority. that associated crew member physical effort 5. Operating Context 24 hr weather predicted. does not exceed human (Environment) factors as defined in TBD 6. Desired Performance (level TBD maximum rover acceleration. document. across scenarios) Any crew EVA manual control not to exceed human factors per TBD document. 7. Off-Nominal Behavior (1) Acceleration fails Off. (2) Acceleration fails On 8. Off-Nominal Recovery (1a) Don’t not use rover; (1b) Attempt to repair rover; (2a) Enable contingency acceleration override; (2b) Then purse contingency return to habitat (walk) (limit rover distance to safe EVA walk). 25
- 26. (3) Interface Requirements- Example Identify the interface items in the architecture models Use the “Catcher-Pitcher-Ball” approach to develop the interface requirements Arcitecture Modeling Methodology for each interface. Interface ‘Pitcher’ ‘Ball’ ‘Catcher’ Requirement Set (Send Data) (Data Characteristics) (Receive Data) Example FS Provides H&S Data 10. H&S Data US Receives H&S Data The 1st Stage shall provide The H&S message shall The US shall receive H&S H&S data to the US in consist of Z data across data from the US in and do accordance with US / 1st interface 295. something in accordance with Stage IRD 10. US / 1st Stage IRD 10. Description <Include Interface <Provide the <Include Interface Requirement Requirement in the SRD for characteristics of the data in the SRD for the second the first physical system being sent in the IRD physical system specifying that specifying that data is being between the two physical data is being received from the provided to the second systems.> first physical system.> physical system.> The single Interface item in the sample eFFBD Sample eFFBD reflects a common set of Interface First Stage Upper Stage Function X Function Z Requirements in the following three documents: 1) First Physical System SRD (Ex.: First Stage) Upper Stage H&S Function Y 2) Second Physical System SRD (Ex.: Upper Stage) External Interface 3) Common Interface IRD 26
- 27. Trace Derived Requirementsto Model Elements Trace/link the derived requirements (operational, functional, interface) back to the associated modeled elements Arcitecture Modeling Methodology Use the projects requirements management tool (Cradle, CORE, etc.) for linking. This linking activity close the loop for Model-Based Systems Engineering (MBSE). Accelerate OR Vehicle Move Accelerator Requirement Item Functional Model Item Pedal Disengage Brake System Disengage Brake System Decelerate Accelerate Vehicle Accelerate Vehicle Vehicle Decelerate Vehicle Decelerate Vehicle Change Vehicle Direction Change Vehicle Direction Move Engage Brake System Engage Brake System Brake Pedal Change Vehicle Direction ‘Maneuver Rover’ Top-Level FFBD Move Steering System 27
- 28. Arcitecture Modeling Methodology E. Model-Based Output 28
- 29. Model-Based Systems Engineering (MBSE) Output Generate a resulting MBSE requirements document: Arcitecture Modeling Methodology Where the SRD (and IRD) document headers are the actual model element names. Where the requirements text traced/linked to that model element are output under the header. Models PFD & FFBD Model “Names” become Requirement Document “Section Headers” Diagrams (PFD, FFBD, etc.) Requirements Requirement “Text” under each header derived from modeling characterization list. 29
- 30. Arcitecture Modeling Methodology Questions? 30
- 31. Arcitecture Modeling Methodology Backup 31
- 32. Benefits of Models(Why?) Provides Visual representation of system characteristics Arcitecture Modeling Methodology (easier to “see” what is going on). The primary means of communication with Stakeholders, Users, and Builders Guiding and recording aggregation and decomposition of system functions, components, and solution characteristics. Maintenance of system integrity through coordination of design activities. Assisting design by providing templates and recording decisions. Bridges the gap between customers problem space and designers solution space. 32
- 33. Hierarchical Considerations in Modeling The of the architect depends upon where you are in the hierarchy Arcitecture Modeling Methodology Stakeholders Mission Scenarios Level 2 Operational Test SoS External Interfaces Operate Operational Needs Train System Boundaries Integrate Stakeholders Level 3 System Test Acquisition Decisions System Transport Lifecycle Considerations 1 Train Technology Options Integrate Stakeholders Component Test Trade Studies Level 4 Element Manufacture 1.1 Risk Mitigations Sustain Technology Maturity Transport Dispose Each level of the hierarchy follows the same basic process but with a Different Focus 33
- 34. A Side-Track intoBreakdown Structures Product System Work Arcitecture Modeling Methodology Breakdown Structure Breakdown Structure Breakdown Structure (PBS) (SBS) (WBS) An exhaustive, A hierarchical tree A hierarchical tree hierarchical tree structure structure of PBS structure used for of components that make components and defining and organizing up a system, arranged in Implementing systems, the total scope of a whole-part relationship. arranged in whole-part project. relationship. Products PBS + Other Systems PBS + Services 34
- 35. The Boundary Diagram -Onion Model- SBS = PBS + Other Systems WBS = PBS + Services Arcitecture Modeling Methodology Training Transport System System Crew PBS Comm Sustain ? Manufacture System System PBS = Products Test System Other Ext 35
- 36. Swim Lanes UsingOnion Model Onion Model used to help identify PFD Swim Lanes depending on Project Level and Mission Phase. Arcitecture Modeling Methodology SoS Mission Phases System Mission Phases SoS Mission Phases System Mission Phases NA Operational Test Manufacture Operate System Test Integrate Transport Train Sustain Swim Lanes SoS External External 36
- 37. Operation and PhysicalElement Association (System Level) The table below illustrates the association of the System Level Operations to the applicable System Level Physical Arcitecture Modeling Methodology Element(s). Operation Allocation to System Level System Level Trans. to Hit Return Physical Exit Driving Golf To Enter Element Habitat Range Balls Habitat Habitat Habitat Swim Lanes Crew used for the Rover “Transition to Crew Equip Driving Range” EVA operation CTN (Comms) The “Crew” and “Rover” physical elements are involved in the ‘Transition to Drive Range’ operations, so they become the respective Swim Lanes in the associated Process Flow Diagram. 37
- 38. Transition from Operationalto Functional Modeling The model transition from “Operational” (using PFDs) to “Functional” (using FFBDs) may vary depending on the Arcitecture Modeling Methodology physical element involved. SoS Level SoS Mission / Operational Model System to Element Level (see table below) (see table below) Ground Systems Mission Systems Crew Module Launch System Operational Operational Operational Operational System Functional Elem SubSys Operational Operational Functional Functional Functional Functional Functional Functional 38
- 39. Decompose Function UntilUniquely Allocated to a Single Element The decomposition should continue Constraints System Performance until the function can be allocated Arcitecture Modeling Methodology Function C1, C2, C3 20 sec uniquely to a single physical element. Yellow Boxes (Leaf Nodes) 7s 1s 12 s Represent functions that will be used C1,C2, C1 C1,C3 C3 to specify Element Requirements (System 3.7 allocations). 4s 2s 1s 10 s Gray Boxes 2s Represent interim steps in the C1,C2 C1 C3 C1,C3 functional analysis. They DO NOT have associated 3s 1s 3s 4s 3s Element Requirements. C1,C2 C2 C3 C1,C3 C3 Ensure Performance and Constraints are properly carried down to leaf functions. 2s 1s Define Element Interface needs and C3 allocations. Deriving Element Functions Stop When Only Leaf Nodes specify requirements 39