Context, Foundations and Impact of Cyber-Physical Systems

In an early posting, I addressed the question of what constitutes a Cyber-Physical System and How Do I Know When I See One? In this posting, I would like to follow up and add some more reflection.

First of all, the introduction of the concept of CPS has had quite some impact. The original US initiative was recognized by the US President’s Council of Advisors on Science and Technology, eventually resulting in the launch of a multidisciplinary research program on CPS by the National Science Foundation (a program that is still active), [Ref: Cyphers D2.1]. Since its introduction, the use of CPS has spread and it has also been adopted within several industrial domains, notably in the form of Industry 4.0 initiative in Germany, as a manufacturing domain interpretation of CPS. A large number of definitions of CPS have been introduced over the years. Let us here focus on three representative ones.

1. “The integration of physical systems and processes with networked computing has led to the emergence of a new generation of engineered systems: Cyber-Physical Systems (CPS). Such systems use computations and communication deeply embedded in and interacting with physical processes to add new capabilities to physical systems. These CPS range from minuscule (pace makers) to large-scale (the national power-grid).” - This US definition was part of the initial CPS initiative [Ref: Cyphers D2.1]
2. “A Cyber-Physical System (CPS) is a system with embedded software (as part of devices, buildings, means of transport, transport routes, production systems, medical processes, logistic processes, coordination processes and management processes), which:
   • directly records physical data using sensors and affect physical processes using actuators;
   • evaluates and saves recorded data, and actively or reactively interacts both with the physical and digital world;
   • is connected with other CPS and in global networks via digital communication facilities (wireless and/or wired, local and/or global);
   • uses globally available data and services;
   • has a series of dedicated, multi-modal human-machine interfaces.”,
   
   This more detailed definition was provided by acatech, the German National Academy of Science and Engineering in its work on an Integrated Research Agenda for CPS [Ref: Acatech]
3. Cyber-Physical Systems or "smart" systems are co-engineered interacting networks of physical and computational components. This represents a more recent definition as part of the NIST CPS framework initiative [Ref: NIST 2017 ]

The different emphasis between the definitions (1 and 3 on one hand, and 2 on the other), provides two common but different perspectives to CPS; one emphasizing co-design and multidisciplinarity (definitions 1 and 3), and the other, the IT/cyber side capabilities of CPS (definition 2). Further definitions of CPS often highlight characteristics such as a large scale nature and capabilities related to adaptivity and intelligence.

Considering the etymological origin of the word, it is interesting and important to note the dual interpretation of the word “cyber”. The mainstream interpretation of the term “cyber” refers to the use of computers or computer networks, see e.g. [Ref: M-W, 2018]. However, the term originates from Norbert Wiener who coined cybernetics from the Greek “kybernetike”, meaning "governance", referring to feedback systems, [Ref: Wiener]. Today, both interpretations are relevant for CPS.

A key aspect of CPS is the potential for integrating information technologies, operational technologies in terms of embedded systems and control systems, and physical systems, to form new or improved functionalities.

It is important to realize that such integration concerns more than just matching apparent interfaces and combining cyber and physical parts. The composition has the purpose to achieve overall functionality and end-to-end system properties such as safety, availability and extensibility. Composition is thus multi-dimensional. A key challenge in developing CPS is that our current engineering methods and tools only provide limited support for such multi-dimensional integration -
see the Foundations workshop which addressed these and other challenges.

The diversity of definitions, and since more and more systems are becoming “CPS”, led the CyPhERS project to propose a characterization of types of CPS (the definitions tend to be rather general). The characterization recognizes that there are different types of CPS (e.g. from centralized to decentralized, with or without humans, at lower or higher levels of automation, etc.) and the fact that people using the term often have a bias, or emphasis when using it. This emphasis may, for example, refer to a viewpoint considering cloud and edge computing as core aspects of a CPS, see e.g. [Ref: Cyphers D2.1, Cyphers D2.2, Törngren]. Since CPS per definition represents heterogeneous systems, it is natural that they will have to be described by multiple views. A characterization of CPS can, for example, draw upon the CPS architectural framework by NIST, emphasising development of safety-critical CPS with common viewpoints such as functions and interfaces, as well CPS specific aspects such as timing and composition [Ref: NIST 2017 ].

As a perspective, it is interesting to relate to ongoing methodological work on Systems Engineering (SE) by INCOSE. In this work it was noted that there was little consensus on how to define what a “system” is among leading SE experts! It was however possible to identify a core set of traits that provide a common notion of what characterizes a “system”. These traits include the following: (i) there are relationships between the parts (of a system); (ii) there are interactions between the parts; (iii) there is more than one part; and (iv) there are "emergent properties" – that is, properties of the whole system not possessed by the individual parts acting separately [Ref: Sillitto].

One might then draw the conclusion that a CPS, in addition to these basic criteria, also needs to contain cyber- (computers) and physical parts, that are connected through feedback. Most CPS will in addition be communicating with other CPS, and have many types of interactions among the cyber (computer)- and physical parts, as well as with the environment in which the CPS acts, [Ref: Törngren, CPS, 2018]¹. The CPS will also typically encompass multiple layers, having to deal with mul-tiple time horizons and abstraction levels.

From an ongoing survey of academic research literature on CPS (carried out thin the Platforms4CPS project) we conclude that the use of the term within the academic research community is dominat-ed by computer science – thus of the cyber side in terms of IT. We also however note that CPS as a concept, but under other names, is prevalent in many other engineering disciplines, for example under the umbrella of smart industry, mechatronics and even 5G efforts.

Considering research that is labelled as CPS, there appears to be less work that embraces the physical side and actual co-design of cyber-and physical systems (along the lines of definitions 1 and 3). Further areas where research are needed were identified by the Platforms4CPS workshop on the Foundations of CPS, [Ref: Platforms4CPS D4.3], including Humans as part of CPS, Dealing with CPS complexity, Au-tonomy and AI as part of CPS, and Composability for CPS.

Are there factors by which a CPS can be distinguished from other types of systems, e.g. those la-beled as IoT? In general the terms may well be used to refer to the same kind of system. Often the terms reflect specific perspectives (e.g. IoT emphasizing communication). IoT is by many academics seen as a subset of CPS as an intellectual discipline, since a CPS may, or may not, include internet connections, [Ref: Lee and Seshia]. An IoT system on the other hand may not necessarily in-volve feedback, but may still encompass multiple considerations of the physical world.

¹ Martin Törngren and Ulf Sellgren. Complexity Challenges in Development of Cyber-Physical Systems (accepted for publication). To appear in Principles of modeling, Springer Festschrift" LNCS post-proceedings – Essays dedicated to Edward Lee. 2018

The increasing use of CPS leads to “sophisticated technology in everyone’s hands”. This use and deployment of applications beyond closed industrial applications deserves special attention since it has important implications for risks related to systems on which we increasingly depend, our perceptions of risks and decision making relating to these risks in the first place. The risks, and our perceptions of them, are also likely to evolve as part of the ongoing technological shift! (Click here for more details).

Essentially, the increasing capabilities of CPS are also mirrored by the introduction of new, and/or changing risks. Examples of this are for example seen with automation (e.g. automated vehicles), connectivity (e.g. connected critical infrastructures) and new forms of collaboration (such as between humans and robots in manufacturing, letting robots out of the fences).

For example, consider connectivity and the electrical grid, where we are seeing a change towards heterogeneous and distributed power supplies and new services, all relying on connectivity. Already today, many households today have connected electricity meters with web access to data regarding their electricity consumption and the electricity meters can be upgraded by the operators. This obviously leads to new cybersecurity risks with potential further implications such as unavailability of power.

While all these developments are driven by business cases and opportunities to improve functionality and cost-efficiency, there a number of concerns that become increasingly emphasized:

• Wider cone of uncertainty at system deployment (release) time. Releasing CPS into complex environments (beyond protective realms) has the implication that the number-of-unknowns – including unforeseen usages and what can go wrong, increase dramatically. As a consequence, the so called cone of uncertainty, what is known about the systems and their environments at design and release time, will widen as opposed to traditional CPS.
• Increased cyber-security threats. Opening up CPS directly implies new potential attack surfaces (forming part of the wider cone of uncertainty). Security risks have to be considered carefully and weighted towards the opportunities of connectivity. Cyber-security needs to be considered as part of CPS architecting in particular to ensure end-to-end security. With increasing strength of security mechanisms, humans in the loop are likely to represent the main vulnerability.
• Unavailability of service. When CPS is applied to critical infrastructures and services that are becoming part of our everyday life, our reliance on them will increase. As opposed to many traditional safety critical systems, there may not be a safe state for shutting down the system if something goes wrong. While we may stop trains, cars, electricity, water, etc. temporarily, the longer the outage, the larger the societal costs and implications.
• Perception of risk. Our perceptions of risks are not always rational, compare for example our perception the risk of driving vs. flying. For many of the new CPS applications it is quite unclear what our perception of risk will be. For example, in automated driving, how safe should a highly automated vehicle be – or rather – how much better than human driven vehicles should the automated vehicle perform? The requirements are not defined as of now, not even minimum ones, and yet, automated vehicles are soon to hit the market.
• Transient effects and socio-technical implications. Introducing new CPS will at least initially lead to a situation with mixtures of modern and existing (old) technology, such as for example automated and traditional cars. People will have to learn and understand the behavior of “the new”, and developers have to deal with mixed systems. On a longer term time-scale, people’s behaviors are likely to change and have impact on the functioning of entire systems.

All these concerns relate to an increase of the overall complexity (as discussed in a previous posting.) What are the implications of these concerns – i.e. regarding the increasing security risks, uncertainty, availability requirements, and the evolving nature of systems and requirements?

One take away is that we need to engage into debate on how these advanced CPS should behave – what the requirements should be. It is interesting to note the debate on data access and privacy that is now taking placing especially concerning Facebook. When lives are at stage, we would like to have these discussions earlier, rather than later.

A further take away is that future CPS will have to be engineered and maintained to be trustworthy – and that effort for accomplishing this need to be prioritized upfront. As a consequence, the system architectures need to be robust, yet also flexible and adaptable, such that systems can deal with failures and attacks, and also be adjusted and improved.

It is well-known that risks have to be closely monitored during the entire life-cycle of (safety/mission) critical systems. However, as opposed to traditional CPS, the level of uncertainty and high availability requirements will require to break new ground. Risks will increasingly have to be addressed operationally, by providing abilities to detect, reason about and deal with risks (such as security threats and failures) as they occur.

It will thus be necessary to gather data about actual operation and feed it back into development to adjust the CPS appropriately (new risks, faults and vulnerabilities learnt, adjusting trade-offs between security, availability and safety, etc.). All these concerns will drive towards extended DevOps for CPS (as introduced in a previous posting).

Automated vehicles represent a very interesting class of Cyber-Physical Systems, and a domain that is right now pushing the limits of CPS technology. I am writing this posting the evening after the presumably first accident where a pedestrian was killed by an automated test vehicle (despite a supervising person being present).
Most of the topics I have touched upon, such as the challenges, opportunities and complexity facets of CPS, can be very well illustrated with automated driving. An automated vehicle (at high levels of automation, corresponding to roughly SAE levels 3 and above), will need to be able to carry out tasks such as:

• Understanding complex and varying driving environments (roads, signs, debris, people, other vehicles, etc.)
• Understanding where the ego-vehicle is positioned within such environments
• Taking decisions on what to do in the short and longer term

The complex environments have to be mirrored by correspondingly sophisticated and complex perception, mapping, planning and control systems.
Key challenges in developing such automated systems include the following:

• Dealing with unexpected driving scenarios. While industry will likely do their best, it will not be possible to provide exhaustive coverage of driving scenarios. There will be limitations in the training of machine learning systems and sometimes also overtraining. AI (machine learning) systems of today lack the generalization power of humans, and it is hard to reason about the robustness of today’s machine learning systems.
• Dealing with uncertainty in perception and world understanding – for example in terms of the intent of pedestrians and other vehicles on the road,
• Dealing with faults in the ego vehicle (sensors, computation, software and hardware),

Automated driving is pushing the limits of existing technologies and methodologies. A key resulting challenge is that there is no established best practice for how to build such systems. Traditional safety critical systems mandate appropriate risk reduction, the use of simplicity for safety critical parts, and heavy redundancy when safety requires availability (such as in aircraft control systems).
The understanding of these concepts (risk, simplicity, heavy redundancy) in the context of high levels of automated driving is insufficient and current investigations imply that these best practices are at best only partly applicable. For example, safety still requires a proper understanding of the environment and the actions of the ego-vehicle, so the complexity of the perception problem remains. Active safety systems may help to some extent, with the risk of undesired activations of braking/stopping (false positives), which in turn may lead to hazards and accidents.
While the automotive industry is pushing hard and are getting closer to introduce automated vehicles for special business cases such as robot taxis, legislation, safety standards and guidelines are sorely lagging behind. Since automated driving means to design systems that break new ground – it is thus not so strange that these are lagging. It does however mean that there is a lack of a solid understanding of how to build such systems. Standards and guidelines can be developed only when such an understanding exists. Current functional safety standards were conceived long before the era of automated driving, and thus cannot represent best practices for how to deal with such complex systems.
The market drivers are very strong and will continue to drive, but accidents may strike back on the industry. Caution in testing and the introduction is highly advisable!! And it is clear that we need to accelerate the development of methods, theory and practices for automated driving.
Even if automated vehicles (eventually) will perform much much better than humans, there will unfortunately still be accidents. A final challenge then refers to how society perceives the behavior of automated vehicles - going well beyond technology!

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.

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:

• abilities to record data from various life-cycle phases of the CPS for structured (and potentially long-term) storage of data, code and models of the CPS,
• leveraging such data, code and models for
  • analysis and predictions, as well as for
  • coordinated development, testing, and upgrading of cyber and physical parts of a CPS,
• remote control of the CPS,

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 .

Several of my previous postings have referred to the complexity of CPS, but what do we mean by the complexity of CPS?
There are many interpretations and studies of “complexity”, from technical to socio-political systems. There are also many propositions for metrics and definitions of complexity. Few metrics however appear to be adopted into actual engineering practice and definitions tend to focus on certain facets of complexity.

Frequently discussed facets of complexity in the context of CPS include:

• heterogeneity of CPS, e.g. in terms of heterogeneous requirements, technologies, parts and behavior (e.g. as typically constituting hybrid, distributed, closed-loop real-time systems). As a result of their heterogeneity, CPS will be represented using multiple interdependent views, captured with different formalisms and tools,
• size and computability, e.g. in terms of the number of connectors, states, lines-of-code and requirements involved in a CPS. Computability refers to the number of operations required for solving an algorithm as a function of the problem size; many CPS design concerns belong to the class of NP-complete problems for which no polynomial time algorithms are known,
• uncertainty and change, referring to different kinds of unknowns and closely related to change. Typical examples include changing and conflicting requirements, unknown properties of technologies, impacts of design decisions, states in a distributed system, and the uncertainty of environment perception of a CPS,
• dynamics or structure, referring to behaviors that are difficult to predict, e.g. due to highly non-linear dynamics, dependencies among parts and things that may fail. The inherent parallelism and resource sharing in a CPS contribute to this type of complexity. The behaviors and structures may also change dynamically such as in self-learning systems and in a system of system.
• goals and socio-technical context of the CPS, referring to the complexity of the goals in terms of their feasibility, and organizational aspects such as competition, conflicts, policies and management.

Distinctions are often made between incidental vs. essential complexity (terms due to Brooks). Incidental complexity arises from the way in which a system is designed (for example because of the use of legacy components). Essential complexity instead concerns characteristics inherent to the problem being solved. A key example of incidental complexity is that of design that leaves certain aspects undefined (or only implicitly defined), implying that side-effects may occur, exemplified by undesired feature interaction.

Complexity can be viewed in terms of what Hillary Sillitto referred to as “objective complexity” or in terms of “subjective complexity”. Objective complexity refers to technical characteristics, and may be exemplified by the size/computability facet. Subjective complexity instead refers to how humans perceive the systems, for example, the perceived difficulty in understanding CPS behavior.

We are currently facing a growth in CPS complexity, with increasingly advanced functionality and the use of CPS in more open environments. In particular, this increases the uncertainty and makes it more difficult to reason about risk. Large systems imply that many things can go wrong and that there likely will be increased security risks. It will not be possible anymore to a priori foresee all scenarios and what might go wrong so dynamic risk management will increasingly be necessary. However, adding more protection mechanisms may further increase the system complexity. While the introduction of AI in terms of machine learning into CPS provides new capabilities, they also pose new challenges in terms of robustness of machine learning systems.

Finally, there is a close relation between the complexity of an environment of a CPS, the CPS itself, and the organization(s) developing the CPS. This is natural, since the essential complexity has to be matched!

Understanding the complexity facets of CPS, their sources, effects and how to deal with them, will be essential for engineering the CPS of tomorrow. I believe that one important perspective is that of contrasting facets of CPS complexity with limitations of organizations/humans and methodologies. (that have to deal with those facets). Understanding the gaps, may help to better identify means to deal with the complexity of CPS. I have a publication underway on this topic – soon to be linked from here – stay tuned!

If you would like to comment on this post, please contact platforum@itm.kth.se to request a login to the PlatForum. Thanks.

I will now turn to the question of what constitutes the foundations of CPS. With foundations I will refer to theory in the sense of well-confirmed models, procedures and explanations that help in performing design as well as in understanding and analyzing existing CPS – i.e. as an engineering perspective to foundations. A theory for CPS should provide us with “tools” to predict behaviors and properties of CPS as a function of design descriptions. By changing certain design parameters we should for example be able to understand how changes propagate and influence other parts and properties of a CPS.

A key opportunity and also key challenge for CPS, is their heterogeneity, exploiting multiple technologies and the synergies among the physical and cyber worlds. The CPS approach is “compositional” . Unfortunately this does not align with how science and engineering have progressed. In dealing with an expanding scope of knowledge, progress has instead been characterized by increasing depth and specialization, resulting in many specialty disciplines. As a consequence, there is no single CPS theory available today (this challenge is by the way shared by many contemporary fields today!).

The behavior of a CPS is multifaceted. To understand and design a CPS, we will most likely have to resort to a large number of theories including Newtonian laws of motion, control and dynamic systems, hybrid systems, real-time, programming, digital logic, information theory, cognitive science (when CPS involves humans), etc. In addition, we will be needing theory related to cross-cutting theories and engineering foundations such as those concerned with security, reliability and safety.

The inherent complexity of a CPS, likewise implies that engineering methodologies will involve a number of ways to divide and conquer a complex problem into separate pieces (parts, or steps part of engineering processes), with guidelines for integrating them. The challenge here lies in having foundations to support both the decomposition as well as the composition (the integration).

The properties of a CPS appear as a result of the component, software and physical system properties and their interactions. Since a CPS typically involves tight integration among components and various technologies, intricate relationships will result which impact system level aspects/properties such as functionality, performance, safety, security, availability and interoperability. Changes in some of the component level properties, or the composition of components, is likely to affect multiple system level properties. This leads to tensions and necessitates trade-offs assuming that these interrelations are understood and can be managed). The challenge of CPS engineering also becomes an organizational challenge since it is beyond the capabilities of a single person to develop an advanced CPS (the design of a modern car will involve thousands of engineers).

Systems Engineering (SE) has a goal to deal with complex systems, and as such help to deal with composition and integration. However, SE was developed initially mainly to target large scale physical systems, and there is a realization that it needs to evolve to better embrace the cyber dimensions.

There is thus a great need for addressing the foundations of CPS, in innovating foundations that cut across the multiple facets of CPS. The involved challenges and opportunities for further work include to develop a better understanding of facets of CPS complexity, composability of CPS (principles for achieving desired behaviors, properties and trade-offs), dealing with Cyber-Physical Systems of Systems (including cross-organizational interactions), human-centered design of CPS, and handling AI as a novel ingredient in CPS.

If you would like to comment on this post, please contact platforum@itm.kth.se to request a login to the PlatForum. Thanks.

Having discussed opportunities and capabilities provided by CPS in the previous posting, it is natural to turn to challenges posed by CPS. There is a clear duality between opportunities and challenges, often mirroring different perspectives that relate to the same CPS capability. Take for example connectivity, providing opportunities for gathering operational data, enabling collaboration etc. while at the same time raising new security threats, failure modes and trust issues (can I trust data from another system?).

Trends towards connectivity, new services, automation, smartness, etc. imply that we are embarking towards Cyber-Physical Systems of Systems (CPSoS), for example in terms of intelligent transportation systems composed of collaborating (semi-) autonomous vehicle, infrastructure and various traffic management services. The CPSoS will be formed by dynamically integrating systems developed by multiple providers, acting in highly changing environments.

On a societal scale, infrastructures for e.g. water, energy, transportation, etc. will be relying on the services provided by multiple CPS. Unless such infrastructures are properly developed and maintained, the society will be vulnerable if these services are not available or malfunction. It is thus evident that special care needs to be devoted towards the entire life-cycle of these CPS; we want them to be trustworthy. The development of future CPS raises a host of related challenges including the following:

• Ensuring safety, security and availability at affordable cost. A key issue here is that of managing the complexity of future CPS (I will return to this topic in a forthcoming posting).
• Providing CPS which are understandable and intuitive, working well with humans!
• Setting the requirements for future CPS. Since these systems are likely to change our behaviors, and since they are new, this is not an easy task (compare for instance with autonomous driving where standards and legislation are lagging technological developments). The introduction of future CPS thus interplays with (evolving) regulations, standards and public expectations.
• Designing future CPSoS, in terms of regulations, rules, and coordination protocols that define proper interactions among individual CPS. This will be very difficult because of technical complexity and because multiple organizations are involved in open markets. I will however be very important to pursue this in order to avoid large scale risks, e.g. caused by unforeseen and unintended feature interactions.
• Ensuring robustness and safety of AI technologies that are likely to be increasingly adopted as part of CPS.
• Dealing with sustainability of the CPS themselves, i.e. ensuring that all the electronics dispersed into our societies can be dealt with as part of a circular economy.

The drivers for, and capabilities of CPS, has the implication and downside that future CPS will be of unprecedented complexity. There is strong need for new theory, methods and tools for countering and managing this complexity.
To pursue this, collaborative and multidisciplinary efforts will be important; the CPS challenges go beyond what single disciplines have to offer.

Do Cyber-Physical Systems represent a technical revolution, with an impact similar to that of the changes incurred by the inventions of steam-engines, electrification and mass-production? If so, what are the indications of this and what can we learn from previous industrial revolutions?

With Industrie 4.0, CPS is described as representing a 4th industrial revolution (recall that Industrie 4.0 constitutes a domain specific incarnation of CPS within manufacturing – see my previous posting on this topic). The revolutions preceding CPS are described as (1) mechanical production facilitated by steam and water power; (2) mass-production and electricity, and (3) electronics and IT driving automation. The 4th revolution is then described as an “organizational” one, where existing technologies (e.g. communication, computing, sensors, 3D printing, etc.) have improved to the point that cost-efficient integration is able to provide entirely new services, performance and organizations. This numbering of industrial revolutions can be discussed, but this is not the main point here.

Industrial revolutions are typically associated with technological innovations where old and new technologies compete for a time, but where new technologies eventually provide cost-efficiency and radically better performance,. Industrial revolutions are also associated with new opportunities and new risks (compare exploding steam engines when they were introduced!), and with potentially drastic market changes, where new companies emerge and existing ones that fail to adopt the new technology face the risk of eradication. Examples from previous technical revolutions include for example the replacement of horses and carriages by steam- and combustion engine powered transportation, or the replacement of mechanical calculators by electronic calculators and computers.

In his essay on the steam engine and the computer, Herbert Simon revisits previous industrial revolutions an identifies that

• technological revolutions are slow; the first revolution (involving steam engines) took 150 years to change society – with 6 generations as a tentative time constant;
• there is no single technology - behind of revolution; rather there is a web of technologies, and moreover, technological change has to be accompanied by organizational change;
• revolutionary significance lies in generality, to serve a number of purposes (in ways we would not even think possible); and finally that
• we shape the technological revolutions (for better or for worse) and most of the noticeable societal impact will become tangible during the 2nd half of the time of change.

Considering these insights from H. Simon, and what is happening now, there are many signs that we are indeed going through a technological revolution. Indications in this direction include the following:

1. The ability to integrate and combines technologies from both cyber- and physical sides, provide unprecedented opportunities and capabilities. The current technological landscape provides a “melting pot” with cloud computing, connectivity, automation and AI, new sensing and actuation technologies, and more.
2. Many new players are appearing, for example providing new cloud services related to CPS. There is also a multitude of acquisitions and new coalitions forming – the area of autonomous cars provides ample examples of this.
3. Combining new technological capabilities with the adoption of non-conventional business models provide new opportunities for services and revenues. The provisioning of services instead of products provides one instance of this (so called servitization), for example referring to providing transportation services rather than selling cars.
4. New risks and challenges are becoming emphasized with increasing connectivity and use of AI. An important example is that of cyber-security threats for CPS, and another potential threat is posed by misbehaving AI systems.

Considering the advice of from the past, and that we are part of an ongoing industrial revolution, there is no need for immediate panic, but it will be essential to strategically consider what the implications may be and how your organization should position itself.

The concept of Cyber-Physical Systems (CPS) was introduced 2006 in the US to represent the Integration of computation, networking and physical processes where CPS range from minuscule (pace makers) to large-scale (e.g. national power-grid), [Ref]. Several other definitions have been proposed including the following one by NIST: Cyber-Physical Systems or "smart" systems are co-engineered interacting networks of physical and computational components.

The mainstream interpretation of the term “cyber” refers to the use of computers or computer networks (see e.g. Merriam-Webster), with many related connotations and usages (see e.g. here for a review). The term however originates from Norbert Wiener who coined cybernetics based on the Greek term “kybernetike” which means "governance", essentially referring to broad classes of feedback systems.

As CPS is centered on interactions and integration among cyber- and physical elements, “cyber” as part of CPS therefore relates to the computer interpretation of the term cyber. However, the second interpretation in terms of “feedback" is also relevant for many types of CPS, since any CPS will involve some form of sensing and/or control as means for cyber-physical interactions. As for systems (e.g human vs. nature made), there will be different types of CPS, referring to for example the structuring of the system (level of decentralization/distribution), the scale, the level of criticality (referring to safety and security), the level of automation and whether the CPS directly includes humans, (see e.g. this CyPhERS project deliverable for an elaboration).

When does a system qualify as a CPS? Let us take the following examples:

• A house with a computer inside it
• A house with an electricity meter mounted in the house to measure and report electricity consumption.
• A modern combustion engine with computer control unit bolted onto it.
• An industrial robot performing pick-and-place operations

The first example does not represent any significant interactions nor integration among the computer (cyber part) and the physical elements (the house), although the computer may make use of power from the house (if not run on a battery). The second example instead provides an example of an integrated functionality, representing both physical and informational integration. The third example, illustrates an even tighter interaction where the physical environment will be essential for the design of the cyber part, and where the cyber part is designed explicitly to monitor and control the engine, requiring detailed knowledge of the physical engine. The CPS engine is likely be integrated to form part of a larger system such as a car. The fourth example, the industrial robot (IRB), encompasses a mechanical structure, energy provisioning and a computer control system. Often, an IRB system emphasizes feed-forward but also includes feed-back control. The system clearly represents a co-engineered system, although the level of optimization of both cyber- and physical parts with respect to each-other may vary.

This emphasizes again that there will be different types of CPS with different types of integration and interactions. When these interactions are significant, co-engineering becomes crucial for cost-effective development, production, operation and maintenance.

A further key aspect of CPS is that they embody the potential integration among information technologies and embedded systems/control systems, representing very different traditions and expected properties (from very fast turn-around, open and security aware systems to safety-critical real-time closed systems). This poses particular opportunities as well as integration challenges!

CPS’s do not represent a new phenomenon per se; the novelty lies in the potential scale and capabilities of upcoming CPS, the potential to combine and incorporate new technologies, their widespread use in society, and the resulting impact on our lives and societies. Examples of future CPS can be found essentially in all kinds of domains (from individual devices and machines up to interacting systems of systems: consider autonomous vehicles to coordinated transportation systems), and also across existing domains. The cyber integration enables integration and coordination among previously not integrated systems. Mastering their design therefore becomes extremely important.

As projected by several investigations, (see e.g. CPSoS, Road2CPS, and CyPhERS) the opportunities and challenges with future CPS are enormous, and their full impact and potential have yet to be understood. In future posting on this blog, we will be discussing such impacts and concerns.

The increasing connectivity, software-defined functionalities and penetration of electronics and software into virtually all facets of our lives, results in a society which is becoming dependent on smart devices that are part of and form inter-connected systems. Combining advances in electronics and software together with advances in new materials and technologies such as 3D printing, sensors and augmented/virtual reality, moreover provides unprecedented opportunities for innovation including the adoption of non-traditional business models in industrial domains.

Different perspectives to these developments have led to the creation of many terms to represent the new types of systems that can be formed. Such terms include Cyber-Physical Systems (CPS), the Internet of Things (IoT), Industrie 4.0 (I4.0), the Fog and edge computing, and the Swarm.

How are these terms related? The terms have different origin and emphasis in what they intend to describe. CPS emphasizes the development of smart systems as co-engineered interacting networks of physical and computational components. IoT emphasizes sensing of the physical world and uniquely identifiable things with (Internet) connectivity to communicate data with limited or no human interaction. Communication is often considered the key aspect, often in conjunction with business models. CPS differs through a systems perspective, not necessarily requiring Internet connectivity. The Industrial IoT simply refers to industrial usages of IoT. IIoT comes very close to Industrie 4.0 which thus essentially represents the introduction of CPS and IoT in the manufacturing domain. Terms such as fog and edge computing, used in the context of IoT and CPS, represent the growth of internet and telecom networks to also encompass communication between things and machines. a perspective that emphasizes computing aspects. Finally, the concept of swarms has been used to describe large the deployment of a large number of sensors into the environment and their interconnection to the cloud.

All these terms share the same paradigm of immersive and distributed sensing and computing, and are typically motivated in terms of their potential to contribute to help to solve societal-scale problems. They also observe the same types of trends, although providing slightly different perspectives to them. As evident from this description there is a lot of overlap between the terms. Often they are used as umbrella terms; sometimes they are used in more specific contexts. In practice, many of them are used as synonyms. An even broader concept, often used by decision makers, is that of digitalization.

As a take away from this posting, I recommend that you describe your intended perspective when using any of these terms. Further clarification can be provided by use of a characterization of the types of systems you want to describe (see my previous post on this blog).