1. Integrating MBSE into a Multi-Disciplinary Engineering Environment A Software Engineering Perspective
Mark Hoffman
20 June 2011
Copyright © 2011 by Lockheed Martin Corporation. Published and used by INCOSE with permission.

2. Background
Large Systems Integration that includes large scale distributed S/W systems
100’s of system and software engineers
Over a 100 Components
Hardware components and software components (CSCIs)
Well over 1 million lines of code
100’s of Hw / Sw Interfaces
1000’s of Requirements
Engineering disciplines use multiple languages and tools whose results are not always easily integrated
The potential for MBSE is that it provides a means to integrate multi-disciplinary engineering including systems, hardware, software, analysis, and test throughout the development life cycle

3. Software Engineering is mostly Model Based Software Development
Current Approach
Software Engineering is mostly Model Based Software Development
SysML models – requirement analysis
UML models and Matlab/Simulink models – design & implementation
Systems Engineering flow down of System Design, Interfaces and Requirements to Software Engineering typically consists of Textual Documentation
Word Documents, PowerPoint slides, Excel spreadsheets, , etc.

4. Lack of integration is a source of design discrepancies and errors
Problem
Lack of integration is a source of design discrepancies and errors
As design, interfaces or requirements change integration issues are introduced
Time lag for information
Coordination of changes showing up at the same time
Often manually intensive to gather up the changes and get distributed to the stake holders

5. Considerations For Incorporating MBSE Approach
Incorporation of MBSE into a broader multi-disciplinary engineering environment could provide
More timely information
Similar semantics using standards like SysML
Easier integration with Software Modeling
Tighter integration to improved traceability
Requirements
System model artifacts such as interfaces
Test Cases – System scenarios (Activity Diagrams)
Impact Analysis

6. Questions to be addressed with an MBSE Approach – (1)
What should other engineering disciplines expect from MBSE?
Software engineering should expect the high level conops of the system (mission scenarios)
How the system will be used
Software engineering should expect interface definitions including component channelization
Software engineering should expect change impact due to requirement changes that effect software

7. Questions to be addressed with an MBSE Approach – (2)
What can MBSE learn from model-based approaches used in other engineering disciplines?
MBSE can learn model organization from software engineering
For large systems, model organization is key for achieving
Reusable model components
Minimizing merging of modeling artifacts
MBSE can learn effective approaches for configuration management of model components
To facilitate good collaboration, configuration management of these model components is critical
MBSE can learn effective design patterns / frameworks that allows for effective collaboration and reuse

8. Questions to be addressed with an MBSE Approach – (3)
How should the practices and tools be integrated/coupled across disciplines?
For large scale, complex designs the following areas need to be considered:
Model Organization
Number of Team Members
Geographical distribution
Configuration Management of model components
Integration of tools
Requirements Management tool
Modeling tool
Configuration Management tool
Databases (that contain program specific data such as parameter values)

9. Questions to be addressed with an MBSE Approach – (4)
How are the system, hardware, and software models managed to ensure an integrated technical baseline?
To manage an MBSE effort of this scale the following topics would need to be addressed
Program Management – Manage overall modeling activities across all disciplines
Configuration Management – Manage the CM architecture to facilitate technical baselines, reuse components, distributed CM for collaboration
Model Architecture – Manage the modeling structure and model organization to enable consistency and seamless integration between disciplines