Content area
Model-Based Systems Engineering (MBSE) is a relatively recent approach to model systems within the systems design lifecycle. MBSE draws from the Unified Modeling Language (UML) that was used for software development. The SysML (Systems Modeling) language using nine graphical diagrams that enable integration within and across the models for easier review, improved efficiency, and consistency of modeling. There are many challenges that are faced when moving from a document-based systems engineering practice and culture to one that embraces MBSE. This paper will discuss the challenges and a framework that addresses both cultural and structural components of moving to MBSE in designing systems.
Abstract
Model-Based Systems Engineering (MBSE) is a relatively recent approach to model systems within the systems design lifecycle. MBSE draws from the Unified Modeling Language (UML) that was used for software development. The SysML (Systems Modeling) language using nine graphical diagrams that enable integration within and across the models for easier review, improved efficiency, and consistency of modeling. There are many challenges that are faced when moving from a document-based systems engineering practice and culture to one that embraces MBSE. This paper will discuss the challenges and a framework that addresses both cultural and structural components of moving to MBSE in designing systems.
Keywords Systems Engineering, Model-Based Systems Engineering, Engineering Management
1. Introduction
Model Based Systems Engineering is an approach to applying systems engineering principles, tools and activities with a focus on developing electronic models that are architected to be integrated throughout the systems engineering life cycle as well as from high levels to more detailed levels of the models, and from single elements to the integrated system, as illustrated in Figure 1.
2. Problem Description
Badiru identified two levels of integration, horizontal across the phases of the life cycle, and vertical integration from the component to the system to the operational level of models [2]. For our MBSE conceptual model, we add a dimension integrating between elements to the system. The three dimensions of integration in our view of MBSE is: 1) between phases of the life cycle; 2) between levels of detail; and 3) integration between elements to the system. The MBSE models integrate elements between each phase of the life cycle: concepts, stakeholders and risk in the concepts phase, to requirements and architecture in that phase, to specifications and integration and interfaces in detailed design, through test cases and results in implementation, verification and validation, through to a deployed integrated system. The models integrate increasing detail from high level functions through to decomposed functions providing more insight into details of supported system functions. Lastly the models show integration and connectivity between elements, sub-systems, and systems.
MBSE requires a change in thinking from a modeling approach based on documents, such as, requirements, specifications, drawings, test cases, to one based on integrated models that are architected to demonstrate traceability between the elements of the traditional documents used in systems engineering design and development. According to Madni and Sievers [3] the value of MBSE comes from the system-related information being stored in a centralized and configuration managed repository. The software repository should enable the architected and interconnected capability of the system elements and models. It should also ensure alignment to the modeling language and standards, and incorporate error identification as part of the information system.
In this paper, we discuss the challenges and a framework that addresses both cultural and structural components of moving to MBSE in designing systems. This framework is based on the authors' experience applying, developing and teaching modeling of businesses, processes and systems.
3. Related Research
3.1 Benefits of MBSE
There are many benefits to using MBSE including: [3], [2].
* Having a common modeling language with electronic architecture of models and model elements
* Using an electronic repository, configuration management, and change control
* Providing improved efficiency, productivity, and quality
* Enhances communication and coordination amongst systems engineering stakeholders
* Enabling automation and optimization using the modeling elements and definitions of their behaviors
* Enabling multiple views of the system and its elements, interfaces, and interaction points, from a repository of models that eliminate redundant data entry
Following is more detail related to each benefit.
Having a common modeling language with electronic architecture of models and model elements
When using a MBSE software the system architecture includes the systems elements, the behaviors and the relationships between the elements and the models, which is controlled by the software and business rules embedded within the information system. A large benefit is having a common modeling language, with standard models and symbols that systems engineers can learn and communicate. This standard modeling language provides consistency which can be communicated and learned by different users, leading to less variation in the use of the models.
Electronic repository, with configuration management and change control
The electronic repository helps to manage the configuration and changes in the models throughout the systems engineering lifecycle. If a requirement changes, the impacted models are easily identified and can be changed due to the connectivity of the models and their elements. These changes can be easily communicated and distributed electronically to those who need to know.
Improved efficiency, productivity, and quality
The standard, electronic models incorporate configuration and change control helps to enhance efficiency and productivity of the models, the first time they are developed, as well as when they are changed, throughout the systems engineering lifecycle. The quality of the modeling is enhanced due to reduced variation and enhanced model standardization. Electronic error checking can also enhance model quality. According to Jorgensen [4], a "traditional functional requirements decomposition approach is likely to capture 50% of problem understanding." Incorporating use cases and scenarios can increase problem understanding to 90% or more the first time through. Up to 40% fewer requirement defects were found in systems developed with MBSE [5].
Enhances communication and coordination amongst systems engineering stakeholders
Concurrent engineering led to huge improvements in communication and coordination amongst engineering teams as they worked together to develop requirements, design, verification and validation. Teams of marketing, design, manufacturing and process engineers, along with other disciplines worked collaboratively versus each discipline completing their function in isolation, sequentially. MBSE has further enhanced the collaborative nature of systems engineering teams working together through automation, communication, workflows, error checking, configuration and change control. The integrated nature of the models and the electronic repositories leave less to chance and can reducing errors when models are changed.
Enabling automation and optimization using the modeling elements and definitions of their behaviors
Having electronic models of the systems requirements, design and testing, enable integration to other electronic automation and tools, including optimization programs, simulation, statistical analysis, forecasting and other decision analysis tools.
Enabling multiple views of the system and its elements, interfaces, and interaction points, from a repository of models that eliminate redundant data entry
MBSE enables having multiple views, diagrams, reports and documentation of the system and its elements, along with interfaces and interaction points. The engineer who develops the model the first time, and the stakeholder groups can decide the narrative and graphical views that they want to review, inspect and approve. These models can also be used for training, communication and educational purposes.
3.2 Challenges
There are many challenges that have hindered the adoption of MBSE, including: [3] and [2]
* Lack of training and education of the MBSE tools, principles, and methods in both industry and academia, with steep learning curve of tools and practices.
* Need to change the culture and practice from document-centric to model-centric modeling.
* Limitations of preferred system architectures and models in existing MBSE software applications.
* Lack of rigor in requirements analysis.
* Focus on activities that leverage MBSE has focused on requirements and architecture modeling versus design, verification, and validation phases of the life cycle.
Following is additional detail related to each of the challenges.
Lack of training and education of the MBSE tools, principles, and methods in both industry and academia, with steep learning curve of tools and practices.
Much of the education and training within traditional engineering programs teach Computer-Aided Design (CAD) for design drawings instead of MBSE for systems engineering. CAD applications have been around much longer than MBSE applications, and the use of these applications is much more mature than with MBSE. Since MBSE models were derived mainly from those in Object-Oriented modeling from the software development world, they have only recently been used to model systems through the SysML modeling language. There is a steep learning curve related to the tools, language and practices related to systems engineering life cycle activities and modeling, along with requirements elicitation techniques.
Need to change the culture and practice from document-centric to model-centric modeling.
This challenge is one of the biggest challenges and quite often discussed as a challenge preventing MBSE adoption. Existing systems engineering and design reviews that are based around document-based applications have a great deal of inertia, so incorporating new ways to review MBSE models is a distinct challenge. The new applications, modeling languages, approaches all need to be learned, but also new ways to review these models need to be developed and adopted. Reviewing graphical models with some narrative is vastly different that reviewing mostly narrative requirements documents. The review packages can be substantially different from what teams and customers are used to in the document-centric world. [3]
Limitations of preferred system architectures and models in existing MBSE software applications.
MBSE applications have evolved out of Information Architecture and Enterprise Architecture modeling and tools. One of the seminal papers by John Zachman was published in 1987 [6], that described the information architecture concepts which evolved into Enterprise Architecture. Zachman has developed and continually enhanced his models called primitives, schemas and an ontology that answered the fundamental architecture questions of what (data), how (process), where (location), who (roles), when (timing) and why (motivation) [7]. The MBSE concepts have evolved in the last 40 years, and were initially focused on information architecture and modeling. Each MBSE modeling tool may contain their own ontology, modeling elements, relationships and models that may vary based on the embedded architecture. Additionally, the look, feel and interface of these tools also varies significantly, causing significant learning curves. Additionally, integration with CAD and engineering drawings and tools is limited. This lack of integration can prevent model and requirements traceability, as well as configuration control issues.
Lack of rigor in requirements analysis.
Not only are there steep learning curves related to MBSE models, languages and software, there can be even heavier qualitative requirements elicitation techniques gaps based upon scenario building, process maps and use case tools which also must be learned. Engineers typically do not learn and practice requirements analysis elicitation techniques in traditional engineering programs. Many of the communication and professional skills are less learned and practiced including interviewing, building user stories and scenarios, listening, and facilitation skills which can be effectively applied to elicit systems engineering requirements.
Focus on activities that leverage MBSE has focused on requirements and architecture modeling versus design, verification, and validation phases of the life cycle.
The majority of the current use of MBSE has been in the requirements and architecture modeling and phases of the systems engineering lifecycle. This leaves very little use, practice and expertise of MBSE in the design, verification and validation phases. There needs to be use and connectivity across the systems engineering lifecycle. The requirements models, in particular use case diagrams and use cases lend themselves to easily be used to develop verification and validation test cases, but this use has been limited. [8]
4. Methodology
The methodology applied was to perform a literature review of the MBSE benefits and challenges to understand the landscape of what has prevented adoption of MBSE, as discussed in section three. This knowledge along with the author's experience in applying and teaching in the MBSE space enabled the development of a framework that addresses both the cultural and structural components that can help systems engineering organizations move to effectively adopting MBSE to design and deploy systems.
5. Results
The MBSE Structure and Culture Adoption Framework (MSCAF) is illustrated in Figure 2. These components are design to address the challenges in adopting MBSE.
The structural components of the MSCAF include the Systems Engineering (SE) lifecycle, modeling review approach, and modeling techniques. The cultural components include the culture change and professional skills.
Structural Components:
Systems Engineering (SE) Lifecycle:
Systems Engineering teams need to be educated in the Systems Engineering (SE) Lifecyle that is chosen in the organization to design and deploy their systems. The Vee model is a common model that includes the following phases: 1) Concept of Operations, 2) Requirements and Architecture, 3) Detailed Design, 4) Implementation, Integration Test & Verification, 5) System Verification and Validation and 6) Operation and Maintenance.
Modeling Techniques:
Special focus should be on identifying the MBSE systems modeling tools and automation that will be used in the organization that aligns to the organization's SE Lifecycle. An automated SE modeling tool with a user friendly interface that is easy to learn, and use should be selected. The SysML modeling language and the models that will be used should be identified and part of the automated SE modeling tool. Integration with CAD drawing tools, simulation, optimization and other decision analysis tools should also exist with the selected automated SE modeling tool. Systems Engineers and other team members should be educated and trained in the modeling tools. Experienced modelers should be hired to mentor the newer systems engineers, and help ensure appropriate use, error checking and consistent modeling techniques and practices.
Modeling Review Approach:
An approach for how to best perform the myriad reviews of the models needs to be expertly designed with the systems engineering teams. Additionally a migration plan for how to migrate from document-centric review to model-based reviews needs to be part of the review process. Assessment with key performance indicators related to the maturity of MBSE use should also be performed.
Cultural Components:
Cultural Change:
Culture change related to the different ways that engineers should optimally work together to design and deploy systems is critical for successful MBSE adoption. Culture change should be planned and communicated. Engineers will need to work collaboratively in teams, and this should be part of the culture change. Moving from a documentcentric to an MBSE approach should be part of the culture change.
Professional Skills:
Qualitative requirements elicitation techniques based upon scenario building, process maps and use case tools are critical to developing the systems requirements in the missions conceptualization phase, and the requirements and architecture phase. Engineers should learn and practice requirements analysis
elicitation techniques. Interviewing, building user stories and scenarios requires extensive communication, listening, and facilitation skills that some engineers may not have been exposed to in their past educational and industry experience, so this should be a first order of business for successful MBSE adoption.
6. Conclusions
This paper provided a review of the literature on the MBSE benefits and challenges to adoption as well as a framework to address the structural and cultural barriers to MBSE adoption in organizations that design and deploy systems. Future research includes empirically examining the usefulness of the MSCAF framework.
References
[1] Furterer, Sandra L., Systems Engineering: Holistic Life Cycle Architecture Modeling and Design with RealWorld Applications, CRC Press, Boca Raton, Florida, 2022.
[2] Badiru, A., Systems engineering models: theory, methods, and applications, Taylor and Francis, Boca Raton, Florida, 2019.
[3] Madni, Azad M., and Michael Sievers. "Model-Based Systems Engineering: Motivation, Current Status, and Research Opportunities." Systems Engineering, vol. 21, no. 3, 8 May 2018, pp. 172-190., doi: 10.1002/sys.21438.
[4] Jorgensen RW. Defining operational concepts using SysML: definition from the human perspective in rockwell coilins. INCOSE International Symposium; 2011; Denver, CO.
[5] Estefan JA. Methodology and metrics activity: overview, update, and breakout agenda. INCOSE International Workshop, January 28-February 2, 2011; INCOSE MBSE Initiative, Phoenix, AZ.
[6] Zachman, J.A., "A framework for information systems architecture," in IBM Systems Journal, vol. 26, no. 3, pp. 276-292, 1987, doi: 10.1147/sj.263.0276.
[7] Zachman, The Zachman Framework for Enterprise Architecture, https://www.zachman.eom/images/ZI PIes/ZF3.0.jpg Accessed 3/3/2021, 1967-2011.
[8] Glaessgen EH, Stargel DS. The digital twin paradigm for future NASA and U.S. air force vehicles. AIAA 53rd Structures, Structural Dynamics, and Materials Conference; 2012.
Copyright Institute of Industrial and Systems Engineers (IISE) 2025