1. INCOSE IW 2012 MBSE Workshop Systems Modeling
John C. Watson
Principal Member of Engineering Staff
Lockheed Martin, MS2 Moorestown

2. 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?

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

4. 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

5. 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

6. ... …. …. 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

7. 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?

8. 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?

9. 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

10. 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

11. 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

12. 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

13. 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

14. 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

15. 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

16. 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

17. 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

18. 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

19. 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

20. 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

21. INCOSE Vision - What are the Challenges?

22. 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”

23. 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

24. 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

26. INCOSE IW 2012 MBSE Workshop
Requirements Flowdown Breakout Session
John C. Watson
Principal Member of Engineering Staff
Lockheed Martin, MS2 Moorestown

27. 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

28. ... …. …. 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

29. 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?

30. 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?