Publication

In recent years, the Department of Defense has emphasized modular and open approaches to system development to improve interoperability, facilitate system evolution and technology insertion, and foster competition. Requirements such as the Modular Open Systems Approach (MOSA) have been imposed on acquisition efforts. However, it can be difficult for the Government to assess whether the resulting architectures and systems are truly modular.

In this research task, RT‐205, Identifying and Measuring Modularity Violations on Cyber‐Physical Systems, we investigated modularity violations in cyber‐physical systems. Cyber‐physical systems are composed of diverse subsystems consisting of both physical and software components. Cyber‐physical systems are more representative of the systems that the DoD acquires than a pure software system. Our approach combined the analysis of alternative architectural perspectives with the analysis of project version control systems and project documents, and machine learning techniques. We were able to identify modularity violations from different architectural perspectives that were driven by hardware or domain factors instead of pure software issues. To accomplish this, our research approach consisted of four complementary activities:

1. We investigated techniques to decompose the architecture of a cyber‐physical system into modules using three different criteria for addressing different stakeholders’ concerns.
2. We leveraged machine learning and natural language processing techniques to identify hardware related concepts that are responsible for triggering changes in cyber‐physical systems.
3. We combined the previous two techniques to identify modularity violations triggered by hardware issues in different architectural views of the cyber‐physical systems 
4. We implemented a proof‐of‐concept demonstrator to show how stakeholders can perform modularity violation analysis in cyber‐physical systems.

For test cases, we used two open source cyber‐physical projects, OpenWrt and MD PnP. In OpenWRT, we were able to determine that the majority (78%) of system maintenance actions were associated with hardware concepts, such as firmware support, chip support, and hardware bugs. We were also able to detect potential modularity violations and assess the likely driving factors. For example, at one level of the system architecture, we found 16 potential modularity violations driven by hardware issues. Of those, 11 are explicitly related to adding support for new chip types. This result strongly suggests that, despite the modular architecture of OpenWRT, it is unable to fully contain cascading changes from the introduction of new chip types. Such cascading changes are one of the chief concerns of the DoD as it acquires, maintains, and upgrades a complex web of cyber‐physical systems for the warfighter. In an ideal modular system, the introduction of a new mission component should not require reengineering the other components of the system. Of course, this ideal is never achieved, but the goal here is to enable DoD to get as close as possible while remaining cost‐effective.