Digital engineering (DE) is gaining momentum as the system engineering community matures practices and tooling. In its present avatar, DE workflows and tools rely on MBSE (Model-Based Systems Engineering) for developing and maintaining digital system artifacts and keeping these artifacts in sync during all phases of the system. This is presently achieved via descriptive models that digitally encode use-cases, system requirements, and system architecture. Simultaneously, the field of Model Based Design (MBD) has made great progress in modeling and analyzing domain-specific engineering systems. This has saved both time and money and increased safety of complex systems across application domains like aerospace, infrastructure, and medical devices. Knowing that, one might wonder: “How can DE exploit advances in MBD?”
What do you mean by combining MBSE and MBD?
Even though the MBSE and MBD models are conceptually related, they are often developed and maintained by different teams (and sometimes in isolation with very little intercommunication). The models do not exchange information and are often out of sync or inconsistent, which decreases their usage through the development process. Overall, such limited reuse and disconnectedness increases cost while providing little value. In this post we talk about what benefits programs and engineers can reap from a deeper integration between MBSE and MBD and what shape a solution might take.
In this post, we focus exclusively on Cyber-Physical Systems (CPSs)1 domain since they are an excellent source of large systems composed of complex subsystems whose interaction produces a rich set of behaviors. Modeling CPSs is challenging due to their inherent complexity that increases the amount of details that need to be captured, and the fact that these details need to be coherently combined across heterogeneous (and mathematically incompatible) modeling paradigms. Furthermore, CPS models touch all development phases including requirements and design, acquisition, development, verification, validation, and certification.
MBSE models of CPS typically track all different components and parts, wiring, requirements and product families. These models are fairly high-level and abstract, often relying on a mix of natural language and UML representations. By contrast, behavior models used in a MBD process are mathematically precise and include more details. MBSE and MBD models offer benefits individually, yet if done correctly, the integration of MBSE and MBD models promises far greater returns by serving as the single source of truth (SSOT) for all development phases. Apart from reducing development and maintenance cost, SSOT will enable automation of various analysis and artifact generation (reports, code, etc.). The more mathematical rigor is used to define SSOTs, the more automated reasoning becomes possible. For example, formal models enable automated model ↔ code bidirectional conversions, thus ensuring that the code and models are always in sync no matter where the change is made.
How? Keep reading and let’s dig in.
What is behavior modeling and why should I care?
For my systems engineering readers, the value of MBSE is likely obvious. CPS are often far more complex than our brains can comprehend. High level abstraction is necessary to help us mere humans understand, maintain, and improve these complicated systems. But why should a systems engineer care about behavior modeling? To answer that question, let’s take a look at the example problem of balancing a pendulum on a cart only by pushing or pulling the cart. Called the cart-pole system, it consists of an inverted pendulum fixed to the cart using a hinge such that it can lean in either direction freely. The system is unstable and, if left by itself, the pendulum will eventually fall. We would like the controller to be able to balance the pole on top of the cart, and the only input that the controller can provide is the input force (F) to the cart to move it horizontally. To come up with such a controller, one needs to understand how the cart-pole system behaves as time progresses and how it will react to the input force (F). In other words, we need a model that captures all the internal and external forces, as well as the laws of physics governing the motion and system parameters.2 If needed, this simple model can be further enriched by adding details of the mechanical elements using multibody modeling.
The more mathematically precise and unambiguous the model is, the more confident we can be about its performance. Ordinary differential equations (ODEs) fit the requirements well as they are expressive enough to represent the continuous time evolution of this system. Once we have the ODEs, we can mathematically compute and visualize (simulate) how our controller tries to balance the pole. A bigger benefit is that we can reuse the model to tweak the controller when requirements and systems change. These can be a change in requirements—energy minimization vs high performance—or it can be a change in the system parameters—heavier pendulum, balancing it on Mars, and so on.
In summary, the behavior of a system can be modeled as a set of rules that govern how it evolves in time. These rules are defined by its internal behaviors, interaction with other systems and the environment. The choice of modeling paradigm depends on the engineering domain, the abstraction level, and the system visibility. Some examples include ODEs, DAEs,3 PDEs, difference equations, automata (state machines), hybrid automata, petri-nets, programming languages, and more. The tools to model each are specialized to the application domain: EDA tools for semiconductor chip design, CAD tools, Mathworks, Ansys, Dassault Systèmes ecosystems for dynamical systems and so on.
OK, so why integrate MBSE and MBD models?
MBD models are high fidelity, used for simulations (think digital twins) and computational analysis. But when it comes to system engineering, these models are underutilized or completely tossed away and replaced with their abstract approximations. Sometimes they are coupled loosely in the system development process using frankenstein integration mechanisms (think bash scripts). This introduces a gap between low-level engineering and high-level architecture and system design, thus resulting in imprecise and suboptimal results. For readers familiar with the V-model of system engineering, this effectively makes the two arms inconsistent with each other.
The individual phases of the traditional systems development V-model can be made consistent with each other by using models as a single source of truth, as below.
In part this gap is expected as system engineers typically work with abstractions of behaviors and do not need the nitty gritty details as domain engineers do. A single source of truth lets us define this gap and better manage the effects of the gap. Without an SSOT, different analyses will rely on different models of the same system and since we can’t track the inconsistencies between these different models, it is not possible to track the resulting inconsistencies between analyses. That makes for inefficient maintenance, sustainment, and modification processes that cost time and money. What’s more, it also increases the risk of safety or security flaws being missed in analyses of critical systems.
By contrast, a tight integration between use-case and scenario design (which is a part of MBSE and MBD) offers tangible benefits. Case in point, consider CSAF,4 a component based modeling tool for verification and validation developed as part of Galois’ effort on the DARPA Assured Autonomy program. CSAF let’s system developers specify scenarios, requirements and design for a common model which are then used for simulation and verification analysis of individual components as well as the integrated system. Let’s take the example problem of analyzing an autonomous F-16 fighting falcon performance in different scenarios, including adversarial scenarios. In the figure on the right, we have a static air balloon and an adversarial aircraft (in red) that tries to manipulate the autonomous collision avoidance maneuver of the autonomous F-16 to try to hit the air balloon. Using CSAF, we not only model the flight control systems of the aircraft (MBD behavioral model), but a systems engineer can define high-level behaviors and requirements of the aircraft and also set-up a collision scenario using a high-level scenario description capability (MBSE model). Moreover, when the models are defined rigorously, CSAF can use them to automatically search for undesirable scenarios. The figure illustrates one such collision scenario found by CSAF. This concrete scenario can be simulated, visualized, and used to better the design.
An adversarial aircraft (red) tries to force the F-16 (black) to change its flight path and collide with the air-balloon. The x-y axis are the North/South and East/West coordinates. For illustration purposes, the aircraft are not allowed to change altitudes.
So why are we not doing it already? And do we stop at behavior modeling?
We are! And no, integrating behavior modeling is just the start! Tools like Ansys ModelCenter, SCADE Suite and SCADE Architecture are a step in the right direction and address aspects of the problem. But to really harness these tools’ and techniques’ full potential, the integration needs to be done both at the process and tool levels. This would require a rethinking of how engineering teams and decision makers communicate and will in turn affect that.
A large CPS team consists of mechanical engineers, control engineers, chip designers, and software engineers. For a long time, the success of the team has been dependent on the process they follow. Such a process is often bespoke and hard to reuse and replicate. Developing a rigorous system representation that is rich enough to serve as a single source of truth for all the teams and machine readable will decrease the dependence on the process. It will enable human-machine teaming, relieve humans of the tedious aspects of the work, catch inconsistencies earlier, and remove certain kinds of failures altogether.
Unified system representations can bring diverse domains closer together, and enable co-design resulting in highly optimal, performant, safe and secure designs. Imagine a situation where a mechanical engineer can sit with an embedded software expert and a hardware design engineer to co-design and optimize a design. Any change they make not only updates them about how the different aspects interact, but also simultaneously updates them of resulting alteration in the cybersecurity posture. That is what unified MBSE and MBD makes possible. The below figure illustrates how a unified system representation can connect different phases of the development process.
It might appear that such a unified representation is far out, but we don’t need one model to represent everything. What we need are semantics that can relate different models allowing them to be translated, checked for equivalence, and so on. Moreover, this is not an all or nothing endeavor, and even having some pieces of the puzzles can and are already yielding benefits. In fact, there has been a lot of progress in unifying and relating models. Efforts like ARL GEMINI are addressing unified simulator development for bringing together various subsystems (algorithms, communication networks, software, firmware, hardware, all the way to transistor level designs) and concerns for ground vehicle design, DARPA SSITH addressed cybersecurity of hardware-software co-design, and DARPA FIRE is taking on the challenge of developing models relevant to assessing cybersecurity vulnerabilities of complex CPS.
In short, this isn’t fancible technology, it exists here and now. The benefits aren’t a pipe dream, they’re already being realized. The digital engineering revolution has begun. It’s up to us to keep up.
1 CPS includes most other systems from domains like mechanical, electrical and electronics, and software.
2 System parameters for the model include the mass and the length of the pendulum, the gravitational acceleration, damping coefficients and external disturbances.
3 Differential Algebraic Equations
4 The Control System Analysis Framework (CSAF) was developed on DARPA Assured Autonomy.