Systems engineering and software engineering have evolved as distinct disciplines with different terminologies, focuses, and concerns. As software becomes an increasingly important element in all systems, there is a growing need for these disciplines to develop effective ways of collaborating. In this blog post, I briefly summarize the history and current state of the convergence between systems engineering and software engineering and recent developments that are forging new practices for engineering the smart systems of the future.

Mechanical and electronic systems today are increasingly cyber-physical systems (CPSs)—physical systems that are controlled or monitored by computer-based algorithms (in other words, software). Previously, many systems were predominantly physical—and as these systems grew in complexity, systems engineering matured to balance design, risks, costs, and other system objectives. More recently, software has become a larger part of these systems—and often a more crucial component of the systems’ overall functionality.

Today’s automobile is a good example of a CPS. As early as 2010, there were about 10 million lines of software code in a car. Software helps to monitor and control such automobile subsystems as brakes, heating and cooling, navigation, and entertainment, as shown in Figure 1. Today the number of lines of software code in cars has increased to more than 100 million. Software continues to make possible most of the advanced capabilities of modern automobiles and is the primary catalyst for the growth and evolution of these capabilities over time.

A smart CPS is a system characterized by autonomous system attributes that function outside the direct control of humans. Today we have autonomous aircraft, unmanned aerial vehicles (UAVs), industrial and agricultural robots, assisted devices, robots that look for improvised explosive devices (IEDs), and self-driving cars. Because software provides the autonomous system attributes for all of these CPSs, a smart CPS draws on software engineering as well as systems engineering.

The escalating demand for new features, new capabilities, and new devices is likely to continue to increase the primacy of software in our physical systems and devices. Software can add capability without adding weight or greatly increasing power requirements. It can also lower the cost of deployment and improve systems more quickly by providing updates over the airwaves. But with these added benefits come challenges. The trend toward autonomous systems with greater capability has led to

• increased software size and complexity
• increased cybersecurity risk
• rapidly changing operational environments
• the need to accommodate more—and more frequent—feedback loops
• the need for new ways to verify and validate adaptive systems

Verification and validation (V&V) practices are a key element of systems engineering. Traditionally, V&V practices were used to vet a system before deployment, with the assumption that the system would not change much once deployed. As software has made development cycles shorter, we still go through V&V in every sprint and cycle, but we do it faster and with more automated tools. For autonomous, adaptive systems that employ machine learning and artificial intelligence, however, we don’t always have full visibility into how the systems make decisions. If we allow systems to continue to evolve post-delivery, these systems change after their initial vetting. How do we conduct continuous V&V in this dynamic new environment?

This kind of rapid system and software evolution has motivated the growth and widespread adoption of the DevOps approach to system development, which assumes that development is never finished, but instead continues throughout the system’s life. DevOps concepts bring new practices and processes into the systems-development lifecycle that we built in the past.

As our systems become more adaptive, they become more data-dependent. If systems are allowed to adapt autonomously, we need strong feedback loops and strong dataflow back to developers, architects, or relevant stakeholders who must be able to watch changes in a digital twin or model-based system to assess the implications of the adaptation. If a machine-learning or AI system starts to learn bad habits or is attacked in training and induced to learn the wrong thing, developers must be able to correct them. Through continual testing, autonomous testing, and lifecycle testing, they need to ensure that systems are secure and remain secure, and that as vulnerabilities are discovered, they are quickly patched.

Systems engineering is concerned with such system attributes as power, weight, performance, cost, and schedule, as well as risk and resiliency. Because systems engineering traditionally sought to balance system design by interacting with other engineering disciplines, systems engineers treated software as a separable component of the system that performed certain specific functions such as power and timing. As software has grown to represent much of the system’s functionality, the boundary between systems engineering and software engineering has begun to break down.

Here are a few examples that illustrate the blurring of this boundary:

• The cost, speed, weight, and features of commercial-off-the-shelf (COTS) units today frequently exceed those of organically developed, bespoke systems.
• Software cost overruns now frequently exceed the cost of system delivery and sustainment.
• Latent cyber vulnerabilities and those exposed during operations or due to underlying dependencies are putting the security of entire systems at risk.

In cyber-physical systems, developers must integrate hardware and software throughout the lifecycle. The software cycle can evolve more quickly than the hardware cycle because it is not dependent on physical resources. Techniques have emerged in recent years to develop, integrate, and deploy software frequently and quickly. Companies such as Google, Netflix, and Amazon deploy versions of their software daily, and sometimes multiple times a day. Theoretically, such rapid deployment of software functionality is possible in almost every system, but with a cyber-physical interface, there are increased safety concerns. These concerns are especially germane in the defense, auto, aeronautics, and medical domains, where errant code could inadvertently cause harm. In this environment of emerging and escalating risks, finding ways to successfully integrate systems engineering and software engineering is gaining urgency.

Neither systems engineering nor software engineering is physically based in the way that, for example, mechanical or aeronautical engineering are. As system functionality increasingly resides in software, these disciplines can and must collaborate—rather than conflicting, their different views and approaches should support and enhance each other. Such synergy is both possible and necessary.

Software engineers can perform most or all of the systems engineering for the software in information systems, but not for the non-software elements of CPSs. The hardware in CPSs is still within the purview of systems engineers in collaboration with the software engineers who take responsibility for the software. In a CPS, systems engineering work should be cleared for software acceptability, and software engineering work should be cleared for systems acceptability. As software provides new capability and customer options, good systems engineering is required to manage and oversee cost and schedule, integration, and delivery of a system that meets customer needs.

Systems and software engineers must negotiate and agree on roles and tasks. Software engineers must architect, design, and implement their software in a system context. Systems engineers, in performing necessary tasks not done by subsystems and disciplines, must adapt their practices to include software engineers as important participants.

Opportunities for achieving synergy between systems engineering and software engineering include the following:

• Architecture—A core principle of the Agile Manifesto is that working code is more important than architecture; the manifesto proposes “loosely coupled and highly cohesive” system architecture. This is a sound approach for many systems. But some systems need tighter coupling; some systems are so large and complex that some level of architectural abstractions and reasoning are necessary, and some systems need architectural insights due to safety, regulations, and potentially lethal effects.
  
  Architecture combines and adapts effective design patterns and balances business goals and mission goals with system design to maintain focus on those goals, as shown in Figure 2 below. As developers go through the frequent sprints and other short-term cycles that characterize modern system development, an architectural framework keeps developers focused on what is most important to the system. While no one should over-architect a system, there are good reasons not to under-architect some systems as well.

• Model-based systems engineering (MBSE)—As DevOps and Agile practices shorten the time needed to develop working systems, another rising tide in systems and software engineering has been MBSE. A digital-modeling environment that applies MBSE creates a common standards-based approach to documenting a system that enforces the use of the standard by all stakeholders. This common modeling environment improves the ability to analyze the system and reduces the likelihood that defects will be injected. The availability of digitized system data for analysis across disciplines provides consistent propagation of corrections and incorporation of new information and design decisions. With MBSE, this information can be stated once and then automatically propagated to various views of the data for all stakeholders. The result is an overall reduction of development risks and the ability to find and correct defects earlier in development, when changes are relatively inexpensive.
  
  The SAE International and Object Management Group (OMG) are two organizations that have been active in the development of standards for MBSE. Organizations that have adopted and applied these standards have benefited from the ability to test designs in software and consider alternative designs with quantitative and qualitative measures before committing to development. An SAE standard that the SEI has been instrumental in helping to develop is the Architecture Analysis and Design Language (AADL), which has been used extensively to positive effect in the avionics industry. Advances in speed of delivery through Agile and DevOps, coupled with advances in quality and alternative design from MBSE, point toward an exciting future for synergistic systems and software engineering practices.
• Security engineering—With DevOps and automated tooling, we can now conduct security tests daily on code and continue to check security every night when we commit new code. The new development of autonomous red teams, or red team as a service, allows organizations to scan for vulnerabilities on a continuous basis for all of their systems, including supply-chain, financial, and contracting systems that are often the source of insider threat. Automated red teaming promises to improve security for everyone.
• Modern software practices—Agile, DevOps, DevSecOps, and techniques for continuous development, integration, and delivery, along with automated testing, are fundamentally changing the way systems are developed. As software factories increase developer productivity, developers have more powerful tools to do their jobs well and creatively and to test their work frequently. As the prevalence of tooling developed by the commercial software industry is being successfully applied in other domains, the systems engineering community is investigating what aspects of this automatic tooling and continuous integration and delivery can be brought into the CPS and hardware side of systems.

Developing the systems of the future will require the expertise that currently resides within—and beyond—the separate disciplines of systems engineering and software engineering. Without software, there is no new capability, and without good systems engineering, integration is problematic, and the delivered system may not meet customer needs. Synergy and collaboration between systems engineering and software engineering are essential—and problems of the future will require still more synergy among those disciplines and others such as computer science and human-centered design.

The International Council on Systems Engineering (INCOSE) chartered a working group in 2017 to address the interfaces between systems and software—physical, logical, data, and human—and to delineate relationships between technical and management processes, products, tools, and outcomes. This group is working to help close the gap between systems and software bodies of knowledge as systems evolve into using more software, and software evolves into needing and using systems engineering.

As we look ahead to a future where AI-enabled systems provide leap-ahead mission capabilities, a whole-system approach will be necessary to build such systems reliably and responsibly, including the human-centered aspects of these systems. We will look to emerging disciplines, such as AI engineering, which draws on a multitude of disciplines including software engineering and systems engineering, to realize the promise and power of these capabilities in a trustworthy, reliable, and scalable way.

At the SEI, we are working with the defense industrial base, academia, the defense industry, and the commercial software industry to define and pursue a research agenda aimed at spurring advances across all system types with a focus on innovation, deployment speed, vulnerability, and global competitiveness. We welcome your suggestions and ideas for collaboration—please contact us at info@sei.cmu.edu.