INCOSE IW 2012 MBSE Workshop Systems Modeling John C. Watson Principal Member of Engineering Staff Lockheed Martin, MS2 Moorestown john.watson@lmco.com

Topics Systems Engineering Modeling Approaches Key Practices Integration Challenges How are we using our system models? What’s hard to do in the model? What’s hard about connecting to other domains?

INCOSE - Integrated Systems Engineering Vision Where is the SAM in his picture and how does I contribute?

The MBSE Integration Across Domains Lockheed Martin Proprietary Information Lockheed Martin Proprietary Information Lockheed Martin Proprietary Information Lockheed Martin Proprietary Information Lockheed Martin Proprietary Information Lockheed Martin Proprietary Information The MBSE Integration Across Domains Customer Specification Program Management Product Support System Architectural Model ò G ( s ) U Analytical Models Verification Models Analysis Spec Test Plan Performance, RMA, SWaP, Cost, etc. MBSE Inside is cross domain ** This domain integration also occurs not just to the significant bubbles but can also place within the modeling environment Analyze the System Specification to create System Level Requirements Using the System Level requirements and the process of refining Use Case and Scenarios to capture the System Architecture composed of behavior, structure, and interfaces utilizing SysML The System is further decomposed to a set of components that collaborate to meet the System Level Requirements as well as additional derived requirements for the components. At all points, relevant analysis is identified to verify that current constraints can be satisfied with specification or to consider multiple trades and options. How does Behavior Execution benefit? Analysis Models Higher quality behavior definition helps better understand the analysis problem and therefore improves the quality and of analysis effort The connection improves out ability to measure change impact to the analysis effort Test Opens the door for test to be involved more on the left side of the V Visualize Behavior of what and how to test Performance Stress and thermal analysis Reliability, Maintainability and Accessibility = RMA Size, Weight and Power = SWaP Role of blue bubble is to; Analyze customer needs Derive a system architecture that satisfies needs Derive a specification for each of the component parts. Same tasks, different approach Initial scope within engineering but now Domains include: Analysts, Integration and Test, Software design, Documentation, Mechanical Design, Electrical design, manufacturing, PM, Support Manufacturing Mechanical & Electrical Models Q SET CLR S R Software Models Lockheed Martin Proprietary Information Lockheed Martin Proprietary Information Lockheed Martin Proprietary Information Lockheed Martin Proprietary Information Lockheed Martin Proprietary Information Lockheed Martin Proprietary Information

System Architectural Model Value Added Improve communications across all domains engineering, manufacturing, management and support Uniform and Consistent Repository of the “Truth” integrated across all engineering domains Improve ability to Measure Change Impact A more thorough and complete assessment Reduce time to access the change Reduce the number of  defects and detect them earlier

... …. …. A Model Tree … … SoS Level - System Specification System of Systems Model - System Specification Spec S1 System Level System Model - Subsystem Specification Spec 1 Spec 2 Spec n ... Subsystem Level Subsystem A Model Subsystem B Model Subsystem C Model …. Component Specification Spec 1 Spec 2 Spec 3 Spec 4 Spec 5 Spec 6 Spec 1 …. Spec n Spec 1 Spec n Component Level - Design - Implementation S/W … Component Domain Model 1 H/W S/W … Component Domain Model 2

SAM Goal - Derive Component Requirements The Requirement Flow Down Analyze Customer Needs Define System Requirements Refine Logical Architecture Synthesize Allocated Architecture Results A derived Set of Component Specifications Used to Buy, Modify or Build Components End result – Logical model, behavioral model, physical model, requirements for each entity, and the relationships tying them together, So what else can we do with this information?

System Architecture Model Content System Architecture Model – A structured representation that focuses on the overall system requirements, behavior, structure, properties, & interrelationships Requirements What are the stakeholder goals, purposes, and success conditions for the system Specification of black box behavior and characteristics for each component Behavior What the system has to do to meet the requirements Transformations of inputs to outputs (functional/activity models) State/Mode-based behavioral differences (state models) Responses to incoming requests for services (message models) Structure The parts that exhibit the behavior The component hierarchy, elements, interfaces and stores Properties The performance, physical characteristics and governing rules that constrain the structure and behavior Interrelationships Including all UML/SysML relationships between model elements. What Practices do we use to integrate across domain, system model is a across domain model? Once we have this infrastructure in place how can we leverage it to implement other SE tasks How do we leverage the SAM foundation to Integrate other domains?

Integration of SE Domains within SAM Allocate & Manage System Budgets Size Weight Power System Cost Development Costs System Readiness Levels Reliability, Maintainability and Availability (RMA) Because the SE view manages across the system development and disciplines

Allocate &Manage System Budgets System X Max Power = 100 W System Actual = 87.3 18.8 38 30.5 20 40 30 Subsystems SS1 SS2 SS3 9.6 4.9 4.3 16.5 9.5 4.5 10 5 5 15 10 5 Components C1-1 C1-2 C1-3 C3-1 C3-2 C3-3

Integration to Program Change Control Process Evaluate change requests Assess change impact Path to all domains Estimate cost of change Assess Change Requests Isolate information involved in the change Evaluate alternatives Implement change Implement Changes Prepare Review Package Conduct review Adjudicate issues Review Change Merge Change into Current Baseline Resolve conflicts Baseline Take snapshot of the CM environment (entire or partial) Name and manage Baselines

Integration of SE Domains within SAM Behavior Execution Animation Component collaboration Validate desired behavior Manage Requirements Manage Domain Specific Requirement Attributes Requirement Traceability and Coverage Derived, Verify, Refine, Satisfy Manage System Hazards and Safety Requirements Manage Product Line Variations Generate External Documents With Report Generators Or By Modeling Document Content and Format

System Architecture Models vs. Analytical Models Analysis Spec ò G ( s ) U Analytical Models Used to capture the system’s behavior, structure, constraints, interfaces and requirements Used to reduce risks thru analysis, validation and optimization Mathematically-based to support computation or simulation Repository-based to define product entities and their inter-relationships SAM = Requests analysis AM – calculates answer(s) SAM – Retains Answer A vehicle to solve or verify a solution defined by constraints and assumptions consistent with SAM A vehicle to define the needed analysis task including the task’s goals, imposed constraints, and assumptions

Analysis and Simulation Tool Integration ò G ( s ) U Analytical Models How have we used them? Early Conceptual Design Increase the number of early Architectural iterations Improves quality and reduces risk of proposal Behavior Performance Analysis Validate latency requirements and software deployment Mechanical Analysis Thermal Analysis Calculate allocated budgeted values Trade Studies Cost Analysis Analysis Spec Tend to be quantitative Model Center – Tool integration Adams - multi-body dynamics simulation model used to analyze the vehicle performance MATLAB is used to define the optimization functions SEER-H -perform hardware life cycle cost analysis

Analysis and Simulation Tool Integration Integrate SAM with multiple analysis tools Optimization Across multiple individual analyses e.g. Optimize across cost, performance, weight Weight G ( s ) U Cost G ( s ) U Performance G ( s ) U

Software Domain Integration Derive Software Architecture Deliver Specifications Software Requirement Specification (SRS) Interface Requirement Specs (IRS) Interface Definition Documents (IDD) Interface Description Language (IDL) code file Approach Direct - SysML to UML Model Indirect– Extract documents from SAM Spec Software Models

Mechanical and Electrical Integration Deliver Firmware Component Specifications Direct approach Interface to Firmware Design Tools SAM (SysML) → SystemC → VHDL → Hardware Indirect approach Extract specification document from SAM Cable Specification Documents Derived Cable Requirements Identified cable numbers, cable interconnects and internal cable connections Deliver Interface Control Document (ICD) Mechanical & Electrical Models Q SET CLR S R SAM captures blackbox requirements, Interfaces and Behavior

Integration and Test Integration Verification Models SAM Provides Requirements, behavior, structure, etc. Using SysML and UTP to: Define the Test System Architecture Derive an Integration and Test Plan Define Test Contexts, Test Cases, and Test Components Requirement Traceability Matrix Manage Test Component Inventory By using SysML and UTP it makes an easier integration

Program Management Exchange Development Status Metrics Schedules Development Costs Product Costs Development Progress Technical Performance Support Change Control Process Assess Change Request Estimate cost of change

Manufacturing and Support Product Support Provide Product Line Management Data Product Line Variants Component Revision Compatibility Synchronize BOM to SAM Second Source or Component Replacement Component Specification Rationale Help evaluate alternatives Manufacturing

INCOSE Vision - What are the Challenges?

INCOSE Vision - What are the Challenges? Tool Environment Integration We use many analysis/design and test tools Today they are difficult to set-up, configure and upgrade We need to be able to easily and quickly integrate them Establish more Standard Transformations e.g. SysML-Modelica Transformation Specification SysML Modeling tool compatibility We need to share models with our customers, contractors and within LM We will not all use the same modeling tool Complete SysML Model Tool Interchange is needed XMI and Diagram Interchange Spend too much time setting up and maintaining tool environment Today we need tool experts for each tool Transition to new updates and inter-tool compatibility Need “Plug and Play”

INCOSE Vision - What are the Challenges? Maintaining Information integrity Need better and quicker ways to validate information Leverage Re-use Standardized Domain Profile definitions Profile, Library, Viewpoints, Use Case, Validation constraints, icons, etc. Domain Libraries Reference Architecture Standardized Viewpoints Need ability to quickly switch to one or combination of selected domain viewpoints Filter out what is not needed Marking and Isolating Classified or Proprietary Information Standardized Domain definitions – maybe even validation algorithms and profile test cases (XMI and tool compatibility) Standards for marking documents, not for models

INCOSE Vision - What are the Challenges? Barrier to change Understand Risk and Benefits of change Understand Cost to change and ROI Tool Vendors – What is SE? Most of the UML based SE modeling tools originated from software domain communities SW development community, e.g. UML experts not SE experts Understand the SE workflow use cases Not just within a single tool but across the entire SE domain workflow use case Without that understanding it has been difficult to; Deliver the most productive product by automating Task Non-homogeneous MBSE environment Some Departments/companies are document based In SE we are not delivering a detailed design or implementation but an abstraction of the detail in the form of a specification

INCOSE IW 2012 MBSE Workshop Requirements Flowdown Breakout Session John C. Watson Principal Member of Engineering Staff Lockheed Martin, MS2 Moorestown john.watson@lmco.com

The MBSE Integration Across Domains Lockheed Martin Proprietary Information Lockheed Martin Proprietary Information Lockheed Martin Proprietary Information Lockheed Martin Proprietary Information Lockheed Martin Proprietary Information Lockheed Martin Proprietary Information The MBSE Integration Across Domains Customer Specification Program Management Product Support System Architectural Model ò G ( s ) U Analytical Models Verification Models Analysis Spec Test Plan Performance, RMA, SWaP, Cost, etc. MBSE Inside is cross domain ** This domain integration also occurs not just to the significant bubbles but can also place within the modeling environment Analyze the System Specification to create System Level Requirements Using the System Level requirements and the process of refining Use Case and Scenarios to capture the System Architecture composed of behavior, structure, and interfaces utilizing SysML The System is further decomposed to a set of components that collaborate to meet the System Level Requirements as well as additional derived requirements for the components. At all points, relevant analysis is identified to verify that current constraints can be satisfied with specification or to consider multiple trades and options. How does Behavior Execution benefit? Analysis Models Higher quality behavior definition helps better understand the analysis problem and therefore improves the quality and of analysis effort The connection improves out ability to measure change impact to the analysis effort Test Opens the door for test to be involved more on the left side of the V Visualize Behavior of what and how to test Performance Stress and thermal analysis Reliability, Maintainability and Accessibility = RMA Size, Weight and Power = SWaP Role of blue bubble is to; Analyze customer needs Derive a system architecture that satisfies needs Derive a specification for each of the component parts. Same tasks, different approach Initial scope within engineering but now Domains include: Analysts, Integration and Test, Software design, Documentation, Mechanical Design, Electrical design, manufacturing, PM, Support Manufacturing Mechanical & Electrical Models Q SET CLR S R Software Models Lockheed Martin Proprietary Information Lockheed Martin Proprietary Information Lockheed Martin Proprietary Information Lockheed Martin Proprietary Information Lockheed Martin Proprietary Information Lockheed Martin Proprietary Information

... …. …. A Model Tree … … SoS Level - System Specification System of Systems Model - System Specification Spec S1 System Level System Model - Subsystem Specification Spec 1 Spec 2 Spec n ... Subsystem Level Subsystem A Model Subsystem B Model Subsystem C Model …. Component Specification Spec 1 Spec 2 Spec 3 Spec 4 Spec 5 Spec 6 Spec 1 …. Spec n Spec 1 Spec n Component Level - Design - Implementation S/W … Component Domain Model 1 H/W S/W … Component Domain Model 2

SAM Goal - Derive Component Requirements The Requirement Flow Down Analyze Customer Needs Define System Requirements Refine Logical Architecture Synthesize Allocated Architecture Results A derived Set of Component Specifications Used to Buy, Modify or Build Components End result – Logical model, behavioral model, physical model, requirements for each entity, and the relationships tying them together, So what else can we do with this information?

Questions to Explore What is the content of these exchanges between domains? What are the challenges to do these exchanges? How would we like to exchange data?