Defining adaptivity and logical architecture for engineering (smart) self-adaptive cyber–physical systems

https://doi.org/10.1016/j.infsof.2022.106866Get rights and content

Highlights

  • The community lacks a precise definition of adaptivity and self-adaptive systems.

  • This paper formally defines the notion of system adaptivity.

  • Logical architecture for engineering autonomous and decentralised self-adaptive CPSs.

Abstract

Context:

Modern cyber–physical systems (CPSs) are embedded in the physical world and intrinsically operate in a continuously changing and uncertain environment or operational context. To meet their business goals and preserve or even improve specific adaptation goals, besides the variety of run-time uncertainties and changes to which the CPSs are exposed—the systems need to self-adapt.

Objective:

The current literature in this domain still lacks a precise definition of what self-adaptive systems are and how they differ from those considered non-adaptive. Therefore, in order to answer how to engineer self-adaptive CPSs or self-adaptive systems in general, we first need to answer what is adaptivity, correspondingly self-adaptive systems.

Method:

In this paper, we first formally define the notion of adaptivity. Second, within the frame of the formal definitions, we propose a logical architecture for engineering decentralised self-adaptive CPSs that operate in dynamic, uncertain, and partially observable operational contexts. This logical architecture provides a structure and serves as a foundation for the implementation of a class of self-adaptive CPSs.

Results:

First, our results show that in order to answer if a system is adaptive, the right framing is necessary: the system’s adaptation goals, its context, and the time period in which the system is adaptive. Second, we discuss the benefits of our architecture by comparing it with the MAPE-K conceptual model.

Conclusion:

Commonly accepted definitions of adaptivity and self-adaptive systems are necessary for work in this domain to be compared and discussed since the same terms are often used with different semantics. Furthermore, in modern self-adaptive CPSs, which operate in dynamic and uncertain contexts, it is insufficient if the adaptation logic is specified during the system’s design, but instead, the adaptation logic itself needs to adapt and “learn” during run-time.

Introduction

In recent years, the widespread availability of cost-effective embedded systems with increasing computation power and the expansion of wireless networks has led to the rise of Cyber–Physical Systems (CPSs) in many different domains. CPSs are software-intensive systems that are embedded in the physical world. They monitor, control, and coordinate processes in both the physical and the digital world. These modern CPSs are often mobile, decentralised, and operate autonomously, e.g., robots, drones and self-driving cars. Additionally, multiple CPSs can communicate and work collaboratively towards achieving one or several common objectives, for instance, by forming fleets of robots or drones, or platoons of automated self-driving cars. Multiple collaborating CPSs can provide shared and more complex functionalities that a single system in isolation cannot attain. As a consequence of their interaction and deployment into the physical world, CPSs operate in a dynamic and uncertain environment, or execution context [1], [2], [3], [4]. The context and the CPSs themselves are continuously changing in unanticipated ways that could not be known during the systems’ design. Despite the changes and uncertainties at run-time, business continuity of modern CPSs requires the systems to resume operating efficiently and reliably within inherently dynamic conditions. Ramirez et al. [5] classify the sources of run-time uncertainties in adaptive systems in two groups: (1) internal uncertainties that originate from the self-adaptive system itself, i.e., sensor failure, sensor imprecision, sensor noise and effectors, and (2) external, e.g., unpredictable environment. Additionally, due to the sensing limitations of the hardware (i.e., the limited sensor range) of the CPSs, they observe the environment or the context in which they operate only partially. Concretely, the CPSs cannot observe the complete state of their context during their operation, introducing another dimension of run-time uncertainty. A common approach to deal with run-time changes and uncertainties that could not be fully anticipated during the design of the CPSs—while preserving the systems’ performance or certain quality objectives—is to make the CPSs self-adaptive.

In architecture-based self-adaptation [4], [6], [7], [8], a common approach to introduce the necessary self-adaptation capabilities is to extend the CPS, which is the managed element as part of a self-adaptive system, with an adaptation logic (see Fig. 1). Traditionally, the adaptation logic is based on the MAPE—a closed feedback loop [6]. In previous works, the adaptation logic has also been referred to as managing system [3], or as autonomic manager [6]. The MAPE-K loop is comprised of four consecutive functions or phases: Monitor, Analysis, Plan, and Execute, with Knowledge that is shared across all four stages of the loop.

Problem: Despite the notable advancements on many fronts, engineering (self-)adaptive systems remains more challenging than traditional systems [9], especially when the concepts of self-adaptivity are aligned with new emerging technologies found in CPSs. The difficulty in defining self-adaptive systems primarily originates from the lack of understanding (1) what is a system’s adaptivity, and (2) how self-adaptive systems differ from ordinary systems that are considered non-adaptive.

As part of this paper, we explore the following hypothesis:

Due to the scarcity of precise definitions of adaptivity and the lack of a precise characterisation of self-adaptive systems, there is a deficiency of architectures and design patterns that can serve as a blueprint for engineering these systems. Establishing definitions and understanding what self-adaptive systems are, is the first step towards specifying, modelling and designing these systems. However, definitions still remain mainly descriptive, as definitions do not provide constructive insights into how self-adaptive systems are designed and built. Therefore, the identified problem is two-fold: (1) there is a gap between the MAPE-K (see Fig. 1) conceptualisation and potential technical implementations of a self-adaptive system. Concretely, the conceptual MAPE-K model has a very high level of abstraction and is not particularly helpful in designing and implementing the actual system; and (2) the conceptual MAPE-K model does not provide concrete insights on how self-adaptive systems (engineered according to MAPE-K) differ from “ordinary” systems that are non-adaptive. As a result, a need emerges for architectural solutions on how to build self-adaptive systems at some intermediate level of abstraction—beyond the conceptual MAPE-K model—especially when SACPSs that operate in changing, uncertain and partially observable contexts are in focus.

Gap: Existing works do not provide concrete architectures for engineering self-adaptive systems, particularly decentralised and autonomous self-adaptive CPS (SACPS) that operate in changing and uncertain contexts that are only partially observable by the CPSs. Until now, in the literature, there are several proposed design patterns for self-adaptive systems [10], [11]; however, these works mainly focus on different combinations in the decentralisation of the four phases of the MAPE, and they exclude the knowledge component. Although different MAPE-based patterns are more informative regarding the system’s design, inherently they have the same limitations as the MAPE-K closed feedback loop itself: their high level of abstraction and low level of details, which does not provide any characterisation of how a system built upon the MAPE loop differentiates from the ordinary, non-adaptive systems.

Solution: As part of this work, first we formally define context and adaptivity and show how quality plays a central role in understanding and defining self-adaptive systems. Second, we embed the formal concepts of adaptivity into a logical architecture for engineering SACPSs that narrows the gap between the formal foundations and potential technical implementations of a class of use cases. Concretely, the proposed logical architecture can serve as guidance or a blueprint for engineering autonomous and decentralised SACPSs. In our logical architecture, not only the managed elements (i.e., the CPSs) but the adaptation logic adapts as well. In other words, the adaptation logic “learns” and changes itself during run-time to accommodate run-time changes and uncertainties that could not be anticipated during the design of the self-adaptive system. The proposed formal definitions of adaptivity can be considered as orthogonal to architectures at different levels of abstraction: (1) the MAPE-K conceptual model at the highest level of abstraction and the lowest level of details, (2) the proposed logical architecture at an intermediate level of abstraction and intermediate level of details, and (3) a potential technical architecture of an implementation—instantiated from our logical architecture—at the lowest level of abstraction and highest level of details.

Structure: The remainder of the paper is structured as follows: in Section 2, we present the use case, followed by related work in Section 3. In Section 4, we define adaptivity before giving a high-level overview of the logical architecture in Section 5. In Section 6, we explain in more detail the design-time components, and in Section 7, we explain the run-time components of the architecture. In Section 8, we evaluate the proposed formal notions of adaptivity on an implementation from the robotics domain and discuss the benefit of our logical architecture by comparing it to prior works. In our discussion in Section 9, we discuss the threats to validity, the implications from the technical implementation of systems according to our logical architecture and future research directions. Section 10 concludes the paper.

Section snippets

Class of use cases from the CPSs domain and general setting

The logical architecture proposed in this paper can be used as a blueprint for the development of the technical architecture, i.e., the implementation for the class of CPSs explained in this section. Concretely, we consider every use case in which one or more mobile and decentralised CPSs autonomously traverse an environment to discover and collaboratively attain tasks that are continuously appearing. What we aim at adapting in this class of use cases is how the CPSs traverse the dynamically

Related work

In this section, we examine the most relevant approaches with respect to our proposed logical architecture.

Models. More than twenty years ago, Kephart and Chess, in their famous IBM manifesto on autonomic computing [6] have proposed the MAPE-K conceptual model. As explained previously in Section 1, most of the architecture-based self-adaptation systems are built upon the MAPE-K loop, or at least on different variations of the five phases of the MAPE-K. However, the MAPE-K is a conceptual model

Defining context and the notion of partiality and uncertainty

Over the years, with the shifting focus on modern, dynamic systems, including CPSs, the importance of the notion of operating context, or simply context has emerged—in particular when understanding and engineering self-adaptive systems is in the focus [3], [4], [22]. According to traditional software engineering [23], every system operates in an environment, also referred to as universe (U). The context () is the part of the environment that consists of all the objects relevant to the system.

Overview of the logical architecture

This section introduces our logical architecture for engineering self-adaptive CPSs that operate in dynamic, uncertain, and partially observable context. In comparison with conceptual architectures or models (e.g., MAPE-K), logical architectures should provide a higher level of detail without restriction to any particular technology or implementation. A logical architecture [28], [29] defines: (i) functional components in which different elements from a physical architecture are grouped by

Logical architecture: Design time components

In our logical architecture, the Goals and the Quality Function are design time components, which are use case-specific and guide the development of the other components in the self-adaptive system, i.e., the Managed Elements and the Adaptation Logic. Considering the Goals, the designer of the self-adaptive system needs to define the following: (1) the Quality Function Q (previously introduced in Section 4.2) as a measure of how good the system performance is with respect to the business and

Managed Elements

The Managed Elements (i.e., the CPSs) are responsible for any direct interaction between the self-adaptive system and its context—the details of that interaction are encapsulated within their implementation. The Adaptation Logic makes no assumption about that implementation; therefore, it is independent of the actual type of the Managed Elements and only expects it to conform to the following interface:

Input from the Adaptation Logic. The adaptation logic sends to the Managed Elements adapted

Evaluation

To evaluate the applicability and the usability of the logical architecture, we have designed and implemented: (i) a ROS-based, simulated, multi-agent SACPS motivated by the running example from Section 2.3, and (ii) a so-called evaluation framework that can evaluate the adaptivity of the simulated SACPS within our defined use case.2

Threats to validity to the Quality Function Q

First, for calculating the Quality Function Q, we assumed that the context and the system Σ are available. However, due to the partiality in the observations of the CPSs, the systems do not have access to the complete state of the context. Therefore, to quantify the quality of the self-adaptive system, there are two possible alternatives: (1) some form of external validation—which is not a subject to the same limitations of partiality—that provides the actual total state of the context. In

Conclusion

The lack of commonly accepted definitions of different terminology of adaptivity makes it difficult for the works in this domain to be engineered, discussed and compared. We addressed this problem by formally defining system’s adaptivity, and characterising self-adaptive systems more precisely, by differentiating when a system functions and when does it adapt. However, the formal definitions are mostly declarative and descriptive and do not provide constructive insights on how to engineer

CRediT authorship contribution statement

Ana Petrovska: Conceptualization, Methodology, Software, Validation, Resources, Visualization, Formal analysis, Writing – original draft. Stefan Kugele: Conceptualization, Methodology, Formal analysis, Supervision, Writing – review & editing. Thomas Hutzelmann: Conceptualization, Methodology, Formal analysis, Writing – review & editing. Theo Beffart: Conceptualization, Methodology. Sebastian Bergemann: Software, Validation. Alexander Pretschner: Conceptualization, Methodology, Supervision,

Declaration of Competing Interest

The authors declare that they have no known competing financial interests or personal relationships that could have appeared to influence the work reported in this paper.

References (34)

  • WeynsD. et al.

    Forms: Unifying reference model for formal specification of distributed self-adaptive systems

    ACM Trans. Auton. Adapt. Syst. (TAAS)

    (2012)
  • WeynsD. et al.

    On patterns for decentralized control in self-adaptive systems

  • QuinF. et al.

    Decentralized self-adaptive systems: A mapping study

    (2021)
  • J. Zhang, B.H. Cheng, Model-based development of dynamically adaptive software, in: Proceedings of the 28th...
  • MusilA. et al.

    Patterns for self-adaptation in cyber-physical systems

  • AffonsoF.J. et al.

    A reference architecture based on reflection for self-adaptive software

  • V. Braberman, N. D’Ippolito, J. Kramer, D. Sykes, S. Uchitel, Morph: A reference architecture for configuration and...
  • View full text