1. © 2018 Lockheed Martin Corporation
Migrating a Department of Defense (DoD) Program to an Automated Information System using Model-Based Systems Engineering (MBSE) Approach
Gene Rosenthal
Lockheed Martin Space
© 2018 Lockheed Martin Corporation

2. Agenda My Background Project Background
Project Objectives & Deliverables
Model-Based Systems Engineering
Safety Critical Functions
Transition to a Model-Based Environment
Model Validation
Challenges & Lessons Learned
Conclusion
References & Q&A

3. My Background Gene Rosenthal, Systems Engineer Staff
Lockheed Martin, Space ~15 years
Model-Based Systems Engineer (MBSE) practitioner for ~3 years
Leading multiple MBSE projects, including projects for the Navy and Missile Defense customers
Previously worked on other programs, including the International Space Station and NASA’s Near Infa-Red Camera (NIRCam) programs
Phone:

4. Project Background
DoD safety community performs safety assessments on proposed architecture using a systems engineering approach
Process developed over decades
Uses a defined set of safety critical functions for each subsystem
Captured in numerous documents, spreadsheets, PowerPoints
Critical functions are managed in a text based document and distributed among various appendices by subsystem
Each critical function lists associated safety standard(s) and additional attributes used for categorization
Contractors responsible for each subsystem manage their critical functions
DoD Needs to Perform Faster & More Agile Safety Assessments to Better Accommodate Fixed-Price Contracts

5. Project Objectives & Deliverables
Desire to transition the program from a document-centric to a model-centric approach
A pilot project consisting of the various contractors was stood up and chartered to transform how these assessments are performed
Two Main Objectives:
Duplicate safety document content in a system model to enable ongoing model-based management of safety data
Establish a design-agnostic safety framework for use in future architecture trades
Deliverables:
Functional model capturing critical and derived functions that traces to subsystem physical architecture
Modeling approach
CONOPs to support safety assessments using the model

6. What is Model-Based Systems Engineering?
Model-Based Systems Engineering (MBSE) IS Systems Engineering…..In a Model!
Definition of system CONOPS, functionality, architecture, interfaces
Requirements traceability to design for accurate and efficient impact assessment
Requirement and implementation trades
Planning and support for system verification and validation
System Model
A descriptive representation of a system of interest captured using a graphical, object-oriented language (e.g. System Markup Language (SysML)®)
Tools
IBM Rhapsody, No Magic Cameo System Modeler (Magic Draw), Sparx Systems’ Enterprise Architect
OMG SysML logo
Magic Draw logo
INCOSE logo

7. Safety Critical Function Breakdown
Critical functions are managed in a text based document
Each subsystem critical function lists associated safety standard(s) and additional attributes used for categorization
Safety Standard
Applicable safety standard the subsystem critical function satisfies. Satisfying the standard(s) is a requirement on the subsystem to prevent hazardous condition(s).
Event Category
Event categories were also used to classify subsystem critical functions. These event categories are closely related to the safety standards and allows critical functions related to a particular event easily identified (e.g. security).
System Critical Function
System critical functions are used to “bucket” subsystem system critical functions. One or more subsystem critical functions may fall under one system-level function.
Subsystem Critical Function
Name of the subsystem critical funciton
Definition
Definition of the subsystem critical function
Hazard/Rationale
In addition to the definition, each subsystem critical function lists the potential hazards that may result if the function does not meet the intent; related to the safety standards/event categories.
Critical Component(s)
Each subsystem critical functions list the affected component(s) related to the critical function
Understanding Document Structure Key to Model Organization

8. Transitioning to a Model-Based Environment
Transition was done using a phased approach
Setting up the Model - Establish Metamodel, Profile, and Package Structure
Metamodel: Serves as a framework that defines how model elements relate to each other
Profile: Collection of unique model stereotype
Package structure: Folder structure for model organization
Reproduce document content within the model
Capture design-agnostic functions and rationale
Identify approach and benefits to use the model for safety activities

9. Metamodel & Profile Enable a Consistent Modeling Approach
Metamodel and Profile
Metamodel & Profile Enable a Consistent Modeling Approach

10. Model Organization Key to Collaboration
Package structure (folders) in the model use a simple numbering scheme to clearly identify where content resides
Keeping original document content in its own model to manage separately for future document releases
Organizing folders by subsystem allowed contractors to work their models separately
The metamodel, profile, and style guides are available in a common section for all contractors to reference
Model Organization Key to Collaboration

11. Reproduce Document Content within the Model
Initial baseline model captured document
Safety Standards, Critical Functions, Event Categories, etc.
Content enabled generating table views that resemble tables within the document
The model illustrated various issues with the document structure
Naming conventions/classification were reused
Compound functions/names
Reusing naming conventions and generating compound functions (activities) are considered a bad modeling practice
Discussions with safety subject matter experts to understand document structure background
Resolution led to a better model

12. Design-Agnostic Functions and Rationale
Safety document functions and rationale were very design-specific and could require significant revision to apply to future system upgrades
Team derived design-agnostic content to be reusable for future system trades and more explicitly capture the intent for critical functions and the rationale for system design decisions
Two levels of derived content
Subsystem Derived Functions: derived from Critical Function definitions
Consequences: derived from either the Safety Standard, Hazard/Rationale, or through Subject Matter Experts
A visual representation (thread) of each subsystem critical function and derived content were captured within a Block Definition Diagram (BDD)
Thread development guidance allowed each contractor to have a consistent look and feel
Derived Content Enables Knowledge Capture for Future Workforce

13. Thread Development Guidance

14. Identify Model Approaches and Benefits
Use cases depict how the model can be used
A model-based approach allowed the team to describe future state safety activities
Assess Impacts of
Proposed Change
Manage/Maintain
Safety Critical
Functions
Use Cases Describe Model Usage

15. Validation Ensures Model Utility
Model Validation
Model validation was performed to ensure model was accurate and useful
Validation was done using a phased approach
Model content accurately capture document content
Derived functions – design agnostic? Consistent terminology used? Reuse?
Consequences – accurately reflect rational and relationship to derived functions were correct
Deep dive into derived functions that cross multiple subsystems
Visual thread validation – element relationships correct
Validation Ensures Model Utility

16. Challenges and Lessoned Learned
Difficulties of Change
Misconception that derived functions introduced new requirements
Discussions with Safety and Modeling teams resulted in a more mature/useful model
Collaboration Challenges
No source control utility to collaborate with multiple contractors
Baseline model with package structure distributed among the contractors
Models merged
Coordinated “passing the model” between contractors
SysML® Education
Several folks new to MBSE and SysML®
General concepts understood, but nuances of modeling language and tools were new concepts (e.g. associations vs dependencies, functional decomposition)
Data Structure Transition from a Document to a Model
Visual representation (threads) of Critical Functions highlight document inconsistencies
Document ontology flaws discovered
Safety Community Buy-In
Agreement on modeling approach (safety team will use the model)
Model becoming primary artifact; ownership of critical function lost?

17. Model-Based Systems Engineering Key Enabler to Cost Savings
Conclusion
Safety impacts related to architecture changes are now easily visible
Design-agnostic safety model lays the foundation for future trade studies and safety assessments
Validation efforts continue to mature the model and ensures the usefulness
Currently looking for a project to pilot the models usage, which can lead to the generation of additional views
Future state: Document will be retired and the model will serve as the primary artifact
Cost saving are beginning to be realized by having this safety content within a model-based environment
Model-Based Systems Engineering Key Enabler to Cost Savings

18. References
International Business Machine (IBM) Rationale Rhapsody
No Magic. Magic Draw
Object Management Group (OMG) Systems Markup Language (SysML®)
Sparx Systems Enterprise Architecture

19. Thank you Questions ? Gene Rosenthal: 408-756-5654