CPS life-cycle efficiency and integration (or extended “DevOps” for CPS)

martint Monday January 15, 2018

I would now like to introduce what I consider as an important trend for many cyber-physical systems - the integration of life-cycle phases of CPS. With this I mean the following types of capabilities:

All this is of course not something new and has partly been realized by some organizations. The trend is highlighted by concepts such as digital twins and DevOps. The latter concept – that of integrating systems development and operations through continuous development, integration, testing and delivery (emphasizing measurements and improvements), is already standard practice in the IT-domain, with a close connection to agile software development practices.

As indicated, the mentioned capabilities would correspond to an extended DevOps practice for CPS, encompassing software and hardware, as well as access to data from the physical world and potential local as well as remote control of the CPS. Much of the life-cycle integration would leverage the cyber-side of a CPS as well as computing infrastructure. It would also however imply needs for modularity and proper architecting across the cyber- and physical parts.

For CPS, DevOps as found in the IT domain is still not standard practice. The challenges and problem space are also expanding with larger scale deployment of more advanced CPS.

By making data available from the various life-cycle stages of a CPS, a DevOps approach provides potential for data analysis and visualization, for example in terms of functionalities for predictive maintenance. Functionalities like these, in turn, enable to create new service-based business models. While such services may still rely on CPS products, they provide added value, facilitate life-cycle changes, and overall change the focus of the customer offering.

An extended DevOps approach for CPS has the potential to increase cost-efficiency of the CPS, e.g. replacing hardware parts only when needed, providing agility for improving services to meet new needs (including new customer and regulatory requirements), and finally, provides an important means to deal with the increasing system complexity.

The significantly increasing system complexity for CPS, compared to traditional systems, has the effect to increase the uncertainty that remains when a new system is launched to the market; the more complex the system is, the more uncertainties will remain even after the system has been deployed. This implies that a system will almost per definition need to evolve after it has been deployed. The sheer complexity of the system will require learning from deployments and actual operation, and the ability to act, for example in terms of software upgrades. This is however not straightforward to accomplish. Would this type of approach be relevant for all CPS? The answer; whenever relevant services and business are possible! This is especially true for advanced CPS – where maintenance, the possibility to upgrade/downgrade and reuse are ample (such as for example automated driving vehicles) but will likely become common for less sophisticated CPS too.

Introducing such an extended DevOps approach however poses quite a few challenges and potential obstacles – these will be the topic of the forthcoming posting. For further insights and lessons learnt on DevOps for CPS, see the ICES conference 2017 .

Permalink: https://platforum.proj.kth.se/tiki-view_blog_post.php?postId=30