Journal of Software Engineering for Autonomous Systems

2.1. Goal Modeling

During requirements engineering goal modeling (cf. [20,21,22]) is used to capture and reason among goals. Goal modeling approaches commonly used in the literature include GRL [11], i* [23,24] and its extension Tropos [25], or KAOS [26]. These approaches not only systematically support the definition, analysis and evaluation of goal models, but often also include facilities to graphically represent goal relationships and formal foundations that allow reasoning about goals (see e.g. [27,28]). Goal modeling approaches often share a formal basis and are closely linked to other approaches. For example, the modeling language GRL (Goal-oriented-Requirements Language) [11] is based on the i* [23,24] modeling framework.

Studies have shown that in direct comparison of goal modeling with textual requirement specifications, compact goal models are better suited to uncovering possible conflicts than text documents (see e.g. [29]). Goal models are also used as the basis for automated reasoning techniques such as [27] or [28]. A more detailed overview over goal-oriented RE is given in [21].

Many extensions of established goal modeling techniques and languages have been proposed for specific purposes and types of systems, e.g. aspect-oriented extension of GRL [30]. Moreover, goal modeling has been successfully applied to drive adaptation strategies, such as in multi-agent systems (e.g. [31,32]), self-adaptive systems ([20,33,34]), systems of systems (e.g. [35,36]) or, like in this work, CPS (e.g. [37]).

2.2. Goal Modeling for Self-Adaptive CPS

Especially in self-adaptive cyber physical systems, goal models are heavily used to drive the adaptation decisions. For example, in [20] goal models are used to describe the current goals of a system and potential goals that characterize the system after adaptations (which are depicted in separate goal models). The Tropos4AS approach [34,38] proposes several extensions that consider states of environmental entities and potential failures to adapt autonomous agents. Others propose formal approaches that involve executable runtime models [39,40] to reason about goal satisfaction during operation. In [41,42] goal models are considered evolvable runtime entities to drive adaptations, considering adaptive goals that may induce changes in the goal models. Similarly, the OMACS approach [43] involves runtime goal modeling specific for multi-robot systems. In [44] goal models are used complementarily with other artifacts to reason about the impacts of different possible adaptation decisions, which is also supported by respective infrastructure at runtime. The FLAGS approach [45] employs fuzzy extensions to goal models to account for different degrees of goal satisfaction in the context of dynamic runtime adaptations. Another related approach that utilizes goal models, Adapt Cases [46], provides a framework for analyzing and documenting desired adaptivity during the development.

All of these approaches exclusively consider system-level goals for system-level adaptation. None of the above approach considers network-level goals in collaborative scenarios, like for CPS. Yet, designing collaborative systems adaptive is necessary to ensure that the CPS network meets system goals and network goals alike.

Modeling and reasoning over collaborative CPS requires considering multiple, distributed MAPE-K feedback control loops [5,47]. Regarding the use of goal models, this means that each CPS uses its own goal model for adaptation. State-of-the-art approaches typically only focus on single self-adaptive systems. For example, the underlying assumption of the OMACS approach [43] is that overall goals can be achieved by individual robots. In contrast, in a collaborative system with emergent properties, the individual goals of different partaking CPS cannot be considered in isolation. Rather, there are cross-dependencies between individual goals and the overall goals to be achieved through collaboration (cf. [35]). Hence, goals of the individual systems and goals of the overall system network should be explicitly distinguished in model-based manner [8] in order to monitor the adaptation of system behavior using, for example, a MAPE-K feedback control loop [47]. Hence, by contrast in [10], we proposed an approach for explicitly modeling these different goals and their relationships through clearly separating the individual systems and the overall CPS network.

In this article, we build upon existing goal modeling approaches and introduce a distinction between goal models of the CPS network and goal models of the individual CPS. This serves as a foundation to guide the systematic adaptation of collaborative CPS. Our approach specifically supports the systematic derivation of adaptation strategies in early phases based on such goal models. State-of-the-art approaches do not systematically support such derivation process in detail either. Rather, the identification of strategies as well as the identification of relationships to underlying goals and other relevant parameters of the adaptation context is often not considered in a structured manner from a requirements engineering (most notably, elicitation) perspective.

3.1. Network Goal, System Goal, and Adaptation Strategy Modeling

Fig. 1 gives an overview of the core concepts that are underlying our approach, as well as their relationships. The approach interrelates the CPS network goal model (containing network-level goals) with the CPS goal models (containing system-level goals) specifying goals of the individual systems, and relevant context parameters to be sensed. Together, this allows the definition of adaptation strategies. We define the following Goal Model Types:

Figure 1

Overview of the concepts underlying our goal-based approach.

• •

  The CPS network goal model defines the goals of the collaborative CPS network. Collaborative CPS interact with other CPS in a network of collaborative CPS. This CPS network is formed to achieve goals the individual systems can only achieve in collaboration, but not on their own. As collaborative networks do not have a management instance monitoring goal fulfillment at runtime, the CPS network goals must be defined during development. The CPS network goal model contains every goal the CPS network shall be able to achieve eventually during its operation, independent from specific CPS network configurations, and specific context situations.

• •

  The CPS goal models define the goals of the individual systems. The individual CPS strive to contribute to CPS network goals. Hence, the goals of the individual CPS are defined to fulfill the CPS network goals, which depend upon the individual CPS. Moreover, the individual CPS have their own goals they try to achieve in addition to contributing to the CPS network goals. In doing so, dependency relations between CPS network goals and individual CPS goals as well as conflicts are documented.

Hence, goal modeling is used to explicitly specify goals of the collaborative CPS network and the goals of the individual CPS. Furthermore, there exist dependency relations (modeled through respective links), as an individual CPS must contribute to the CPS network goals, and, consequently, satisfaction of CPS network goals depend on the satisfaction of certain individual CPS goals.

Naturally, not all goals can be fulfilled all the time. For instance, it is possible to have contradictory goals or goals that are specific for certain context situations. The goal models specify all the possible goals of the CPS network and its constituent CPS, and thus include goals that may not be achieved by a specific CPS network. Rather, the goal models can be seen as the basis to perform adaptations by selecting which goals to achieve as reactions to changing context situations. The goal models of individual CPS may even include goals that have no relation to CPS network goals, as each CPS is seen as an autonomous unit that aims to achieve individual goals as part of an overall system (cf. [48]). Hence, during requirements engineering, it can be challenging to define desired collaborations considering such trade-offs between network and individual goals.

Parameters. In addition to the goal models, our approach considers parameters that have an impact on the specific adaptations to be carried out during runtime. In our approach, the following parameter types are considered, based on the distinction between a CPS network and the individual CPS engaged in this network:

• •

  Context parameters define the current contextual circumstances in which the CPS network operates at a certain point in time. These context parameters define relevant attributes of the physical surroundings, business strategies, or user demands to be fulfilled. For instance, in the platooning example from Section 1, the desired speed or the maximum allowed speed on a specific position on a highway are context parameters in this sense.

• •

  CPS operational parameters capture the execution context an individual CPS faces w.r.t. fulfilling its goals. This includes resources that are used by CPS, such as computing or communication capabilities. Hence, positive or negative impacts of selecting a specific CPS goal for adaptation on such operational parameters have to be systematically captured as well.

Our approach emphasizes the role of context parameters that characterize the environment of the CPS network in order to monitor network-level goal satisfaction at runtime. While individual operational parameters of collaborating CPS may influence the possible adaptations as well, our approach most notably elaborates on how context parameters constrain the adaptation strategies to be defined. Depending on the context parameters it is defined under which conditions a certain strategy shall be chosen. Hence, constraints are defined over the context parameters, e.g. specifying a range of values a context parameter can take, given which strategy is selected. Furthermore, explicitly capturing effects on CPS operational parameters allows investigating the impacts of selecting a certain adaptation strategy.

Adaptation Strategies. Adaptation strategies define the adaptation behavior of CPS in dependence of the behavior of its context. A strategy takes into account context parameters, a set of system-level goals which are achievable by behaving according to the strategy, and a set of network-level goals that the CPS is contributing to, given the strategy. When context parameters or goals change at runtime, a strategy might no longer be sufficient for contributing to the goals, and a new strategy has to be chosen. This reflects in adaptation scenarios describing which CPS and network goals are to be pursued under certain circumstances. The sensed context parameters, the goals of the individual CPS and the goals of the CPS network in relation to the possible evolution of context parameters over time lead to the definition of adaptation strategies.

Strategies are selected based on observations of the environment, i.e., concrete values of the context parameters that characterize the current environment situation. Changes in the context may require adaptations to be performed in order to maintain operation of the overall CPS network, i.e., to achieve its goals. However, depending on the specific context situation, some goals may not be achievable. Such situations are specified using adaptation scenarios that describe how the CPS network needs to behave in terms of switching between different goal alternatives, as reactions to changes in context parameters. For instance, a corresponding strategy may focus merely on some minimal set of goals (e.g. defining degradation modes to avoid safety hazards) that can be achieved while other important goals may be ignored. Goal modeling decreases the number of strategies that have to be generated for a CPS at design time by identifying sets of goals that are not achievable in specific context situations (e.g. due to conflicts between goals).

3.2. Goal-Based Adaptation Planning

To support the systematic definition of adaptation strategies as introduced above, we identified a set of essential steps that should be followed when eliciting such strategies early in development. Fig. 2 shows a UML Activity Diagram that outlines the process for deriving adaptation strategies based on goal models.

Figure 2

Process for goal-based definition of adaptation strategies.

Step 1. Initial versions of the CPS and the CPS network goal model are created. These do not necessarily have to be consolidated, i.e., there might be inconsistencies w.r.t. the possible adaptations of individual CPS that take the overall network goals into account. This might be especially the case when the goal models are created concurrently, e.g. by different development teams. This is a predominantly manual engineering process facilitated during typical system development.

Output: The outcome of this step is a set of goal models that allow defining the relevant functions and entities that will participate in the collaboration.

Step 2. Based on the goals models of the previous step, the contextual and CPS operational parameters are defined to systematically enhance and amend these models for the purpose of enabling the individual CPS to orchestrate and adapt according to strategies that ful-fill the CPS network goals. As described in Section 3.1, these parameters can be captured in a textual representation. Furthermore, possible impacts of individual CPS goals on the operational parameters are defined as well. We argue that our goal-based approach also helps identifying the relevant parameters to be considered for potential adaptations.

Output: The outcome of this step is a set of consolidated goal models aligning adaptation goals of individual systems with desired adaptation goals on network-level.

Step 3. Using these parameters and narrowed-down entities involved in an adaptation, dependencies between CPS network goals and individual CPS goals are identified next. Here the focus is on defining which overall CPS network goal can be achieved by which individual CPS goal(s). Goal dependencies can be modeled graphically using GRL [11], as explained in Section 3.1.

Output: The outcome of this step is a GRL specification relating concrete goals of individual CPS with adaptation goals of the CPS network. This lays the foundation for selecting the ideal network adaptation.

Step 4. Based on the information elicited so far, requirements engineers can then systematically explore adaptation scenarios. In these adaptation scenarios, possible connections and interrelations between the parameters and the goals that can be selected or deselected for adapting the system, as well as associated impacts on CPS performance are illustrated. Adaptation scenarios specify concrete examples how context parameter values may evolve over time. They consist of a sequence of time steps, each illustrating CPS network context parameter values and CPS operational parameter values, as well as the CPS goals that are selected to be “active” in order to achieve certain network goals (at each specific scenario step) in order to react upon context changes.

Output: The outcome of this step is a set of concrete adaptation scenarios showing the execution of adaptations at runtime.

Step 5. Technical solution examples specified in the scenarios in the previous step allows revisions of the initially devised CPS goal model from a more concrete, technical perspectives. Alternatives can be added, inconsistencies resolved, and goals can be relaxed in order to enable adaptations (cf. [49,50]) and make it technically feasible. Following this approach, individual CPS goals and CPS network goals are systematically aligned so that the identified strategies consider not only the individual CPS goals, but also the satisfaction of the overall CPS network goals.

Output: The outcome of this step are systematic revisions, additions, and deletions to the previously identified adaptation scenarios. This allows identifying missing adaptation goals for individual CPS or the entire network, discard superfluous goals, and identify missing scenarios to ensure successful adaptation at runtime.

Step 6. The aligned goal models and the adaptation scenarios then constitute the basis for defining strategies in the form of subsets of all the goals specified in the CPS network goal model. A strategy is then selected based on the identified relationships to relevant context parameters, i.e., when certain context parameter constraints are met.

Output: The outcome of this step is the specific strategies in which a CPS network-wide adaptation shall occur at runtime and which roles individual CPS will play.

Our approach has been originally devised for application in early requirements phases of collaborative CPS development processes, where adaptation needs to be planned in order to enable capabilities to engage and collaborate in a system network, and satisfaction of overall CPS network goals. Nevertheless, the approach in principle also helps when monitoring an existing CPS network, which may be open and consist of several individual systems whose contribution to the overall network can only be assessed on the level of potential goals they strive for.

4.1. Case Example: Autonomous Transport Robots

Autonomous transport robots can form so-called fleets in order to process transport tasks together as a collective. Such robot fleets, consisting of individual transport robots, are used in production logistics to ensure prompt delivery and collection of material to and from various locations in production processes and are seen as enabler for smart factories [51]. Developing and operating autonomous transport robots poses many challenges, including a highly dynamic operating environment and the demand for reacting flexibly to changes in business constraints and new goals to be fulfilled [52].

There is a trend towards organizing transport robot fleets in a decentralized, collaborative manner, in order to allow for more flexibility and achieve better scalability through adding or removing individual robots (cf. [53]). In such a setting, agent-oriented techniques such as auctions, where the individual robots place bids for taking over a transport task, are typically employed to coordinate the fleet [54]. The individual robots taking part in a fleet may differ from each other in features such as load capacities, for example. While a noncollaborative robot typically optimizes its own route for goods transportation, the fleet allows the robots to optimize their routes taking into account the routes of other robots in order to avoid collisions. In addition, the fleet optimizes the transport of goods because in a collaborative network the task assignment to individual robots is handled flexibly through collaboration.

4.2. Goal Models of the Autonomous Transport Robots

Fig. 3 shows a goal model for the autonomous transport robots. The model represents two actors, the Robot Fleet and a Transport Robot belonging to the fleet. While the overall goal of the fleet is the fulfillment of all transport tasks, which can be divided into several subgoals, the overall goal of the robot is “task transport” in general. The goal of the individual robot is also divided into many sub goals, such as “maintain battery utilization”.

Figure 3

Goal model of individual transport robot (CPS) and the robot fleet (CPS network).

While the sub goals of “transport task request” have to be fulfilled in order to fulfill the super goal as well, the goal “maintain battery utilization” is fulfilled when only one of its illustrated sub goals is achieved. Similarly, the goal “reduction of maintenance costs” of the overall robot fleet has two alternative realizations, defining the different ranges of the distance to be covered by each of the constituent robots. The maximum difference of the covered distance among the individual robots can be either 500 m or 800 m, depending on the strategies defined by the plant manager, as will be explained below.

4.3. Definition of Adaptation Strategies

Based on the goal models introduced above, two exemplary strategies have been defined. There is one strategy incorporating goals to be achieved in normal operation (i.e., in standard mode), and one for peak mode, where the number of transport tasks to be fulfilled is significantly increased. Table 1 compares these two strategies, and lists an excerpt of the goals selected in each strategy.

As introduced in Section 3, context parameters are identified in addition to goal models. One context parameter is the number of transport tasks that are issued due to production demands. The standard mode assumes that neither urgent tasks nor too many tasks have to be carried out by the robots at once. Therefore, the goal “reduction of maintenance costs” of the robot fleet can be achieved, if the total covered distance differs between the robots by a maximum of 500 m, while being able to fulfill the normal transportation demands. Furthermore, the goal “keep battery level in range 40–60%” of the CPS is selected to allow for optimal battery usage to increase the lifespan of the battery. Thus, battery level and lifespan are two relevant CPS operational parameters that are considered in this case example.

The strategy defined for the peak mode includes a different subset of goals. The goal “reduction of maintenance costs” of the overall system network is in conflict with serving a high amount of incoming transport tasks. Hence, there needs to be another alternative sub goal that, when selected, reduces the distance in order to adapt to the high load. For this strategy it is more important to fulfill all tasks than to reduce maintenance costs of the robots. The goal of the system network is then achieved when the total distance covered by individual robots differs from the distances covered by other robots by a maximum of 800 m. Similarly, as each individual robot has to accomplish more transportation tasks, another desired average battery level is selected for the peak mode strategy. The goal to serve transportation task peaks of the overall robot fleet can thus only be reached when the desired battery level is in between the broadened range of 30% to 80%.

4.4. Adaptation Scenarios

The fleet has the goal of fulfilling all transport tasks requested by the machines of the production plant without violating the due dates of the tasks. One possible adaptation scenario for illustrating the actual application of the defined adaptation strategies (based on the goals and parameters that have been identified in the first place) considers switching from standard mode to peak mode. This means that initially all robots of the fleet shall cover similar distances (e.g. at each point in time the difference between the minimum and maximum of the distances the individual robots covered on the same day is smaller than 500 m), so they have equal wear and tear and the mechanics can maintain all robots at the same time instead of having to visit the plant several times. According to the current strategy, each robot has the goal of holding its battery level in the range of 40% and 60%, so that the lifespan of the battery is high. Equipped with those two goals on the fleet level and one individual goal for each robot, each robot chooses a strategy that allows fulfilling the goals. Those strategies determine which robot is taking over which transport task at runtime. We assume that each robot has a task queue and is able to estimate the time, the covered distance and its battery level which it will have after fulfilling the last task of its queue. For example, each transport robot can choose the strategy of taking over a transport task if and only if all of the following conditions hold according to estimations of the robot:

• •

  By adding the transport task to the end of its transport queue, it can fulfill the transport task in time.

• •

  Directly after having fulfilled the task, the battery level of the robot is between 40% and 60%.

• •

  According to the actual distribution of transport task over the fleet, all other robots will cover a longer distance to fulfill the task, i.e. the difference between the covered distance of the robot and the robot with the least covered distance after having fulfilled the task is minimal among all robots.

This strategy for standard mode might be suitable as long as the goals of the fleet or of at least one robot is not changing and the number of transport tasks is so low, that the goals can be fulfilled. In reality, a fleet of transportation robots is regularly facing short time periods in which the amount of transport tasks is significantly higher than in the rest of the time, e.g. the number of transport tasks peaks each morning when all machines are turned on and require material at the same time. This becomes visible in relevant context parameters, in this case an increase in the number of transport tasks, which is evaluated based on defined constraints. For enabling the fleet to adapt to such situations, the plant manager may decide to adapt the strategy to peak mode, i.e., to weaken some of the goals to be fulfilled by the fleet and the individual robots before such peaks occur by increasing the permissible battery level to 30–80% and the difference in the covered distance to 800 m. This is done by activating the respective goals according to the new strategy selected, and could also be automated based on the defined context parameter constraints. By relaxing the fleet’s goals, the robots can choose better strategies according to their individual goals, e.g. by charging all batteries up to 80% before the peak in the amount of transport tasks occurs, when the respective goal related to battery utilization has been switched (cf. Fig. 3). Hence, the adaptation of behavior to new goals increases the effectiveness of the robot fleet.

Another trigger for adaptation of the behavior is an update of the context model of the CPS network or of at least of one CPS. Such an update can be made manually (e.g. a new machine or charging station is installed in the plant, so that the internal map of the robots has to be updated) or by learning processes. For example, the fleet of robots can learn that a certain machine is requesting a specific transport good from the stock every 10 minutes. By adding this information to the context models of the robots, a change of the strategy can increase the performance of the fleet. For example, if the machine will request for the transport good within the next minute, a robot which is idling near the stock should not leave its position to take transport task at the other side of the plant, but should wait for the transport task to come and leave other transport tasks to the other robots.

5.1. Observations From Application With Industry Representatives

We proposed the specification of the individual CPS goals and the CPS network goals in GRL goal models, and explicitly documenting contribution links between these goal models. The majority of practitioners found the explicit specification of goal models useful and intuitive as it reflects their thinking about the system, which, due to the collaborative nature, mostly happens in terms of system goals. The explicit distinction between system goals and network goals extends the typical real of investigation and was well appreciated. Industry partners stressed the value of these strategies to reason about adaptation needs and problems arising in certain situations at early stages as well as for driving the further development process. Although not executed in all stages yet, industry partners have developed a prototype transport robot fleet using this goal-based approach for strategy definition. The defined strategies have further been used to instantiate monitoring and adaptation mechanism due to changed context values. So far, it has been confirmed that this approach aids in keeping track of the goals to be fulfilled for different configurations and situations.

5.2. Limitations

There remain several limitations and threats to validity. First of all, as is always the case for case study research, it cannot be ensured that the approach is applicable to other case examples as well. This is particularly the case, as the approach itself has been developed in close collaboration with industry partners, always having the transport robot case example in mind, which is comparable to design science research principles [56,57]. However, this increases the risk of having developed a specific solution approach only applicable to this case or to a limited number of comparable cases.

Discussions with other industry partners from the same domain, working on similar systems, confirmed the applicability of the approach for the development of industrial transport robots. However, discussions with practitioners from other domains or developing very different types of systems showed slightly different results. For instance, in case of a production system that relies on conveyor belts for transportation but places emphasis on the overall production process, practitioners preferred a scenario-based approach, rather than reasoning about goals first. The approach has also been considered partly helpful by partners of the automotive domain. While the idea of using goals and explicitly specifying the interplay between the goals of the individual system and the network were very well received, automotive engineers expressed the desire for additional scenario representations, as this more closely related to the feature-centric development of automotive systems. We assume that the explicit expression of the adaptation scenarios with common model-based scenario languages can foster the application of the approach in these areas.

5.3. Inferences

Based on our findings we are confident that the approach is applicable and useful for the development of the transport robot case. We have also found evidence of the usefulness for the development of collaborative CPS from other domains. However, for now, we assume, that some kind of “goal thinking” must already have been established to make the utmost benefit of the approach. For other cases we aim at combining the strategy definition and the visualization of strategies with common approaches for scenario modeling and linking these to the goals. So far, we assume that this helps the transfer of the approach to the development of other system types.