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.

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:

• Systems Modeling Language (SysML)
• Architecture Analysis and Design Language (AADL)
• Unified Modeling Language (UML)

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:

• SysML provides some capabilities to perform tradeoff analysis, along with semantics checks. SysML supports requirements engineering and will provide a mechanism to assess that all requirements are traced to system constituents.
• AADL is an SAE International standard that the SEI has been instrumental in helping to develop. It has been used extensively to positive effect in the avionics industry. AADL provides more capabilities to support performance, safety, or security analysis. In addition, it enables project-specific analysis to assess some structural properties, such as conformance to some modeling guidelines. This analysis allows designers to assess most of the non-functional properties and ensure partial functional correctness.
• UML supports semantics checks to validate that the model is sound, just like compilers. The benefits of a modeling approach pertain to the ability to master the complexity of software functions. Programming languages now propose a variety of tools to assert software correctness based on satisfiability modulo theory (SMT) solvers, such as ANSI/ISO C Specification Language (ACSL) for the C language, or SPARK2014 for Ada.

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

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.

• MBSE relies on models as first-class abstractions of a system under study. Automated code generation results in both increased confidence in produced software and fast delivery. Yet, this is usually a one-way process with challenges in debugging generated software or informing model updates.
• Simulation capabilities are important to perform early validation of cyber-physical systems. Co-simulation supports model execution as a federation of executable models. Some standards, such as the Functional Mockup Interface (FMI), provide a standardized interface to interconnect models and the associated simulation environments.
• Digital twins consist “of three components, a physical product, a virtual representation of that product, and the bi-directional data connections that feed data from the physical to the virtual representation, and information and processes from the virtual representation to the physical.” These links support continuous improvement and maintenance of the system through the analysis of runtime logs and their comparison to the system’s optimal performance.

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

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.

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

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 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 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:

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.

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.