Simulating Self-Adaptive Component-Based Systems using MATLAB ...

Simulating Self-Adaptive Component-Based Systems using MATLAB/Simulink Christian Heinzemann, Jan Rieke, Wilhelm Sch¨afer Software Engineering Group Heinz Nixdorf Institute, University of Paderborn Zukunftsmeile 1, 33102 Paderborn, Germany Email: [c.heinzemann | jrieke | wilhelm]@uni-paderborn.de Abstract—The automotive industry uses MATLAB/Simulink models for specifying the behavior of software components and for early validation of that behavior using model-in-the-loop simulations. During a simulation run, these models may not structurally change. Thus, MATLAB/Simulink is not amenable to realizing self-adaption behavior, where the software architecture of the system evolves during runtime. In this paper, we show how to model self-adaptive software using our language MechatronicUML and how we transform a model specified in MechatronicUML into a MATLAB/Simulink model automatically. In particular, we generate several helper functions that emulate self-adaptive behavior in MATLAB/Simulink, relying only on standard Simulink blocks. We illustrate our approach using an example of car platoons.

I.

Introduction

Today, the automotive industry increasingly applies model-driven techniques for developing the software for their cars. Current development approaches [1] employ the AUTOSAR standard [2] for defining a software architecture of the system and MATLAB with its toolbox Simulink for defining the behavior of the software components. Central to this approach is the early validation of the software functions using model-in-the-loop (MIL) simulation in Simulink. In a MIL simulation, a model of the software is validated against a model of the environment. A Simulink simulation model is static, i.e., once specified, the components and their connections in the simulation model may not change while running a simulation. That prevents the specification and early validation of functions that require structural changes in the software architecture. Examples of such functions are self-healing to recover from hardware failures [3] or car-to-car communication where communication partners change frequently. In this paper, we use car platoons as an of a selfadaptive system that uses such car-to-car communication. In a car platoon, cars drive at low distances for reducing the energy consumption and increasing the throughput on a highway [4]. In current approaches, the leading car is usually operated manually and all remaining cars, called followers, operate autonomously and are controlled by software only. In a platoon, the leading car must notify all followers about a braking maneuver to prevent accidents. Consequently, all vehicles that want to join the platoon need to register with the leader.

Such functionality requires a self-adaptation [5] of the software architecture at runtime by using structural reconfiguration [6], i.e., instantiating, removing, and reconnecting software components during runtime. In our example, joining a platoon requires a follower to instantiate the software for driving autonomously and to replace the current velocity controller by a distance controller that considers the distance to the preceding car. The leading car needs to instantiate a software component for managing the platoon members. That, in turn, requires to manage a varying number of communication links with varying communication partners, because cars may join or leave the platoon at any time. Specifying the necessary runtime reconfiguration and message-based communication functionality is not natively supported by Simulink. Thus, supporting such functions in a MIL simulation requires the manual implementation of workarounds, which is time-consuming and error-prone. In literature, there exist only few approaches for realizing self-adaptation in Simulink. They support the simulation of reconfigurable FPGA hardware [7], [8], but they do not consider adding/removing components to/from a simulation model and message-based communication behavior. Approaches targeting reconfiguration of AUTOSAR-based automotive systems [9], [10], [11] only support later phases of the development process. All of these approaches have in common that they do not provide concepts for early validation by MIL simulation in Simulink. Corresponding efforts for MIL simulation in Modelica [12] require language extensions and, as a consequence, special simulators [13], [14]. That, in turn, prevents the use of standard production code generators for producing the target code for the system. In this paper, we extend our approach of [15] towards supporting MIL simulation of a self-adaptive system in Simulink without extending Simulink. In particular, we use our modeling language MechatronicUML [16], [17], [18] for specifying a reconfigurable software architecture. We use a rule-based specification based on graph transformations [19] for specifying reconfigurations that is called component story diagrams [20]. These rules encode the knowledge of which reconfiguration is necessary in which particular situation. Since MechatronicUML natively supports reconfigurable software architectures, the resulting rule-based specification is compact and easily maintainable. In this paper, we restrict ourselves to a fixed set of rules and leave the integration of further rules (e.g., encoding machine learning algorithms) for future works.

As our core contribution, we illustrate how we translate a MechatronicUML model of a self-adaptive system to MATLAB/Simulink. Therefore we automatically derive all possible configurations of the software including the transitions between configurations from the MechatronicUML specification. This information serves as in input for an automatic model transformation that generates a Simulink model emulating the reconfiguration behavior. In particular, we automatically generate a set of Embedded MATLAB Functions that encode the reconfiguration behavior of the system, which relieves the developer from implementing such functionality manually. By using only native features of Simulink for emulating reconfiguration, we enable the use of off-the-shelf production code generators for producing the target code. We illustrate our approach using the aforementioned example of a car platoon. The paper is structured as follows. In Section II, we provide a short overview of MATLAB/Simulink. Section III introduces MechatronicUML, which we use for specifying the reconfigurable software architecture. We provide an overview of the transformation of non-adaptive MechatronicUML models to Simulink in Section IV before giving an overview of our core contribution, the transformation of a reconfigurable software architecture, in Section V. Sections VI to VIII provide details on the different steps of the transformation. We discuss related work in Section IX before concluding the paper in Section X. II.

MATLAB/Simulink

MATLAB is a commercial tool for numerical computation and visualization, which is developed by The MathWorks. The Simulink toolbox1 is an extension for MATLAB for modeling and simulating technical systems. In particular, it supports the specification and simulation of systems with continuous dynamics such as cars. A Simulink model consists of blocks connected by signals. Simulink provides a wide range of basic blocks, e.g., for mathematical operations, signal generation and routing. Blocks can be grouped hierarchically using subsystems. A special kind of subsystem is the enabled subsystem shown in Figure 1. The enabled subsystem NormalDriveController is only active if the control signal at the top has a value greater than 0. If it is not active, it is not executed.

Simulink models may also be extended by Embedded MATLAB Functions. Embedded MATLAB is a subset of the MATLAB scripting language that can be generated into efficient real-time C code using the Simulink Coder. III.

MechatronicUML [16], [17] is a model-driven design method that adapts concepts of the UML to model software for self-adaptive mechatronic systems. Mechatronic systems like cars consist of mechanical, electrical, and software parts that, in combination, realize the behavior of the system. MechatronicUML follows the componentbased approach [22] where the software architecture of a system is specified by a set of interacting components. In our component model [18], we distinguish between atomic components and structured components. Atomic components contain a behavior specification while structured components are assembled by embedding other (atomic or structured) components. A structured component may optionally specify a reconfiguration behavior [23]. In case of atomic components, MechatronicUML distinguishes between software components and continuous components. A software component contains a stateful discrete behavior specification while a continuous component defines a quasi-continuous behavior specification based on differential equations. We use continuous components to represent the feedback controllers of the system that control the physical system. Their behavior is specified by control engineers in Simulink directly. Car

peer

peer

leader

leader

force curSpeed

NormalDriveController Fig. 1.

Enabled Subsystem

“A signal is a time varying quantity that has values at all points in time” [21]. It has a name, a data type, and a dimension, where the dimension is used for specifying arrays. Signals can be grouped into busses. A bus may contain signals of different types that are accessed by their name. We use busses for encoding messages; as we explain in Section IV. 1 http://www.mathworks.com/products/simulink

platoonSetup : PlatoonSetup [0..1]

leader : PlatoonLeader [0..1] refSpeed

follower : PlatoonFollow [0..1] refSpeed

refSpeed

follower

follower

refDist refDist

curSpeed

ctrl : DriveController [1] curDist

Legend:

Fig. 2. refSpeed

MechatronicUML

Discrete Port

Hybrid Port

torque

Continuous Port

MechatronicUML Component for a Car

Figure 2 shows an example of a structured component which is a simplified excerpt of the software architecture of a Car. It embeds four other components. The PlatoonSetup component implements the communication protocol for forming a platoon or for joining an existing platoon. The PlatoonLeader component implements the behavior of a platoon leader, e.g., for notifying followers about a braking maneuver. The PlatoonFollower component implements the functionality of being a follower, e.g., the automatic drive functionality and the communication with the platoon leader. Finally, the DriveController controls the speed of the car based on its current speed measured by a sensor and the reference speed at which the car should drive, it computes the torque which is to be applied by the engine. The DriveController, shown in Figure 3, is a structured

component as well. It embeds two continuous components NormalDriveController and DistanceDriveController. The NormalDriveController is used by the leader and by cars that do not drive in a platoon. The DistanceDriveController is used by followers in a platoon, because it considers the distance (measured by a distance sensor) to the preceding car while computing the torque. Since the controllers operate in a feedback loop, they automatically adjust the torque such that speed and distance remain constant.

car1 : Car

:peer

:peer

car2 : Car

ps1 / platoonSetup : PlatoonSetup

:peer :follower

fo1 / follower : PlatoonFollow

:peer

:follower :leader

ps1 / platoonSetup: PlatoonSetup

ld1 / leader: PlatoonLeader :leader

:refSpeed

:refDist

:refSpeed

:refSpeed

:refDist

:refSpeed

:curSpeed

drive / ctrl : DriveController

:torque

:curSpeed

drive / ctrl: DriveController

:torque

:curDist

DriveController

refSpeed

Fig. 4. Cars

refSpeed

normal_ctrl : NormalDriveController [0..1]

curSpeed

torque

torque

curSpeed refSpeed curSpeed refDist

refDist

curDist

curDist

Fig. 3.

distance_ctrl : DistanceDriveController [0..1]

Component Instance Configuration of a Platoon with two

torque

MechatronicUML Component for the DriveController

A component encapsulates its inner structure and behavior and allows interaction with other components only via its ports. The MechatronicUML component model distinguishes between discrete ports, continuous ports, and hybrid ports. Discrete ports may only be used for software components and execute a stateful, message-based communication protocol. In Figure 2, the port leader of PlatoonLeader is a discrete port that executes the communication protocol for interacting with followers. Continuous ports define the interface of the feedback controllers of the system. They emit or receive a signal value of a specified data type which has the same semantics as a signal in Simulink (cf. Section II). For instance, the DriveController receives the current speed from a sensor by its continuous curSpeed port. Hybrid ports are used at software components for interacting with the continuous components. In particular, they are used for receiving and setting values from/to controllers. refSpeed of PlatoonLeader is a hybrid port that is used for setting a new reference speed to the DriveController. We connect ports of components of the same level of hierarchy by assembly connectors and those of adjacent levels by delegation connectors.

Cardinalities define the minimum and maximum number of instances of a port or an embedded component. For embedded components, the cardinality is specified in square brackets. For ports, we use a cascaded border line if the port may be instantiated more than once, as it is the case for the port leader of a car. Since a platoon leader needs to communicate with many followers, we instantiate one additional instance of the port for each new follower [17]. The resulting port instances represent single-cast end-to-end connections between the cars using a wireless network. We assume that platoons only use a single lane of traffic without any non-platoon cars mixed in. In our model, the instances of the multi-port leader in a particular configuration are ordered in the same way as the followers in the convoy. In our example, we do not specify a fix upper bound for the number of instances of the leader port enabling platoons of arbitrary length in our MechatronicUML model. Each component specifies an initial configuration that defines the port instances and, in case of a structured component, the embedded component instances that will be created when the component is instantiated. The initial configuration of all components define the initial component instance configuration for the system. The car component in Figure 2 initially only contains an instance of the PlatoonSetup and an instance of the DriveController. The DriveController, in turn, initially contains one instance of the NormalDriveController.

In our component model, we distinguish between component types and component instances. The component types, denoted as components, are instantiated to component instances in a component instance configuration. A component instance configuration defines a concrete software architecture of a system. Components may be instantiated multiple times within a system. All components of the same type share the same behavior specification, but may be in different states at runtime.

The component instance configuration of a system can be modified at runtime by performing a reconfiguration. MechatronicUML supports adding and removing component instances, port instances, and connector instances. We specify reconfiguration operations in a rule-based fashion using so-called component story diagrams [20]. Component story diagrams are UML activity diagrams whose activity nodes are formally specified by domain-specific graph transformations [19]. In particular, we embed partial component instance configurations into the activity nodes and annotate the modification as shown in Figure 5.

Figure 4 shows a component instance configuration of a platoon consisting of two cars where car2 is the leader and car1 is a follower. As described before, the leader executes an instance of PlatoonLeader and uses the NormalDriveController as it can be inferred from the ports of the DriveController instance. The follower executes an instance of PlatoonFollow and uses the DistanceDriveController.

The component story diagram in Figure 5 specifies the reconfiguration of a car to become a follower in a platoon. The component instance on which the component story diagram is executed is denoted by this. Upon execution, the component story diagram searches for the DriveController in the component instance configuration of the car. Then, it creates an instance of the PlatoonFollow component

which is indicated by the «create» annotation. In addition, it creates an instance of the follower port for the car including the delegation to the follower port instance of the new PlatoonFollow instance. Further, the component story diagram calls another component story diagram named switchToDistanceCtrl on the DriveController for switching to the DistanceDriveController and connects the DriveController to PlatoonFollow by two assembly connectors.

1 0 2 3

car1 inBus fcn outBus

BusCreator

Car::becomeFollower() Create PlatoonFollow and trigger Controller

3

this «create» :follower

peer_recv peer port instance peer_net_addr peer_send peer_recv_net_addr follower_recv follower port instance follower_net_addr follower_send follower_recv_net_addr

2 «create»

:follower «create»

4

fo / follower : PlatoonFollow

0

CommunicationSwitch BusSelector

leader1_recv leader1_net_addr

leader port instance

leader1_send leader1_recv_net_addr peer_recv peer port instance peer_net_addr peer_send peer_recv_net_addr

car2 «create»

:refSpeed :refDist «create» :refSpeed :refDist

c / ctrl : DriveController switchToDistanceCtrl()

Fig. 5.

Component Story Diagram for Becoming a Follower

For realizing this car platoon example, we need, of course, further rules covering other aspects of selfadaptation. For enabling longer convoys, we need another rule for adding further followers to an existing platoon (cf. [17]). We may add further rules that perform reconfigurations for handling, for instance, changing environmental conditions or hardware failures in a system. We refer to [23] and [24] for more information on these topics. IV. Transforming Non-Adaptive MechatronicUML Models to Simulink In our previously published approach for transforming non-adaptive MechatronicUML Models to Simulink [15], we transform one component instance configuration into a Simulink model. In particular, we transform each component instance in the component instance configuration into a subsystem with the same name. In case of a structured component instance, we repeat that transformation recursively for the embedded component instance configuration. Figure 6 shows the result of transforming the component instance configuration in Figure 4 to Simulink. We obtain two subsystems for the two cars car1 and car2. These subsystems, in turn, contain subsystems for the embedded component instances, which are left out in the figure for better readability. Since Simulink provides no native support for handling asynchronous message-based communication, we implemented several helper blocks as described in [15] for handling such communication. One important helper block is the communication switch. It provides a functionality like an Ethernet switch and dispatches messages within one subsystem. Therefore, all assemblies between discrete ports are transformed to connections from and to the communication switch as shown in Figure 6. The communication

Fig. 6.

Non-Adaptive Subsystem in Simulink

switch is used for MIL simulation only and is intended to be replaced by the AUTOSAR Virtual Function Bus (VFB) later on. For realizing the message dispatching, each port of the MechatronicUML model receives a uniquely identifying network address in Simulink. We encode messages by a six-tuple consisting of a package id, the sender network address, the receiver network address, the message, an optional parameter, and a timestamp. If a message enters the communication switch, it is dispatched based on the receiver network address that is contained in the message. For realizing message-based communication, each port of MechatronicUML is transformed into a port structure consisting of three input ports and one output port in Simulink as shown in Figure 6. Considering the bidirectional port follower of car1 in Figure 4, we obtain the inputs follower recv, follower net addr, and follower recv net addr as well as the output follwer send. follower recv receives messages from the communication switch, follwer send sends messages to the communication switch. The input follower net addr defines the uniquely identifying network address of the port instance follower of car1, while follower recv net addr is the network address of the port instance to which the port instance is connected. We realize the assembly between follower of car1 and leader1 of car2 by setting the receiver network addresses. The port follower of car1 receives the receiver network address 3 which is the network address of leader1 of car1. By the same rule, leader1 receives the receiver network address 2. The peer ports receive a receiver network address 0 which indicates that they are not connected. V.

Approach for Transforming Reconfigurable MechatronicUML Models to Simulink

MechatronicUML supports the creation and deletion of component instances, port instances, and connector instances during runtime. Since Simulink does not permit that a simulation model changes during a simulation run, the Simulink model needs to contain all possible configurations a priori. Then, we need to switch between those

4

Computing Possible Configurations

Generate Simulink Model

Component Model 2

Component Story Diagrams

Fig. 7.

3x -> 2x

Determine Required Number of Instances

3

Discrete Software Model

Reconfiguration Behavior

1 Initial Top-Level Configuration

switch config case 1 platoonSetup = 1 leader = 0 follower = 0 case 2 ...

Controller Model

Plant Model

Encode Configurations

Overview of the Steps for Computing and Encoding Configurations in Simulink

configurations during a simulation run to emulate the selfadaptive behavior. Figure 7 provides an overview of the necessary steps for computing and encoding the configurations in Simulink. The input for the procedure are an initial top-level configuration of the system, the component model containing all components, and the component story diagrams defining reconfigurations of the components. The initial top-level configuration specifies which top-level components exist and how many instances of them should be executed. A top-level component is a component that is not embedded in a structured component. In our example, Car is the only top-level component and we define that two instances of Car should be executed in Simulink. In the first step, we compute all possible configurations of the MechatronicUML model based on the initial top-level configuration (cf. Section VI). Based on the configurations, we determine the required number of component instances and port instances that need to be created in Simulink (cf. Section VII). Then, we encode the configurations as well as the transitions between different configurations in Simulink (cf. Section VIII). In particular, we specify several helper blocks for realizing the reconfiguration. In Step 4, we generate a Simulink model file using the results of Steps 1 to 3. The generation of reconfigurable models extends the generation of non-adaptive models (cf. Section IV). We use a bidirectional model transformation language for creating an intermediate representation of the Simulink model file before generating the actual file using XPand [25]. For a detailed technical description of the generation process, we refer to our technical report [26]. The result of the procedure is a Simulink model that resembles the MechatronicUML model including the reconfigurations. That model can then be integrated with the controller models and the plant model for performing a MIL simulation. The plant model captures the physical aspects of the controlled system and the environment of the system. VI.

Computing Possible Configurations

In the first step, we apply a reachability analysis for computing all possible configurations of the system using our tool presented in [27]. The result of this step is a

reachability graph where each node is a component instance configuration and where transitions correspond to the application of a component story diagram. Thereby, we follow the general structure for self-adaptive systems illustrated in [28]. The inputs for the reachability analysis are the initial top-level configuration providing a number of cars, the component model, and the component story diagrams. Initially, each car is instantiated with its initial configuration. This component instance configuration is contained in the initial state config1 of the reachability graph as shown in Figure 8. config1

car1 : Car

:peer

:peer

car2 : Car

ps1 / platoonSetup : PlatoonSetup

:peer

ps1 / platoonSetup: PlatoonSetup

:peer

:refSpeed

:curSpeed

:refSpeed

drive / ctrl : DriveController

:curSpeed

:torque

startPlatoon()

splitPlatoon()

car1 : Car

:peer

:peer

drive / ctrl: DriveController

ps1 / platoonSetup : PlatoonSetup

:peer :follower

:peer

:follower :leader

ps1 / platoonSetup: PlatoonSetup

ld1 / leader: PlatoonLeader :leader

:refSpeed

:refDist

:refSpeed

:refSpeed

:refDist

:refSpeed

drive / ctrl : DriveController

config2

car2 : Car

fo1 / follower : PlatoonFollow

:curSpeed

:torque

:curSpeed

:torque

drive / ctrl: DriveController

:torque

:curDist

... Fig. 8.

Cutout of a Reachability Graph for Two Cars

Then, Car1 and Car2 may agree on executing the component story diagram startPlatoon() which invokes the component story diagrams for becoming a leader and becoming a follower (cf. Figure 5) on the two cars. The resulting component instance configuration, which has been shown in Figure 4, forms the second state of the reachability graph. We continue computing the reachability graph by repeatedly applying component story diagrams to the states

of the reachability graph. The computation terminates if no new configurations can be found.2 If a configuration that is already contained in the reachability graph is created a second time, the corresponding states are merged. In our example in Figure 8, if car1 and car2 split the platoon, the initial configuration is reached again. In addition, we respect the cardinalities of embedded components (cf. Section III), i.e., we may not call becomeFollower on car1 a second time because a Car component instance may contain at most one instance of PlatoonFollow. In our illustrative example, we obtain three configurations for each of the two cars: one for being the platoon leader, one for being a follower, and one for driving alone. VII.

Determine Required Number of Instances

In our component model, we specify lower and upper bounds for all ports of a component and for all embedded components of a structured component. Naively, we could just generate the maximum number of subsystems for each embedded component and the maximum number of ports. However, after computing the reachability graph in Step 1, we may check whether we actually need that number of embedded component instances and port instances by counting how many have actually been used in the computed configurations. In our example, we did not specify an upper bound for the number of instances of the leader port of a Car (cf. Section III). However, since we restrict ourselves to two cars in the initial top-level configuration, we can automatically set the upper bound for the multi-port to 1 for this particular export. VIII.

Encoding Configurations in Simulink

We realize reconfiguration in Simulink by implementing a set of helper blocks that encode the configurations that we computed in Step 1 (cf. Section VI). The helper blocks can change the currently instantiated component instances, port instances, and connector instances. In addition, they define an interface for setting a new configuration for a subsystem. In the following subsections, we illustrate how we create and destroy component instances (Section VIII-A), port instances including assemblies (Section VIII-B), and delegation instances (Section VIII-C) in Simulink. A. Component Instances We transform component instances of MechatronicUML to enabled subsystems with the same name in Simulink. An enabled subsystem has a control input which controls whether the subsystem will be executed or not. If a component instance is not instantiated in the current component instance configuration, we set a 0 to the control input of the corresponding subsystem. Otherwise, we set a 1 to the control input to enable the corresponding subsystem. 2 Please note that our reachability analysis is depth-limited to achieve termination even if the configuration space is unbounded. Then, the developer needs to revisit the MechatronicUML model.

config

platoonSetup fcn follower

platoonSetup

ctrl

leader

follower

leader

BlockControl

Fig. 9. BlockControl Block for Creating/Destroying Component Instances

Figure 9 shows a simplified subsystem that was generated for the Car component of Figure 2. We obtain one enabled subsystem for each embedded component and one additional BlockControl block. The BlockControl block is responsible for setting the control inputs of the enabled subsystems and, thus, for controlling which subsystem becomes enabled based on the current component instance configuration. If a an embedded component instance is instantiated in all configurations, we transform it into a normal subsystem as, e.g., the subsystem ctrl. Listing 1 shows the contents of the BlockControl of Car1. Listing 1. Contents of BlockControl of Car1 switch c o n f i g case 1 platoonSetup = 1 leader = 0 follower = 0 case 2 platoonSetup = 1 leader = 0 follower = 1 case . . . end

The BlockControl is implemented as an Embedded MATLAB Function using switch/case-statements to distinguish the configurations. If Car1 is in configuration 1 (cf. Figure 8), only the embedded component instances platoonSetup and ctrl are instantiated. Consequently, the BlockControl outputs 1 for platoonSetup, which enables the enabled subsystem, and 0 for follower and leader. ctrl is always enabled because it is a normal subsystem. If Car1 switches to configuration 1, the follower subsystem is enabled for instantiating the follower component instance. B. Port Instances and Assemblies For the transformation of port instances and assemblies, we need to distinguish between discrete messagebased ports and continuous signal-based ports. In Simulink, we emulate instantiating and deleting assemblies and their adjacent port instances by setting new receiver network addresses to the ports. As an example, consider the assembly between the leader port instance of car2 and the follower port instance of car1 in Figure 4. Initially, the two cars will not be in platoon mode and, therefore, the assembly is not present. We realize this situation by setting 0 as the receiver network address for both ports in Simulink. We create the assembly by giving the leader1 port instance of car2 the receiver network address 2 (which is the network address of follower of car1).

In addition, we set the receiver network address of follower of car1 to 3. Then, messages sent by follower of car1 will be dispatched to leader1 of car2 by the communication switch. For destroying the assembly, we set 0 as the receiver network address, again, which causes both ports to be silent.

config

fcn ctrl_refSpeed .

refSpeed

follower_recv follower_net_addr follower_recv_net_addr

follower_send

follower

leader

PortControl 1

0

2 *,0

Multiport Switch

2

refSpeed

refSpeed

ctrl

Fig. 11. PortControl Block for Creating/Destroying Assemblies between Continuous and Hybrid Ports

car1 inBus fcn outBus config

car1_follower fcn . car2_leader1

Bus Creator

CommunicationSwitch

Bus Selector

PortControl 3

leader1_recv leader1_net_addr leader1_recv_net_addr

leader1_send

car2

Fig. 10. PortControl Block for Creating/Destroying Assemblies between Discrete Ports

We use the PortControl block shown in Figure 10 for setting the receiver network addresses of all discrete port instances based on the current configuration. Listing 2 shows the contents of the PortControl of the top-level subsystem. Listing 2. Contents of PortControl of the Top-Level Configuration switch c o n f i g case 1 car1 follower = 0 car2 leader1 = 0 case 2 car1 follower = 3 car2 leader1 = 2 case . . . end

In configuration 1, the two cars are not in platoon mode and, therefore, they are not connected. As a consequence, PortControl sets the receiver network address for both port instances to 0 which disables them. In configuration 2, the port instance follower of Car1 is connected to the port instance leader1 of Car2. Therefore, PortControl sets the receiver network address of follower of Car1 to 3 and the receiver network address of leader1 of Car2 to 2.

leader is propagated to the output of the Multiport Switch. If we apply a 2 to the control input, refSpeed of follower is propagated. In any other case, the default input is propagated to the output, which is 0 in our example. We use the PortControl block, again, for setting the control input of the Multiport Switch for activating and deactivating the connections based on the current configuration. The PortControl of Car is encode analogously to the PortControl of the top-level configuration in Listing 2. C. Delegations For transforming delegations, we need to distinguish between discrete ports and continuous ports, again. At runtime, we can reconfigure delegations such that a port instance of a structured component instance is delegated to a different port instance of an embedded component instance. For discrete ports, we require that they receive uniquely identifying network addresses (cf. Section IV). When using the address of port leader1 of the embedded subsystem leader in Car2 for the communication between the two cars, changing a delegation becomes visible to Car1. That violates the desired encapsulation of components. Therefore, we use a hierarchical addressing scheme based on network address translation (NAT, [29]) where network addresses are uniquely identifying only within one subsystem. Then, port instances of structured component instances serve as proxies and translate between the network address visible to the outside world and the network address of the delegated port.

For continuous and hybrid ports, we realize reconfiguration differently, because these ports directly specify Simulink signal values. In our example in Figure 4, the refSpeed for the DriveController is either provided by the component instance ld1 if the car is the platoon leader or by the component instance fo1 if the car is a follower. Thus, on the type level (cf. Figure 2), the port refSpeed of DriveController has two incoming assemblies where at most one of them may be instantiated during runtime.

In our example in Figure 10, the port leader1 of car1 is delegated to the embedded component leader (cf. Figure 2). If car2 sends a message to the port leader1 of car1, it is opaque for car2 whether this port is delegated or not and to which embedded component it is delegated. Consequently, each port instance of a structured component receives a network address which is used by the communication partner. That address is then translated by so-called address translation blocks to the internal address of the delegated port, as shown in Figure 12.

We specify reconfiguration of such assemblies using the Multiport Switch block of Simulink as shown in Figure 11. The Multiport Switch has one control input, n data inputs, and one default data input. We generate one data input for each incoming assembly which results in two data inputs, labeled with 1 and 2, in our example. By applying a 1 to the control input, the value provided by refSpeed of

Figure 12 shows how the port leader1 of car1 is delegated to the port leader1 of the embedded subsystem leader. If a message is sent to leader1 of car1, it first enters the addressTranslationIN subsystem which knows the network address of the port leader1 of car1. The address translation then replaces the receiver network address in the message by the address of the receiving port and

config

config 1

inBus

leader1_recv 2

leader1_ net_addr

3

net_addr

addressTranslationIN

1 config

fcn leader_leader1 .

PortControl

leader_leader1 fcn outBus

fcn leader_leader1 .

recv_net_addr

leader1_recv_ net_addr

leader1_recv leader1_net_addr leader1_recv_net_addr

1

leader1_ send

addressTranslationOUT

leader1_send

For realizing reconfiguration of such delegation, we implemented the DelegationSwitch subsystem as shown in Figure 13. fcn deleg_refSpeed .

config

refSpeed

PortControl

leader

normal_ctrl

control

Fig. 12. AddressTranslation Blocks for Creating/Destroying Delegations for Discrete Ports

forwards it via the corresponding out-port. There exists one output at the address translation for each outgoing delegation connector that was specified in the MechatronicUML component. The corresponding source code for the addressTranslationIN block is shown in Listing 3. Listing 3. Contents of the addressTranlationIN Block for leader1 switch c o n f i g case 1 leader leader1 = 0 case 2 l e a d e r l e a d e r 1 = inBus leader leader1 . receiver net addr = 1 case . . . end

In configuration 1, the delegation is not instantiated and, therefore, the addressTranslationIN returns 0. In configuration 2, the delegation is instantiated. Therefore, addressTranslationIN outputs the message received through the inBus and replaces the receiver net addr in the message by the net addr of the port leader1 of leader. If a message is sent by the embedded subsystem leader, that message enters the addressTranslationOUT subsystem. The addressTranslationOUT subsystem replaces the receiver network address by the leader1 recv net addr which is the receiver network address of leader1 of car1. The corresponding source code for the addressTranslationOUT block is shown in Listing 4.

1

value

refSpeed

normal_ctrl_refSpeed distance_ctrl_refSpeed

DelegationSwitch

refSpeed

distance_ctrl

Fig. 13. DelegationSwitch Block for Creating/Destroying Delegations for Continuous and Hybrid In-Ports.

The subsystem has two inputs and one output for each delegation that is specified in the MechatronicUML component. In this case, we have two delegations, one for each controller. Based on the control input, the value received via refSpeed of DriveController is either propagated to normal ctrl (control == 1) or to distance ctrl (control == 2) using an Embedded MATLAB function. By applying a 0 to the control input, the delegation is destroyed. The out-port torque of DriveController is always provided by one of the two controllers depending on the current configuration. In this case, changing the delegation always results from exchanging the controller. If a controller is exchanged instantaneously by another controller, a jump may occur at the output torque of DriveController which may cause damage to the physical system. In previous publications, fading functions [30] and flat switching functions [31] have been introduced for solving that problem. Then, the output of the destroyed controller is faded to the output of the created controller in a controlled fashion that guarantees stability of the system. config

fcn

deleg_torque .

PortControl

Listing 4. Contents of the addressTranlationOUT Block for leader1 switch c o n f i g case 1 outBus = 0 ; case 2 outBus = l e a d e r l e a d e r 1 ; outBus . r e c e i v e r n e t a d d r = r e c v n e t a d d r ; case . . . end

Since the delegation is not instantiated in configuration 1, the addressTranslationOUT block writes 0 to the outBus in that case. In configuration 2, the port leader1 of subsystem leader is delegated and, thus, this input is written to the outBus. In addition, the receiver net addr of the message on the bus is replaced by the receiver net addr that was set for the port leader1 of car1 (cf. Figure 10). For continuous ports, we need to distinguish two cases: delegations of an in-port and delegations to an out-port. Consider the DriveController in Figure 3 as an example. The port refSpeed is either delegated to normal ctrl or to distance ctrl depending on the current configuration.

control torque

normal_ctrl

normal_ctrl_torque distance_ctrl_torque

torque

1

torque

Fading Function

torque

distance_ctrl

Fig. 14. Fading Block for Creating/Destroying Delegations for Continuous and Hybrid Out-Ports.

Figure 14 shows the resulting Simulink block structure. The torque output ports of normal ctrl and distance ctrl are both connected to the Fading Function. The control input of the Fading Function determines which value has to be used. If the value of control changes, a fading is performed. The specification of a fading function is subject to control engineers and depends on the concrete controllers to be exchanged. Due to space limitations, we will not provide details of the fading functions in this paper and refer to the given literature [30], [31].

IX.

Related Work

Related work stems from three areas of research: specifying reconfiguration in Simulink models, adding reconfiguration capabilities to AUTOSAR-based systems, and specifying reconfiguration in other tools for MIL simulation, namely Dymola/Modelica. We discuss related approaches in this order. Cancare [8] and Paiz et al. [7] describe approaches for simulating reconfigurable FPGA-boards in Simulink. They only switch between implementation variants of the same block using switches, but provide no means for messagebased communication and adding/removing components from the simulation. Schulze et al. [32] provide a concept for product line support in Simulink where a concrete variant is configured via control signals. This is comparable to our block control blocks, but their approach does not permit changing the configuration at run-time. The Quanser Real-Time Control Software (QUARC, [33]) provides special blocks for switching between two Simulink models during run-time. They stop the simulation, transfer variables, and restart the simulation on the target model. In contrast to our approach, this approach does not permit to simulate the transient phase where the reconfiguration is executed. In addition, using self-defined blocks hinders the use of standard code generators. Becker et al. [9] define an extension for AUTOSAR to support architectural reconfiguration which makes it probably the closest to our approach. In their approach, a developer needs to specify all configurations of system manually including an automaton defining switches between the configurations. Then, they generate an AUTOSAR system containing all variants including code for a so-called StateManager and a RoutingComponent. The StateManager controls the current configuration, while the RoutingComponent redirects signals. In contrast to their approach, we use a rule-based approach for specifying reconfiguration, which is more efficient if the system configurations are large showing only little differences. In addition, their approach does not allow for early validation using MIL simulations. Berger and Tichy [10] extend the AUTOSAR watchdogs towards transactional reconfigurations with rollback support, but they do not consider simulation of the system. Zeller et al. [34], [11] and Klobedanz et al. [35] provide reconfiguration of networked embedded systems by reallocating of software components to new ECUs at run-time. Their approaches can be used for technically realizing reconfiguration, but not for MIL-simulations in Simulink. Trumler et al. [36] and Feng et al. [37] propose middlewares for automotive systems supporting runtime reconfiguration by migrating tasks (Trumler et al.) or switching between different component implementations (Feng et al.). Their middlewares are supposed to replace the AUTOSAR RunTime Environment (RTE), but do not support MIL simulation. Modelica [12] with the commercial simulator Dymola3 is a competitor of MATLAB/Simulink for the specification and simulation of technical systems. While Modelica does not support runtime reconfiguration, there exist two 3 http://www.3ds.com/de/products/catia/portfolio/dymola

extensions of Modelica, Mosilab [13] and Sol [14], that support reconfiguration. However, both approaches rely on own simulators because their extensions are not supported by Dymola. That, in turn, hinders using standard code generator for generating production code for the system.

X.

Conclusions

In this paper, we presented an approach for realizing MIL simulations of self-adaptive systems in MATLAB/Simulink extending our approach of [15]. Based on a model of the system in our language MechatronicUML, we automatically derive all possible system configurations based on the specification of the reconfiguration behavior. We generate an encoding of these configurations by implementing several helper blocks in Simulink. In particular, we use enabled subsystems for creating/deleting component instances and a communication switch implementation for creating/deleting ports and assembly connectors. Finally, we support creating/deleting delegation connectors by address translation blocks. By using only native blocks of Simulink and Embedded MATLAB Functions, we enable using standard off-the-shelf code generators for generating production code for the target system. In contrast to MATLAB/Simulink, MechatronicUML enables developers of self-adaptive systems to natively specify the communication and reconfiguration behavior. That significantly reduces the complexity of the reconfiguration model and, therefore, helps improving the quality of the software. We used this approach successfully for creating models for the RailCab system4 , a modern railway transportation system with autonomous trains having complex self-adaptive behavior. In future work, we plan to integrate our approach with the transactional reconfiguration approach for MechatronicUML presented in [23]. This approach guarantees that all reconfigurations are executed safely and only produce a consistent component instance configuration. In addition, it ensures that conflicting adaptation requests are properly serialized. Further, we plan to investigate whether our approach can be combined with the approach by Becker et al. [9] such that the generated Simulink model may be used as an implementation of their reconfigurable AUTOSAR system. Finally, we want to further evaluate our approach in an industrial case study.

Acknowledgment This work was partially developed in the project “Simulationsgest¨ utzter Entwurf f¨ ur Elektrofahrzeuge” (Simulation-based Design of Electrical Vehicles) which is funded by the European Union and the state of Northrhine-Westphalia (grant No. 64.65.69-EM-1008A). We thank Andrey Pines for laying ground to this paper as part of his Bachelor’s Thesis. We thank Matthias Becker and Matthias Meyer for useful comments. 4 http://www.railcab.de

References [1]

[2]

[3]

[4]

[5]

[6]

[7]

[8]

[9]

[10]

[11]

[12] [13]

[14]

[15]

[16]

[17]

[18]

L. Stockmann, D. Holler, and D. Spenneberg, “Early simulation and testing of virtual ECUs for electric vehicles,” in International Battery, Hybrid and Fuel Cell Electric Vehicle Symposium (EVS26), 2012. S. F¨ urst, J. M¨ ossinger, S. Bunzel, T. Weber, F. KirschkeBiller, P. Heitk¨ amper, G. Kinkelin, K. Nishikawa, and K. Lange, “AUTOSAR – a worldwide standard is on the road,” in Proc. of the 14th Int. VDI Congress Electronic Systems for Vehicles, 2009. M. Shaw, ““self-healing”: softening precision to avoid brittleness,” in Proc. of the 1st Workshop on Self-healing Systems, ser. WOSS ’02. ACM, 2002, pp. 111–114. T. Robinson, E. Chan, and E. Coelingh, “Operating platoons on public motorways: An introduction to the sartre platooning programme,” in 17th World Congress on Intelligent Transport Systems, 2010. B. H. C. Cheng, R. de Lemos, H. Giese, P. Inverardi, and J. Magee et al., “Software engineering for self-adaptive systems: A research roadmap,” in Software Engineering for Self-Adaptive Systems, ser. LNCS, vol. 5525. Springer, 2009, pp. 1–26. P. Oreizy, N. Medvidovic, and R. N. Taylor, “Architecturebased runtime software evolution,” in ICSE ’98: Proc. of the 20th Int. Conference on Software Engineering. IEEE Computer Society, 1998, pp. 177–186. C. Paiz, B. Keltelhoit, and M. Porrmann, “A design framework for fpga-based dynamically reconfigurable digital controllers,” in IEEE Int. Symposium on Circuits and Systems, 2007, ser. ISCAS 2007, 2007, pp. 3708–3711. F. Cancare, “Modeling methodologies for dynamic reconfigurable systems,” Master’s thesis, University of Illinois at Chicago, 2008. B. Becker, H. Giese, S. Neumann, M. Schenck, and A. Treffer, “Model-based extension of autosar for architectural online reconfiguration,” in Models in Software Engineering, ser. LNCS, S. Ghosh, Ed. Springer, 2010, vol. 6002, pp. 83–97. C. Berger and M. Tichy, “Towards transactional self-adaption for autosar on the example of a collision detection system,” in Proceedings of the 10th Workshop Automotive Software Engineering, I. Schaefer and M. Wille, Eds. GI e.V., 2012. M. Zeller and C. Prehofer, “Timing constraints for runtime adaptation in real-time, networked embedded systems,” in 7th Int. Symposium on Software Engineering for Adaptive and SelfManaging Systems, 2012, pp. 73–82. P. Fritzson, Principles of Object-Oriented Modeling and Simulation with Modelica 2.1. John Wiley & Sons, 2004. G. Zauner, F. Judex, and P. Schwarz, “Classical and statechartbased modeling of state events and of structural changes in the modelica simulator mosilab,” Simulation News Europe (SNE), vol. 18, no. 2, pp. 17–23, 2008. D. Zimmer, “Enhancing modelica towards variable structure systems,” Simulation News Europe, vol. 17, no. 2, pp. 23–28, 2007. C. Heinzemann, U. Pohlmann, J. Rieke, W. Sch¨ afer, O. Sudmann, and M. Tichy, “Generating simulink and stateflow models from software specifications,” in Proc. of the 12th Int. Design Conference (DESIGN 2012), 2012, pp. 475–484. H. Giese, M. Tichy, S. Burmester, W. Sch¨ afer, and S. Flake, “Towards the compositional verification of real-time uml designs,” in Proc. of the 11th Int. Symposium on Foundations of Software Engineering (FSE ’03). ACM Press, 2003, pp. 38–47. T. Eckardt, C. Heinzemann, S. Henkler, M. Hirsch, C. Priesterjahn, and W. Sch¨ afer, “Modeling and verifying dynamic communication structures based on graph transformations,” Computer Science - Research and Development, vol. 28, no. 1, pp. 3–22, 2013, published online July 2011. S. Becker et al., “The mechatronicuml design method – process, syntax, and semantics,” Software Engineering Group, Heinz Nixdorf Institute, University of Paderborn, Tech. Rep. tr-ri-12326, 2012.

[19]

[20]

[21] [22] [23]

[24]

[25] [26]

[27]

[28]

[29]

[30]

[31]

[32]

[33]

[34]

[35]

[36]

[37]

G. Rozenberg, Handbook of graph grammars and computing by graph transformation: volume I. foundations. World Scientific Publishing Co., Inc., 1997. M. Tichy, S. Henkler, J. Holtmann, and S. Oberth¨ ur, “Component story diagrams: A transformation language for component structures in mechatronic systems,” in Postproc. of the 4th Workshop on Object-oriented Modeling of Embedded Real-Time Systems (OMER 4), 2008, pp. 27–39. MathWorks, http://www.mathworks.de/de/help/simulink/ug/ signal-basics.html. C. Szyperski, Component Software: Beyond Object-Oriented Programming. Addison-Wesley, 1998. C. Heinzemann and S. Becker, “Executing reconfigurations in hierarchical component architectures,” in Proc. of the 16th Int. Sym. on Component based software engineering. ACM, 2013. C. Priesterjahn, D. Steenken, and M. Tichy, “Timed hazard analysis of self-healing systems,” in Assurances for SelfAdaptive Systems, ser. LNCS, J. C´ amara, R. de Lemos, C. Ghezzi, and A. Lopes, Eds. Springer, 2013, vol. 7740, pp. 112–151. Eclipse Foundation, http://www.eclipse.org/modeling/m2t/. C. Heinzemann, J. Rieke, J. Br¨ oggelwirth, A. Pines, and A. Volk, “Translating MechatronicUML models to MATLAB/Simulink and Stateflow,” Software Engineering Group, University of Paderborn, Tech. Rep. tr-ri-13-330, 2013. C. Heinzemann, J. Suck, and T. Eckardt, “Reachability analysis on timed graph transformation systems,” Electronic Communications of the EASST, vol. 32, 2010. J. Zhang and B. H. C. Cheng, “Model-based development of dynamically adaptive software,” in ICSE 06: Proc. of the 28th Int. Conf. on Software engineering. ACM, 2006, pp. 371–380. Network Working Group, RFC2663 - IP Network Address Translator (NAT) Terminology and Considerations, 1999. [Online]. Available: http://tools.ietf.org/html/rfc2663 S. Burmester, H. Giese, and O. Oberschelp, “Hybrid UML components for the design of complex self-optimizing mechatronic systems,” in Informatics in Control, Automation and Robotics I, J. Braz, H. Ara´ ujo, A. Vieira, and B. Encarnacao, Eds. Springer, 2006. S. Osmic, E. M¨ unch, A. Trachtler, S. Henkler, W. Sch¨ afer, H. Giese, and M. Hirsch, “Safe online-reconfiguration of selfoptimzing mechatronic systems,” in Selbstoptimierende mechatronische Systeme: Die Zukunft gestalten. 7. Int. Heinz Nixdorf Symposium f¨ ur industrielle Informationstechnik, J. Gausemeier, F. J. Rammig, and W. Sch¨ afer, Eds., 2008, pp. 411–426. M. Schulze, J. Weiland, and D. Beuche, “Automotive modeldriven development and the challenge of variability,” in Proc. of the 16th Int. Software Product Line Conference - Volume 1, ser. SPLC ’12. ACM, 2012, pp. 207–214. “Quanser Real-Time Control Software (QUARC),” http://www.quarcservice.com/ReleaseNotes/files/dynamic reconfiguration.html, accessed Online: May, 2nd, 2013. M. Zeller, C. Prehofer, G. Weiss, D. Eilers, and R. Knorr, “Towards self-adaptation in real-time, networked systems: Efficient solving of system constraints for automotive embedded systems,” in 5th IEEE Int. Conference on Self-Adaptive and Self-Organizing Systems (SASO), 2011, pp. 79–88. K. Klobedanz, A. Koenig, W. Mueller, and A. Rettberg, “Selfreconfiguration for fault-tolerant flexray networks,” in 14th IEEE Int. Symp. on Object/Component/Service-Oriented RealTime Distributed Computing Workshops, 2011, pp. 207–216. W. Trumler, M. Helbig, A. Pietzowski, B. Satzger, and T. Ungerer, “Self-configuration and self-healing in AUTOSAR,” in Proceedings of the 14th Asia Pacific Automotive Engineering Conference (APAC-14), 2007, pp. 25–36. L. Feng, D. Chen, and M. Torngren, “Self configuration of dependent tasks for dynamically reconfigurable automotive embedded systems,” in 47th IEEE Conference on Decision and Control (CDC 2008), 2008, pp. 3737–3742.