search menu icon-carat-right cmu-wordmark

From Model-Based Systems and Software Engineering to ModDevOps

j-hugues Joe Yankel

The increasingly rapid system and software evolution that characterizes modern software practices has motivated the growth and widespread adoption of a DevSecOps approach to secure system development. DevSecOps and Agile practices shorten the time needed to develop, deliver, deploy, and sustain working resilient systems. Another rising tide in systems and software engineering has been model-based systems engineering (MBSE), a formalized methodology that is used to support the requirements, design, analysis, verification, and validation associated with the development of complex systems. A digital-engineering environment that applies MBSE creates a common standards-based approach to documenting a system that enforces the use of the standard by all stakeholders, resulting in an overall reduction of development risks.

In this blog post, we introduce ModDevOps as an extension of DevSecOps that embraces MBSE technology. By making the integration between DevSecOps and MBSE explicit, ModDevOps enables developers to benefit from both the speed of DevSecOps and the risk reduction of MBSE.

About Model-Based Systems and Software Engineering

In MBSE, systems are defined as a collection of models and source-code artifacts. Their combination covers all steps of the engineering cycle, from high-level requirements to the delivery of the source code.

Figure 1 provides an overview of the interplay between abstract activities and the corresponding supporting notation. It covers the languages used:

AT_table_1_v2.original.png
Figure 1: MBSE Partial Overview

The SysML activity-diagram formalism is used to capture the MBSE engineering activities depicted above.

  1. First, the system is specified and designed. A high-level model of the system is captured using SysML, along with a set of system constraints that will serve as requirements for the next step. At this stage, the model of the system is informative and covers its requirements, high-level breakdown structure, and a high-level description of each component interface and behavior.
  2. Next, the system’s architecture is defined. It is derived from the SysML definition and associated constraints. AADL allows for a more precise definition of the system architecture as a collection of components that capture regular software or hardware behaviors (thread, device, processor, etc.).
  3. Finally, the system parts can be engineered. From the AADL model definition, the software low-level requirements can be derived, e.g., the subprogram interfaces to be implemented. These parts can then be generated automatically from Simulink, Ansys SCADE, or other models. Conversely, engineers may choose to use UML to capture the model of the software to implement first or they can implement it directly in their programming language of choice.

However, Figure 1 depicts only the causal dependencies among steps in the process, i.e., its dataflow. In addition, it is necessary to move several decision points across steps, such as moving validation milestones forward or rework activities backward. Each project will thus have dedicated control-flow strategies to decide which steps to execute.

Each modeling technology provides automated processes to perform model analysis or code synthesis. Here is the role of each formalism:

These processes can be embedded into larger systems engineering processes or through proper inclusion in a software production environment.

ModDevOps: Combining MBSE and DevSecOps Practices

Model design and analysis capabilities ultimately contribute to the engineering of a system across its entire lifecycle. Hence, a model can also be used to produce software in various ways, including code generation, simulation-based verification and validation (V&V), and implementing digital twins.

These approaches require a common process to ease model exchange and model transformation, and to leverage automation whenever possible.

ModDevOps, a Primer

So far, we have introduced various considerations on models and how they can be interconnected. We will now define ModDevOps, which extends DevSecOps to incorporate models.

One desirable feature of models, beyond their advanced analysis capabilities, is the ability to deliver secure systems faster, which is the true realization of DevSecOps. DevSecOps has been codified as a set of principles and practices that enable better communication and collaboration among relevant stakeholders including developer (Dev), security (Sec), and operations (Ops), as well as other teams for the purpose of specifying, developing, continuously improving, and operating software and systems products and services. It aims to shorten the systems-development lifecycle and provide continuous deployment with high software quality. DevSecOps relies on the idea of continuous integration, delivery/deployment, monitoring and infrastructure as code as central pillars of its methodology.

ModDevOps Definition

The U.S. Air Force proposed a definition of DevOps that comprises the entire system lifecycle:

DevOps is a software engineering culture and practice that aims at unifying software development (Dev) and software operation (Ops). The main characteristic of the DevOps movement is to strongly advocate automation and monitoring at all steps of software construction, from integration, testing, releasing to deployment and infrastructure management.

We extend this definition to ModDevOps and define ModDevOps as follows, with changes we have made to the Air Force DevOps definition highlighted in bold:

ModDevOps is a systems/software co-engineering culture and practice that aims at unifying systems engineering (Mod), software development (Dev), and software operation (Ops). The main characteristic of ModDevOps is to strongly advocate abstraction, automation, and monitoring at all steps of system construction, from integration, testing, releasing to deployment and infrastructure management.

ModDevOps is built on the premise that MBSE is the natural complement to software engineering. Providing machine-processable models can increase automation to improve system V&V, but also to generate application or infrastructure code. Code generation reduces software engineering effort, thereby freeing resources.

ModDevOps Loop

ModDevOps extends DevSecOps by defining how specific steps can be supported by model-based techniques. ModDevOps refines the typical DevSecOps infinite-loop steps depicted in Figure 2:

AT_table_1_v2.original.png
Figure 2: ModDevOps Loop

Modeling encompasses modeling and source-code definition. Source code is the ultimate machine-processable model of the function to be implemented. This step encompasses the following activities of ModDevOps:

  1. Plan, requirements definition, and properties define the systems-engineering models of the system along with a validation plan.
  2. Modeling architecture and parts refine the models and define domain-specific models to cover the various parts. Models address specific concerns captured in the previous phases (e.g., the need to model the environment, control, or architecture of an embedded system).
  3. Virtual Integration defines the interaction points between these models, e.g., how the realization of an architecture executes specific functions or associated engineering models and the environment model.

Test bench/system realization is an automated software factory that builds the various artifacts of simulation code and executables.

  1. Code generation produces code from models with multiple objectives: generating functional and middleware code to run on the target, and generating simulation elements. Likewise, glue code is generated to (1) monitor properties such as resource consumption or data exchange, and (2) detect specific execution patterns. Finally, software implementations can also be performed manually.
  2. Software assembly combines the various pieces to build multiple targets.

Ops deploys and executes the generated software.

  1. Monitor collects, validates (for accuracy and consistency), and stores data for further analysis.
  2. Data Analysis produces metrics that inform follow-up updates to the system requirements and properties, and updates to the system design, either at the level of the model or of the software.

As defined, ModDevOps extends DevOps with MBSE. These steps appear mostly during the Dev phase, aggregating engineering artifacts. The Ops phase entails collection of data to inform subsequent updates of the system. These can affect all elements of the process, from high-level systems artifacts down to software elements. The quality of the data collected and its analysis are critical.

Future Development of ModDevOps

Model-based techniques have demonstrated their added value in defining proper abstractions to conduct early analysis and virtual system integration. Modeling encompasses activities well beyond software development. It touches all engineering domains, including systems engineering, mechanical engineering, electrical engineering, etc. The larger view of a DevSecOps-like process that we have presented in this blog post embraces modeling activities as an integral part of the engineering of software-intensive systems.

ModDevOps extends DevSecOps by recognizing the role of modeling activities in the engineering of systems, especially cyber-physical systems. The formalization of ModDevOps using SysML allows us to better characterize the various steps of the process. As defined, ModDevOps remains a generic process that can be tailored. For more information about ModDevOps and how you can apply these practices in your organization, please contact us at info@sei.cmu.edu.

Additional Resources

Read the SEI blog post, An Introduction to DevOps.

Read about SEI work in DevSecOps.

Read the SEI blog post, An Introduction to Model-Based Systems Engineering (MBSE).

Read about SEI work in AADL.

SHARE

This post has been shared 3 times.