CUADRO 3 VARIACIÓN DE ESCAÑOS UNINOMINALES LA PAZ N° Circunscripciones

In this chapter, we introduce a consolidated component model for MECHATRONICUML that enables to specify software architectures for self-adaptive mechatronic systems. Thereby, our component model primarily addresses the reflective operator of the OCM reference architecture but also includes the interface to the feedback controllers on the controller level. Therefore, it combines and enhances two existing component mod- els for MECHATRONICUML that have been created by Burmester, Giese, and Hirsch [GTB+03, GBSO04, BGO06, HHG08, GS13] as well as Tichy [THHO08, Tic09]. In a little more detail, we use the necessary distinction of discrete atomic components and continuous atomic components representing feedback controllers from Burmester and Giese [GBSO04, BGO06]. In addition, we use the specification of structured com- ponents by means of component parts from Tichy [Tic09]. Compared to the previ- ous component models, our new component model guarantees component encapsula- tion, enforces a separation of concerns between functional and reconfiguration behav- ior, and improves semiotic clarity [Moo09] of the concrete syntax. In our component model, we use CSDs [THHO08, Tic09] for specifying reconfigurations of components because they enable for a more concise specification compared to hybrid reconfigura- tion charts [GBSO04, BGO06]. Furthermore, we introduce a concept for instantiating RTCPs between AMS that are not yet connected with each other. Finally, we defined

component SDDs that enable to specify architectural constraints and component proper- ties based on the software architecture.

We underpin the suitability of our component model for specifying software architec- tures of self-adaptive mechatronic systems by providing a software architecture of the RailCab system (cf. Section 1.1) focussing on the convoy mode. Our example includes the component definitions and the necessary CSDs for realizing RailCab convoys. Ad- ditional CICs and CSDs of the example scenario are given in Appendix A. We use this example as a basis for illustrating the further contributions of this thesis in the subse- quent chapters.

4 Transactional Execution of Hierarchical

Reconfigurations

Reconfigurations in a hierarchical component model often require the reconfiguration of several components that are located on different levels of hierarchy. As an example, the reconfiguration of a structured component instance may require the upfront reconfigura- tion of one or more of its children as it has been shown in the example of Figure 3.11. In this example, creating the instancemcofMemberControlrequires to reconfigure the instances ofOperationStrategyandVelocityControllerfirst. Then, the port instances created by these reconfigurations are connected byRailCabDriveControl. In general, we distin- guish two use cases for such reconfigurations.

In Use Case 1, an embedded component instance, in the following referred to as child, detects a situation that requires a reconfiguration that it cannot handle by itself. In our ex- ample in Figure 3.6, theOperationStrategycomponent negotiates that the RailCab enters a convoy, but it does not know how to do this itself. Thus, it needs to send a request to the embedding structured component instance of typeRailCabDriveControlto handle that situation and to execute the necessary reconfiguration. We will refer to the embedding structured component instance as parent in the following.

In Use Case 2, a structured component instance executes a reconfiguration that requires the reconfiguration of one or more of its children. In our example, becoming a member of a convoy requires a reconfiguration of theRailCabDriveControl(cf. Figure A.31). Exe- cuting this reconfiguration, however, requires that theOperationStrategychanges its port instances and that theVelocityControllerswitches to theConvoyDrivecomponent instance (cf. Figure 3.12). Therefore,RailCabDriveControlneeds to trigger the corresponding re- configurations on its children.

For both use cases, executing such reconfigurations safely demands that all component instances, which are required to reconfigure, perform their reconfiguration in a coordi- nated way. The necessary conditions for executing a hierarchical reconfiguration safely are given by the ACI-properties (atomicity, consistency, and isolation) of database sys- tems [BHG87, LLC10] and a correct timing. Atomicity requires that either all or no component instances, which need to reconfigure, execute their reconfiguration. If re- configurations are only executed partially, the system is usually unsafe. Consistency requires that any component instance has a valid architecture before and after each re- configuration. Isolation ensures that reconfigurations do not interfere with each other. Interference of reconfigurations results in invalid architectures. A correct timing de- mands that if a hard deadline for executing a reconfiguration exists, the system needs to make sure that it meets the deadline before starting to reconfigure. For the remainder, we refer to these properties as ACI-T properties. If a reconfiguration is executed according to ACI-T properties, we denote this as transactional execution.

For guaranteeing ACI-T properties for a distributed execution of reconfigurations, we provide an approach that adapts the 2-phase commit protocol for distributed database systems [BHG87, ch. 7] to the domain of mechatronic systems. In accordance to the 2-phase-commit protocol, a structured component instance asks all children that are re- quired to reconfigure whether they can execute the required reconfiguration. If all chil- dren confirm and if the reconfiguration can be finished in time, the children are notified to execute their reconfiguration. Additionally, we need to check whether the reconfigu- ration can be finished in time, which is not part of the original 2-phase-commit protocol.

Figure 4.1 summarizes our process for specifying reconfigurations based on our vari- ant of the 2-phase-commit protocol [HSST13]. This process specifies Step S4 of our overview process in Figure 1.3 on Page 25 in more detail. In the first Step S4.1, the developer specifies the reconfiguration rules using CSDs as introduced in Section 3.3. Thereafter, the developer creates a declarative, table-based specification of hierarchical reconfigurations in Step S4.2. This specification defines in which situation which CSD is to be executed, but it relieves the developer from specifying how the reconfigura- tion is carried out [HB13]. Then, we automatically generate an operational behavior specification based on RTSCs from the declarative table-based specification in Step S4.3. The operational behavior specification additionally specifies how reconfigurations are executed based on the 2-phase-commit protocol. In Step S4.4, the developer specifies architectural invariants based on component SDDs (cf. Section 3.5) that define the set of valid configurations for instances of a component. In Step S4.5, we use the component SDDs as well as the generated RTSCs that form the operational behavior specification for verifying that the reconfiguration specification fulfills ACI-T properties.

Specify Architectural Invariants (Sect. 3.5) Specify Reconfiguration Rules (Sect. 3.3) Specify Declarative Reconfiguration Model (Sect. 4.3) ACI-T properties fulfilled ACI-T properties not fulfilled

S4.4

S4.2

S4.1

Verify Behavior for ACI-T Properties (Sect. 4.5) S4.5 reconfiguration behavior component model Generate Operational Behavior Specification (Sect. 4.4) _S 4.3

process step conditional execution artefact

Legend

Figure 4.1: Process for Specifying Reconfiguration Behavior (cf. [HSST13])

In the remainder of this section, we first introduce the MECHATRONICUML reconfigu- ration controller with its constituent elements that contains our declarative, table-based reconfiguration model (Section 4.1). Thereafter, we explain how reconfigurations are executed with respect two the 2-phase-commit protocol (Section 4.2). Section 4.3 de- fines how we specify these reconfigurations declaratively based on tables in our recon- figuration controller. This specification is the basis for generating operational behavior models as described in Section 4.4. Section 4.5 describes our approach for verifying ACI-T properties for the reconfiguration specification for guaranteeing its safety. We describe our implementation of the hierarchical reconfiguration approach in Section 4.6 and discuss the assumptions and limitations of our approach in Section 4.7. Section 4.8

presents related work regarding transactional execution of reconfigurations before we summarize the contributions of this chapter in Section 4.9.

4.1 MechatronicUML Reconfiguration Controller

In the MECHATRONICUML component model, a developer defines a set of CSDs that

specify the possible reconfigurations of a reconfigurable component. This does not en- able to specify in which situation which reconfiguration is to be executed. In addition, the MECHATRONICUML component model as introduced in Chapter 3 does not offer means to execute a reconfiguration hierarchically according to ACI-T properties while preserving component encapsulation.

As a solution, we syntactically extend each reconfigurable discrete or hybrid compo- nent with a dedicated reconfiguration controller that is inspired by the reconfiguration controller of the Fractal component model [BCL+06, BHR09]. Our reconfiguration con- troller as shown in Figure 4.2 introduces two syntactic elements, namely a manager and an executor, that encapsulate the necessary behavior for deciding when to execute which reconfiguration and for executing a particular reconfiguration. Optionally, we may add a

risk manager to the reconfiguration controller that decides whether it is safe to execute

a particular reconfiguration [PHST12]. RailCabDriveControl RM reconfMsg Manager Executor RM R RM parent embeddedCI executor events _RER embeddedCI RE reconfExec RE parent

component part compartment reconfiguration controller compartment

component name compartment

RiskManager

riskManager manager

Figure 4.2: Reconfiguration Controller of a Structured Component (cf. [HB13])

By using a dedicated reconfiguration controller, we retain separation of concerns be- tween functional behavior and reconfiguration behavior as advised by McKinley et al. [MSKC04]. We use the RM ports and RE ports as introduced in Section 3.1.1.2 in our reconfiguration controller for providing the necessary interfaces for executing reconfig- urations across different levels of hierarchy without violating component encapsulation. In our approach, the executor is responsible for executing reconfigurations respecting hi- erarchy and ACI-T properties based on the 2-phase-commit protocol. Thus, it is similar to the script interpreter of Fractal [BHR09]. The manager decides which reconfigura- tion is executed in which situation, which is not supported by the Fractal reconfiguration controller. The RM ports and RE ports provide the bottom-up and top-down message flow for initiating and executing reconfigurations.

In a little more detail: A component uses its RM ports for sending information on sit- uations that may require a reconfiguration to its parent. Consequently, RM ports are used for bottom-up information provision and to provide the necessary message flow for realizing Use Case 1. A component uses its RE port for offering reconfigurations to its parent. The parent may trigger a reconfiguration on a child by sending a message to the RE Port of that child. Thus, RE ports are primarily used for top-down reconfiguration initiation and to provide the necessary message flow for realizing Use Case 2. As of [BHR09], Fractal only supports Use Case 2.

For enabling message flow across different levels of hierarchy at runtime, we connect the manager (and executor) to the parent and all embedded component instances using the RM ports (or RE ports). Figure 4.3 illustrates these connections for an instance of theRailCabDriveControlcomponent for driving alone.

standaloneRC : RailCabDriveControl RM :reconfMsg : Manager : Executor RM RM :parent :embeddedCI :executor :events :embeddedCI RE :reconfExec RE :parent RM RM _{RE RE RE} vc1 / ctrl : VelocityController :refSpeed :curSpeed :force os / strategy :

OperationStrategy :speedProvider dl / drive :_DriveLogic :refSpeed

B

:protocolInst

B

:protocolInst :section1 :section1

:section2 :section2 :maxSpeed sp / sp : SpeedSensor :speed RM RE RM RE RM RE 180180

[isStandalone == true, isCoordinator == false]

:riskManager :manager

: RiskManager

Figure 4.3: Component InstanceRailCabDriveControlwith Reconfiguration Controller

As shown in Figure 4.2, the manager specifies two RM ports namedparentandembed- dedCI. The RM portparentimplements the RM port of the structured component and is used for sending messages to the parent. The RM multi portembeddedCIconnects the manager to the RM port instances of the embedded component instances for receiving their messages. At runtime, one subport instance of this port exists for each child of the structured component instance as shown in Figure 4.3. Sincedc:DriveControlhas three embedded component instances, theembeddedCIport of the manager contains three sub- port instances. The executor is connected to the parent and the embedded component instances in the same fashion.

Since the reconfiguration controller has the same structure for any structured compo- nent and introduces additional visual complexity, we typically use the short-hand nota-

tion shown in Figure 4.4 for visualizing reconfigurable structured and atomic compo- nents [HPB12].

RailCabDriveControl

component part compartment RM

reconfExecRE reconfMsg

(a) Reconfigurable Structured Component

reconfExec reconfMsg ConvoyManagement coordinator speedProvider strategy profileProvider RM RE

(b) Reconfigurable Atomic Component

Figure 4.4: Short-hand Notation for Reconfigurable Components

Initial ideas regarding the introduction of a manager and executor including dedicated ports for handling reconfiguration have been presented by Dreising [Dre11]. These ideas have been refined and extended significantly in our publications [HPB12] and [HB13].