In the following, we describe our concept for testing the correct integration of discrete and continuous components in a self-adaptive mechatronic system based on MIL simulation. Our concept requires sofware engineers and control engineers to collaboratively perform several steps that are summarized in the process shown in Figure 6.4. This process specifies Step S5
of our overview process in Figure 1.3 on Page 8 in more detail. In the following, we refer to the software engineers and the control engineers simply as the developers if they work collaboratively on a process step.
Translate MechatronicUML Model to MATLAB/ Simulink and Stateflow platform-independent SW model MATLAB/Simulink and Stateflow Model integrated platform-independent model S5.1
Define Scenarios for MIL Simulation
test scenarios MIL simulation model Integrate Controller + Environment Model S5.3 S5.2 Perform Simulation in Simulink S5.4 testable MIL simulation model controller + environment model
process step artefact
Legend
parallel execution
Figure 6.4: Process for Performing a MIL Simulation of a MECHATRONICUML Model in Simulink and Stateflow
The software engineer starts in Step S5.1by translating the verified MECHATRONICUML
model into a MATLAB/Simulink and Stateflow model. The next two process steps may be performed in parallel. In Step S5.2, the developers need to integrate the controller and
environment models into the Simulink model that resulted from Step S5.1. These models
have been specified directly in Simulink by the control engineers. At the same time, the developers need to define scenarios for the MIL simulation in Step S5.3. These scenarios are
test cases that define a particular environmental situation and generate suitable stimuli for the MIL simulation model. In our RailCab example, we may, for example, define a scenario where two RailCabs start a convoy at a switch. In this case, the scenario defines where the RailCabs will start to drive on the track system and it configures the operation strategy such that the RailCabs will start a convoy. Based on the MIL simulation model and the test scenarios, the developers may perform the MIL simulation in Simulink in Step S5.4.
In the remainder of this chapter, we will focus on Step S5.1 and derive a concept for au-
tomatizing the translation from MECHATRONICUML models to MATLAB/Simulink and
Stateflow models. Steps S5.2to S5.4 need to be carried out manually by the developers. In
particular, deriving a set of scenarios from requirements is beyond the scope of this thesis. Figure 6.5 summarizes the algorithm for translating a MECHATRONICUML model into
a MATLAB/Simulink model. The inputs are the (reconfigurable) components that are used in the MECHATRONICUML model and an initial CIC of the system. The latter defines how many component instances exist on the system level, e.g., how many RailCabs should be simulated. The output is a Simulink and Stateflow model that shows the same behavior as the MECHATRONICUML model.
The algorithm in Figure 6.5 consists of two phases. The first phase is defined by the expansion region and consists of Steps 1 to 4. These steps explicitly enumerate all possi- ble configurations for each component that is used in the MECHATRONICUML model and encode these configurations. These steps need to be executed separately for each (recon- figurable) component. The second phase consists of Steps 5 to 7. These steps create the simulation model in Simulink and Stateflow and are executed once after the first phase has been finished.
In the first phase, we start in Step 1 by computing the possible configurations for each reconfigurable component based on the CSDs contained in its reconfiguration controller. If a component is not reconfigurable, it only has one possible configuration at runtime. There-
Algorithm: Translate MechatronicUML Model to MATLAB/Simulink and Stateflow (S5.1)
«parallel»
1. Compute Possible Configurations
2. Create Integrated CIC for Component
3. Generate MATLAB- specific Reconfiguration
Controller
4. Encode Configurations and Generate Control
Signals (Reconfigurable) Components Initial system CIC 5. Create Integrated System CIC 6. Translate Integrated System CIC to Simulink
Block Diagram 7. Translate RTSCs to Stateflow Charts Simulink/ Stateflow Model
Integrated Component CICs
... ... Step ... Artefact Expansion Region Inputs / Outputs Initial Node Final Node Control Flow Data Flow Legend
Figure 6.5: UML Activity Diagram Defining the Algorithm for Translating a MECHATRON-
ICUML Model into a MATLAB/Simulink and Stateflow Model
after, we create a so-called integrated CIC for the component that contains the superposition of all possible configurations that were computed in Step 1. Based on this, we generate a MATLAB-specific reconfiguration controller in Step 3. The MATLAB-specific reconfigura- tion controller contains an additional component for encoding the model@runtime as given by the integrated CIC. The MATLAB-specific reconfiguration controller enables to execute reconfigurations using control signals that are computed in Step 4. The result of this phase is one integrated CIC for each component of the MECHATRONICUML model.
In the second phase, we create the Simulink and Stateflow models. Therefore, we use the integrated CICs in Step 5 for generating an integrated CIC for the overall system based on the initial system CIC. The result is a MECHATRONICUML model that (a) contains all possible configurations that the system may use at runtime and that (b) contains an explicit encoding of the model@runtime including control signals for switching between the encoded config- urations. In Step 6, we translate the integrated system CIC to a Simulink block diagram. Thereby, we generate additional helper constructs for emulating message-based communica- tion. In Step 7, we translate the RTSCs of the component instances in the integrated system CIC to Stateflow charts.
In Figure 6.5, we highlighted Steps 6 and 7 with different color because they may be used without prior execution of Steps 1 to 5 for translating a MECHATRONICUML model
not employing runtime reconfiguration to MATLAB/Simulink. We address this use case in detail in our technical reports [HRB+13, HRB+14].
In the following, we start in Section 6.3 by describing the translation of a CIC to MAT- LAB/Simulink (Step 6). Thereafter, Section 6.4 describes the translation of RTSCs to State- flow charts (Step 7). We describe these steps first because this translation determines how we need to encode configurations and which control signals we require for switching between configurations. Finally, Section 6.5 describes Steps 1 to 5 of our algorithm in detail and ex- plains how the MATLAB-specific reconfiguration controller is integrated into the Simulink block diagram.