© 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

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

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 Email: gene.rosenthal@lmco.com Phone: 408-756-5654

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

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

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 http://www.omgsysml.org/what-is-sysml.htm   Magic Draw logo https://www.nomagic.com/media/k2/items/cache/0548677e6432786dd8df61eb3aaec139_M.jpg INCOSE logo https://www.incose.org/

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

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

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

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

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

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

Thread Development Guidance

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

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

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?

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

References International Business Machine (IBM) Rationale Rhapsody https://www.ibm.com/us-en/marketplace/rational-rhapsody No Magic. Magic Draw https://www.nomagic.com/products/magicdraw Object Management Group (OMG) Systems Markup Language (SysML®) http://www.omgsysml.org/ Sparx Systems Enterprise Architecture http://sparxsystems.com/products/ea/index.html

Thank you Questions ? Gene Rosenthal: 408-756-5654 gene.rosenthal@lmco.com