Towards Modeling Reconfiguration in Hierarchical ...

Towards Modeling Reconfiguration in Hierarchical Component Architectures Christian Heinzemann, Claudia Priesterjahn, Steffen Becker Software Engineering Group Heinz Nixdorf Institute, University of Paderborn Zukunftsmeile 1 33102 Paderborn, Germany

[c.heinzemann|c.priesterjahn|steffen.becker]@uni-paderborn.de ABSTRACT Today’s real-time embedded systems operate in frequently changing environments on which they react by self-adaptations. Such an approach needs adequate modeling support of these reconfigurations to enable verification of safety properties, e.g., by timed model checking. Component-based development of such systems realizes these self-adaptations by structural reconfigurations of components and their connectors. However, component models proposed in literature do not support reconfigurable components in real-time embedded context but focus on other domains like business information systems. In this paper, we present an extension of our modeling language MechatronicUML to support structural reconfigurations taking the specific requirements of our domain into account. Based on the proposed extension we outline our research roadmap to achieve verification and realization of systems modeled in MechatronicUML.

Categories and Subject Descriptors D.2.2 [Design Tools and Techniques ]: Components; C.3 [Special-Purpose and Application-based Systems]: Real-time and embedded systems

Keywords Modeling, Component Model, Runtime Reconfiguration, Self-Adaptive Systems

1.

INTRODUCTION

Today, real-time embedded systems operate in changing environments and coordinate to achieve a common goal. For example, a swarm of software coordinated robots can explore and secure inaccessible areas after severe accidents. These systems react to changes in their environment like the discovery of an additional robot by structural reconfigurations of their software’s component structure. For example, such a

Permission to make digital or hard copies of all or part 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. To copy otherwise, to republish, to post on servers or to redistribute to lists, requires prior specific permission and/or a fee. CBSE’12, June 26–28, 2012, Bertinoro, Italy. Copyright 2012 ACM 978-1-4503-1345-2/12/06 ...$10.00.

reconfiguration establishes an additional assembly connector in order to communicate with the newly discovered robot. During the design of such systems, software developers model components and connectors as well as their real-time behavior and deployment. Additionally, designers need to model the reconfiguration behavior of the systems. Here, the requirement is to support the encapsulation of components and to maintain a separation of concerns, i.e., not to mix modeling the component’s functional behavior with its reconfiguration behavior [11]. Our previous versions of our modeling language MechatronicUML supported two different variants of modeling structural reconfigurations: hybrid reconfiguration charts [7] and component story diagrams [14]. Both approaches did not achieve the requirements listed above to a sufficient extent. Hybrid reconfiguration charts required knowledge of components on surrounding levels of hierarchy thus breaking component encapsulation. Component story diagrams contained no explicit specification of component interfaces that mapped reconfiguration messages to their reconfiguration behavior. Other related approaches found in literature either support real-time systems or reconfigurations but no approach found supports both. In this paper, we present an extension to our component model which focuses on the specification of reconfiguration behavior. The approach maintains the encapsulation of the components, i.e., defines clear interfaces for reconfiguration requests. Additionally, it addresses the specification of realtime information. Based on these component model extensions we outline a research roadmap to achieve verification and realization of systems modeled in the extended MechatronicUML. We use a running example throughout the paper to illustrate our extended component model based on the swarm robot scenario outlined above. In the example, we model the software of a set of BeBots. BeBots are experimental robots that can explore their environment and communicate with other BeBots, e.g., to form a convoy in which they can drive together to a specific destination. To give a first impression, Figure 1 shows an example of the component and connector types used in a simplified BeBot. It has three component parts SpeedControl, Coordination, and MemberControl used to control the BeBots drive and to communicate with other BeBots. We will explain and extend the elements of this models in the following sections. The paper is structured as follows. Section 2 introduces the foundations of MechatronicUML. Based on these

Bebot

b1:Bebot provider

refSpeed provider

Coordination [0..1]

coordinator

coordinator

refSpeed

sc:SpeedControl

co:Coordination

coordinator

coordinator

member

member

SpeedControl [1] refSpeed provider

b2:Bebot MemberControl [0..1]

member

member

provider refSpeed

sc:SpeedControl

Figure 1: Component Type for the BeBot Software

foundations, Section 3 introduces the modeling extensions for structural reconfigurations. Section 4 addresses how our approach ensures safety during reconfigurations. After discussing related approach in Section 5, we outline our research agenda towards verification and realization of the modeled systems.

2.

MECHATRONIC UML

In this section, we briefly introduce MechatronicUML that adapts concepts of the UML to model the software of mechatronic systems. In MechatronicUML, the static system architecture is specified by components. The MechatronicUML component model [1] distinguishes between atomic components and structured components. Atomic components are active objects and contain a stateful behavior specification. Structured components are assembled by embedding other components.Therefore, structured components carry no explicit behavior specification by themselves. Further, our component model distinguishes between component types and component instances. A component instance is the occurrence of a component type. The component instances of one component type have the same behavior specification but may be in different system states. Our component model allows for multiple instantiation of components within a system. A component encapsulates its inner structure and behavior and allows interaction with other components only via its interfaces. In our component model, the interfaces are realized by ports. The component type of Figure 1 has two ports named member and coordinator. Communication between ports is realized by asynchronous messages. A component type defines a set of named port types. Further, port types specify a cardinality with a lower and upper bound. The lower and upper bound define the minimum and maximum number of possible port instances of a port. Ports of component types and component parts of the same level of hierarchy are connected by assemblies. Those of adjacent levels are connected by delegations. Figure 2 shows two BeBot component instances being connected via their ports. When a component instance is derived from a component type, the variable parts of the component type are determined, e.g., the port instances from the port types and embedded component instances from the component parts. Component instances are connected by connector instances. The resulting structure is called component instance configuration. We model the behavior of software components and ports by real-time statecharts [1]. A real-time statechart is a UML statemachine extended by clocks, as known from timed automata, and constraints over these clocks.

mc:MemberControl

Figure 2: Component Instance Configuration for a Convoy of Two BeBots

3.

COMPONENT MODEL EXTENSIONS

In this section, we introduce our extensions to the MechatronicUML component model of Section 2 that enable reconfiguration of hierarchical component instances. The extensions aim, on the one hand, at separation of concerns between reconfiguration behavior and functional behavior. On the other hand, the extensions preserve the encapsulation of components while explicitly supporting to trigger reconfigurations on embedded component instances. Figure 3 shows the BeBot component type of Figure 1 that has been extended to support reconfiguration. The additional middle compartment now contains the components that realize the reconfiguration behavior which is always split into a Manager and an Executor component. Both are marked by a special component icon. Bebot parent R

R

executor

Manager

reconf embeddedCI

R

R

events

RR

embeddedCI

Executor

RR

reconf

R

refSpeed reconf

R

provider

SpeedControl [1]

Coordination [0..1] reconf

coordinator

coordinator

member

member

R

refSpeed provider

MemberControl [0..1]

Figure 3: Reconfigurable BeBot Component The connection between manager and executor as well as the connections of the manager to the embedded component instances are made via reconfiguration ports. Reconfiguration ports are introduced in detail in the subsequent Section 3.1. The Manager component is responsible for controlling the reconfiguration process. It decides which reconfiguration to execute in which situation. We discuss the manager in detail in Section 3.2. The Executor component encapsulates the reconfiguration rules in terms of component story diagrams and is responsible for executing them. The concept of an executor is similar to the concept of a reconfiguration script interpreter in Fractal [2]. We introduce the executor in detail in Section 3.3. The connections from the reconfiguration compartment to all embedded component instances are assumed to be present as long as the embedded component instance exists. Thus, for a concrete component type like the BeBot, the reconfiguration compartment adds no additional information

besides the fact that the BeBot is reconfigurable. In order to reduce the visual complexity of the concrete syntax, we support a short-hand notation for reconfigurable components which is shown in Figure 4. Bebot reconf

R

R

refSpeed

reconf reconf

R

provider

Coordination [0..1] reconf

SpeedControl [1]

coordinator

coordinator

member

member

R

refSpeed provider

MemberControl [0..1]

Figure 4: Shorthand Notation for the Reconfigurable BeBot Component The short-hand notation omits the reconfiguration compartment as well as all connectors to the embedded component instances. The icon with the letter R visualizes that the BeBot is reconfigurable.

3.1

Reconfiguration Ports

In our approach, reconfiguration of hierarchical components across different levels of hierarchy is achieved by using reconfiguration ports and so-called reconfiguration messages that are exchanged via the reconfiguration ports. A reconfiguration message is used to request a reconfiguration of a component. The BeBot, e.g., may be requested to operate as a coordinator of a convoy by sending a reconfiguration message becomeCoordinator to its reconfiguration port reconf. As a result, the BeBot either performs the reconfiguration and reports its success to the requester or it reports a failure if the reconfiguration is currently not executable. More details on the flow of reconfiguration messages through a structured component is given in Section 3.2. Reconfiguration ports are bidirectional. Their interface specifies the reconfiguration messages that the component is able to send and react to. For each message, the interface gives a description of the effect of this reconfiguration for a developer and specifies two durations for the reconfiguration, namely duration to success and duration to failure. The duration to success is the time span from sending a reconfiguration message to a component until the reconfiguration has been fully executed. The duration to failure is the time span from sending a reconfiguration message to a component until receiving the answer that the reconfiguration failed or is currently not executable at the latest. Message

Effect

becomeCoordinator BeBot serves as a Coordinator for a convoy

Duration Duration to Success to Failure 50ms

Bebot

5 ms R

reconf

Figure 5: Interface Specification of a Reconfiguration Port Figure 5 shows an example for an interface specification of a reconfiguration port. The BeBot component offers a reconfiguration message becomeCoordinator which causes the BeBot to serve as a coordinator for a convoy and takes 50ms to be executed completely. If the creation of the Coordination component fails, it takes 5ms until the failure is reported.

The duration to success d of the reconfiguration is based on three parameters. First, a reconfiguration of a structured component may include reconfigurations of one or more embedded components, e.g., for creating a new port. These re. Second, the time e for configurations have a duration dsub i executing the reconfiguration of the structured component itself needs to be considered. There, we need to estimate the time needed for executing a component story diagram. In [14], Tichy et.al. introduce a concept for a worst-case execution time analysis (WCET analysis) for component story diagrams which we reuse for this purpose. Third, the time m consumed by the message flow between a structured component and its embedded component instances needs to be considered. If all reconfigurations of the embedded component instances are executed in parallel, the duration d is computed as: }+e+m d = max {dsub i i

If the reconfigurations of the embedded component instances are not executed in parallel but sequentially, the maximum . in the formula needs to be replaced by the sum of all dsub i The duration to failure f is computed by using the duration to failure f sub of the embedded component instances. In contrast to the case of success, we assume that no component story diagram will be executed in the structured component if the reconfiguration of the embedded component instances fails. Thus, the duration to failure is computed as: f = max {fisub } + m i

For now, we assume that all reconfiguration messages that are received by a reconfiguration port are created by a component in the environment. The proposed concept needs to be extended by a planning and decision making component that decides, e.g., whether to build a convoy or not and which roles the BeBot will serve in that convoy. This extension is left for future works.

3.2

Manager

The manager component is responsible for managing the reconfiguration process, for maintaining the configuration state of the component (i.e. its currently instantiated embedded component instances and connectors as model at runtime, see below), and for controlling the flow of reconfiguration messages through the component. Therefore, the manager is connected to the reconfiguration port of the structured component and it is connected to the reconfiguration ports of all component parts as well as to the executor as shown in Figure 3. For the remainder of this paper, we will denote the embedded component instances of a structured component as children and the structured component containing a component as parent. A reconfiguration message may reach the manager from two sources. First, it may be sent by the parent and, second, it may be sent by one of the children. The manager needs to decide whether the structured component needs to react to this reconfiguration message by executing a reconfiguration. If so, it forwards the reconfiguration message to the executor which performs the reconfiguration (cf. Section 3.3). The message is only forwarded to the executor, if the guard condition referring to the configuration state is evaluated to true. The specification of a guard condition for a message is optional.

Figure 6 shows an example for modeling the reconfiguration manager of the BeBot by using a table. The manager specifies two reconfiguration messages becomeCoordinator and lowBattery. becomeCoordinator is received from the parent and will be treated by the BeBot, i.e., the message is sent to the executor. The reconfiguration will only be executed if the number of instantiated MemberControl components inside the BeBot is zero, i.e., the BeBot may only operate as a coordinator if it is not already a member of a convoy. lowBattery is received from an embedded component and will not be treated by the BeBot. Message

from

becomeCoordinator Parent Child

lowBattery

treat

propagate guard

Yes

No

No

Up

#MemberControl == 0

For modeling reconfiguration, we employ component story diagrams as introduced in [14]. Component story diagrams specify structural transformations on component instance configurations. They are based on UML Activities. Each activity specifies a transformation of the component instance configuration in the form of a component story pattern. Story patterns are a well-proven variant of graph transformations to create and alter object structures. Component story patterns are an extension of story patterns that allow for using the concrete syntax of component instance configurations for specifying reconfigurations. Figure 7 shows a component story diagram that creates an embedded component instance co:Coordination if it is not present, and connects it to the ports provider of sc:SpeedControl and coordination of the current embedding component instance.

Bebot

createCoordinationComponent()

parent R

reconf

R

executor

embeddedCI

this

R

Manager

[success] provider

RR

sc:SpeedControl

refSpeed

co:Coordination

coordinator

coordinator

RR

[failure]

Figure 6: Specification of the Manager

this «create»

Besides reacting to the message by executing a reconfiguration, the manager may also propagate the reconfiguration message. It may either propagate the reconfiguration message to its parent, to all of its children, or both. If the message has been sent by the parent, it must not be propagated to the parent again. If the message has been sent by a child, it may be propagated to all children. In that case, however, the reconfiguration message is not propagated to the particular child which has sent the message in the first place. In our example, becomeCoordinator will not be propagated while lowBattery will be propagated to the parent which is indicated by Up. The table of the manager needs to contain all messages that are contained in the interface of the reconfiguration port of the structured component. The specification of a guard is optional. For evaluating the guards, the manager needs to maintain the configuration state of the structured component. That, in turn, requires to maintain a model of the structured component at runtime [4]. On the lowest level, the configuration state is determined by the component parts that are currently instantiated and their connector. After the executor has executed a reconfiguration, the configuration model is updated. An extension to higher level states or features of a component, e.g., being a coordinator of a convoy is left for future works.

3.3

Executor

The executor component encapsulates the reconfiguration behavior that actually changes the structure of the component. Thus, it is responsible for executing reconfigurations based on reconfiguration messages that it receives from the manager. The reconfiguration itself is then executed on the model of the structured component whose changes are reflected in the running system [4].

provider «create»

sc:SpeedControl

refSpeed

«create»

co:Coordination

coordinator

coordinator

Figure 7: Component Story Diagram reconfiguring a BeBot to become a Convoy Coordinator For the specification of reconfigurations in component story patterns, we consider component instance configurations as graphs, i.e., components as nodes and connectors as edges. We then model reconfiguration as a graph transformation rule. A graph transformation rule consists of a left hand side and a right hand side. The left hand side identifies the part of the configuration in which the rule can be applied, i.e., the graph contains an isomorphic image of the left hand side as a subgraph. The right hand side defines the result of the application, i.e., the changes to be made to the subgraph such that it is an isomorphic image of the right hand side. For a short hand notation, left and right hand side are depicted in one single graph. Instances that are created during rule application are drawn in green and are annotated with the stereotype «create». Instances that are destroyed are drawn in red and are annotated with the stereotype «destroy». Using component story diagrams, the executor is specified by a simple assignment of reconfiguration messages to component story diagrams. Figure 8 shows an example for the specification of the executor of the BeBot of Figure 3. The executor only specifies the message becomeCoordinator. If this message is received, the executor will execute the component story diagram createCoordinationComponent() which is shown in Figure 7. If the reconfiguration of a structured component instance requires reconfigurations of the children, then the procedure described in Section 4 is executed.

Message

Reconfiguration Rule

becomeCoordinator createCoordinationComponent() R

events

Executor

Figure 8: Specification of the Executor

4.

EXECUTING RECONFIGURATION

The reconfiguration of a structured component instance may require the reconfiguration of one or more of its children. For example, creating or changing assemblies might require a child to create a port first which is then connected by the structured component instance. If the structured component instance created the port of the child directly, this would violate the encapsulation property of components. Thus, we need to execute the reconfiguration bottom-up, i.e., we start at the child that is nested most deeply. However, we must only start the reconfiguration, if we can ensure that the reconfiguration can be executed completely. Since we consider embedded real-time systems, we must not try to reconfigure optimistically and roll-back to a preexisting configuration if the reconfiguration fails as proposed for reliable reconfiguration of Fractal components in [9]. This is for two reasons: first, the system might come into an inconsistent state which causes it to malfunction if a reconfiguration is only executed partially. Second, it is not guaranteed that returning to the configuration before reconfiguration has started is even possible. Environment struct:StructuredComponent

children:Component

performReconf(r) mayReconfigure(r‘) loop (#embedded, #embedded)

alt

check(r‘): reconfPossible

[reconfPossible == true] confirm(time of validity)

[else]

abort() failed := true

alt

[failed == true] doAbort() failed()

[else]

doReconfigure(r‘)

loop (#embedded, #embedded)

execute(r‘) finished()

execute(r) done()

Figure 9: Protocol for Execution a Reconfiguration The problem which needs to be solved is similar to processing transactions in a distributed database. There, a commit may only be done if all affected databases can actually commit. Accordingly, a reconfiguration may only be executed if all affected children can reconfigure as well. Figure 9 shows the interaction between the structured component

and its children. The protocol is inspired by the 2-phasecommit protocol [3, Chap. 7] for distributed databases. The protocol starts with a voting phase in which the structured component instance asks all affected children whether they can perform the requested reconfiguration. All children either confirm or abort. If at least one abort is received, the variable failed will be set to true. The second phase, modeled by the alternative fragment, is immediately left if failed is true. If not, all children are forced to reconfigure. After all these reconfigurations have finished, the structured component instance itself executes its reconfiguration. As a prerequisite to reconfiguration, a component instance must be in a quiescent state because only in a quiescent state, reconfiguration is safe [15, 10]. If a child confirms that it can reconfigure, it must be in a quiescent state and it is tied to that confirmation, i.e., it must not leave the quiescent state deliberately. For avoiding that a child is enforced to leave the quiescent state due to a safety-critical computation before reconfiguration took place, the child sends a time of validity as a parameter to the confirmation. Then, the minimum of all times of validity of the children must be less than the duration to success of the whole reconfiguration. Identifying quiescent states and computing the time of validity is left for future works.

5.

RELATED WORK

Our concept for hierarchical reconfiguration relates to two research areas. These are architecture description languages for self-x systems and component models that support reconfiguration at run-time. In the remainder of this section, we will discuss related work in that order. Zhang and Cheng [15] describe a general procedure for modeling self-adaptive systems proposing a separation of adaptation behavior and functional behavior which we also use in our approach. In [5] an overview of modeling approaches for self-adaptive systems is presented. From this survey, the architecture description language GeReL uses a hierarchical component model and separates functional and reconfiguration behavior thereby respecting the encapsulation of the components. In contrast to our approach, reconfigurations are specified in a declarative first-order logic based scripting language. PiLar uses a hierarchical component model that allows for creation and deletion of components and connectors during run-time. PiLar distinguishes component types and instances, but mixes them on different levels of hierarchy in the model. Reconfiguration is specified in a CCS-based scripting language. Dynamic Wright uses a component-based approach that allows for creation and deletion of components and connectors during run-time. Reconfigurations are specified in a CSP-based textual language. Like in MechatronicUML, each component has an initial configuration and a set of reconfiguration operations. In contrast to our approach, Dynamic Wright does not support hierarchical components and their reconfiguration. All of the approaches do not take real-time aspects into account. The survey [8] focuses on component models for the development of embedded real-time systems, only. General purpose component models (like CORBA, EJB, ...), which are typically intended to model non-real-time systems, do not fit in the considered class of systems as real-time aspects are not considered. Our approach is inspired by the reconfiguration concepts of Fractal [6] which have been extended to distributed exe-

cution in [2]. We adopted the concept of a reconfiguration executor and extended the remote reconfiguration invocation. In contrast to their approach, we support a higher level modeling language for modeling reconfiguration rather than implementing it as a script. SOFA HI [12] is an extension of the SOFA 2.0 component model for real-time systems. While SOFA 2.0 supports creating and deleting components as well as connectors during run-time, SOFA-HI restricts the reconfiguration capabilities to updating components to newer versions which is a major restriction compared to our approach. The same restrictions hold for Robocop and Koala. Other component models for real-time systems, like Progress, do not support reconfiguration.

6.

CONCLUSION AND FUTURE WORK

This paper presents work in progress on an extension of the MechatronicUML component model towards structural reconfiguration. We argue that our extension supports real-time behavior while retaining component encapsulation. The future work of our approach consists of several steps which need to be taken to complete the reconfiguration approach. First, we will provide an automatic generation of the behavior of manager and executor from the specification introduced in this paper. In addition, we intend to provide further modeling constraints for structured components which, e.g., indicate that a Coordination component may only be instantiated inside a BeBot if no MemberControl is instantiated. Then, we will use the specification to perform timed model checking on the specification, e.g., using timed graph based model checking introduced in [13] to verify that the reconfiguration behavior is correct. Afterwards, we plan to define quiescent states [10, 15] for our models in which reconfiguration may take place. Thereafter, we will move the reconfiguration approach into an implementation and validate the approach using an advanced, self-adaptive transportation system. That requires a framework which performs the transactional execution of the reconfiguration as, e.g., [10]. Further extensions of our approach may include the use of higher-level configuration states, e.g., modeled by feature diagrams.

7.

ACKNOWLEDGMENTS

We thank Christian Dreising for contributing some ideas presented in this paper as part of his Bachelor’s thesis. This work was developed in the course of the Collaborative Research Center 614 – Self-optimizing Concepts and Structures in Mechanical Engineering – University of Paderborn, and was published on its behalf and funded by the Deutsche Forschungsgemeinschaft. This work was partially supported by the German Research Foundation (DFG) within the Collaborative Research Centre ”On-The-Fly Computing” (CRC 901). Christian Heinzemann is supported by the International Graduate School Dynamic Intelligent Systems.

8.

REFERENCES

[1] S. Becker, C. Brenner, S. Dziwok, T. Gewering, C. Hein-zemann, U. Pohlmann, C. Priesterjahn, W. Sch¨ afer, J. Suck, O. Sudmann, and M. Tichy. The MechatronicUML method – process, syntax, and semantics. Technical Report tr-ri-12-318, Software Engineering Group, University of Paderborn, Feb. 2012.

[2] B. Bennour, L. Henrio, and M. Rivera. A reconfiguration framework for distributed components. In Proc. of the 2009 ESEC/FSE workshop on Software integration and evolution @ runtime, SINTER ’09, pages 49–56. ACM, 2009. [3] P. A. Bernstein, V. Hadzilacos, and N. Goodman. Concurrency Control and Recovery in Database Systems. Addison Wesley, 1987. [4] G. Blair, N. Bencomo, and R. B. France. Models@ run.time. Computer, 42(10):22 –27, oct. 2009. [5] J. S. Bradbury, J. R. Cordy, J. Dingel, and M. Wermelinger. A survey of self-management in dynamic software architecture specifications. In WOSS ’04: Proc. of the 1st ACM SIGSOFT workshop on Self-managed systems, pages 28–33. ACM, 2004. [6] E. Bruneton, T. Coupaye, M. Leclercq, V. Qu´ema, and J.-B. Stefani. The fractal component model and its support in java. Software: Practice and Experience, 36(11-12):1257–1284, 2006. [7] S. Burmester, H. Giese, and O. Oberschelp. Hybrid uml components for the design of complex self-optimizing mechatronic systems. In J. Braz, H. Ara´ ujo, A. Vieira, and B. Encarnacao, editors, Informatics in Control, Automation and Robotics I. Springer, Mar. 2006. [8] P. Hosek, T. Pop, T. Bures, P. Hnetynka, and M. Malohlava. Comparison of component frameworks for real-time embedded systems. In Proceedings of CBSE 2010, LNCS. Springer, 2010. [9] M. L´eger, T. Ledoux, and T. Coupaye. Reliable dynamic reconfigurations in a reflective component model. In L. Grunske, R. Reussner, and F. Plasil, editors, Component-Based Software Engineering, volume 6092 of Lecture Notes in Computer Science, pages 74–92. Springer, 2010. [10] X. Ma, L. Baresi, C. Ghezzi, V. Panzica La Manna, and J. Lu. Version-consistent dynamic reconfiguration of component-based distributed systems. In Proc. 13th European conference on Foundations of software engineering, ESEC ’11, pages 245–255. ACM, 2011. [11] P. K. McKinley, S. M. Sadjadi, E. P. Kasten, and B. H. C. Cheng. Composing adaptive software. Computer, 37(7):56 – 64, july 2004. [12] M. Prochazka, R. Ward, P. Tuma, P. Hnetynka, and J. Adamek. A component-oriented framework for spacecraft on-board software. In Proceedings of DASIA 2008, DAta Systems In Aerospace, Palma de Mallorca, European Space Agency Report Nr. SP-665, May 2008. [13] J. Suck, C. Heinzemann, and W. Sch¨ afer. Formalizing model checking on timed graph transformation systems. Technical Report tr-ri-11-316, Software Engineering Group, University of Paderborn, 2011. [14] 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), pages 27–39, 2008. [15] J. Zhang and B. H. C. Cheng. Model-based development of dynamically adaptive software. In Proc. of the 28th Intern. Conf. on Software engineering (ICSE ’06), pages 371–380. ACM, 2006.