A number of obstacles and challenges need to be overcome before DevOps (as for IT) and extended DevOps for CPS (previous posting) can be adopted. We elaborate some further obstacles in the following.

• Safety: Many CPS are mission- and/or safety-critical in nature, governed by strict regulations and standard practices that involve significant verification and validation (V&V) efforts before products (and software) are launched into the market. Such efforts are known to consume a large percentage of the development cost; sometimes figures in the order of 50% are mentioned. So while upgrades should be beneficial to safety (because of the learning involved), adopting a DevOps style practice requires a completely different approach to V&V and for regulations/standards to adopt the new approach.
• Security: A DevOps approach may partly help to deal with security but certainly requires a certain level of security (software and hardware) to be in place as an enabler before DevOps can be adopted. For example, in the auto-industry, collaborative services face this security challenge due to limitations in current vehicle to vehicle communication protocols.
• Cultural change: An extended DevOps approach requires a very different way of working, and would often come along with a change of business model (from a product to a service offering).
• Leadership and competences: Closely related to the cultural challenge, a successful change will require the right (often non-traditional) competence to be available as well as insightful leadership.
• Decoupling interdependent processes: CPS requires reconciling the speeds of development and dependencies among software, electronics and physical systems (integrated as part of a CPS). In CPS development, it is common practice that a few physical and electronics prototypes are developed while software at the same time experiences 100’s of iterations. While it is highly desirable to decouple the cyber and physical parts, this is still difficult because of explicit and implicit dependencies that are especially relevant for software. Successful decoupling thus requires that interfaces and other dependencies are thoroughly considered.
• Technology: Gather data from CPS will often result in huge amounts of data. A large “machinery” in terms of supporting software and tools will be required to deal with the data. Moreover, a whole range of tools and tool-chains, leveraging automation (for example for software building and testing), are required for the introduction of DevOps. This also points to a related challenge, that of achieving cost-efficient interoperability across CPS tools and data-bases.
• Ensuring properties in a CPSoS: Applying the extended DevOps approach in a system of system (where there is no more a single integration), requires extra considerations. It is necessary to ensure that the (more or less independent) evolution of individual CPS maintains compatibility. The “rules of the game” that govern direct interactions as well as emerging behaviors need to be controlled in order to for example avoid undesired increase of risk. Extra efforts for this coordination will thus be necessary at the CPSoS level.

These challenges thus encompass socio-technical concerns.

When it comes to data gathering, my understanding is that a lot of data is already gathered but that many companies do not yet systematically make use of the data, including also connecting the variety of data available from multiple life-cycle stages. This requires both new competences, strategies and technical integration. In the longer term, I believe that data analytics will be a natural connection to CPS, eventually also providing real-time data analytics, thus providing a higher level loop and further extending the scope of CPS.

CPS architectures will play an important role in fully adopting the extended DevOps approach. Upgrading of cyber and physical parts will require a strong emphasis on stable interfaces and managed (as well as reduced no. of) dependencies. Availability and safety will require the ability to switch to previous (or trusted, reduced capability) versions of software.