International Defense Security & Technology Your trusted Source for News, Research and Analysis
A system is defined by NASA as a construct or collection of different elements that together produce results not obtainable by the elements alone. Systems Engineering (SE) is defined as: The process by which a customer’s needs are satisfied through the conceptualization, design, modeling, testing, implementation, and operation of a working system. It is an approach to help cope with the complexity inherent in systems, to help avoid omissions and invalid assumptions, manage real-world changing issues and produce the most efficient, economic and robust solution.
It brings together a number of techniques to make sure that all requirements are satisfied by the designed system. It concentrates on architecture, implementation, integration, analysis, and management of a system during its lifecycle. It also considers software, hardware, personnel, processes, and procedural aspects of the system. Today, engineers and developers have fairly well codified the processes and techniques for building large, complex systems, and when executed properly, result in reliable and useful systems that serve users well.
MBSE focuses on creating and exploiting domain models as the primary means of information exchange between engineers, rather than on document-based information exchange. With traditional approach of Document-Based Systems Engineering (DBSE), project and design information is stored in documents and must be manually maintained and transferred between domains The traditional DBSE approach is labor-intensive and consists mostly of manual analysis, review and inspection.
Model-Based Systems Engineering (MBSE) is a systems engineering methodology that looks to achieve the goals of systems engineering through the formal application of models. A model is a simplified version of something–a graphical, mathematical, or physical representation that abstracts reality to eliminate some complexity. These models provide an efficient way to virtually prototype, explore, and communicate system aspects, while significantly reducing or eliminating dependence on traditional documents.
In a document-based approach, many documents are generated by different authors to capture the system’s design from various stakeholder views, such as system behavior, software, hardware, safety, security, or other disciplines. Using a digital-modeling approach, a single source of truth for the system is built in which discipline-specific views of the system are created using the same model elements.
Advantages of MBSE
MBSE is the formalized application of modeling to support system requirements, design, analysis, verification, and validation activities beginning in the conceptual design phase and continuing through development and later life cycle phases.
Models are used to explore the structure, behavior, and operational characteristics of system elements, evaluate design alternatives, and validate assumptions faster and earlier in the system life cycle. This is particularly useful for large and complex systems—satellites, aircraft, medical systems, and the like—where the solution must be proven practical beyond all possible doubt before, for example, launching into space or connecting to the first patient. Models also record and communicate decisions that will be useful to others. This information serves as documentation for Compliance, impact analysis, and other needs.
A model-based systems engineering (MBSE) approach can address the consistency and knowledge problems. A specification that is altered in one subsystem will be updated across the whole system. Traceability can be enhanced by connecting a subsystem design or activity to requirements. Subsystems will understand better which requirements they need to meet, and management will know how the requirements are met.
With the model, interactions between the subsystems can become clearer, and have an easy to access repository of hardware specifications. A member of one subsystem will be able to find out what material the structure is made of without having to read through many documents.
By using interconnected models to store, represent and relate this information and data, MBSE promotes consistency, communication, clarity and maintainability within systems engineering projects and addresses issues associated with cost, complexity and safety.
One area of concern within complex systems is cybersecurity. The SEI CERT Division has begun researching how MBSE can be used to mitigate security risks early in the system-development process so that systems are secure by design, in contrast to the common practice of adding security features later in the development process. Capturing system attributes in models enables systems engineers to perform threat-modeling analysis of the system early and incorporate mitigation strategies into the system design, thereby reducing the system’s overall security-related risks.
Modeling
A model must have a structure. A well-structured model can make the model understandable, usable, and maintainable, which is particularly important for complex systems. The goal of a model is to show stakeholders that the presented design satisfies the system’s requirements.
A model must describe both a problem that the designed system solves, and the designed system itself (the solution). The model must have these two sides, the problem side and the solution side. These are sometimes referred to as the operational and system points of view.
The operational point of view is the perspective of users, operators, and business people. It should represent business processes, objectives, organizational structure, use cases, and information flows. The operational side of the model can contain the description of “the world as-is” and the future state.
The system point of view is the solution, the architecture of the system that solves the problem posed in the operational side of the model. It should describe the behavior of the system, its structure, dataflows between components, and allocation of functionality. It should describe how the system will be deployed in the real world. It can contain solution alternatives and analyses of them.
Each of these points of view has two parts, logical and physical. Separating logical and physical aspects of the model is a way to manage a system’s complexity. Logical parts of the model usually change little over time, while physical changes are often initiated by technology advances.
A modeling language is a common terminology for clearly communicating an abstract idea that the model captures. The modeling language can be formal, with strict syntax and rules. A few system-modeling languages exist, including general-purpose languages such as the Systems Modeling Language (SysML) and Unified Modeling Language (UML), as well as specialized languages such as Architecture Analysis Design Language (AADL).
In practice, System Markup Language (SysML) based models have gained the most prevelance in MBSE application. SysML has strict syntax and rules for relationships and connections between elements, which helps to avoid ambiguity. These models are system relationship models and are useful for showing relationships among system functions, requirements, developers, and users. These models support 3 aspects of systems engineering:
System Functional Flows (i.e., System Architecture)
System Requirements Traceability
System and Organizational Process Flows
Requirement management in MBSE
The model is represented through four main areas: requirements, behavior, structures, and parametrics. Although various types of requirements can be represented in the model, here are three main types:
Business requirements: High-level statements of the goals, objectives, or needs of an organization. They usually describe opportunities or problems that pertain to the organization.
User requirements: Mid-level statements of the needs of a particular stakeholder or group of stakeholders. They usually describe how someone wants to interact with the intended solution. User requirements are often situated midway between the high-level business requirements and more detailed solution requirements.
System requirements: Usually detailed statements of capabilities, behavior, and information that the solution will need including detailed statements of the conditions under which the solution must remain effective, qualities that the solution must have, or constraints within which it must operate. System requirements include non-functional requirements, often called quality attributes or “ilities,” such as security, usability, testability, and modifiability.
MBSE with SysML offers the generic element type requirement, as well as subclasses: business requirement, usability requirement, functional requirement, performance requirement, interface requirement, physical requirement, and design constraint.
MBSE provides the opportunity to link various domain-specific tools together to produce a model-based framework for a systems engineering project. It is often discussed in terms of the three MBSE pillars: language, tool and methodology. The tool is the software used to produce the model, which consists of model elements, tables, diagrams, etc. representing the appropriate modelling language. Of the multiple languages available, the Object Management Group’s (OMG) Systems Modeling Language (SysML) has become the de facto modelling language for systems engineering, and is well suited to the description of the MBSE activities. The methodology is the process used to build the model.
While these potential benefits of MBSE are generally agreed upon by would-be practitioners, its implementation is challenging and many organisations struggle to overcome the cultural and technical hurdles along the long and winding road to MBSE adoption.
MBSE historically focused on expressing and recording requirements, design, analysis, and verification information. As modeling technology matures, it provides even more value by accelerating learning (e.g., simulation) and provide better insights into the physical world (e.g., digital twins). Both are important to evolve live systems and enable Enterprise Solution Delivery.
Digital twin technology supports MBSE. A digital twin is a virtual instance of a physical system synchronized through the physical twin’s operational data such as performance, maintenance, and health. Integrating the physical and virtual worlds validates virtual models and helps engineers improve system analysis, better predict failures or downtime, and provide for more accurate maintenance schedules. Digital twins support business agility by better predicting when future enhancements and product upgrades will be necessary to make Solution Roadmaps more accurate. And they can uncover new business opportunities by making learning, faster, cheaper, and more reliable.
Model-Based Software Design and Verification
An emerging trend is to use automation to create detailed software designs from high-level graphical inputs, and then use automatic code generation to create the code. This process is called Model-Based Design (MBD) or Model Design-Driven (MDD) software development.
Model-based design methods are becoming more prevalent because they work to accelerate the iterative software design-code-test/verify development cycle. Of most importance, model-based design tools enable the early validation of the software requirements.
The model-based design approach begins with a careful delineation of the software requirements, just as for the waterfall development process. However, after the textual requirements are complete, the MBD approach creates
the high-level software architecture in the form of graphical models of the code that shows connections between program modules and describes the software behavior using statecharts, sequence diagrams, and/or timing charts.
Once the software architecture is specified in the model notation, the model-based design tools perform the detailed software design without the user having to worry about declaring variables, allocating memory, or anything else normally associated with writing a Java, C, or C++ program. The detailed software design created by the model-based design tools may be the actual code, but it can also be a metamodel that can be executed to verify
that the software design meets the software requirements before the actual code is generated. This allows verification that the expected high-level behaviors of the software are actually triggered by high-level mechanisms. It can be executed to verify that all states of the system are reachable and that all communication interfaces work properly. The ability to easily and quickly execute the metamodel eliminates the need to perform unit testing. If problems using the metamodel or actual code are discovered, all debugging is done at the graphical model level (diagrams, statecharts).
Model-based design tools use the process of automatic code generation to keep the model in synch with the code. The code is automatically generated from the detailed software design or metamodel. All debugging to fix problems with the code occurs at the model level. Hand coded changes are not allowed because the introduction of hand-coded “fixes” would cause the code and model to get out of synch.
Automatic code generation thereby ensures coherency between the model and the code which is important for software engineers desiring to re-use model elements in new programs. Generally, however, hand-coded device drivers must usually be integrated into the complete software at build time (unless the drivers are also produced using model-based design methods).
Model-based design tools, while taking some time to implement up-front, have the potential to save a lot of software development time and cost. These tools allow the automation to automatically do low-level software design, coding, unit testing, and automatic code generation. This allows the cyclic steps of software design, test, and validation to be iterated very efficiently and at low cost. The use of automatic code generators also enables another nice feature: being able to generate software in multiple languages, or for different platforms, without additional software design work. Several model-based design tools have the capability to generate code in different execution languages (e.g., C, C++, Java), thereby allowing easy migration of software between small satellites having different operating systems or different microprocessors.
There are many model-based design tools available. However, the model-based design tools that most stand out in the small satellite literature are the Unified Modelling Language™ and the MathWorks’ MATLAB®
/Simulink® model-based design tools.
Model-Based Design Using the Unified Modelling Language
The Unified Modelling Language™ is perhaps the most widely known and used model-based design and
verification tool. The current specification of this modeling software is called UML2 and it is available for purchase from the Object Management Group (OMG). UML® was used by NASA, CSA, and all other subcontractors to design the software architecture and all software components for the James Webb Space telescope (200,000 lines of C++ code). UML® was used by the University of Alcala to design a small satellite real-time operating system.
CNES used UML to create autonomous software for the AGATA (gamma ray observatory) satellite. The Spanish National Institute of Aerospace Technology used UML in the design of the Nanosat-1B and UPMSat-2 micro-satellites.
UML® is primarily used to model object-oriented programs, but it can also be used to model procedural languages (e.g., FORTRAN). In UML® , the components are only allowed to communicate using message passing through interfaces. The components’ reactive behavior is defined by a Harel-type state chart and the messages trigger the transition between the states. UML2® can be used to describe the interaction of software components using behavior diagrams, component diagrams, activity diagrams, sequence diagrams, class diagrams, use case diagrams, and communication diagrams, and may ultimately be used to generate code using one of several commercially available tools.
Model-Based Design With MATLAB®/Simulink®
MathWorks’ MATLAB® /Simulink® has also been used to facilitate the model-based design of small satellite
software as embedded systems. The Aerospace Corporation has designed and developed software for several cubesat satellites using MATLAB® /Simulink as embedded programs in MATLAB® and then autogenerated to C code using MATLAB® Embedded Coder. MATLAB® has been used by Lalbhai Dalpatbhai College of Engineering to develop a customized toolbox for implementing small satellite communications.
OHB AG used MATLAB® MBD tools to model and simulate code for the guidance, navigation, and autonomous control of the PRISMA satellite. NASA Ames Research Center used MATLAB® /Simulink® to model, autogenerate code, and test the resulting software for the Lunar Atmosphere Dust Environment Explorer (LADEE) satellite.
References and Resources also include:
https://insights.sei.cmu.edu/blog/introduction-model-based-systems-engineering-mbse/
https://s3vi.ndc.nasa.gov/ssri-kb/static/resources/20150010982.pdf
