Comparison of the MechatronicUML Component ...

Comparison of the MechatronicUML Component Models

Technical Report tr-ri-14-341

Christian Heinzemann and Steffen Becker Software Engineering Group, Heinz Nixdorf Institute University of Paderborn Zukunftsmeile 1 33102 Paderborn, Germany [c.heinzemann|steffen.becker]@uni-paderborn.de

Version: 1.0

Paderborn, June 27, 2014

2

1 Introduction Today’s technical systems are usually build as a combination of mechanical and electric parts that are increasingly controlled by embedded software. We call these systems mechatronic systems [VDI04]. Typical examples include modern cars, trains, or airplanes. Increasingly, software is used for realizing advanced functionality using self-adaptation [BCDW04] where the software architecture of the embedded software is modified at runtime by the system itself. We refer to this as reconfiguration [OMT98]. A common approach for specifying the software architecture and its reconfiguration at runtime is a component-based approach where the software architecture is built from a set of interconnected components. "The cornerstone of any component-based development methodology [SGM02] is its underlying component model, which defines what components are, how they can be constructed and represented, how they can be composed or assembled, how they can be deployed and how to reason about all these operations on components." [Lau06] In addition, the component model defines how components interact if they are composed or assembled [HC01, p. 11]. The M ECHATRONIC UML method is a component-based approach for defining a software architecture of a mechatronic system based on a component model. In previous works, however, two different component models have been defined for M ECHATRONIC UML. These are the component model by Burmester, Giese, and Hirsch [GTB+ 03, GBSO04, HHG08, GS13] as well as the component model by Tichy [THHO08, Tic09]. The former focuses on the integration of discrete software components with the underlying feedback controllers that control the physical movement of the mechatronic system. The latter focuses on a flexible specification of reconfiguration but does not consider the special characteristics of feedback controllers. In addition, both component models do not provide particular features that are essential for specifying software of self-adaptive mechatronic systems. For example, they do not enable to exchange information between discrete software components and feedback controllers and to establish connections between autonomous mechatronic systems that are not yet connected with each other. In this paper, we define a set of requirements that need to be satisfied by a component model for M ECHATRONIC UML that may be used for defining a software architecture for a mechatronic system including its reconfiguration at runtime. We derive the requirements from literature as well as from examples of our domain. Then, we compare the two pre-existing component models for M ECHATRONIC UML based on these requirements. Finally, we briefly indicate how the component models may be consolidated into a new component model for M ECHATRONIC UML that satisfies the given requirements. We illustrate the component models based on the RailCab system [HTS+ 08] that is developed at the University of Paderborn. The RailCab system is a new kind of railway transportation system where small trains, called RailCabs, travel autonomously on the track system. They are controlled by software and may form so-called convoys where they drive at very small distances for reducing air resistance by exploiting the slipstream effect. Such convoys a built up automatically on track as illustrated in Figure 1. In a convoy, RailCabs do not use

3 mechanical coupling, i.e., the whole convoy operation is controlled by software. For guaranteeing safe and stable convoys, the leading RailCab of a convoy acts as a so-called coordinator and provides reference data to all following RailCabs. The following RailCabs are called members.

Figure 1: Illustration of a Convoy Built-Up at a Switch In the remainder of this paper, we first introduce our requirements for the M ECHATRON component model in Section 2. Thereafter, Section 3 compares the two component models with respect to the requirements. We conclude the paper in Section 6. IC UML

2 Requirements for the MechatronicUML Component Model This section introduces the requirements for the M ECHATRONIC UML component model that serve as a basis for comparing the two existing component model for M ECHATRONIC UML. We consider three kinds of requirements. These are requirements for modeling components (Section 2.1), requirements for specifying reconfigurations (Section 2.2), and non-functional requirements (Section 2.3). Along with the requirements, we introduce the terminology that we will use for the remainder of this thesis.

2.1 Modeling Components This section introduces the functional requirements for modeling components. "A [..] component is a software element that conforms to a component model and can be independently deployed and composed without modification according to a composition standard." [HC01, p. 7]. In accordance to the UML [Gro11], components are either implemented directly or they are assembled from other components. We refer to the former as atomic components and to the latter as structured components. In addition, we distinguish between component types and

2.1

MODELING COMPONENTS

4

component instances. The component types are instantiated to component instances for representing a configuration of the system’s software. In the following, we refer to component types simply as components. We require our component model to distinguish between atomic components and structured components. In addition, our component model needs to distinguish components and component instances. We provide more specific requirements for atomic components (Section 2.1.1), structured components (Section 2.1.2), component instances (Section 2.1.4 and 2.1.5), and the way they are connected to each other (Section 2.1.3) below. 2.1.1 Kinds of Atomic Components An atomic component directly contains a behavior specification and does not embed other components. In mechatronic systems, we typically have two kinds of atomic components: discrete components and continuous components. Discrete components define the discrete, event-based real-time behavior of the system. Continuous components represent the feedback controllers of the system. Their behavior is typically defined "by block-diagrams, differential equations, or transfer functions" [Bur06, p. 56]. As a result, a discrete component operates on time-discrete values and implements message-based communication based on Real-Time Coordination Protocolsf. In contrast, a continuous component operates on time-continuous values often represented by signals, which have defined values at all points in time [Mat]. As a result, instances of both kinds of components have a state that is defined by the state of the Real-Time Coordination Protocol (discrete atomic component) or the values of the signals (continuous atomic component) as opposed to stateless, reentrant components used, e.g., in the Palladio component model [BKR09]. We require our component model to explicitly distinguish between discrete and continuous atomic components due to their conceptual differences. In addition, the component model needs to provide a state-based behavior specification for discrete components, while we only intend model the external interfaces of continuous components. The behavior of continuous components should be specified directly in a control engineering tool like R R MATLAB /Simulink . 2.1.2 Kinds of Structured Components A structured component embeds other component types either by directly embedding component types [BCL+ 06] or by means of component parts that are defined as an association to an other component type [Gro11]. If a component embeds other types directly, there exists only one instance of each component in the system and this instance is shared between different components. In contrast, component parts specify a cardinality (cf. Section 2.1.5) and each structured component instantiates its own instances. Since instances of components have a state, each instance might be in a different state during runtime. Therefore, using component parts in the only viable option for our component model.

2.1

MODELING COMPONENTS

5

In addition, we require structured components to be able to embed both, discrete components and continuous components. 2.1.3 Kinds of Ports and Connections Components are connected via their ports using connectors. As described in Section 2.1.1, we need to distinguish between discrete and continuous components because they operate on different kinds of data. Consequently, the component model also needs to distinguish different kinds of ports based on the data they process. Thus, we aim at using a so-called "port-based" interface concept for our component model [CSVC11]. We need discrete ports that may send and receive messages for realizing a message-based communication between discrete components. These ports need to define the message types that the port can process as well as the messages’ parameters. In addition, we need continuous ports that receive or emit a signal for specifying the interfaces of continuous components. These ports need to define the data type and, in case of arrays, the dimension of the signal value. In our RailCab example, however, we observe use cases for connecting discrete and continuous components. A member RailCab receives a reference speed for the convoy that is provided by a coordinator as a parameter of a message. The member needs to propagate the reference speed value as a signal to the velocity controller that is modeled as a continuous component. In addition, discrete components need to obtain, e.g., the position of the RailCab from a sensor for deciding whether there exist RailCabs nearby that are eligible for building a convoy. Since discrete components may only operate on time-discrete values, we cannot add continuous ports to them. If we did so, we would require to verify discrete components with hybrid model checking techniques [Hen96]. These, however, can only verify very small system models [Alu11] and cannot be used in conjunction with M ECHATRONIC UML’s compositional verification approach [GTB+ 03]. Therefore, we need so-called hybrid ports at discrete components for exchanging values with continuous components. These ports emit or receive signal values but need to provide a sampling period that discretizes the value of the port at fixed, predefined points in time. Based on the identified kind of ports, the component model needs to enable connecting components via connectors. According the UML 2.4 [Gro11], we propose using assembly connectors for connecting ports of components on the same level of hierarchy. Delegation connectors connect ports of adjacent levels of hierarchy. Based on the kinds of ports, we want to enable both kinds of connectors between discrete ports and between continuous ports. Furthermore, we need connectors continuous and hybrid ports. 2.1.4 Initial and Valid Configurations A component instance has a configuration that is defined by the currently instantiated port instances, embedded component instances, and connector instances. If the component is reconfigurable as in our approach, a component instance may switch between different configura-

2.1

MODELING COMPONENTS

6

tions at runtime by executing reconfigurations. The current configurations of all component instances in the system define the configuration of the system itself. In the context of M ECHA TRONIC UML we will refer to a specific configuration of a system or of a component instance in a system as a component instance configuration (CIC). The initial configuration of a component defines which configuration any instance of the component acquires upon instantiation. Components may define an initial configuration implicitly or explicitly. An implicit specification is, for example, instantiating all ports and embedded components according to the lower bound of the cardinality (cf. Section 2.1.5). With an explicit specification, the developer needs to specify the initial configuration. In this case, a component may offer one or many initial configurations. In the latter case, a specific initial configuration needs to be selected upon instantiation. We require our component model to enable explicit specification of an initial configuration. This enables the developer to precisely define how components need to be instantiated. An implicit specification may additionally be used as a default case if no explicit initial configuration has been provided. A valid configuration is a syntactically correct and semantically meaningful configuration. A configuration is syntactically correct if it adheres to the component type specification and if all port instances are connected by connectors. A semantically meaningful configuration executes a useful behavior. Valid configurations need to be defined by the developer. In our RailCab example, RailCabs may either be coordinator or member of a convoy but not both at the same time. Therefore, valid configurations of a RailCab may not contain component instances for being a coordinator and member at the same time. A component model for reconfigurable components needs to be able to express such conditions for valid configurations. These conditions need to be verifiable to ensure that reconfigurations cannot lead to invalid configurations. 2.1.5 Cardinalities Cardinalities define how many instances of a port and, in case of a structured component, how many instances of an embedded component may be instantiated during runtime. A cardinality defines a lower bound and an upper bound specifying the minimum and maximum number of instances of a particular port or embedded component. Thus, cardinalities define the number of possible configurations of a component. In principle, it is desirable to limit the number of possible configurations of a component to those that are necessary for realizing the functionality of the component. This is for two reasons. First, reducing the number of configurations improves the efficiency of verifying the reconfiguration behavior. Second, the software of mechatronic systems needs to be allocated to embedded computing devices with little memory and computing power. Having fewer configurations for a component eases this task [Hüw13]. For a mechatronic system, it is a reasonable assumption that we can define precise cardinalities. Often, these are implied by the physical construction of the system. As an example, a RailCab has four wheels. Each of which is equipped with an active suspension module that

2.2

MODELING RECONFIGURATION

7

is controlled by software. Thus, any RailCab has exactly four instances of the component that controls the suspension. Concluding, the component model needs to be able to express cardinalities in the form [n..m] where the n ∈ N0 is the lower bound and m ∈ N ∪ {∗} is the upper bound. The asterisk denotes an arbitrary upper bound. n and m may be equal. In this case, the cardinality may be abbreviated as [n]. In the following, we refer to ports (or component parts) with an upper bound greater than 1 as multi ports (or multi parts, respectively) [Hir08, Tic09].

2.2 Modeling Reconfiguration This section introduces the functional requirements for modeling reconfiguration. We assume a graph-based specification of reconfigurations [BCDW04]. The criteria presented in this section have been introduced as part of a Bachelor’s thesis [Sch12]. 2.2.1 Reconfiguration of Discrete Components Bradbury et al. [BCDW04] define four basic operations with respect to discrete components that a language for modeling reconfiguration needs to offer. These are creating and destroying component instances as well as creating and destroying connectors. This includes, in particular, creating and destroying port instances of component instances. In addition, it needs to be possible to change delegation connectors such that a port instance of a structured component instance is delegated to a different embedded component instance after the reconfiguration. That includes to delegate a port that was previously attached to an assembly connector and vice versa. 2.2.2 Reconfiguration of Continuous Components In M ECHATRONIC UML, we only intend to specify the interfaces of atomic continuous components without specifying their behavior (cf. Section 2.1.1). Consequently, our language for specifying reconfiguration only needs to include features for creating and destroying continuous component including connector instances that are attached to their port instances. We cannot instantiate or destroy port instances of continuous component instances on the level of M ECHATRONIC UML. This operation needs to be performed by the continuous component instance itself in order to maintain encapsulation. Since it has no behavior specification in M ECHATRONIC UML, we cannot define reconfiguration of its port instances in M ECHA TRONIC UML. In contrast to discrete component instances, continuous component instances cannot be replaced instantaneously if they produce the same output signal as illustrated in Figure 2. There, Controller 1 is to be replaced by Controller 2. Both feedback controllers compute values for the same controlled variable of the physical system. The green graphs illustrate the computed value over time while the vertical yellow bar denotes the point in time where

2.2

8


the feedback controllers are replaced instantaneously. In this case, a jump in the value of the controlled variable occurs at the physical machine that may damage it. «destroy» currentValue controlledVariable referenceValue

Controller 1 «create»

Physical Machine

currentValue controlledVariable referenceValue

Controller 2

Figure 2: Illustration of Exchanging a Controller without Fading Function Therefore, the reconfiguration needs to be executed using a fading function [BGO06] or flatness-based switching [OMT+ 08]. These approaches smooth the signal while the feedback controllers are exchanged such that no jumps may occur. Consequently, we require our language for modeling reconfigurations to use such approaches when replacing continuous components. 2.2.3 Support of Multi Ports and Multi Parts Multi ports and multi parts impose a particular challenge to the language for modeling reconfiguration because they can be instantiated arbitrarily often in case of a [0..∗] cardinality. As a result, the number of configurations of a component becomes unbounded. An example is given by the convoy mode of our RailCab system. In principle, an arbitrary number of member RailCabs may join a convoy. Since we require at least one dedicated discrete port instance for each member to communicate with it, the coordinator needs an arbitrary number of port instances. If we do not limit the number of convoy members, the component implementing the behavior of a convoy coordinator has infinitely many configurations. Since our component model shall support multi ports and multi parts (cf Section 2.1.5), we require our language for modeling reconfigurations to support multi ports and multi parts as well. In particular, we require that multi ports and multi parts may be instantiated arbitrarily often if they define a [0..∗] cardinality. 2.2.4 Instantiating Connectors on System Level A component model for self-adaptive mechatronic systems needs to support communication on the so-called system level. Communication on system level denotes the communication between different autonomous mechatronic systems in order to form a networked mechatronic system [GRS14, pp. 8-10]. A key idea of M ECHATRONIC UML is that all communication

2.2


9

between different autonomous mechatronic systems needs to be specified by Real-Time Coordination Protocolsf [GTB+ 03, EHH+ 13, GS13]. Real-Time Coordination Protocolsf, in turn, require to use dedicated single-cast connectors to ensure safe communication. As a result, two autonomous mechatronic systems need to instantiate a connector including a Real-Time Coordination Protocol before they can start to collaborate. The instantiation of Real-Time Coordination Protocolsf on system level, however, cannot be achieved by a single reconfiguration that creates the connector. Instead, the two autonomous mechatronic systems need to agree on instantiating a particular Real-Time Coordination Protocol. Then, each system needs to reconfigure locally in order to instantiate a port instance including the (virtual) connector instance. That, however, already requires the systems to communicate to establish the agreement before they have actually created a connector for communication. Therefore, the component model needs to provide explicit means for the instantiation of connectors including a Real-Time Coordination Protocol on system level. 2.2.5 Control Flow Bradbury et al. [BCDW04] argue that a language for modeling reconfiguration needs to support so-called composite operations as well as basic control flow in terms of sequencing, choices, and iterations. A composite operation enables to create and/or destroy several component instances, port instances, or connector instances at the same time. Control flow enables that the result of the reconfiguration depends on the current architecture which makes their specification much more flexible. 2.2.6 Modeling Real-Time Properties M ECHATRONIC UML is dedicated to modeling software of mechatronic systems that underlies soft or hard real-time constraints [Kop97]. As a result, reconfiguration operations need to respect real-time properties as well. If a reconfiguration is not finished in time, the system might not be able to execute part of its functional behavior according to its hard deadlines. That, in turn, makes the system unsafe. If real-time constraints apply to a reconfiguration, the language for modeling reconfiguration needs to be able to express them. 2.2.7 Determinism A deterministic execution of reconfigurations ensures that the execution of a reconfiguration on a particular component instance configuration always produces the same result. Since a mechatronic system is a special case of a real-time system, its software needs to be predictable as emphasized by Butazzo [But05]. Consequently, also the language for modeling reconfiguration needs to provide a deterministic behavior.

2.3

NONFUNCTIONAL ASPECTS

10

2.3 Nonfunctional Aspects This section introduces important nonfunctional properties that we require for the specification of components and reconfiguration operations. They ensure that the specification is maintainable and verifiable. The criteria introduced in this section have been introduced as part of a Bachelor’s Thesis [Sch12]. 2.3.1 Component Encapsulation Encapsulation is one of the most essential properties of a component [SGM02]. It denotes that the internals of a component are hidden to the outside world. Access to the capabilities or data of a component is only allowed via its ports. In particular, that means that a component may not reconfigure structures that are outside its boundaries. In addition, a structured component must not reconfigure the internals of its embedded components. That enables to replace one component by another one with a compatible interface without affecting any other component in a system. In addition, component encapsulation is one of the key enablers of compositional verification [BCC98, GTB+ 03] because it guarantees that there may not exist more dependencies to other components than those captured by ports and connectors. Consequently, we require our component model to enforce component encapsulation. 2.3.2 Separation of Concerns Separation of concerns demands that the reconfiguration behavior of a component is specified separately from its functional behavior [MSKC04] (also called steady-state behavior [ZC06]). McKinley et al. [MSKC04] denote separation of concerns as one of three major enabling technologies for successfully developing self-adaptive systems. In addition, it enables to verify both parts of the behavior individually as shown by Zhang and Cheng [ZC06] thereby enabling scalable verification. Consequently, we require our component model to support separation of concerns between functional and reconfiguration behavior. 2.3.3 Verifiability Reconfigurations in a mechatronic system are safety-critical because an erroneous reconfiguration may leave the system in an invalid configuration. Consequently, the language for modeling reconfiguration needs to be verifiable to prove that the reconfigurations cannot produce invalid configurations (cf. Section 2.1.4). 2.3.4 Semiotic Clarity of Concrete Syntax A fundamental idea of M ECHATRONIC UML is using visual notations as concrete syntax. Moody [Moo09] emphasizes that visual notations need to provide a 1:1 correspondence between graphical symbols and semantic constructs of the language. In particular, symbol overload, i.e. the same graphical symbol may denote different semantic constructs, needs to be pre-

11 vented "as it leads to ambiguity and the potential for misinterpretation" [Moo09]. Therefore, we require the visual notation for our component model to be free of symbol overload. However, we do not require 1:1 correspondence because a symbol deficit, i.e., semantic constructs without graphical representation, may reduce diagrammatic complexity [Moo09].

3 Evaluating the Pre-Existing Component Models for MechatronicUML This section compares the two pre-existing component models for M ECHATRONIC UML. We first introduce the component model by Burmester, Giese, and Hirsch in Section 3.1 before introducing the component model by Tichy in Section 3.2. For both component models, we evaluate how they consider the criteria identified in Section 2. We summarize the results of this evaluation in Section 3.3.

3.1 Component Model by Burmester, Giese, and Hirsch The component model by Burmester and Giese was the first component model of M ECHA TRONIC UML [GTB+ 03, GBSO04, BG05, BGS05, BGT05, BGO06, Bur06, GHH+ 08, GS13]. It is based on the UML 2.0 component model [Gro05] and allows to specify types of components (cf. Section 3.1.1) that can be instantiated to specify the software architecture of the mechatronic system (cf. Section 3.1.2). The component model particularly focuses on the integration of feedback controllers. It has been extended by Hirsch [Hir08, HHG08] to support 1:n communication protocols. Reconfigurations of the system are specified by a state-based approach called hybrid reconfiguration charts (HRCs) (cf. Section 3.1.3). 3.1.1 Component Specification Burmester [Bur06] extends the UML 2.0 component model by distinguishing between discrete atomic components and continuous atomic components (called basic component in [Bur06]). Discrete atomic components contain a behavior specification in terms a of Real-Time Statechart [Bur06, Hir08, GB03], while the behavior of continuous atomic components "is specified by block-diagrams, differential equations, or transfer functions" [Bur06, p. 56]. It is assumed to be specified in a control engineering tool [BGH+ 07]. Structured components are referred to as hybrid components that embed an arbitrary number of component instances. Burmester argues that "not all instances [...] are needed simultaneously at runtime" [Bur06, p. 56]. Therefore, they have an implicit cardinality of [1] or [0..1] and "the component diagram shows the superposition of all instance situations possible at runtime" [Bur06, p. 56]. Embedding instances is, however, invalid according to UML [Gro05] although the approach claims to use the UML 2.0 component model. The behavior of a hybrid component is specified by its hybrid reconfiguration chart (cf. Section 3.1.3) and the parallel execution of the embedded component instances.

3.1

12

COMPONENT MODEL BY BURMESTER, GIESE, AND HIRSCH

In the given literature, the concrete syntax of components has not been defined consistently. In our example, we mainly rely on the concrete syntax used by Giese et al. [GHH+ 08] and Hirsch [Hir08]. Figure 3 shows the component RailCabDriveControl of the RailCab that implements all necessary behavior for the RailCab to drive. It embeds an instance of the basic discrete component MemberControl and an instance of the hybrid component ConvoyCoordination. MemberControl implements the communication that is needed for driving in a convoy as a member, while ConvoyCoordination implements the behavior of the coordinator. In addition, RailCabDriveControl embeds an instance ctrl of the VelocityController component shown in Figure 4. The VelocityController is responsible for controlling the speed of a RailCab. It embeds two instances ds and cs of the basic continuous components StandaloneDrive and ConvoyDrive, respectively. StandaloneDrive implements the feedback controller for driving alone or leading a convoy as a coordinator based on the current speed and a reference speed. The ConvoyDrive implements the feedback controller for driving in a convoy as a member. Therefore, it additionally receives the current distance to the preceding RailCab and a reference distance that it should preserve. RailCabDriveControl

peer

member coordinator

coordinator member

refDistProvider refDistProvider

convoy:ConvoyCoordination

member:MemberControl refPosReceiver refPosReceiver

refSpeed curSpeed refDist

force

curDist

ctrl:VelocityController

Figure 3: Component Type DriveControl using the Component Model by Burmester and Giese The component model distinguishes between discrete ports and continuous ports. A discrete port sends or receives at most one signal event at a time [GS13] that is specified by means of the class SignalEvent of the UML [Gro05, p. 435]. The signal events correspond to the messages being sent or received. They are defined in interfaces of the port. A discrete port with a provided interface may receive signal events, a discrete port with a required interface sends signal events. Each discrete port is associated to a role of a Real-Time Coordination Protocol [GS13]. Continuous ports are defined by time-continuous variables that have "a well-defined value for each point in time" [GS13]. Burmester mentions the use of so-called hybrid ports that combine "multiple discrete and continuous ports as syntactic construct to

3.1


13

VelocityController

refSpeed

refSpeed curSpeed

force

ds:StandaloneDrive force

refSpeed curSpeed

curSpeed

refDist

refDist

curDist

curDist

force

cs:ConvoyDrive

Figure 4: Component Type VelocityController using the Component Model by Burmester and Giese reduce visual complexity" [Bur06, p. 56]. However, they are never used and their usage is not explained. In Figure 4, all ports are continuous ports. In the concrete syntax, we visualize these ports as triangles following the proposals by Burmester [Bur06] and Hirsch [Hir08]. In the example, refSpeed, curSpeed, refPos, and curPos receive data, while force emits data. In Figure 3, all ports of RailCabDriveControl are discrete ports that are visualized by unfilled squares. The port refPosProvider specifies a required interface represented by a half circle. The port refPosReceiver specifies a provided interface represented by the full circle. The ports peer, coordinator, and member specify both, a required and a provided interface. Giese and Schäfer [GS13] distinguish permanent and optional ports. While permanent ports are present in all possible instances, optional ports are not always present. Hirsch additionally introduces so-called discrete multi-ports that may be instantiated arbitrary often [Hir08]. Thus, discrete ports have one of the three cardinalities [0..1], [1..1], [0..∗]. Continuous ports are restricted to cardinalities [0..1] and [1]. In the concrete syntax, we represent permanent continuous ports by black filled triangles as, e.g., refSpeed of VelocityController in Figure 4. For optional continuous ports, the triangle remains unfilled as it is the case for refDist of RailCabDriveControl [GS13]. The squares representing discrete ports are always unfilled. A discrete multi-port is visualized with a cascaded border line [Hir08] as, for example, the ports coordinator and refDistProvider in Figure 3. The Real-Time Statechart that defines the behavior of a discrete atomic component has a fixed, hierarchical structure [Hir08, p. 133] as shown in Figure 5 for the component MemberControl. The Real-Time Statechart contains one hierarchical state with several regions. There

3.1


14

exists one region for each discrete port that contains the Real-Time Statechart of this port. In addition, the Real-Time Statechart may contain one so-called synchronization Real-Time Statechart that may be used to synchronize the port Real-Time Statecharts [GTB+ 03]. MemberControl MemberControl_Main member

refPosReceiver Synchronization1

Figure 5: Structure of a Real-Time Statechart of a Discrete Atomic Component A hybrid component either implements its ports in its hybrid reconfiguration chart or it delegates its ports to its embedded component instances using delegation connectors. The DriveControl component in Figure 3 implements the port peer, while it delegates all other ports to the embedded component instances convoy and member. In addition, the ports of embedded component instances may be connected by assembly connectors if they implement different roles of the same Real-Time Coordination Protocol. In both cases, discrete ports may only be connected to discrete ports and continuous ports may only be connected to continuous ports [GS12, pp. 51-52]. In [Hir08, p.64], this problem is circumvented by directly reading/writing data from/to embedded continuous components within a hybrid reconfiguration chart, which violates component encapsulation. 3.1.2 Component Instances The component model provides an instance view for modeling component instance configurations. In contrast to the definition of a structured component, a component instance configuration only contains the embedded component instances that are active. The concrete syntax is the same as for embedded component instances shown in Figures 3 and 4. 3.1.3 Specifying Reconfiguration In the component model by Burmester and Giese, reconfigurations of structured components are specified in terms of hybrid reconfiguration charts(HRCs, [GBSO04, Bur06, BGO06]). A hybrid reconfiguration chart is a Real-Time Statechart that embeds component instance configurations of embedded component instances in its states. The component instance configuration defines which embedded components are instantiated and how they are connected by assembly connectors. According to Burmester [Bur06], the port instances of the structured com-

3.1

15


ponent instance are visualized at the border of the states. That enables to specify which ports are delegated to embedded component instances. Later publications [BGO06, Hir08, GS13] do not use ports at the border of the states, but therefore loose the ability to reconfigure delegation connectors. ffadeToDist

toDistanceCtrl /

[50;50] DistanceControl

SpeedControl refSpeed curSpeed

refSpeed

force

refDist

force

curSpeed

:StandaloneDrive

curDist

cs:ConvoyDrive [50;50] ffadeToSpeed

toSpeedCtrl /

Figure 6: Hybrid reconfiguration chart of the Component VelocityController Figure 6 shows the hybrid reconfiguration chart of the component VelocityController of Figure 4 as an example. It consists of two states SpeedControl and DistanceControl. The former contains the component instance configuration for driving alone while the latter contains the component instance configuration for driving as a convoy member. The component instance configuration in state SpeedControl requires that the structured component instance VelocityController has port instances refSpeed, curSpeed, and force that are delegated to the embedded component instance StandaloneDrive. As a consequence, these port instances are visualized at the border of state SpeedControl. The state DistanceControl has been created accordingly. At any point in time, the component instance has the configuration that is contained in the currently active state of its hybrid reconfiguration chart. Thus, only configurations contained in the states are valid and no other configurations are possible. The initial state of the hybrid reconfiguration chart defines the initial configuration of the component instance. The transitions of the hybrid reconfiguration chart define possible changes of the active configuration. When firing a transition, the system switches from the configuration contained in the source state to the configuration contained in the target state. Thus, the configurations in source and target state can be considered as left-hand side and right-hand side of a graph transformation rule [Roz97]. Hybrid reconfiguration charts enable to create and destroy embedded component instances and assembly connector instances. As defined by Burmester [Bur06], they also support to create and destroy port instances of a structured component instances including delegation connector instances. Transitions of a hybrid reconfiguration chart may carry a fading function if continuous component instances are replaced by the reconfiguration. Hybrid reconfiguration charts support

3.1

16


both, fading functions [BGO06] and flatness-based switching [OMT+ 08] (cf. Section 2.2.2). Since hybrid reconfiguration charts extend Real-Time Statecharts, they may also specify realtime properties of the reconfiguration. In our example in Figure 6, we switch from SpeedControl to DistanceControl using the fading function ff adeT oDist that is annotated at the end of the transition arrow. Executing this reconfiguration takes 50 ms of time as specified by the deadline of the transition. Giese et al. [GBSO04] and Burmester [Bur06] define that transitions with a fading function have a thick line, while all other transitions have a thin line. Burmester et al. [BGO06] and Hirsch [Hir08] define that all transitions with a deadline have a thick line even if they do not define a fading function. Giese and Schäfer [GS13] do not use thick lines at all. In the section, we rely on the concrete syntax by Burmester et al. [BGO06]. In addition to its hybrid reconfiguration chart, each structured component has a so-called interface statechart [GBSO04, BGO06]. The interface statechart captures the externally visible configurations of a component in terms of its instantiated port instances. The interface statechart can be automatically abstracted from the hybrid reconfiguration chart of the structured component [GBSO04]. In addition, it can be used to verify correct hierarchical composition of reconfigurations [Hir08]. toDistanceCtrl /

[50;50] refSpeed curSpeed

refSpeed

force

refDist

force

curSpeed

[SpeedControl]

curDist

[DistanceControl] [50;50] toSpeedCtrl /

Figure 7: Interface Statechart of the Component VelocityController Figure 7 shows the interface statechart of the VelocityController that was abstracted from the hybrid reconfiguration chart in Figure 6. The interface statechart contains two states named SpeedControl and DistanceControl that correspond to the states of the hybrid reconfiguration chart. The states of the interface statechart are visualized as components where the name of the state is used as the component name label in square brackets [GBSO04, BGO06, GS13]. In addition, the interface statechart contains the transitions for switching between the component instance configurations including their deadlines. The use of the component figure for visualizing states of an interface statechart produces symbol overload. Hybrid reconfiguration charts can be specified hierarchically according to the component model. The hybrid reconfiguration chart uses the interface statecharts of the embedded com-

3.1

17


ponents for modeling hierarchical reconfigurations. Each component instance embedded in a state of the hybrid reconfiguration chart then denotes its current configuration based on its interface statechart. The hybrid reconfiguration chart may demand a reconfiguration of an embedded component instance when firing a transition by using different states of the interface statechart in the source and target state. becomeSlave / [50;50] Coordinator_1Member

Member NoConvoy

member

refSpeed coordinator curSpeed

member:MemberControl refPosReceiver

force

ctrl:VelocityController [SpeedControl]

refPosProvider

convoy:ConvoyCoordination

...

refSpeed refSpeed

curSpeed refDist

curSpeed

force

force

ctrl:VelocityController [SpeedControl]

curDist

ctrl:VelocityController [DistanceControl]

[50;50] becomeMaster /

becomeMaster /

Figure 8: Hybrid reconfiguration chart of the Component DriveControl Figure 8 shows the hybrid reconfiguration chart of the RailCabDriveControl component in Figure 3. RailCabDriveControl embeds the VelocityController shown in Figure 7. It denotes the current configuration of the VelocityController based on the interface statechart shown in Figure 7. In state NoConvoy, only the VelocityController is instantiated and it is in configuration SpeedControl. If the RailCab becomes member of a convoy, the hybrid reconfiguration chart switches to Member and instantiates the embedded MemberControl component. In addition, it demands a reconfiguration of the VelocityController, which needs to switch to DistanceControl. According to the definition of a correct embedding of other components given by Hirsch [Hir08], the VelocityController must perform the reconfiguration that is requested by the DriveControl. In addition, the VelocityController cannot decide itself to perform a reconfiguration. That would change the externally visible configuration forcing its parent component, the DriveControl, to reconfigure as well. That, however, additionally violates component encapsulation. In Figure 8, we included the state Coordinator_1Member that contains the component instance configuration of a RailCab for operating a coordinator of a convoy with one member. That component instance configuration includes an instance of a multi-port, although hybrid reconfiguration charts have never been extended to support multi port or multi parts [Hir08]. However, even if we extended hybrid reconfiguration charts such that they support multi ports and multi parts, we would only be able to specify a hybrid reconfiguration chart for a fixed up-

3.2

COMPONENT MODEL BY TICHY

18

per bound of convoy members. In addition, the hybrid reconfiguration chart for the DriveControl becomes very large. Since the order in which the members follow the coordinator matters and is encoded in the order of the multi port, the number of states of the hybrid reconfiguration chart is given by an arithmetic series ΣN n=1 n. For N = 10 members in a convoy, the hybrid reconfiguration chart has 57 states which is hardly manageable for a developer. In addition to specifying the reconfiguration of a structured component, the hybrid reconfiguration chart may also implement discrete ports of the structured component [GBSO04, BGO06, GS13]. Then, the hybrid reconfiguration chart follows the same structure as shown in Figure 5. In our example, the port peer of RailCabDriveControl (cf. Figure 3) is not delegated to an embedded component and, thus, implemented by the hybrid reconfiguration chart. As a result, the hybrid reconfiguration chart of RailCabDriveControl has one region for the Real-Time Statechart of the port peer and one region containing the hybrid reconfiguration chart shown in Figure 8. This, however, mingles functional and reconfiguration behavior.

3.2 Component Model by Tichy The component model by Tichy [TH07, THHO08, Tic09] is based on the UML 2.1.1 component model [Gro07]. It mainly differs from the component model by Burmester, Giese, and Hirsch in the specification of hierarchical components (cf. Section 3.2.1) and the specification of reconfiguration operations (cf. Section 3.2.3). In particular, reconfiguration operations are specified using a rule-based approach called component story diagrams (CSDs, [THHO08]). 3.2.1 Component Specification The component model by Tichy only considers one generic kind of atomic component (called simple component in [THHO08]). It does not specify how the behavior of these atomic components is specified. Structured components embed other components by means of component parts as defined by the UML 2.1.1 component model [Gro07]. Component parts have a name and an explicit cardinality that defines how many instances may be instantiated at runtime. The component model supports two cardinalities: [0..1] and [0..∗]. Component parts with cardinality [0..∗] are called multi parts. The behavior of a structured component is solely defined by the parallel execution of the embedded components and the component story diagrams (cf. Section 3.2.3). That enables for a separation of concerns between functional and reconfiguration behavior. Figure 9 shows the structured component type ConvoyCoordination (cf. Figure 3). ConvoyCoordination defines the behavior of a coordinator of a convoy. It embeds two component parts. The component part man refers to the atomic component type ConvoyManagement and has a cardinality of [0..1]. This component implements the communication protocols that enable other RailCabs to join the convoy. The component part refGen refers to the atomic component type RefGen and has a cardinality of [0..∗]. It computes reference data for the convoy members [Tic09, p. 40]. Component parts with cardinality [0..∗] are visualized with a double border line [Tic09, p. 38].

3.2

19


ConvoyCoordination

coordinator

coordinator

refSpeedProvider

man : ConvoyManagement

refSpeedProvider infProvider

curPos

refDistProvider

curPos

refDistProvider prev

infReceiver

refGen : RefGen next

Figure 9: Hierarchical Component Type using the Component Model by Tichy including a multi part Similar to components, the component model only considers one generic kind of port. Tichy mentions that discrete, continuous, and hybrid ports exist, but he does not further distinguish them [Tic09, p. 35]. Interfaces define the information that a port may send (required interface) or receive (provided interface). Tichy mentions that the interfaces define the types of messages that may be send or received via the port [Tic09, p. 36]. In addition, ports either have cardinality [0..1] or [0..∗] in accordance to Hirsch [Hir08] (cf. Section 3.1.1). In the concrete syntax, ports and their interfaces are visualized according to the UML notation [Gro07, p. 159] as shown in Figure 9. Ports with a cardinality of [0..∗] as visualized with a cascaded border line as proposed by Hirsch [Hir08]. Besides embedding component parts, a structured component also defines how component parts are connected with each other. The component model by Tichy requires that all ports of a structured component are delegated to ports of component parts using delegation connectors [Tic09, p. 42]. Ports of component parts are connected by assembly connectors. Both kinds of connectors need to respect the cardinalities of their endpoints. The cardinality of an endpoint is defined by the port cardinality and the component part cardinality. In the example in Figure 9, the port infProvider has an endpoint cardinality of [0..∗] resulting from the port cardinality. The port infReceiver has an endpoint cardinality of [0..∗] as well. In this case, the endpoint cardinality is defined by the cardinality of the component part. Thus, both ports may be connected by an assembly connector. The component model by Tichy uses a special system component that defines which components occur on system level and how they may be connected to each other. In our example, the system component contains, for example, RailCabs and defines how they can be connected to convoys. The system component may not contain ports and may not be embedded as a component part in other components [Tic09, p. 41]. However, it may contain component story diagrams and, thus, enables to instantiate connectors on system level. Such system component,

3.2

20


however, does not exist in a running system and, thus, cannot be used for implementing the instantiation of connectors on system level for autonomous mechatronic systems. Finally, components and ports may specify a set of attributes using the primitive types Integer, Double, Boolean, and String. These attributes are externally visible and may store additional data [Tic09, p. 36]. They may be set upon instantiation and modified by component story diagrams (cf. Section 3.2.3) of the parent component. 3.2.2 Component Instances Components are instantiated to component instances and connected in a component instance configuration. The component instance configuration defines the current configuration of all component instances. Upon instantiation, the variable parts of the component need to be determined. For each component instance, we additionally need to determine the number of port instances. For a structured component instance, we need to determine the number of embedded component instances for each component part including the connector instances. cc : ConvoyCoordination

coordinator

coordinator

coordinator

coordinator infProvider

refSpeedProvider

convMan / man : ConvoyManagement

refSpeedProvider infProvider

infReceiver

curPos

curPos

refDistProvider

refDistProvider

member1 / refGen : RefGen next

infReceiver prev

refDistProvider

member2 / refGen : RefGen

refDistProvider

Figure 10: Component Instance using the Component Model by Tichy Figure 10 shows an instance of the structured component ConvoyCoordination (cf. Figure 9). It contains one instance convMan of the component part man of type ConvoyManagement. This instance contains two instances of the multi port coordinator, two instances of the multi port infProvider, and one instance of the port refSpeedProvider. In addition, the structured component instance contains two instances of RefGen. Each of which has an instance of the port infReceiver. These port instances are connected via assembly connector instances to the infProvider port instances of convMan. In addition, the refDistProvider port instances

3.2


21

of the RefGen instances are delegated to the corresponding port instances of the structured component instance cc. Component instances implicitly define three composite aggregations. First, a component instance that is embedded in a structured component instance cannot exist without its parent. An exception to this rule are component instances that are embedded in the special system component. Second, a port instance cannot exist without its surrounding component instance. Third, a connector instance cannot exist without being attached to exactly two port instances [Tic09, p. 42]. 3.2.3 Specifying Reconfiguration In the component model by Tichy, reconfigurations of structured components are specified in terms of component story diagrams (CSDs, [THHO08, Tic09]). Component story diagrams are based on story diagrams [FNTZ00, Zün01, vDHP+ 12] and support the same constructs for specifying control flow including a set of input and output parameters. Story nodes of a component story diagram, however, contain component story pattern instead of story pattern. Component story pattern describe the modification of a component instance configuration using the concrete syntax of component instances. Each story node contains exactly one this variable that represents the component instance being reconfigured. The this variable may contain port variables that are matched on the port instances of the corresponding component instance. In addition, the this variable may contain other component variables and connector variables if it is typed by a structured component. These are typed over the component parts and connectors that are contained in the component specifying the component story diagram. Component story patterns are matched using injective matchings as normal story patterns. The stereotypes «create» and «destroy» define elements that are created or destroyed by the component story pattern. If more than one matching for a component story pattern exists, then the component story pattern is applied on the first matching that is found. That may result in nondeterministic behavior. The propagation of matchings along the control flow edges of the component story diagram is identical to story diagrams. Therefore, Holtmann [Hol08] and Tichy [Tic09] defined the semantics of component story diagrams by a mapping to story diagrams. This mapping also enables verification by using inductive invariants that prove the absence of forbidden configurations [BBG+ 06]. Figure 11 shows a component story diagram addConvoyMemberAtPos for the component ConvoyCoordination of Figure 9. It adds a new instance of the RefGen component to convoy coordination if a new member joins a convoy. It specifies one input parameter position of type Integer and one output parameter result typed over the coordinator port of ConvoyCoordination. The first story node tries to match the first RefGen instance which is the only one having an instance of the curPos port. The corresponding component variable has the name tmpRefGen and is typed over the component part refGen of type RefGen. For any variable, the reference to the part is always preceded by a slash whereas the reference to the type is always preceded by a colon. Variables may remain unnamed as it is the case for the port variable re-

3.2

22


ConvoyCoordination::addConvoyMemberAtPos(position : int) : (result : coordinator) if (next != null){ tmpRefGen = next; next = null; }

getFirstRefGen this

getNextRefGen this

[i < position] :curPos

:curPos

tmpRefGen / refGen : RefGen

tmpRefGen [success]

int i = 1;

[success]

i++;

:next :prev

next / refGen : RefGen

[else] [failure]

[failure] [else]

createRefGen [postion == 1]

this

«create» c : coordinator

createRefGenBeginning

«create» «create» :coordinator

:infProvider

this

«create» c : coordinator

createFirstRefGen

«create» «create» :coordinator

cm / man : ConvoyManagement :infProvider «create»

tmpRefGen

«create»

:next

«create»

«create» «create»

:infReceiver «create» c : coordinator

:coordinator

cm / man : ConvoyManagement :infProvider

«create»

«create» :curPos

«create»

:curPos «create» «create» :refDistProvider :refDistProvider

newRefGen / refGen : RefGen :next

«create» «create» «create» :curPos

«create»

:infReceiver

«create»

«create»

:curPos «create» «create» :refDistProvider :refDistProvider

tmpRefGen / refGen : RefGen

«destroy»

«destroy» «destroy»

tmpRefGen

:curPos

«create»

«create»

this

«create» «create»

cm / man : ConvoyManagement

:prev

:infReceiver «create» «create» :refDistProvider :refDistProvider

:prev «destroy»

newRefGen / refGen : RefGen :next «create» :prev

next / refGen : RefGen

:curPos

result -> c

Figure 11: Component story diagram Creating a new RefGen Instance (cf. [Tic09, Sch12])

3.2


23

ferring to the port part curPos of refGen. The port variable of the this variable is typed over the port type because it has no associated part. If the fist story node cannot be matched, then the story node in the lower left corner creates and connects a first instance of RefGen. Otherwise, the statement node initializes a counter i that is used to iterate over the list of RefGen instances until the instance at the position given as parameter has been found. Then, the story node in the lower middle inserts an instance of refGen at the beginning of the list, while the story node in the lower right inserts an instance of refGen at any other position. Finally, the final node assigns the created port c of type coordinator to the output parameter result. Component story diagrams mostly respect component encapsulation, however, they allow direct creation and deletion of port instances of embedded component instances as shown in Figure 11 and in [Tic09, p. 68]. Since the port instance belongs to the embedded component instance, we consider this as a violation of encapsulation. Component story diagrams support all of the modifications mentioned in Section 2.2.1. In particular, they support sequencing, choices, and iterations using control flow edges as shown in Figure 11 Since the component model does not distinguish discrete and continuous components, they do not consider fading functions or flatness-based switching for replacing continuous components. In addition, they do not provide means for expressing real-time properties of the reconfiguration. To overcome this limitation, Holtmann [Hol08, p. 123] suggested to call component story diagrams in the side effects of Real-Time Statecharts. Then, the capabilities of Real-Time Statecharts can be used for expressing the real-time properties of the reconfiguration. This enables to define all real-time properties that we require. Component story diagrams can invoke other component story diagrams on embedded component instances. That enables to execute reconfigurations hierarchically. An invocation is placed inside the component variable on which the component story diagrams should be called. Any invocation is executed after the modification specified by the component story pattern has been performed [Tic09, p. 62]. All return parameters of the invoked component story diagram may be used as bound variables in subsequent story nodes. Figure 12 shows a component story diagram addConvoyMember for the component RailCabDriveControl. In its first story node, the component variable c binds an instance of ConvoyCoordination using the component part coord. This component variable invokes the component story diagram addConvoyMemberAtPos shown in Figure 11 on the matched component instance. The output parameter result is assigned to the variable p. In the second story node, p is used as a bound port variable. That enables the second story node to create a port at this including a delegation connector instance to p. In addition to component story diagrams, a component may specify a set of so-called constructors. A constructor is a special component story diagram for creating the initial configuration of the component instance. It may only be called on a component variable having the stereotype «create». By using several constructors, a component may specify several initial configurations. All configurations that can be created using constructors and component story diagrams are considered to be valid [Tic09, p. 36].

3.3

24

DISCUSSION RailCabDriveControl::addConvoyMember(position : int) : void

addPort

delegate Port this

c / coord : ConvoyCoordination

this «create» coordinator «create»

p

c

p := addConvoyMemberAtPos(position)

Figure 12: Component story diagram Creating a Adding a new Member to the Convoy

3.3 Discussion Table 1 summarizes the results obtained for the two component models with respect to the requirements introduced in Section 2. As it can be inferred from the table, none of the two component models fulfills all requirements. The component model by Burmester, Giese, and Hirsch supports the specification of continuous components and considers their special characteristics. The component model by Tichy provides a better support for component models with multi parts. Based on the results shown in Table 1, we conclude that a combination of the features of both component models is suitable for fulfilling most of our requirements. However, both component models do not provide effective means for instantiating connectors on system level, which includes the instantiation of a Real-Time Coordination Protocol. In addition, both component models do not support to connect discrete and continuous components enabling, e.g., a RailCab to set a new reference speed to its velocity controller that it has received from a coordinator. Therefore, we need to provide extensions for these two requirements. With respect to modeling reconfiguration, the existing component models provide rather distinct approaches. Therefore, we needed to choose one of them for our new component model. We decided to use the rule-based specification by means of component story diagrams. They enable for a more concise specification, in particular, in the presence of multi port and multi parts. As an example, the hybrid reconfiguration chart in Figure 3 requires 57 states to enable convoys with 10 members (cf. Section 3.1.3), whereas the same reconfigurations can be captured by one component story diagram. Furthermore, component story diagrams can easily be extended towards supporting reconfiguration of continuous components and preserving component encapsulation.

Table 1: Summary of Features of the M ECHATRONIC UML Component Models Burmester, Giese, Hirsch Tichy Criterion Modeling Components Discrete, Continuous No distinction Kinds of atomic components Hybrid, invalid specification of embedded One component kind, component parts for Kind of structured compocomponents using instances embedded components nents Discrete & Continuous Ports, Connectors One port kind, no restrictions on Kinds of interfaces and cononly between same port kinds connectors nections 1 n Initial configurations explicitly enumerated implicitly defined by rule set Valid configurations [0..1] and [1..1] for embedded [0..1] and [0..∗] for component parts and components, [0..1], [1..1], and [0..∗] for Cardinalities ports ports Modeling Reconfiguration yes yes Discrete Components yes no Continuous Components Multi Ports only yes Support of Multi Ports/Parts No Via special system component Instantiating Connectors on System Level yes yes Control Flow yes via embedding in Real-Time Statechart Real-Time Properties yes nondeterministic matchings possible Determinism Nonfunctional Aspects no no Encapsulation no yes Separation of Concerns yes yes Verifiability no yes Semiotic Clarity

3.3 DISCUSSION

25

26

4 The New MechatronicUML Component Model This section consolidates the two pre-existing component models and derives a new component model for M ECHATRONIC UML. Based on our discussion in Section 3.3, we combine the two existing component models with respect to modeling components and use component story diagrams for modeling reconfiguration. In addition, we update the component model definition to UML 2.4.1 [Gro11]. In this section, we only discuss the features of our new component model briefly and refer to the recent M ECHATRONIC UML specification [BDG+ 14] for a detailed introduction of the new component model. In the following, Section 4.1 introduces the specification of components where we explicitly address connections between discrete and continuous components. Thereafter, Section 4.2 defines how components are instantiated to component instances. Finally, Section 4.3 presents our extensions of component story diagrams towards supporting reconfiguration of continuous components.

4.1 Component Specification The concepts presented in this section combine features of both component models for specifying components. We start by introducing the component specification in Section 4.1. Thereafter, we discuss the specification of component instances in Section 4.2 and of reconfigurations in Section 4.3. 4.1.1 Components In accordance to Burmester and Giese, we distinguish between discrete and continuous atomic components. The behavior of discrete atomic components is defined by a Real-Time Statechart having the structure shown in Figure 5. For continuous components, we also assume that their behavior is specified in a control engineering tool and only specify the interface of the component in M ECHATRONIC UML. Figure 13 illustrates the concrete syntax of atomic components. In contrast to the previous component models, we distinguish discrete and continuous atomic components by different component icons in the upper right corner to increase semiotic clarity.

DiscComponentType (a) Discrete Atomic Component

ContComponentType (b) Continuous Atomic Component

Figure 13: Kinds of Atomic Components

4.1

27

COMPONENT SPECIFICATION

Further, we distinguish between discrete and hybrid structured components. A discrete structured component (recursively) embeds discrete components only. A hybrid structured component embeds a mixture of discrete, hybrid, and continuous components. In accordance to Tichy, structured components embed other components by means of component parts. In addition, a structured component only specifies reconfiguration behavior (cf. Section 4.3), but no functional behavior to achieve separation of concerns. Figure 14 shows a hybrid structured component that embeds the two atomic components shown in Figure 13 using component parts part1 and part2. HybridComponentType

part1 : ContComponentType [1]

part2 : DiscComponentType [0..10]

Figure 14: Hybrid Structured Component Our component model allows for a precise specification of cardinalities using integers for lower and upper bound, but still enables to use an asterisk to support an arbitrary number of instances. Supporting precise cardinalities is especially useful for our model transformation to a simulation environment [HRS13, PHMG14]. In Figure 14, the component part part1 has a cardinality of [1]. That means any instance of the hybrid component contains exactly one instance. We call this a single part. part2 has a cardinality of [0..10] such that an instance has at most 10 instances of this component part. In accordance to Tichy, we call this a multi-part. In addition to the aforementioned components, we introduce a special-purpose component type: the fading component [Vol13]. A fading component defines a set of fading functions for switching between continuous components that produce the same output signal. We need such fading components for integrating controller reconfiguration into our transactional reconfiguration approach [HB13]. Figure 15 illustrates the use and the concrete syntax of the fading component. The fading component Fading enables to switch between the two continuous components ctrl1 and ctrl2 that produce the same output signal out. For each continuous component, the fading component has one in-port (cf. Section 4.1.2 for a detailed description of ports). Additionally, it has exactly one out-port that produces the same output signal as the two feedback controllers. The fading component always needs to be instantiated if one of the continuous components is instantiated. At any time, it either forwards one of the input signals unmodified or it executes a fading function for fading from one input signal to the other. As for continuous components, we only specify the interface of the fading component and the signatures of the contained fading functions in M ECHATRONIC UML. At this point, we do not need to

4.1

28


ReconfigurableHybridComponent

ctrl1 : Controller1 [0..1] out

+ -

in1

fade : Fading [1] out

out

in2

ctrl2 : Controller2 [0..1] out

Figure 15: Fading Component for Switching between Two Continuous Components distinguish whether the fading function implements a cross fading [BGO06] or flatness-based switching [OMT+ 08]. We only need to specify its duration. 4.1.2 Ports In our component model, we distinguish between different kinds of ports. We use discrete and continuous ports as defined by Burmester and Giese. Additionally, we use hybrid ports for connecting discrete components to continuous components. Figure 16 summarizes the concrete syntax of these three kinds of ports. A discrete port defines a set of message types that it may send or receive. A message type has a name and an ordered set of typed, named parameters. In contrast to the existing component models, we do not provide explicit interfaces in terms of required and provided interfaces. Instead, we use a port-based specification of the interface where we directly assign message types to the ports [CSVC11]. If a discrete port only sends messages, it is an in-port which is denoted by a small triangle pointing "into" the component similar to the notation of Koala [vOvdLKM00]. If it only sends messages, it is an out-port as denoted by the small triangle pointing "outside" the component. If it both sends and receives messages, it is an in/out-port denoted by two embedded triangles. Discrete ports may only be used at discrete atomic components and structured components. They define a message buffer in the same fashion as a role of a Real-Time Coordination Protocol [HBDS14]. Continuous ports send (out-port) or receive (in-port) a signal value. "A signal is a time varying quantity that has values at all points in time" [Mat]. Currently, we only enable primitive data types for signals and do not support in/out-ports. Continuous ports may only be used at continuous atomic components, fading components, and hybrid structured components. Hybrid ports enable that a discrete component sends a signal to or receives a signal from continuous components. For keeping the behavior specification of a discrete component discrete, hybrid ports define a sampling interval. Then, the value of the signal only changes at the

4.1

29


rate of the signal value and we do not make any assumptions on how the value may change. Hybrid ports may only be used at discrete atomic components. The Real-Time Statechart of the component may read (in-port) or write (out-port) the value of the hybrid port like a normal variable. in-port

out-port in/out-port

discrete

in-port


discrete

continuous

n/A

continuous

n/A

hybrid

n/A

hybrid

n/A

(a) Mandatory Single Ports in-port

(b) Optional Single Ports


discrete

in-port


discrete

continuous

n/A

n/A

n/A

continuous

n/A

n/A

n/A

hybrid

n/A

n/A

n/A

hybrid

n/A

n/A

n/A

(c) Mandatory Multi Ports

(d) Optional Multi Ports

Figure 16: Kinds of Ports [BDG+ 14] Similar to component parts, we also enable to specify precise cardinalities for ports by providing an integer for lower and upper bound. Again, we allow ∗ as an upper bound. If the port has a lower bound of 0, we call it an optional port and visualize it with unfilled triangles (cf. Figures 16b and 16d) according to Giese and Schäfer [GS13]. If it has a lower bound greater or equal to 1, we call it a mandatory port and visualize it with filled triangles (cf. Figures 16a and 16c). Ports with an upper bound of 1 are called single ports while ports with an upper bound greater than 1 are called multi ports in accordance to Hirsch [Hir08, HHG08]. Currently, we only support discrete multi ports that are visualized by a cascaded border line as in the existing component models (cf. Figures 16c and 16d), but no continuous and hybrid multi ports. Additionally, each discrete port needs to refine a role of a Real-Time Coordination Protocol [GTB+ 03, HBDS14]. In our concrete syntax, we enable to visualize the role that is refined by a port by a dashed line that is attached to the port as shown in Figure 17 for port1. Visualizing the refined role of a port is optional.

4.1

30


4.1.3 Connectors Our component model supports assembly and delegation connectors as defined by the existing component models. We follow the concrete syntax of Burmester and Giese and visualize both kinds of connectors by solid lines as shown in Figure 17.

HybridComponentType Protocol ProtocolX.roleY role1 role2

part1 : type1 [0..1]

part2 : type2 [0..1] port4

port3

port2

port1

Figure 17: Assembly and Delegation Connectors Whether two ports may be connected depends on three conditions. First, they need to be structurally compatible. Second, they need to have matching interface specifications. Third, they need to have matching endpoint cardinalities as defined by Tichy. To be structurally compatible, the ports need to be of compatible kinds and have compatible directions. Discrete ports may only be connected to discrete ports. Continuous and hybrid ports may be connected with each other. For delegation connectors, both ports need to have the same direction. For assembly connectors, they need to have inverse directions. Figure 18 summarizes the combinations of structurally compatible ports. Only combinations marked with a checkmark are allowed. Port of Structered Component

out in/out in out in/out in out in/out

(a) Delegation Connectors

continuous

hybrid

in/ in/ in/ in out in out in out out out out discrete

in/ in/ in/ in out in out out out out

in

discrete

hybrid

continuous

discrete continuous hybrid

Port of Component Part

in out

continuous

hybrid

discrete

in out in/out in out in/out in out in/out

(b) Assembly Connectors

Figure 18: Structurally Compatible Ports Allowing for a Connector (cf. [BDG+ 14])

4.1

31


As the second condition, ports need to have compatible interfaces. For continuous and hybrid ports, we require that they send or receive a signal value with the same data type. For discrete ports, we require that they refine the same role of the same Real-Time Coordination Protocol (delegation connector) or different roles of the same Real-Time Coordination Protocol (assembly connector). For assembly connectors, we allow to visualize the Real-Time Coordination Protocol that defines the interaction between the two ports in combination with the assembly connector as shown in Figure 17. The Real-Time Coordination Protocol is visualized using a dashed ellipse [BDG+ 14]. Each role is connected to the port that refines it. In our example, port4 refines role1 and port3 refines role2. This visualization is optional because it introduces a lot of additional visual complexity into the component specification. Finally, we require that the endpoint cardinalities of a connector match. We apply the same rules as defined by Tichy (cf. Section 3.2.1). For a structured component, we require that all of its ports are connected by at least one delegation connector to a port of a component part. In addition, we require that all port of component parts are attached to at least one connector. The only exception to this rule are continuous ports if they are directly connected to a hardware component that is not part of the M ECHATRONIC UML component model.

180

ContComponentType

180

in

180

180

out

Figure 19: Syntax of a Continuous Port that is Directly Connected to Hardware In order to prevent unconnected ports in our component model, we visualize such ports as shown in Figure 19. We use a graphical symbol that is inspired by a pin in a digital circuit diagram as defined in IEC60617 [IEC96] to represent the hardware pin. Then, we connect this pin by a connector to the continuous port. The notation may be used for both, in-ports and out-port. 4.1.4 Valid and Initial Configurations In accordance to the component model by Tichy, we use constructors for defining the initial configurations of a component (cf. Section 3.2.3). Each component may define one or more constructors. If a component does not define a dedicated constructor, all of its ports and embedded component parts are instantiated with minimum cardinality. In addition to the component model by Tichy, we enable to define valid configurations of a component. In particular, we use component story decision diagrams (component SDDs, [Hei14]) for defining valid configurations. Component SDDs are a visual constraint language that enables to define architectural constraints based on non-modifying component

4.2

32

COMPONENT INSTANCES

story patterns. Then, each component may define a set of component SDDs. A configuration of a component is valid if and only if all component SDDs evaluate to true for this configuration.

4.2 Component Instances We rely on the definition of component instances by Tichy. In particular, we use the implicit composite aggregations (cf. Section 3.2.2). In addition, we define syntactically correct component instance configurations as follows. The number of port instances of the component instance complies with the cardinalities of the ports. For a structured component instance, we require that the number of embedded component instances complies with the cardinalities of the component parts. Each discrete port instance is either connected to exactly one other port instance by an assembly connector instance or it is delegated to exactly one port instance of the parent component instance. Port instances of structured component instances have an additional delegation connector instance to a port instance of an embedded component instance. Continuous and hybrid port instances need to fulfill the same properties, but two exceptions apply. A continuous or hybrid out-port may have more than one outgoing connector instance, i.e., the signal value may be send to several other component instances. In addition, continuous in-ports of a structured component instance may be delegated to several embedded component instances. A continuous or hybrid port instance may also have no connector instance if it is directly attached to hardware as, e.g., instances of the port force of VelocityController. In any case, component instances that are embedded in a structured component instance may only be connected by connector instances if the corresponding port types are connected by a connector in the structured component type. Compared to the component model by Tichy, we adjust the concrete syntax to the syntax of components defined in the previous sections. Figure 20 shows an instance of the hybrid component of Figure 14. hc:HybridComponentType

:port3

inst 2 / part2 : type2 :port4

inst1 / part1 : type1

[property1 = true] :port2

:port1

Figure 20: Component Instance Hirsch [Hir08] and Tichy [Tic09] did not distinguish between single port instances and multi port instances in the concrete syntax. However, a multi port instance has the same structure as a multi role instance [EHH+ 13, BDG+ 14], i.e., it consists of a multi role instance that

4.3

SPECIFYING RECONFIGURATION

33

contains several subport instances. Therefore, we propose to visualize the multi port instance by a dashed square that groups its subport instances. The subport instances are visualized as port instances as before.

4.3 Specifying Reconfiguration In our component model, we use component story diagrams for modeling reconfiguration as discussed in Section 3.3. Each structured component contains a set of component story diagrams that defines its reconfigurations. In this section, we do not repeat the general constructs of component story diagrams that we already described in Section 3.2.3. Instead, we only describe our restrictions and extensions that we apply to component story diagrams as defined by Tichy. We discuss restrictions in Section 4.3.1. Thereafter, Section 4.3.2 introduces controller exchange nodes that enable the reconfiguration of continuous components in component story diagrams. Furthermore, we define additional constraints for multi port variables (Section 4.3.3) and enable to specify component story diagrams for atomic components (Section 4.3.4). In addition, we adjust the concrete syntax of story nodes to the concrete syntax used in the latest version of story diagrams [vDHP+ 12]. 4.3.1 Restrictions We restrict component story diagrams as defined by Tichy such that they respect component encapsulation. In particular, we forbid that a component story diagram directly creates or destroys port instances of embedded component instances. Such port instances may only be created by the embedded component instance itself. The corresponding component story diagram that creates the port instance needs to be invoked on the embedded component instance. In addition, we define that a component story pattern can only be executed if its modifications do not violate the cardinalities of ports and component parts. 4.3.2 Controller Exchange Nodes Controller exchange nodes have been introduced by Schubert [Sch12] for enabling the reconfiguration of continuous components. A controller exchange node is a special kind of story node with a fixed structure that enables to safely execute fading functions. Figure 21 shows a controller exchange node based on the component shown in Figure 15. A controller exchange node contains exactly three component variables. Two of which reference continuous components where one is destroyed and one is created. The third component variable refers to the fading component that is connected to the two continuous components. The component variable referring to the fading component additionally specifies which fading function needs to be executed. In the concrete syntax, we mark controller exchange nodes by an icon in the upper right corner. Below the icon, we visualize the duration of the selected fading function.

4.3

34

SPECIFYING RECONFIGURATION

... Exchange Controller

+ [20;30] this «destroy» old / ctrl1 : Controller1 «create»

«destroy» /out

+ -

/in1

«create» /in2

new / ctrl2 : Controller2

fc / fade : Fading fadeIn1ToIn2()

/out

... Figure 21: Controller Exchange Node 4.3.3 Constraints for Multi Port Variables Multi ports are ordered, i.e., the subport instances are arranged in a sequence as it has been defined for multi roles [EHH+ 13, BDG+ 14]. Up to now, this order cannot be used for specifying component story pattern, for example, for creating a subport instance as a successor of another subport instance. As an example, consider the component story diagram in Figure 11. It creates an instance of RefGen along a new subport instance of the multi port refDistProvider. The new subport instance needs to be created as a direct successor of the subport instance delegated to the previous RefGen instance. In [Hei14], we introduced constraints for multi port variables that refer to the order of the subport instances. They are inspired by so-called link constraints of story diagrams [vDHP+ 12]. In accordance to these link constraints, we distinguish between multi port position constraints and multi port order constraints. Both of which are illustrated in Figure 22. A multi port position constraint enables to refer to the first (or last) subport instance of a multi port instance. In our concrete syntax, we visualize it by attaching a stereotype «first» (or «last») to the corresponding subport variable. In Figure 22, the upper subport variable matches the first subport instance while the lower subport variable matches the last subport instance. A multi port order constraint enables to refer to the relative order of the subport instances. We enable to define that a subport instance is a direct successor (or predecessor) of another subport instance. In our concrete syntax, we visualize these constraints by a dashed arrow

35

... Order Constraints

this «first» «next» «last» :port1

... Figure 22: Order Constraints for Multi Port Variables annotated with the stereotype «next» (or «prev») to denote that the target subport instance is a direct successor (or direct predecessor) of the source subport instance. In Figure 22, the lower subport instance is a direct successor of the upper subport instance of the multi port instance of type port1. 4.3.4 Reconfiguration of Atomic Components In our component model, we use component story diagrams for reconfiguring atomic components as well. Tichy neither explicitly defined nor restricted component story diagrams in that way. The only difference to a component story diagram of a structured component is that we visualize the this component variable as an atomic component. Then, the this component variable may only contain port variables but no embedded component variables (cf. [BDG+ 14]).

5 Related Work There exists a large number of component models, many of which are dedicated to embedded real-time systems. Mechatronic systems are a special type of embedded real-time systems and, therefore, these component models are relevant as related works. For recent surveys of existing component models, we refer to Lau et al. [LW07], Crnkovi´c et al. [CSVC11], and Hošek et al. [HPB+ 10]. Only a few of the surveyed component models for embedded real-time systems support runtime reconfiguration. These are SOFA-HI [PWT+ 08, PKH+ 11], MyCCM-HI [BFHP09], BlueArX [KKH+ 08, KRKH09], ProCom [VSC+ 09, YQCH13], CompoSE [KKTS09, ASTPH10], and AUTOSAR [FMB+ 09, AUT13a, AUT13b]. All of these approaches are restricted to mode changes [HKMU06] where a component moves from one implementation to

36 another one. This is comparable to the abilities of hybrid reconfiguration charts. Thus, these component models lack the necessary flexibility of defining reconfigurations and do not consider fading functions for exchanging controllers. In addition, they do not enable to specify and verify asynchronous message-based communication with real-time properties. The Fractal [BCL+ 06, LLC10] and SOFA 2.0 component models [HP06] have been primarily developed for business information systems. Their reconfiguration capabilities are comparable to ours. However, they do not consider real-time properties of the system behavior and do not consider the necessity of fading function for replacing feedback controllers. The DEECo component model [BGH+ 13] provides a non-hierarchical component model for soft real-time systems based on ensembles. In their approach, components do not specify a reconfiguration behavior, but define conditions for being part of an ensemble. Then, a shared runtime framework automatically constructs and dissolves ensembles based on the conditions. The conditions and the runtime framework, however, do not support real-time properties There exist several further component models for embedded real-time systems including SaveCCM [CHP06, ÅCF+ 07], Rubus [HMTN+ 08], Robocop [Maa05], Koala [vOvdLKM00], COMDES-II [KSA07], and PECOS [GCW+ 02]. These component models enable to specify real-time behavior on a low abstraction level and provide means to analyze the (timing) behavior. However, none of these approaches supports message-based communication (except COMDES-II) or runtime reconfiguration.

6 Conclusion In this paper, we consolidated the M ECHATRONIC UML component model. We compared two pre-existing component models by Burmester, Giese, and Hirsch [GTB+ 03, GBSO04, HHG08, GS13] as well as Tichy [Tic09] based on a set of requirements that we impose for a component model for M ECHATRONIC UML. Based on the comparison, we combined the strong features of both component models. In addition, we provided an extension of connecting discrete and continuous components. Table 2 summarizes the features of our new component model with respect to the requirements introduced in Section 2. By comparing it to the results obtained for the two existing component models shown in Table 1, we can conclude that our new component models significantly improves the specification of components. Our new component model fulfills all requirements except connector instantiation on system level and determinism. Since we rely on component story diagrams, there still exists the possibility of nondeterministic matchings that may result in nondeterministic behavior. With order constraints (cf. Section 4.3.3), however, we provide means for developers to specify deterministic component story patterns. Future works need to provide a concept for instantiating connectors on system level. In addition, it is necessary to perform further evaluations of our component model, in particular using applications from different domains such as automotive or production systems. Furthermore, future works need to align our component model with industrial standards for these domains such as AUTOSAR [FMB+ 09].

37

Table 2: Summary of Features of the new M ECHATRONIC UML Component Model New Component Model Criterion Modeling Components Discrete & Continuous Kinds of atomic components Discrete & Hybrid, component parts for Kind of structured compoembedded components nents Discrete, Continuous & Hybrid Ports, Connectors between discrete ports and Kinds of interfaces and conbetween continuous/hybrid ports nections n Initial configurations explicitly defined by constraints Valid configurations [m..n] with m ∈ N0 , n ∈ N ∪ {∗} for Cardinalities component parts and ports Modeling Reconfiguration yes Discrete Components yes Continuous Components yes Support of Multi Ports/Parts no Instantiating Connectors on System Level yes Control Flow via embedding in Real-Time Statechart Real-Time Properties no, nondeterministic matchings possible Determinism Nonfunctional Aspects yes Encapsulation yes Separation of Concerns yes Verifiability yes Semiotic Clarity

38

REFERENCES

References [ÅCF+ 07]

Mikael Åkerholm, Jan Carlson, Johan Fredriksson, Hans Hansson, John Håkansson, Anders Möller, Paul Pettersson, and Massimo Tivoli. The SAVE approach to component-based development of vehicular systems. Journal of Systems and Software, 80(5):655 – 667, 2007. Component-Based Software Engineering of Trustworthy Embedded Systems. URL: http://www.sciencedirect. com/science/article/pii/S0164121206002226, doi:10.1016/j. jss.2006.08.016. 36

[Alu11]

Rajeev Alur. Formal verification of hybrid systems. In Proceedings of the ninth ACM international conference on Embedded software, EMSOFT ’11, pages 273–278, New York, NY, USA, 2011. ACM. doi:10.1145/2038642.2038685. 5

[ASTPH10]

Rasmus Adler, Ina Schaefer, Mario Trapp, and Arnd Poetzsch-Heffter. Componentbased modeling and verification of dynamic adaptation in safety-critical embedded systems. ACM Transactions on Embedded Computing Systems, 10(2):20:1–20:39, December 2010. doi:10.1145/1880050.1880056. 35

[AUT13a]

AUTOSAR. AUTOSAR 4.1 - Guide to Modemanagement, August 2013. Document Identification No. 440, Version 2.1.0. URL: http://autosar.org/download/ R4.1/AUTOSAR_EXP_ModemanagementGuide.pdf. 35

[AUT13b]

AUTOSAR. AUTOSAR 4.1 - Specification of Timing Extensions, September 2013. Document Identification No. 411, Version 2.1.0. URL: http://autosar.org/ download/R4.1/AUTOSAR_TPS_TimingExtensions.pdf. 35

[BBG+ 06]

Basil Becker, Dirk Beyer, Holger Giese, Florian Klein, and Daniela Schilling. Symbolic invariant verification for systems with dynamic structural adaptation. In Proceedings of the 28th International Conference on Software Engineering, ICSE ’06, pages 72–81, New York, NY, USA, May 2006. ACM. doi:10.1145/1134285. 1134297. 21

[BCC98]

Sergey Berezin, Sérgio Campos, and Edmund M. Clarke. Compositional reasoning in model checking. In Willem-Paul Roever, Hans Langmaack, and Amir Pnueli, editors, Compositionality: The Significant Difference, volume 1536 of Lecture Notes in Computer Science, pages 81–102. Springer Berlin Heidelberg, 1998. doi:10.1007/ 3-540-49213-5_4. 10

[BCDW04]

Jeremy S. Bradbury, James R. Cordy, Juergen Dingel, and Michel Wermelinger. A survey of self-management in dynamic software architecture specifications. In Proceedings of the 1st ACM SIGSOFT workshop on Self-managed systems, WOSS ’04, pages 28–33, New York, NY, USA, 2004. ACM. doi:10.1145/1075405.1075411. 2, 7, 9

[BCL+ 06]

Eric Bruneton, Thierry Coupaye, Matthieu Leclercq, Vivien Quéma, and Jean-Bernard Stefani. The fractal component model and its support in java. Software: Practice and Experience, 36(11-12):1257–1284, 2006. doi:10.1002/spe.767. 4, 36

REFERENCES

39

[BDG+ 14]

Steffen Becker, Stefan Dziwok, Christopher Gerking, Christian Heinzemann, Sebastian Thiele, Wilhelm Schäfer, Matthias Meyer, Uwe Pohlmann, Claudia Priesterjahn, and Matthias Tichy. The mechatronicuml design method - process and language for platform-independent modeling. Technical Report tr-ri-14-337, Heinz Nixdorf Institute, University of Paderborn, March 2014. Version 0.4. 26, 29, 30, 31, 32, 34, 35

[BFHP09]

Etienne Borde, Peter H. Feiler, Grégory Haïk, and Laurent Pautet. Model driven code generation for critical and adaptative embedded systems. SIGBED Review, 6:10:1– 10:5, October 2009. doi:10.1145/1851340.1851352. 35

[BG05]

Sven Burmester and Holger Giese. Visual integration of uml 2.0 and block diagrams for flexible reconfiguration in mechatronic uml. In Proceedings of the IEEE Symposium on Visual Languages and Human-Centric Computing, VL/HCC’05, pages 109– 116. IEEE Computer Society Press, September 2005. 11

[BGH+ 07]

Sven Burmester, Holger Giese, Stefan Henkler, Martin Hirsch, Matthias Tichy, Alfonso Gambuzza, Eckehard Münch, and Henner Vöcking. Tool support for developing advanced mechatronic systems: Integrating the fujaba real-time tool suite with camel-view. In Proceedings of the 29th International Conference on Software Engineering, ICSE 2007, pages 801–804. IEEE Computer Society Press, May 2007. doi:10.1109/ICSE.2007.88. 11

[BGH+ 13]

Tomas Bures, Ilias Gerostathopoulos, Petr Hnetynka, Jaroslav Keznikl, Michal Kit, and Frantisek Plasil. Deeco: an ensemble-based component system. In Proceedings of the 16th International ACM Sigsoft symposium on Component-based software engineering, CBSE ’13, pages 81–90, New York, NY, USA, June 2013. ACM. doi:10.1145/2465449.2465462. 36

[BGO06]

Sven Burmester, Holger Giese, and Oliver Oberschelp. Hybrid uml components for the design of complex self-optimizing mechatronic systems. In J. Braz, H. Araújo, A. Vieira, and B. Encarnacao, editors, Informatics in Control, Automation and Robotics I. Springer, March 2006. 8, 11, 14, 15, 16, 18, 28

[BGS05]

Sven Burmester, Holger Giese, and Wilhelm Schäfer. Model-driven architecture for hard real-time systems: From platform independent models to code. In Alan Hartman and David Kreische, editors, Proceedings of the European Conference on Model Driven Architecture – Foundations and Applications (ECMDA-FA ’05), volume 3748 of Lecture Notes in Computer Science, pages 25–40. Springer, Berlin/Heidelberg, November 2005. doi:10.1007/11581741_4. 11

[BGT05]

Sven Burmester, Holger Giese, and Matthias Tichy. Model-driven development of reconfigurable mechatronic systems with mechatronic uml. In Uwe A¨smann, Arend Rensink, and Mehmet Aksit, editors, Model Driven Architecture: Foundations and Applications, volume 3599 of Lecture Notes in Computer Science (LNCS), pages 47– 61. Springer Verlag, August 2005. 11

REFERENCES

40

[BKR09]

Steffen Becker, Heiko Koziolek, and Ralf H. Reussner. The Palladio component model for model-driven performance prediction. Journal of Systems and Software, 82(1):3– 22, January 2009. doi:10.1016/j.jss.2008.03.066. 4

[Bur06]

Sven Burmester. Model-Driven Engineering of Reconfigurable Mechatronic Systems. PhD thesis, University of Paderborn, August 2006. 4, 11, 13, 14, 15, 16

[But05]

Giorgio C. Buttazzo. Hard Real-time Computing Systems: Predictable Scheduling Algorithms and Applications, volume 23 of Real-Time Systems Series. Springer, 2 edition, 2005. 9

[CHP06]

Jan Carlson, John Håkansson, and Paul Pettersson. SaveCCM: An analysable component model for real-time systems. Electronic Notes in Theoretical Computer Science, 160(0):127 – 140, August 2006. doi:10.1016/j.entcs.2006.05.019. 36

[CSVC11]

Ivica Crnkovi´c, Séverine Sentilles, Aneta Vulgarakis, and Michel R. V. Chaudron. A classification framework for software component models. IEEE Transactions on Software Engineering, 37(5):593 –615, September 2011. doi:10.1109/tse.2010. 83. 5, 28, 35

[EHH+ 13]

Tobias Eckardt, Christian Heinzemann, Stefan Henkler, Martin Hirsch, Claudia Priesterjahn, and Wilhelm Schäfer. Modeling and verifying dynamic communication structures based on graph transformations. Computer Science - Research and Development, 28(1):3–22, February 2013. Published online July 2011. URL: http://dx.doi.org/10.1007/s00450-011-0184-y, doi: 10.1007/s00450-011-0184-y. 9, 32, 34

[FMB+ 09]

Simon Fürst, Jürgen Mössinger, Stefan Bunzel, Thomas Weber, Frank Kirschke-Biller, Peter Heitkämper, Gerulf Kinkelin, Kenji Nishikawa, and Klaus Lange. Autosar - a worldwide standard is on the road. In Proceedings of the 14th International VDI Congress Electronic Systems for Vehicles 2009, 2009. 35, 36

[FNTZ00]

Thorsten Fischer, Jörg Niere, Lars Torunski, and Albert Zündorf. Story diagrams: A new graph rewrite language based on the unified modeling language and java. In Hartmut Ehrig, Gregor Engels, Hans-Jörg Kreowski, and Grzegorz Rozenberg, editors, Selected papers from the 6th International Workshop on Theory and Application of Graph Transformations (TAGT ’98), November 16-20, 1998, Paderborn, Germany, volume 1764 of Lecture Notes in Computer Science, pages 296 – 309. Springer Berlin / Heidelberg, 2000. URL: http://dx.doi.org/10.1007/ 978-3-540-46464-8_21, doi:10.1007/978-3-540-46464-8_21. 21

[GB03]

Holger Giese and Sven Burmester. Real-time statechart semantics. Technical Report tr-ri-03-239, Software Engineering Group, University of Paderborn, Paderborn, Germany, June 2003. 11

[GBSO04]

Holger Giese, Sven Burmester, Wilhelm Schäfer, and Oliver Oberschelp. Modular design and verification of component-based mechatronic systems with onlinereconfiguration. In Proceedings of the 12th ACM SIGSOFT Foundations of Software

REFERENCES

41 Engineering, FSE 2004, pages 179–188, New York, NY, USA, November 2004. ACM. doi:10.1145/1029894.1029920. 2, 11, 14, 16, 18, 36

[GCW+ 02]

Thomas Genssler, Alexander Christoph, Michael Winter, Oscar Nierstrasz, Stéphane Ducasse, Roel Wuyts, Gabriela Arévalo, Bastiaan Schönhage, Peter Müller, and Chris Stich. Components for embedded software: The PECOS approach. In Proceedings of the 2002 International Conference on Compilers, Architecture, and Synthesis for Embedded Systems, CASES ’02, pages 19–26, New York, NY, USA, 2002. ACM. doi:10.1145/581630.581634. 36

[GHH+ 08]

Holger Giese, Stefan Henkler, Martin Hirsch, Vladimir Roubin, and Matthias Tichy. Modeling techniques for software-intensive systems. In Pierre F. Tiako, editor, Designing Software-Intensive Systems: Methods and Principles, pages 21–58. Idea Group Publishing, London, UK, July 2008. doi:10.4018/978-1-59904-699-0. 11, 12

[Gro05]

Object Management Group. Unified Modeling Language (UML) 2.0 Superstructure Specification, July 2005. Document formal/2005-07-04. URL: http://www.omg. org/spec/UML/2.0/. 11, 12

[Gro07]

Object Management Group. Unified Modeling Language (UML) 2.1.1 Superstructure Specification, August 2007. Document formal/2007-02-05. URL: http://www. omg.org/spec/UML/2.1.1/Superstructure/PDF/. 18, 19

[Gro11]

Object Management Group. Unified Modeling Language (UML) 2.4.1 Superstructure Specification, August 2011. Document formal/2011-08-06. 3, 4, 5, 26

[GRS14]

Jürgen Gausemeier, Franz-Josef Rammig, and Wilhelm Schäfer, editors. Design Methodology for Intelligent Technical Systems. Lecture Notes in Mechanical Engineering. Springer, 2014. 8

[GS12]

Holger Giese and Wilhelm Schäfer. Model-driven development of safe self-optimizing mechatronic systems with mechatronicuml. Technical Report tr-ri-12-322, Software Engineering Group, Heinz Nixdorf Institute, University of Paderborn, April 2012. 14

[GS13]

Holger Giese and Wilhelm Schäfer. Model-driven development of safe self-optimizing mechatronic systems with mechatronicuml. In Javier Cámara, Rogério de Lemos, Carlo Ghezzi, and Antónia Lopes, editors, Assurances for Self-Adaptive Systems, volume 7740 of Lecture Notes in Computer Science, pages 152–186. Springer Berlin Heidelberg, January 2013. doi:10.1007/978-3-642-36249-1_6. 2, 9, 11, 12, 13, 15, 16, 18, 29, 36

[GTB+ 03]

Holger Giese, Matthias Tichy, Sven Burmester, Wilhelm Schäfer, and Stephan Flake. Towards the compositional verification of real-time uml designs. In Proceedings of the 9th European Software Engineering Conference held jointly with the 11th ACM SIGSOFT International Symposium on Foundations of Software Engineering (ESEC/FSE ’03), pages 38–47. ACM Press, September 2003. 2, 5, 9, 10, 11, 14, 29, 36

REFERENCES

42

[HB13]

Christian Heinzemann and Steffen Becker. Executing reconfigurations in hierarchical component architectures. In Proceedings of the 16th international ACM Sigsoft symposium on Component based software engineering, CBSE ’13, pages 3–12, New York, NY, USA, June 2013. ACM. doi:10.1145/2465449.2465452. 27

[HBDS14]

Christian Heinzemann, Christian Brenner, Stefan Dziwok, and Wilhelm Schäfer. Automata-based refinement checking for real-time systems. Computer Science - Research and Development, 2014. Published Online June 2014. doi:10.1007/ s00450-014-0257-9. 28, 29

[HC01]

George T. Heineman and William T. Councill, editors. Component-based Software Engineering: Putting the Pieces Together. Addison-Wesley Longman Publishing Co., Inc., Boston, MA, USA, 2001. 2, 3

[Hei14]

Christian Heinzemann. Component story decision diagrams. Technical Report tr-ri14-335, Software Engineering Group, Heinz Nixdorf Institute, University of Paderborn, January 2014. 31, 34

[Hen96]

Thomas A. Henzinger. The theory of hybrid automata. In Proceedings of the 11th Annual IEEE Symposium on Logic in Computer Science, LICS ’96, pages 278–292, Los Alamitos, CA, USA, July 1996. IEEE Computer Society Press. doi:10.1109/ lics.1996.561342. 5

[HHG08]

Martin Hirsch, Stefan Henkler, and Holger Giese. Modeling collaborations with dynamic structural adaptation in mechatronic uml. In SEAMS ’08: Proceedings of the 2008 international workshop on Software engineering for adaptive and selfmanaging systems, pages 33–40, New York, NY, USA, 2008. ACM. doi:10.1145/ 1370018.1370026. 2, 11, 29, 36

[Hir08]

Martin Hirsch. Modell-basierte Verifikation von vernetzten mechatronischen Systemen. PhD thesis, University of Paderborn, September 2008. 7, 11, 12, 13, 14, 15, 16, 17, 19, 29, 32

[HKMU06]

Dan Hirsch, Jeff Kramer, Jeff Magee, and Sebastián Uchitel. Modes for software architectures. In Volker Gruhn and Flavio Oquendo, editors, Software Architecture, volume 4344 of Lecture Notes in Computer Science, pages 113–126. Springer Berlin Heidelberg, 2006. doi:10.1007/11966104_9. 35

[HMTN+ 08]

Kaj Hänninen, Jukka Mäki-Turja, Mikael Nolin, Mats Lindberg, John Lundbäck, and Kurt-Lennart Lundbäck. The rubus component model for resource constrained realtime systems. In 3rd IEEE International Symposium on Industrial Embedded Systems, June 2008. URL: http://www.mrtc.mdh.se/index.php?choice= publications&id=1464. 36

[Hol08]

Jörg Holtmann. Graphtransformationen für komponentenbasierte softwarearchitekturen. Diplomarbeit, University of Paderborn, April 2008. 21, 23

43

REFERENCES

[HP06]

Petr Hnetynka and Frantisek Plasil. Dynamic reconfiguration and access to services in hierarchical component models. In Ian Gorton, George Heineman, Ivica Crnkovic, Heinz Schmidt, Judith Stafford, Clemens Szyperski, and Kurt Wallnau, editors, Component-Based Software Engineering, volume 4063 of Lecture Notes in Computer Science, pages 352–359. Springer Berlin / Heidelberg, 2006. doi: 10.1007/11783565_27. 36

[HPB+ 10]

Petr Hosek, Tomas Pop, Tomas Bures, Petr Hnetynka, and Michal Malohlava. Comparison of component frameworks for real-time embedded systems. In Lars Grunske, Ralf Reussner, and Frantisek Plasil, editors, Component Based Software Engineering, volume 6092 of Lecture Notes in Compute Science, pages 21–36. Springer, Berlin/Heidelberg, 2010. doi:10.1007/978-3-642-13238-4_2. 35

[HRS13]

Christian Heinzemann, Jan Rieke, and Wilhelm Schäfer. Simulating self-adaptive component-based systems using matlab/simulink. In IEEE 7th International Conference on Self-Adaptive and Self-Organizing Systems, SASO ’13, pages 71–80. IEEE Computer Society Press, September 2013. doi:10.1109/SASO.2013.17. 27

[HTS+ 08]

Christian Henke, Matthias Tichy, Tobias Schneider, Joachim Böcker, and Wilhelm Schäfer. Organization and control of autonomous railway convoys. In Proc. of the 9th International Symposium on Advanced Vehicle Control (AVEC ’08), pages 318–323, 2008. 2

[Hüw13]

Marcus Hüwe. Das verteilungsproblem für mechatronische systeme. Bachelorsthesis, University of Paderborn, October 2013. 6

[IEC96]

IEC. Graphical symbols for diagrams. IEC 60617, 1996. 31

[KKH+ 08]

Ji Eun Kim, Rahul Kapoor, Martin Herrmann, Jochen Haerdtlein, Franz Grzeschniok, and Peter Lutz. Software behavior description of real-time embedded systems in component based software development. In 11th IEEE International Symposium on Object Oriented Real-Time Distributed Computing, ISORC’08, pages 307–311. IEEE Computer Society, May 2008. doi:10.1109/isorc.2008.69. 35

[KKTS09]

Thomas Kuhn, Sören Kemmann, Mario Trapp, and Christian Schäfer. Multi-language development of embedded systems. In Matti Rossi, Jonathan Sprinkle, Jeff Gray, and Juha-Pekka Tolvanen, editors, Proceedings of the 9th OOPSLA Workshop on DomainSpecific Modeling, DSM ’09, pages 21–27, 2009. URL: http://www.dsmforum. org/events/DSM09/Papers/Kuhn.pdf. 35

[Kop97]

Hermann Kopetz. Real-Time Systems: Design Principles for Distributed Embedded Applications. Kluwer Academic Publishers, Boston / Dordrecht / London, 1st edition, 1997. 9

[KRKH09]

Ji Eun Kim, Oliver Rogalla, Simon Kramer, and Arne Hamann. Extracting, specifying and predicting software system properties in component based real-time embedded software development. In 31st International Conference on Software Engineering -

REFERENCES

44 Companion Volume, pages 28–38. IEEE Computer Society, May 2009. doi:10. 1109/icse-companion.2009.5070961. 35

[KSA07]

Xu Ke, Krzysztof Sierszecki, and Christo Angelov. Comdes-ii: A component-based framework for generative development of distributed real-time control systems. In Proceedings of the 13th IEEE International Conference on Embedded and Real-Time Computing Systems and Applications, RTCSA ’07, pages 199–208, Washington, DC, USA, 2007. IEEE Computer Society. doi:10.1109/rtcsa.2007.29. 36

[Lau06]

Kung-Kiu Lau. Software component models. In Proceedings of the 28th international conference on Software engineering, ICSE ’06, pages 1081–1082, New York, NY, USA, 2006. ACM. doi:10.1145/1134285.1134516. 2

[LLC10]

Marc Léger, Thomas Ledoux, and Thierry Coupaye. Reliable dynamic reconfigurations in a reflective component model. In Lars Grunske, Ralf Reussner, and Frantisek Plasil, editors, Component-Based Software Engineering, volume 6092 of Lecture Notes in Computer Science, pages 74–92. Springer Berlin / Heidelberg, 2010. doi:10.1007/978-3-642-13238-4\_5. 36

[LW07]

Kung-Kiu Lau and Zheng Wang. Software component models. IEEE Transactions on Software Engineering, 33(10):709 –724, October 2007. doi:10.1109/tse. 2007.70726. 35

[Maa05]

Hugh Maaskant. A robust component model for consumer electronic products. In Peter Stok, editor, Dynamic and Robust Streaming in and between Connected ConsumerElectronic Devices, volume 3 of Philips Research Book Series, pages 167–192. Springer Netherlands, 2005. doi:10.1007/1-4020-3454-7_7. 36

[Mat]

The MathWorks, Inc. Signal Basics. URL: http://www.mathworks.de/de/ help/simulink/ug/signal-basics.html [cited Mar. 27, 2014]. 4, 28

[Moo09]

Daniel L. Moody. The "physics" of notations: Toward a scientific basis for constructing visual notations in software engineering. IEEE Transactions on Software Engineering, 35(6):756 –779, November 2009. doi:10.1109/tse.2009.67. 10, 11

[MSKC04]

P. K. McKinley, S. M. Sadjadi, E. P. Kasten, and Betty H. C. Cheng. Composing adaptive software. Computer, 37(7):56 – 64, july 2004. doi:10.1109/mc.2004. 48. 10

[OMT98]

Peyman Oreizy, Nenad Medvidovic, and Richard N. Taylor. Architecture-based runtime software evolution. In ICSE ’98: Proceedings of the 20th international conference on Software engineering, pages 177–186, Washington, DC, USA, 1998. IEEE Computer Society. 2

[OMT+ 08]

Semir Osmic, Eckehard Münch, Ansgar Trachtler, Stefan Henkler, Wilhelm Schäfer, Holger Giese, and Martin Hirsch. Safe online-reconfiguration of self-optimizing mechatronic systems. In Jürgen Gausemeier, Franz J. Rammig, and Wilhelm Schäfer,

REFERENCES

45 editors, Selbstoptimierende mechatronische Systeme: Die Zukunft gestalten. 7. Internationales Heinz Nixdorf Symposium für industrielle Informationstechnik, pages 411– 426, February 2008. 8, 16, 28

[PHMG14]

Uwe Pohlmann, Jörg Holtmann, Matthias Meyer, and Christopher Gerking. Generating modelica models from software specifications for the simulation of cyber-physical systems. In Proceedings of the 40th Euromicro Conference on Software Engineering and Advanced Applications (SEAA). IEEE Computer Society, August 2014. 27

[PKH+ 11]

Tomas Pop, Jaroslav Keznikl, Petr Hosek, Michal Malohlava, Tomas Bures, and Petr Hnetynka. Introducing support for embedded and real-time devices into existing hierarchical component system: Lessons learned. In 9th International Conference on Software Engineering Research, Management and Applications, SERA’11, pages 3 –11. IEEE Computer Society, August 2011. doi:10.1109/sera.2011.14. 35

[PWT+ 08]

Marek Prochazka, Roger Ward, Petr Tuma, Petr Hnetynka, and Jiri 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. 35

[Roz97]

Grzegorz Rozenberg. Handbook of graph grammars and computing by graph transformation: volume I. foundations. World Scientific Publishing Co., Inc., River Edge, NJ, USA, 1997. 15

[Sch12]

David Schubert. Integration von modellierungssprachen für rekonfiguration in mechatronicuml. Bachelor’s thesis, University of Paderborn, June 2012. 7, 10, 22, 33

[SGM02]

Clemens Szyperski, Dominik Gruntz, and Stephan Murer. Component Software - Beyond Object-Oriented Programming. Addison-Wesley, 2nd edition, 2002. 2, 10

[TH07]

Matthias Tichy and Stefan Henkler. Towards a transformation language for component structures. In Proceedings of the 4th Workshop on Object-oriented Modeling of Embedded Real-Time Systems (OMER 4), Paderborn, Germany, pages 68–73, October 2007. 18

[THHO08]

Matthias Tichy, Stefan Henkler, Jörg Holtmann, and Simon Oberthür. Component story diagrams: A transformation language for component structures in mechatronic systems. In Postproceedings of the 4th Workshop on Object-oriented Modeling of Embedded Real-Time Systems (OMER 4), pages 27–39, 2008. 2, 18, 21

[Tic09]

Matthias Tichy. Gefahrenanalyse selbstoptimierender Systeme. Dissertation, University of Paderborn, Warburger Str. 100, May 2009. 2, 7, 18, 19, 20, 21, 22, 23, 32, 36

[vDHP+ 12]

Markus von Detten, Christian Heinzemann, Marie Christin Platenius, Jan Rieke, Dietrich Travkin, and Stephan Hildebrandt. Story diagrams – syntax and semantics. Technical Report tr-ri-12-324, Software Engineering Group, Heinz Nixdorf Institute, July 2012. Ver. 0.2. 21, 33, 34

46

REFERENCES

[VDI04]

VDI. VDI 2206: Entwicklungsmethodik für mechatronische Systeme. Deutscher Ingenieure, 2004. 2

Verein

[Vol13]

Andreas Volk. Hybride, rekonfigurierbare, hierarchische komponentenstrukturen in matlab/simulink. Master’s thesis, University of Paderborn, December 2013. 27

[vOvdLKM00] Rob van Ommering, Frank van der Linden, Jeff Kramer, and Jeff Magee. The Koala component model for consumer electronics software. Computer, 33(3):78 –85, March 2000. doi:10.1109/2.825699. 28, 36 [VSC+ 09]

Aneta Vulgarakis, Jagadish Suryadevara, Jan Carlson, Cristina Seceleanu, and Paul Pettersson. Formal semantics of the ProCom real-time component model. Software Engineering and Advanced Applications, Euromicro Conference, 0:478–485, 2009. doi:10.1109/seaa.2009.53. 35

[YQCH13]

Hang Yin, Hongwan Qin, Jan Carlson, and Hans Hansson. Mode switch handling for the procom component model. In Proceedings of the 16th International ACM Sigsoft symposium on Component-based software engineering, CBSE ’13, pages 13–22, New York, NY, USA, 2013. ACM. doi:10.1145/2465449.2465451. 35

[ZC06]

Ji Zhang and Betty H. C. Cheng. Model-based development of dynamically adaptive software. In Proceedings of the 28th international conference on Software engineering, ICSE ’06, pages 371–380, New York, NY, USA, May 2006. ACM. doi:10.1145/1134285.1134337. 10

[Zün01]

Albert Zündorf. Rigorous Object Oriented Software Development. Habilitation, Software Engineering Group, University of Paderborn, 2001. 21

Comparison of the MechatronicUML Component ...

Comparison of the MechatronicUML Component ...

Suggest Documents

performance comparison of component algorithms for the ...

The MechatronicUML Method: Model-Driven Software ...

The MechatronicUML Method â Process, Syntax, and

The MechatronicUML Requirements Engineering Method: Process ...

Multi-Step Forward Translation of MechatronicUML

COMPARISON BETWEEN THE TWO-COMPONENT PRESSURE ...

A Comparison of Component Integration between ... - CiteSeerX

Comparison of cemented versus uncemented acetabular component ...

Comparison of Component Method with Experimental

A Component-Based Performance Comparison of ...

Comparison of Independent Component Analysis and Conventional ...

Comparison of Independent Component Analysis Algorithms for ...

Performance comparison of independent component analysis - Lirias

MechatronicUML â Syntax and Semantics - Matthias Tichy

Power Comparison of Some Tests for the Error Component Model ...

Evaluation And Comparison Of The Principal Component Analysis

Comparison of Two Component Frameworks: The FIPA-Compliant ...

a comparison of rtk-gps vertical component with ...

Comparison of individual component deletions in a glucose-specific

A Component-Based Performance Comparison of Four ... - CiteSeerX

Comparison of a tribological model and real component test methods ...

Comparison Of Tritium Component Failure Rate Data LC ... - CiteSeerX

Comparison study of egg morphology, component and chemical

Comparison of principal component and cluster analysis for classifying ...

Comparison of the MechatronicUML Component ...