In this paper a framework for engineering supervisory controllers for product lines with dynamic feature configuration is proposed. The variability in valid configurations is described by a feature model. Behavior of system components is achieved using (extended) finite automata and both behavioral and dynamic configuration constraints are expressed by means of requirements as is common in supervisory control theory. Supervisory controller synthesis is applied to compute a behavioral model in which the requirements are adhered to. For the challenges that arise in this setting, multiple solutions are discussed. The solutions are exemplified in the CIF toolset using a model of a coffee machine. A use case of the much larger Body Comfort System product line is performed to showcase feasibility for industrial-sized systems.
1 Introduction
In present day development of systems and products, reuse of both software andhardware components is sought to reduce development and production costs, and shorten time-to-market. The goal of Software/System Product Line Engineering (SPLE) is to facilitate reuse throughout all phases of systems engineering [24]. Adoption of this paradigm requires identification of the core assets of the products in the domain in order to exploit their commonality and manage their variability, often defined in terms of features. A feature is defined as a logical unit of behavior specified by a set of functional and non-functional requirements [7] or a distinguishable characteristic of a concept (system, component, etc.) that is relevant to some stakeholder [11]. Feature models may be used to define which combinations of features are considered valid product configurations [5].
In literature there has been much attention for correct configuration of SPLs [5]. Behavioral correctness is studied only recently, since [10]. Typically the approaches that are used for guaranteeing a proper functioning SPL (i.e., correct with respect to its requirements or specifications) are verification technologies such as theorem provers [9], model checkers [2], and correct-by-construction approaches such as supervisory controller synthesis [35]. In [35], for the first time, supervisory controller synthesis [25, 26] has been considered for constructing supervisory controllers for an SPL described by a feature model.
Supervisory control theory, as introduced by [26], is a model-based approach to control discrete event systems. In this framework a model is created of the uncontrolled system, and behavioral requirements are specified that define what behavior is allowed. Using these models, a supervisory controller can be computed algorithmically (synthesized), such that it restricts the behavior of the system to always be in accordance with the requirements. Depending on the synthesis algorithm, the behavior of the system under control is guaranteed to have some useful properties, such as safety, nonblockingness, controllability, and maximal permissiveness. The benefits of supervisory control theory have been demonstrated in industrial use cases, such as for example supervisory control of lithography machines [42], health-care systems [36], automotive applications [17], and infrastructural systems [27]. Typically, the models that are input to supervisory controller synthesis are discrete-event system models such as (extended) finite automata [8, 33].
The contribution of this work is a model-based framework for the supervisory control of product lines. This approach consists of the following steps:
(1)
Representing the feature model in extended finite automata. This is a prerequisite, because we apply supervisory controller synthesis that is based on automata specifications.
(2)
Capturing dynamic configuration of features in the models. In this work, we pay additional attention to the situation where features might enter or leave the system during runtime.
(3)
Modeling uncontrolled system behavior such that it properly takes the current configuration into account. A component-wise specification of the system behavior is given, where the component behavior is linked to the presence of features in the configuration.
(4)
Modeling behavioral requirements depending on presence of features. The requirements of the behavior are dependent on the current configuration. Additionally, different requirements may apply when the system is in a transitional phase in between valid configurations.
(5)
Applying supervisory controller synthesis. A correct-by-construction supervisory controller is obtained from the developed models.
For most of these steps, there are multiple solutions and it depends on the case at hand which one is most appropriate. We mention the alternatives and illustrate them. To exemplify the method discussed in this paper, we use the coffee machine system from [34] as a running example. Modeling of automata and supervisory controller synthesis is performed using the tool CIF [40]. Scalability and applicability of the approach is later demonstrated using the Body Comfort System (BCS) from [20].
1.1 Related Work
This work is based on, and can be seen as an extension to, [35] and [28]. The basis of the approach we present here was first introduced in [35], where feature models are modeled in CIF, behavioral models of the system components are defined, and a supervisory controller is obtained that takes into account the possible configurations as defined by the feature model. In [28], this work was extended by also considering the setting of dynamic configuration, where components are allowed to enter and leave the system. Relative to [28, 35], the extension we present here includes more modeling possibilities, considerations, explanations, and examples. Additionally, this work also provides a case study of the large BCS use case, showcasing applicability for industrial-sized product line systems.
Below we mention some more related work, which we divide into the following categories: (1) works that study dynamic reconfiguration during run-time, but do not apply supervisory control theory, (2) works that apply supervisory control theory for multiple configurations during design-time, and (3) works that apply supervisory control for dynamic reconfiguration during run-time. Our work fits the latest category. However, our work differentiates from the mentioned works, as in none of them dynamic feature configuration in relation to supervisory control engineering with a clear separation of uncontrolled system behavior and specification of behavioral and dynamic reconfiguration requirements is discussed.
1.1.1 Dynamic Configuration During Run-time.
In [16] an approach for dynamic software reconfiguration in sensor networks is presented. The dynamic reconfiguration is based on formal constraints in terms of quality-of-service parameters that are measured at runtime.
Dynamic runtime variability of software product lines in embedded automotive software systems is applied to create adaptable and reconfigurable software architectures in [32]. Also [29] discusses reconfiguration with the purpose of determining an optimal configuration at runtime. In both papers the dynamic configuration is under control, which is typically not the case in the present paper.
In [31], a feature-oriented method is proposed to support runtime variability reconfiguration by introducing an intermediate level between feature variations and implementations.
In [13], the authors deal with reconfiguration of real-time embedded systems to cope with hardware/software faults.
The authors of [30] argue that it is not reasonable to anticipate all relevant context changes during design-time and therefore propose a model that combines learning of adaptation rules with evolution of the configuration space, which can be applied during run-time.
1.1.2 Supervisory Control and Design-time System Configuration.
In [38] the assumption is made of no a-priori knowledge of the possible system configurations. Computation of a supervisory controller for an updated system, given knowledge over the base system, is studied.
In [3], priced featured automata were translated to extended finite automata and the structure of the SPL was used to greatly reduce the number of supervisory controller syntheses required to solve game-based energy problems.
In [15], feature models are used to generate product instances for the model-based engineering tool LSAT. LSAT is a tool used to design supervisory controllers, but it cannot perform supervisory controller synthesis [41].
In [43], a method to obtain supervisory controllers for a product family is discussed through the use of a configurator, where synthesis is applied after selection of parameterized components.
1.1.3 Supervisory Control and Dynamic Configuration During Run-time.
[4] apply supervisor synthesis to featured modal contract automata. They synthesize orchestrations that match service requests to service offers, for all valid products in a product line, by joining the orchestrations of a small subset of the valid products. By means of a composition operation, the product line can dynamically be updated and new services can join composite services.
1.2 Structure
In Section 2 we introduce feature models and the CIF language. Using the CIF language, we show how feature models can be represented in automata format in Section 3. In Section 4, the use of automata to represent dynamically configured feature models is discussed. Modeling of component behavior in the setting of dynamic configuration is discussed in Section 5. In Section 6, the modeling of behavioral requirements that are dependent on the current configuration is discussed. Supervisory controller synthesis is applied in Section 7. An industrial-sized use case is discussed in Section 8. Section 9 concludes the paper.
2 Preliminaries
2.1 Feature Models
A feature model [14] is a graph with a collection of nodes representing features, and a number of relations between these features, called feature constraints. The feature constraints that can be expressed are summarized in Table 1, which is taken from [35]. The right column provides logical formulas that express how presence of the features (denoted by the \(F_i\)) is restricted by the different types of constraints.
Table 1.
Table 1. Different Feature Constraints of a Feature Model [35]
For any valid configuration a root feature needs to be present. Mandatory features are required to be present when their parents are, and optional features may be present when their parents are. For a set of alternative features, exactly one is present when their parent is present. And for a set of or features, at least one is present when their parent is present. It can also be defined that the presence of a certain feature requires or excludes another feature to be present.
In an extended feature model [6], attributes can be assigned to features. An example of such an attribute could be the weight or price of a feature. Attributes are typically defined by a name, domain (such as integers, enumerations, etc.), and a value. Attribute constraints can be expressed using attributes of features. A constraint could be a maximal value for the total weight or price of the system. We may use the term feature model to refer to both ‘normal’ and extended feature models when the type of feature model is not relevant or clear from the context.
Consider a product line for a coffee machine [34]. An extended feature model that captures the allowed configurations for this product line is presented in Figure 1. In the solid boxes, the features’ names are shown with an abbreviation. We observe that the coffee machine always contains a sweet, coin, and beverage feature. Optionally, the machine may also be able to sound a ringtone or return change. The machine accepts euro or alternatively dollar coins. The machine always offers coffee as a beverage, but may optionally also offer cappuccino or tea. If the machine offers cappuccino, it cannot accept dollar coins. When the machine offers cappuccino, it is required the machine comes equipped with the ringtone feature.
Figure 1 also shows dashed boxes, in which the feature attributes are shown with a name, domain, and value. Some features have no attribute, and some features have a cost attribute. The cost is valued by an integer, and the cost values are between 3 and 10. The total machine cost is the sum of costs of all features that have a cost attribute. Using the attributes, one can formulate an attribute constraint, e.g., the total machine cost must be less than or equal to 30.
The feature model represents 20 valid configurations. If we include the previously mentioned cost constraint, there are 16 valid configurations.
2.2 CIF
There are two tool suites that support supervisory controller synthesis for models expressed as extended finite automata: Supremica [1] and CIF [40]. In [35], it has been shown how the CIF language and tool set can be used for synthesizing a supervisory controller that is suited for an SPL. The approach uses the concept of algebraic variables extensively, which is not available in Supremica.
CIF, part of the Eclipse Supervisory Control Engineering Toolkit (Eclipse ESCET™),1 is a language and tool set that supports model-based engineering of supervisory controllers involving modeling, (visualized) simulation, synthesis, verification, and code generation [40]. In the past years CIF has been applied to many industrial-size case studies [17, 27, 36, 42]. Although CIF allows modeling of real-valued variables that evolve continuously over time (as described by differential equations), for the purpose of this paper our attention is restricted to discrete-event models.
Discrete-event models of the uncontrolled system (also called plant) can be developed in the form of a collection of extended finite automata [33]. The automata that comprise the plant synchronize over shared events and interact through the reading of each others’ (discrete) variables, and thus the global system behavior is achieved through synchronous composition [8]. An automaton consists of locations and edges between these locations. The edges are labeled by an event, a guard, and an update. The guard describes a condition (in terms of the variables) that enables the occurrence of the event associated with the edge. The update describes how the values of the variables change in such a transition. In CIF, variables are declared inside an automaton and follow the ‘global read, local write’ principle, which means that each variable may be inspected in any of the automata, but may only be adapted in its defining automaton. A CIF automaton has at least one initial location, and variables have at least one initial value. The state of an automaton is defined by its current location and variable valuations. Initial/marked locations implicitly define initial and marked states.
Events are defined to be controllable or uncontrollable. Uncontrollable events cannot be prevented from occurring by a supervisory controller, whereas controllable events can be blocked. The extended finite automata may have marked states. Marked states are typically used to denote states in which the system has finished a task. By applying supervisor controller synthesis, the controllable events are restricted in such a way that from every reachable state, a marked state can eventually be reached.
An example of a CIF automaton is given in Listing 1. Its graphical representation is given in Figure 2. Locations are represented by small circles with their name next to them. Initial locations have a dangling incoming arrow and possibly an expression stating the initial values of the variables. In the example there is a c variable that is defined as a discrete (the value will update in a discrete manner) integer, denoted with the keywords disc int, which has an initial value of \(\texttt{0}\). Marked locations have a double circle representation. Edges that are labeled by a controllable event are represented by a solid arrow and edges with an uncontrollable event by a dashed arrow. The optional guard is indicated by the keyword when and the update using do. In this paper we use both textual and graphical representations as we see fit.
Fig. 2.
Fig. 2. Graphical representation of the automaton from Listing 1.
Listing 1.
Listing 1. Textual CIF model of an automaton.
In CIF, requirements are specified by means of automata that state in which orderings the contained events are allowed to occur, or by using state-based expressions such as event conditions and state invariants [22, 23]. An event condition restricts the occurrences of an event to situations where a certain condition in terms of the variables of the model is satisfied. A state invariant expresses in which states the system is allowed to be.
CIF has several concepts that facilitate modeling of large systems, such as a definition/ instantiation mechanism for automata and requirements and algebraic variables. For an algebraic variable, the value is defined to be identical to the value of some expression (in terms of other variables). In this paper algebraic variables are used abundantly.
With each location \(L\) in each automaton \(A\), CIF associates a location variable \(A.L\) that may be used in guards, in right-hand sides of updates and algebraic variables, and in state-based requirements. Updates of these variables are implicit and according to the location change of an automaton.
3 Static Feature Models in CIF
In this section we demonstrate modeling of feature models where features cannot configure dynamically, i.e., they are static, as proposed in [35]. We first discuss normal (non-extended) feature models, and then attributes to allow extended feature models. Next, in Section 4 we will show how these static models can be extended to feature models supporting dynamic feature configuration, i.e., features may enter or leave the system during run-time.
A CIF model representing all allowed configurations for a given feature model is obtained as follows. For each feature, an automaton is introduced that captures whether the feature is present or not. It uses a Boolean variable present, the value of which is fixed initially, that is true when the feature is present and false otherwise. This variable is also used to capture the feature constraints expressed in the feature model.
Since the feature automata have the same structure we use an automaton definition in CIF, which is then instantiated for each feature in the feature model. The CIF specification for this automaton definition is given in the first four lines of Listing 2. In CIF, every automaton needs to have at least one location, hence the dummy location (without a name) defined in Listing 2. Note that the initial value of present is left implicit (is allowed to be either true or false by using the keywords in any). For each feature in the feature model an instance of this feature automaton definition is obtained by a statement such as the ones in lines 6 and 7. These instances act just like separately defined automata. We can write F1.present to refer to the present variable in F1.
Listing 2.
Listing 2. Automaton definition for features and instantiation for features.
Feature constraints arising from a feature model can be modeled in CIF in such a way that the transformation from a feature model to a CIF model can easily be automated. For each of the constraint types in Table 1, an algebraic CIF expression is shown in Listing 3. ‘/\(\!\)/’ in the listing denotes that the remainder of the line is a comment, which we use to specify the constraint type. Also, more complex constraints between features can be formulated in this way. These algebraic expressions can also be used to denote more complex constraints between features that are not considered here.
Listing 3.
Listing 3. Several feature constraint expressions.
A valid configuration is obtained if and only if all feature constraints are satisfied. To this end, the algebraic expressions for the separate feature constraints, such as in Listing 3, can be used. In Listing 4 we introduce an algebraic variable sys_valid that evaluates to true if and only if all feature constraints are satisfied. We also define automaton Validity in lines 3-5 in Listing 4. At the moment this automaton only states that the system initially is in a valid system configuration.
Listing 4.
Listing 4. Validity of configuration.
In an extended feature model, an attribute may be assigned to a feature. To model an attributed feature as an automaton, next to the presence feature one or more variables need to be declared to represent the attribute. In Listing 5 an example is given for a ball feature. The ball feature is attributed with a color, that can either be red, yellow, or blue. When the ball feature is not present, the color is not available (NA). The domain of the color enumerator is defined in line 1 of Listing 5. In line 5 the color variable is defined for the ball feature; it is an algebraic variable that takes the value defined in the feature automaton instantiation (clr) when the feature is present, and is NA otherwise.
Listing 5.
Listing 5. Attributed ball feature.
Example 3.1 (Static Feature Model for Coffee Machine in CIF).
The CIF specification of the feature model for the coffee machine is given in Listing 6.2 Two different plant definitions for features are used; one without any attributes, and one with a cost attribute. The plant definition for the attributed feature can be instantiated with an input variable defining the cost value. An algebraic integer variable cost_sum is introduced in line 39, as the sum of costs of all (present) features. Then, an algebraic Boolean is defined that is true when cost_sum is 30 or less. In the Validity automaton, it is defined that initially both the feature and cost constraints are satisfied. Construction of the state space of this model in CIF results in a structure with 16 allowed configurations, each represented by an initial state (and nothing more as we have not yet modeled any behavior).
Listing 6.
Listing 6. Feature instances of the coffee machine.
4 Dynamic Configuration
In the setting discussed in the previous section, the configuration is decided upon initialization of the system and cannot change at any later stage. In this section, we consider the situation that features may configure dynamically.
Different types of reconfiguration can be imagined. For example, it can be decided if reconfigurations take place in isolation, or may occur simultaneously. We can for example consider the replacement of the euro feature with the dollar feature. If we do this by first removing the euro feature, and then adding the dollar feature in a next action, these are separate reconfigurations in isolation. If we replace the euro feature with the dollar feature in a single action, this is simultaneous reconfiguration. Both alternatives can be modeled in CIF, and are respectively discussed in Sections 4.1 and 4.2. The decision on which alternative to use for a model is generally case-specific: can simultaneous reconfiguration practically be achieved, or are reconfiguration actions always performed one-by-one as in single feature configuration? One can also create a model that contains a combination of simultaneous and single feature reconfiguration. Nevertheless, the supervisory controller that we will generate in Section 7 is always correct-by-construction for the model, and will operate correctly for the physical system if that is adequately represented in the model.
If one allows models to dynamically configure, there may be situations where a specific change in configuration would result in a violation of the feature constraints. For the example we mentioned above for reconfiguration in isolation, temporarily neither the euro nor the dollar feature is present. Hence, it must be decided if such violations of the feature constraints are allowed, this is discussed in Section 4.3.
4.1 Single Feature Reconfiguration
In Section 3, for each feature an automaton with a variable named present is introduced that captures whether the feature is present. To allow change of presence status of a feature, the value of the corresponding present variable needs to be able to change. This can be modeled with a relatively small adaptation to the current feature definition. For each feature a come and go event are introduced that represent the addition and removal of the feature from the configuration. The resulting feature definition is shown in Listing 7. The events come and go are defined inside the automaton. As a consequence, there is an instance of both events for each instance of the plant definition. These events are referred to by, e.g., FM.come or FS.go. The same method of adapting the feature automaton definition to allow for dynamic configuration applies for attributed features.
In our examples the come and go events are chosen to be uncontrollable. This essentially means the supervisory controller safeguards the behavior of the system in the presence of uncontrollable reconfiguration. When the come and go events are controllable this means the supervisory controller can influence when particular reconfigurations can happen or not dependent on the system state. It is system dependent whether the come and go events should be modeled controllable or uncontrollable. It is also possible to have a mix of controllable and uncontrollable reconfiguration in the same model.
Listing 7.
Listing 7. Automaton definition for features with reconfiguration.
By instantiating the plant definition from Listing 7 for all features, a state space is obtained that contains each possible reconfiguration, also those that are invalid by the feature model. Restricting reconfiguration to valid configurations is discussed in Section 4.3.
4.2 Multi Feature Reconfiguration
In Section 4.1 we discussed a situation where features can come and go only one at a time. In some cases it may be desirable to update the presence of multiple features at a time. For example, the dollar feature of the coffee machine can be removed and simultaneously the euro feature can be added. In this way, this reconfiguration can take place without violating the feature constraints, which is impossible with single feature configuration.
To allow updating of the presence variable of multiple feature automata at the same time, a global event can be introduced on which the automata synchronize and their presence variable is updated. In Listing 8 features F1 and F2 are alternative features. The event swap12 is declared to define exchanging F1 and F2. By the restriction of the Validity automaton, the system is initially in a valid configuration. Because of multi feature reconfiguration, F1 and F2 can be swapped without the system being in an invalid configuration, i.e., always either F1 or F2 is present.
Listing 8.
Listing 8. Feature automata with multi feature configuration.
4.3 Strictness of the Feature Constraints
By allowing features to enter or leave the system, the feature constraints may be violated temporarily. Two approaches towards the applicability of the feature constraints during reconfiguration are discussed: (1) violation of feature constraints is strictly prohibited, and (2) feature constraints may be violated temporarily.
Strict feature constraints. Restricting reconfigurations to valid configurations can be achieved by adding a plant invariant such as presented in Listing 9. Adding this invariant removes all states where sys_valid and cost_valid evaluates to false, and all transitions toward these states in the plant’s behavior.
Listing 9.
Listing 9. Invariant restricting reconfiguration to valid configurations.
Fig. 3.
Fig. 3. State space of the coffee machine with reconfiguration.
Example 4.1 (Reconfiguration with Strict Feature Configuration).
Consider the coffee machine from Example 3.1, but now with single feature reconfiguration as discussed in Section 4.1, and reconfiguration restricted such that sys_valid and cost_valid are always true. The state space of this system is shown in Figure 3. Note that this is a single automaton, even though it consists of two unconnected parts. Just as for the static configuration, there are 16 (initial) states that represent the valid configurations. Now, switching between configurations is possible by the come and go events.
Since not all states in the state space are connected to each other, we conclude that for some initial configurations, it is not possible to reconfigure to some other configurations. The seven states on the left hand side are all configurations equipped with the dollar feature, the nine states on the right hand side are all configurations equipped with the euro feature. In this model, it is impossible to reconfigure from a euro to dollar feature and vice versa. This is because for single feature reconfiguration, during reconfiguration either both the euro and dollar feature are present or both are not present, which are invalid configurations.
Relaxed feature constraints. It may be desirable to temporarily allow violation of feature constraints during a reconfiguration phase, where the system configuration moves from one valid configuration to another. This would allow any feature to configure at any moment. Consequently, the system may get into a configuration that does not satisfy the feature constraints.
It should be noted that one may feel the need to express that some of the feature constraints really need to be satisfied at all times. Of course this can still be enforced.
Example 4.2 (Constraints During Reconfiguration).
One may allow invalid configurations to be reached. However, for the coffee machine there may be a constraint when the change feature is present, the coin feature must always be present. This is achieved using the model fragment from Listing 10. The resulting state space consists of 1,364 states, among which 16 are initial states. There are 13,440 come and go transitions. Given the possibilities offered by CIF and the modularly defined feature constraints, it is possible to make more complex constraints.
Listing 10.
Listing 10. Coin feature present when change feature is present.
5 Modeling of Uncontrolled Behavior
Next, the modeling of uncontrolled behavior of the system components is discussed. In Section 6, requirements are defined on this behavior. This can then be used to synthesize a supervisory controller, which is discussed in Section 7.
5.1 Behavior of the Uncontrolled System
The plant modeling aims at capturing all uncontrolled behavior regardless of features, solely focusing on the potential behavior of the physical components.
Fig. 4.
Fig. 4. Plant automata for the coffee machine.
Example 5.1 (Coffee Machine Component Behavior).
We model the uncontrolled behavior of the individual components of the coffee machine. The component-wise behavioral specification of this machine is taken from [35].
The system constitutes of the following components: Coffee, Tea, Sweet, Ringtone, Coin, Cancel, and Machine. For each of the components an automaton is provided that describes its behavior, see Figure 4. Although the different models use the same event names (done), because the events are defined within the automata, they are different, and do not synchronize.
The system that is composed of these seven components has a state space of 18 states and 207 transitions, when there is no imposed (supervisory) control, i.e., the events can occur at any time that they are defined in the system.
The CIF model consisting of the component automata does not yet take into account that in specific configurations specific components are not allowed to show behavior, because they are ‘connected’ to features that are not present. For example, the event ring of component Ringtone (denoted Ringtone.ring) is only available in case the ringtone feature is part of the configuration.
In the coffee machine example, for each component there is a one-to-one correspondence with the features. In general we require the modeler to indicate for each event that occurs in a component model which features need to be present for that event to be able to occur. Note that in some cases the availability of an event may also be dependent on the value of some attribute. In CIF this can then be captured by means of additional conditions on such events. For an event e that requires the presence of feature F1 and an attribute value of x for attribute A of feature F2, this is achieved as shown in Listing 11. The connection is stated in the form of a plant, because it models the physical incapability to perform some events when certain features are not present.
Listing 11.
Listing 11. Definition of link between events and features.
Example 5.2 (Connection between Events and Features for the Coffee Machine).
For the coffee machine, the connection between events and features is captured by the plant event_feature_link in Listing 12.
Listing 12.
Listing 12. Connection between events and features.
The way we expressed the availability of events in relation to the presence of features is conceptually similar to the solution adopted in featured transition systems [9]. In these featured transition systems events are also available conditionally depending on feature presence. The most prominent difference between this paper and the approach using featured transition systems is that here the description of the relation between features and events is separated from the behavioral models of the components. Another difference is that in the approach using featured transition systems not the uncontrolled system and requirements are modeled, but the supervisory controller is developed directly.
5.2 Component Reappearance
As a result of reconfiguration, a component may leave or enter the system repeatedly. Initially, the components are in their initial state as defined in Section 5.1. Sometimes it may be required to reinitialize or reset the state of the component when it leaves or enters the system.
Until now, the appearance and disappearance of features is not directly affecting the states of the involved components. Therefore, when a feature disappears, and in a future configuration reappears, the components linked with this feature are still in the same state.
The modeler can easily adapt the plant model such that, for example, a component transitions to some desired reset state whenever the component enters or leaves the system. For example, by adding an edge, labeled with the come or go event of the respective component, from each state in the plant model of the component to its desired reset state. Because of synchronization, upon occurrence of the come or go event (from the feature plant) the transition with the same label in the component is taken as well. When the plant model of the component has an outgoing transition labeled with this reconfiguration transition from each state, the proposed addition does not restrict reconfiguration possibilities. Otherwise, the reconfiguration event can only take place when the component is in a state where the transition is defined.
Fig. 5.
Fig. 5. Adapted plant for resetting the tea component in case of removal from the configuration.
Example 5.3 (Re-initialization in the Coffee Machine).
Let us consider the case that we want the tea component to go to the NoChoice location when it leaves the system. Applying the proposed approach results in the adapted plant automaton shown in Figure 5. If the tea component leaves the system, i.e., event FT.go occurs, when the automaton is in the Tea location, it will transition to NoChoice. If the event occurs when the automaton is already in NoChoice it will remain there. Note that in this example the automaton does not use the event FT.come and is therefore not influenced when that particular event occurs.
6 Specification of Requirements
In the previous section, we have discussed how to model the uncontrolled system and how to link event occurrences to availability of features. In this section, we discuss the modeling of requirements. In Section 6.1, the specification of behavioral requirements is discussed. In Section 6.2 we elaborate on the specification of requirements in the setting of dynamic configuration.
6.1 Behavioral Requirements
As explained in Section 2, requirements are specified by means of automata that synchronize with the plant or by using state-based expressions such as event conditions and state invariants [23]. The example below demonstrates several ways to specify the formal requirements, given a set of informal requirements.
Example 6.1 (Requirements Coffee Machine).
Below we state the informal system requirements and their corresponding CIF formulation. Requirement automata, event conditions, and state invariants are used. These requirements can be added to the model containing the plant behavior and the feature model.
(1)
The coffee and tea component cannot both be ready to pour:
(2)
Coffee, cappuccino, or tea can only be selected when no choice between them has been made:
Note that, in addition to these requirements, these events can only occur when their respective feature is present, because of the connection between the events and feature presence discussed in Section 5.
(3)
When the ringtone feature is present, it may only ring (once) after the coffee or tea component is finished:
This requirement shows how the behavioral requirements can be made dependent on the presence of features. When the ringtone feature is not present, this requirement automaton will stay in NotCompleted. When the ringtone feature is present, after pouring coffee or tea is done, the automaton needs to transition to the Completed location before the ringtone can be performed.
(4)
A coin needs to be present to make a selection of beverage and sugar:
This requirement showcases the use of a monitor automaton. In literature this is sometimes also called an observer automaton. The automaton CoinPresence never disables any event, but simply tracks whether a coin is present in the system. The state of CoinPresence is used in the subsequent event conditions so that only a selection can be made when a coin is present.
(5)
Coffee is only poured once:
Once more, a monitor automaton is used. This automaton tracks whether Coffee has been poured. Note that we have similar informal requirements with CIF formalizations for only pouring tea and milk once; resulting in automata TeaPoured and MilkPoured.
(6)
Coffee and tea should not be mixed, and tea and milk should not be mixed:
Here the previously defined states of the monitor automata are used in additional state invariants.
(7)
When coffee is selected, the coffee component is done after pouring only coffee. When cappuccino is selected, the coffee component is done after pouring both coffee and milk:
(8)
When sugar is selected, it is poured twice:
Here we use a requirement automaton that is an extended finite automaton to keep track of a count of how many times sugar has been poured. Pouring sugar is only finished after it has been performed twice, and the counter is reset to zero when the cup is taken from the system.
(9)
Cancellation is only possible before anything has been poured:
(10)
The cup can only be taken from the machine when the pouring of coffee, tea, and sugar is done and no new selection was made:
6.2 Requirements During Configuration
As discussed in Section 4.3, it may be beneficial to allow invalid configurations so that reconfiguration can take place. In this case, decisions must be made about allowed behavior in such configurations. There are several ways to deal with the specification of allowed behavior during the configuration phase: (1) disable some events from occurring, and (2) additional requirements. Each of these approaches may be suitable for certain applications. In the following subsections these possibilities are investigated.
6.2.1 Disabling Events.
An approach to restrict the behavior during reconfiguration is to disable some events in case the system is in an invalid configuration. For each such an event, an event condition, such as the one presented for event e in Listing 13, can be defined that restricts that event to occur only when the system is in a valid configuration.
Listing 13.
Listing 13. Disabling an event in an invalid system configuration.
This approach assumes that the system will exhibit safe behavior by not exercising any of the events disabled in this way. As soon as the system returns to a valid configuration these events are no longer disabled. Such event disablement requirements can also be expressed for particular configurations, as discussed in the next example.
Example 6.2 (Event Disablement in Coffee Machine During Reconfiguration).
In the coffee machine, invalid configurations may sometimes be allowed. For example, exchanging the euro and dollar feature through two subsequent single feature reconfiguration events is achieved by either having none or both features present during the reconfiguration. Let us consider the case that both the euro and dollar feature are present. It may be unsafe to cancel the order in this situation, as it is unclear from which feature the coin should be returned. This can be avoided by adding a requirement as given in Listing 14.
Listing 14.
Listing 14. Constraint during invalid configuration.
6.2.2 Additional Requirements.
Another approach is stating additional requirements for the transitional situation. For the coffee machine these are detailed in the next example.
Example 6.3 (Dynamic Configuration Constraints for the Coffee Machine).
We consider the situation that it is allowed that the sweet feature is not present during reconfiguration. However, in case the sweet feature is currently ready to pour sugar, it needs to always be present. Listing 15 shows a formalization of this requirement, that restricts the possible (invalid) configurations that can be reached depending on the current state of the components.
Listing 15.
Listing 15. Constraint during invalid configuration.
7 Supervisory Controller Synthesis
The automata model obtained from the feature model in Section 4, the uncontrolled behavior specification from Section 5, and the behavioral requirements from Section 6 can be placed into a single model. Next, supervisory control synthesis [26] can be applied. A supervisory controller is generated as an automaton that controls the system through synchronizing events. The system under control consists of the supervisor synchronized with all plant and requirement automata. By construction of the supervisor, the system under control is:
(1)
Safe: the requirements are always adhered to. If in synchronous composition the plant can execute an event, but it is not possible in a requirement automaton that synchronizes on that event, the event is prevented from occurring.
(2)
Nonblocking: a marked state can always be reached. Since we modeled the system using multiple automata, this means in the controlled behavior it is always possible to follow a sequence of events such that all automata are simultaneously in a marked state. For example, if we consider the CoinPresence requirement of Section 6.1, we are sure that the system can always return to the state that no coins are present.
(3)
Controllable: the supervisor does not disallow uncontrollable events to occur. In our model of the coffee machine all reconfiguration actions are uncontrollable. The supervisor always allows these to happen, and prevents the sytem from reaching states that are not allowed in a particular configuration, if we may uncontrollably reconfigure to that configuration.
(4)
Maximally permissive: no behavior is disabled that does not strictly need to be disallowed to satisfy the aforementioned properties. This makes sure the supervisory controller does not restrict any behavior that is perfectly fine to occur.
Note that a single supervisory controller is generated that applies to all system configurations.
Example 7.1 (Supervisory Controller Synthesis for the Coffee Machine).
We consider the coffee machine with dynamic single feature configuration, where invalid configurations are never allowed, and the requirements of Section 6 are applied. Applying supervisory controller synthesis to the described system results in a supervisory controller that applies the guards formulated in Listing 16 to the controllable events. Note that the guard for Cancel.cancel is not displayed because the expression is very long. The state space of the system under control contains 6,240 states and 35,336 transitions.
Listing 16.
Listing 16. Additional guards provided by supervisory controller synthesis.
Listing 17.
Listing 17. BCS feature model in CIF.
8 Case Study: Body Comfort System
We present a case study on the Body Comfort System (BCS) [20], which is a frequently used benchmark in (S)PLE-related literature [12, 18, 19, 21]. It is a product line originating from the automotive industry. It contains a number of standard and optional features, such as LEDs in the human machine interface, manual or automatic windows, security options such as an alarm system, and more. The feature model of the BCS is given in Figure 6. This feature model allows for 11,616 valid configurations. Note that for this case study, only features without attributes are considered.
Fig. 6.
Fig. 6. Feature model of the Body Comfort System [20].
The feature model is modeled in CIF as outlined in Section 3, this results in Listing 17.
In this model, the system is initially in a valid configuration, but can reconfigure to any configuration through the come and go events. That is, all invalid configurations are allowed during reconfiguration. This model (without any component behavior added) has 134,217,728 reachable states. Of these states, 11,616 states are initial states representing the valid configurations.
In [20], state machine test models are constructed for product instances of the BCS. In [39], a component wise behavioral model of the BCS is made, as an interpretation of the models in [20]. We will use the models from [39] here.
As an example, we consider the alarm system and interior monitoring features. The uncontrolled behavior of the relevant components is defined by the automata shown in Listing 18. In the event names, “c_” and “u_” are used as prefixes to respectively indicate controllable or uncontrollable events.
Listing 18.
Listing 18. BCS uncontrolled behavior of the alarm system and interior monitoring.
The events of the automata are linked to their presence in Listing 19. One can observe that the events of AlarmSystem and InteriorMonitoring are dependent on the presence features FAlarm and FInterMon, respectively. However, the event AlarmSystem.c_IM_detected requires both features to be present.
Listing 19.
Listing 19. BCS presence check alarm system.
Requirements for these components are given in Listing 20. One can see how these refer to other relevant components in the system such as Key_lock and RCK_CLS, which are the physical key and the remote control key of the central locking system.
Listing 20.
Listing 20. BCS requirements alarm system.
In the complete model,3 there are in total 31 plant automata representing the behavior of the components. Additionally, there are 27 feature automata and 18 plant automata that link the component events to the presence of the features. 55 requirements are specified. Only event condition requirements are used. Using CIF, synthesis can successfully be applied to this system.
Some relevant state space sizes are mentioned in Table 2. The worst-case state space is calculated by calculating the product of the number of states in each automaton. The other state space sizes all denote the reachable states from the initial states. For the uncontrolled systems, no synthesis or requirements are applied yet. For the controlled systems, the state space size is the number of reachable states in the system controlled by the synthesized supervisory controller. Using a standard personal computer and applying supervisory controller synthesis in CIF using the default settings, the supervisor is obtained in roughly 0.3 seconds for each of the static and the dynamic case. For these computations, the CIF application requires no more than 0.5 GB of memory. Even though a state space in the order of \(10^{20}\) can be considered large, CIF has been shown capable of performing supervisory controller synthesis for systems with much larger state spaces [27]. It should be noted that, since CIF uses symbolic supervisory controller synthesis using Binary Decision Diagrams (BDDs), the computational effort of synthesis is dependent on more factors than state space size [37]. Supervisory controller synthesis for the static case requires 19,614 peak used BDD nodes and 1,864,598 BDD operations. For the dynamic case this is 26,140 peak used BDD nodes and 2,039,318 operations. These BDD-based metrics of computational effort of supervisory controller synthesis are detailed in [37] and measurements for benchmark systems are provided in the same work.
Table 2.
State space
Number of states
Worst-case
\(7.7\cdot 10^{20}\)
Uncontrolled static
\(3.2\cdot 10^{14}\)
Uncontrolled dynamic
\(6.2\cdot 10^{20}\)
Controlled static
\(7.6\cdot 10^{13}\)
Controlled dynamic
\(1.1\cdot 10^{20}\)
Table 2. State Space Sizes BCS
Even though the BCS is a frequently used benchmark in literature related to product line engineering [12, 18–21], as far as we are aware there is no existing work to which we can compare these results. In fact, only in [39] the first models of the BCS were made that were suitable for application of supervisory control theory.
With the BCS use case, we have shown that CIF is capable of both modeling an industrial sized product line through the use of feature models, and synthesizing a supervisory controller for this system in which dynamic reconfiguration is allowed.
9 Concluding Remarks
We have presented a framework for engineering supervisory controllers for product lines of which the valid configurations are described by a feature model and where dynamic configuration of the features is allowed. The CIF language has shown to be adequate for modeling the involved concepts. It was shown how the presence and absence of features can be modeled, and how this presence can update through single or multi feature configuration. Component wise modeling of the system behavior has been demonstrated, where the presence of features influences the possible behavior. It was shown how requirements can be formulated that take the presence of the features into account, and how requirements can be strengthened when the system is in an invalid configuration. Supervisory controller synthesis can be applied such that the maximal nonblocking, controllable, and safe behavior under control is obtained. The method was demonstrated using the coffee machine as a running example. Although the coffee machine system is small, feasibility of industrial application has been demonstrated with the much larger BCS use case.
Knut Åkesson, Martin Fabian, Hugo Flordal, and Robi Malik. 2006. Supremica - An integrated environment for verification, synthesis and simulation of discrete event systems. In 2006 8th International Workshop on Discrete Event Systems. IEEE. DOI:
Davide Basile. 2019. Applying supervisory control synthesis to priced featured automata and energy problems. International Journal on Software Tools for Technology Transfer 21, 6 (Sep. 2019), 679–689. DOI:
Davide Basile, Maurice H. ter Beek, Pierpaolo Degano, Axel Legay, Gian-Luigi Ferrari, Stefania Gnesi, and Felicita Di Giandomenico. 2020. Controller synthesis of service contracts with variability. Science of Computer Programming 187 (Feb. 2020), 102344. DOI:
David Benavides, Sergio Segura, and Antonio Ruiz-Cortés. 2010. Automated analysis of feature models 20 years later: A literature review. Information Systems 35, 6 (Sep. 2010), 615–636. DOI:
David Benavides, Pablo Trinidad, and Antonio Ruiz-Cortés. 2005. Automated reasoning on feature models. In Notes on Numerical Fluid Mechanics and Multidisciplinary Design. Springer International Publishing, 491–503. DOI:
Jan Bosch. 2000. Design and Use of Software Architectures: Adopting and Evolving a Product-Line Approach. ACM Press/Addison-Wesley Publishing Co., USA.
Andreas Classen, Maxime Cordy, Pierre-Yves Schobbens, Patrick Heymans, Axel Legay, and Jean-Francois Raskin. 2013. Featured transition systems: Foundations for verifying variability-intensive systems and their application to LTL model checking. IEEE Transactions on Software Engineering 39, 8 (Aug. 2013), 1069–1089. DOI:
Andreas Classen, Patrick Heymans, Pierre-Yves Schobbens, Axel Legay, and Jean-Francois Raskin. 2010. Model checking lots of systems. In Proceedings of the 32nd ACM/IEEE International Conference on Software Engineering - ICSE. ACM Press. DOI:
Krzysztof Czarnecki and Ulrich Eisenecker. 2000. Generative Programming: Methods, Tools, and Applications. ACM Press/Addison-Wesley Publishing Co., USA.
Vanderson H. Fragal, Adenilso Simao, and Mohammad R. Mousavi. 2017. Validated test models for software product lines: Featured finite state machines. In Formal Aspects of Component Software. Springer International Publishing, 210–227. DOI:
Hamza Gharsellaoui, Jihen Maazoun, Nadia Bouassida, Samir Ben Ahmed, and Hanene Ben-Abdallah. 2021. A software product line design based approach for real-time scheduling of reconfigurable embedded systems. Computers in Human Behavior 115 (Feb. 2021), 104925. DOI:
Gökhan Kahraman and Loek Cleophas. 2021. Automated derivation of variants in manufacturing systems design. In Proceedings of the 25th ACM International Systems and Software Product Line Conference - Volume B. ACM. DOI:
Sachin Kogekar, Sandeep Neema, Brandon Eames, Xenofon Koutsoukos, Akos Ledeczi, and Miklos Maroti. 2004. Constraint-guided dynamic reconfiguration in sensor networks. In Proceedings of the Third International Symposium on Information Processing in Sensor Networks - IPSN'04. ACM Press. DOI:
Tim Korssen, Victor Dolk, Joanna M. van de Mortel-Fronczak, Michel A. Reniers, and Maurice Heemels. 2018. Systematic model-based design and implementation of supervisors for advanced driver assistance systems. IEEE Transactions on Intelligent Transportation Systems 19, 2 (Feb. 2018), 533–544. DOI:
Remo Lachmann, Sandro Schulze, Manuel Nieke, Christoph Seidl, and Ina Schaefer. 2016. System-level test case prioritization using machine learning. In 2016 15th IEEE International Conference on Machine Learning and Applications (ICMLA’16). IEEE. DOI:
Sascha Lity, Mustafa Al-Hajjaji, Thomas Thüm, and Ina Schaefer. 2017. Optimizing product orders using graph algorithms for improving incremental product-line analysis. In Proceedings of the Eleventh International Workshop on Variability Modelling of Software-intensive Systems. ACM. DOI:
Malte Lochau, Sascha Lity, Remo Lachmann, Ina Schaefer, and Ursula Goltz. 2014. Delta-oriented model-based integration testing of large-scale systems. Journal of Systems and Software 91 (May 2014), 63–84. DOI:
Chuan Ma and Walter M. Wonham. 2006. Nonblocking supervisory control of state tree structures. IEEE Trans. Automat. Control 51, 5 (May 2006), 782–793. DOI:
Jasen Markovski, Koen Jacobs, Dirk A. van Beek, Lou J. A. M. Somers, and Jacobus E. Rooda. 2010. Coordination of resources using generalized state-based requirements. IFAC Proceedings Volumes 43, 12 (2010), 287–292. DOI:
Peter J. Ramadge and Walter M. Wonham. 1984. Supervisory control of a class of discrete event processes. In Analysis and Optimization of Systems. Springer-Verlag, 475–498. DOI:
Peter J. Ramadge and Walter M. Wonham. 1987. Supervisory control of a class of discrete event processes. SIAM Journal on Control and Optimization 25, 1 (Jan. 1987), 206–230. DOI:
Ferdie F. H. Reijnen, Martijn A. Goorden, Joanna M. van de Mortel-Fronczak, and Jacobus E. Rooda. 2020. Modeling for supervisor synthesis – a lock-bridge combination case study. Discrete Event Dynamic Systems 30, 3 (Mar. 2020), 499–532. DOI:
Michel A. Reniers and Sander B. Thuijsman. 2020. Supervisory control for dynamic feature configuration in product lines. In 2020 Forum for Specification and Design Languages (FDL’20). IEEE. DOI:
Marko Rosenmüller, Norbert Siegmund, Mario Pukall, and Sven Apel. 2011. Tailoring dynamic software product lines. In Proceedings of the 10th ACM International Conference on Generative Programming and Component Engineering - GPCE'11. ACM Press. DOI:
Amir M. Sharifloo, Andreas Metzger, Clément Quinton, Luciano Baresi, and Klaus Pohl. 2016. Learning and evolution in dynamic software product lines. In Proceedings of the 11th International Symposium on Software Engineering for Adaptive and Self-Managing Systems. ACM. DOI:
Hesham Shokry and Muhammad Ali Babar. 2008. Dynamic software product line architectures using service-based computing for automotive systems. In Software Product Lines, 12th International Conference, SPLC 2008, Limerick, Ireland, September 8–12, 2008, Proceedings. Second Volume (Workshops), Steffen Thiel and Klaus Pohl (Eds.). Lero Int. Science Centre, University of Limerick, Ireland, 53–58.
Markus Sköldstam, Knut Åkesson, and Martin Fabian. 2007. Modeling of discrete event systems using finite automata with variables. In 2007 46th IEEE Conference on Decision and Control. IEEE. DOI:
Maurice H. ter Beek and Erik P. de Vink. 2014. Using mCRL2 for the analysis of software product lines. In Proceedings of the 2nd FME Workshop on Formal Methods in Software Engineering - FormaliSE 2014. ACM Press. DOI:
Maurice H. ter Beek, Michel A. Reniers, and Erik P. de Vink. 2016. Supervisory controller synthesis for product lines using CIF 3. In Leveraging Applications of Formal Methods, Verification and Validation: Foundational Techniques. Springer International Publishing, 856–873. DOI:
Rolf J. M. Theunissen, Mihaly Petreczky, Ramon R. H. Schiffelers, Dirk A. van Beek, and Jacobus E. Rooda. 2014. Application of supervisory control synthesis to a patient support table of a magnetic resonance imaging scanner. IEEE Transactions on Automation Science and Engineering 11, 1 (Jan. 2014), 20–32. DOI:
Sander B. Thuijsman, Dennis Hendriks, Rolf J. M. Theunissen, Michel A. Reniers, and Ramon R. H. Schiffelers. 2019. Computational effort of BDD-based supervisor synthesis of extended finite automata. In 2019 IEEE 15th International Conference on Automation Science and Engineering (CASE’19). IEEE. DOI:
Sander B. Thuijsman and Michel A. Reniers. 2022. Transformational supervisor synthesis for evolving systems. Discrete Event Dynamic Systems 32, 2 (Feb. 2022), 317–358. DOI:
Dirk A. van Beek, Wan J. Fokkink, Dennis Hendriks, Albert Hofkamp, Jasen Markovski, Joanna M. van de Mortel-Fronczak, and Michel A. Reniers. 2014. CIF 3: Model-based engineering of supervisory controllers. In Tools and Algorithms for the Construction and Analysis of Systems. Springer Berlin, 575–580. DOI:
Bram J. van der Sanden, Yuri Blankenstein, Ramon R. H. Schiffelers, and Jeroen P. M. Voeten. 2021. LSAT: Specification and analysis of product logistics in flexible manufacturing systems. In 2021 IEEE 17th International Conference on Automation Science and Engineering (CASE’21). IEEE. DOI:
Bram J. van der Sanden, Michel A. Reniers, Marc Geilen, Twan Basten, Johan Jacobs, Jeroen P. M. Voeten, and Ramon R. H. Schiffelers. 2015. Modular model-based supervisory controller design for wafer logistics in lithography machines. In 2015 ACM/IEEE 18th International Conference on Model Driven Engineering Languages and Systems (MODELS’15). IEEE. DOI:
Jeroen J. Verbakel, Erik M. E. W. Vos de Wael, Joanna M. van de Mortel-Fronczak, Wan J. Fokkink, and Jacobus.E. Rooda. 2021. A configurator for supervisory controllers of roadside systems. In 2021 IEEE 17th International Conference on Automation Science and Engineering (CASE’21). IEEE. DOI:
Päßler Jter Beek MDamiani FJohnsen ETapia Tarifa S(2025)Analysing Self-Adaptive Systems as Software Product LinesJournal of Systems and Software10.1016/j.jss.2024.112324222(112324)Online publication date: May-2025
Lima RBezerra CMachado I(2023)A Self-Adaptation Mechanism for Variability Management in Dynamic Software Product LinesProceedings of the 17th Brazilian Symposium on Software Components, Architectures, and Reuse10.1145/3622748.3622754(51-60)Online publication date: 25-Sep-2023
Basile Dter Beek MBussi LCiancia V(2023)A toolchain for strategy synthesis with spatial propertiesInternational Journal on Software Tools for Technology Transfer (STTT)10.1007/s10009-023-00730-125:5-6(641-658)Online publication date: 1-Dec-2023
VariComp '12: Proceedings of the 3rd international workshop on Variability & Composition
For the development of variable systems, software product lines (SPL) are an established way to handle the variability by using feature models. Nevertheless, the configuration of an SPL can be complex, especially if a product line consists of a large ...
KAM '09: Proceedings of the 2009 Second International Symposium on Knowledge Acquisition and Modeling - Volume 02
Software product line development is a new software engineering method. It promotes the predictive software reuse by developing similar software systems together. One of the key artifacts of a software product line is the feature model, which represents ...
VaMoS '16: Proceedings of the 10th International Workshop on Variability Modelling of Software-Intensive Systems
Software Product Lines (SPLs) are a mechanism for large-scale reuse where families of related software systems are represented in terms of commonalities and variabilities, e.g., using Feature Models (FMs). While FMs define all possible configurations of ...
Permission to make digital or hard copies of part or all of this work for personal or classroom use is granted without fee provided that copies are not made or distributed for profit or commercial advantage and that copies bear this notice and the full citation on the first page. Copyrights for third-party components of this work must be honored. For all other uses, contact the owner/author(s).
Päßler Jter Beek MDamiani FJohnsen ETapia Tarifa S(2025)Analysing Self-Adaptive Systems as Software Product LinesJournal of Systems and Software10.1016/j.jss.2024.112324222(112324)Online publication date: May-2025
Lima RBezerra CMachado I(2023)A Self-Adaptation Mechanism for Variability Management in Dynamic Software Product LinesProceedings of the 17th Brazilian Symposium on Software Components, Architectures, and Reuse10.1145/3622748.3622754(51-60)Online publication date: 25-Sep-2023
Basile Dter Beek MBussi LCiancia V(2023)A toolchain for strategy synthesis with spatial propertiesInternational Journal on Software Tools for Technology Transfer (STTT)10.1007/s10009-023-00730-125:5-6(641-658)Online publication date: 1-Dec-2023
