automata-based refinement checking for real-time systems

Comput Sci Res DevDOI 10.1007/s00450-014-0257-9

SPECIAL ISSUE PAPER

Automata-based refinement checking for real-time systems

Christian Heinzemann · Christian Brenner ·Stefan Dziwok · Wilhelm Schäfer

© Springer-Verlag Berlin Heidelberg 2014

Abstract Today’s mechatronic systems are increasinglyinterconnected using communication protocols for realiz-ing advanced functionality. Communication protocols under-lie hard real-time constraints and need to meet high qualitystandards for ensuring the safety of the system. A commonapproach for achieving their necessary quality and masteringtheir impending complexity is model-driven development.Applying this approach, a developer builds formal modelsof the communication protocols and applies formal verifi-cation techniques (e.g., model checking) for proving thatthe communication is safe. However, these techniques typ-ically face the state-explosion problem that prevents proofsfor large systems like interconnected mechatronic systems. Inprevious publications, we introduced the MechatronicUMLmethod that provides a compositional verification approachfor tackling the state-explosion problem. A key enabler forsuch an approach is a definition of refinement. In this paper,we extend the compositional verification approach of Mecha-tronicUML in particular by using different kinds of refine-ment definitions including an automatic selection of the mostsuitable refinement definition. In addition, we significantlyextend an existing approach of test automata constructionfor refinement checking. Using this approach we can alsoguarantee that a refined model is constructed correctly con-

C. Heinzemann · C. Brenner · S. Dziwok (B) · W. SchäferSoftware Engineering Group, Heinz Nixdorf Institute,University of Paderborn, 33102 Paderborn, Germanye-mail: [email protected]

C. Heinzemanne-mail: [email protected]

C. Brennere-mail: [email protected]

W. Schäfere-mail: [email protected]

cerning the selected and applied refinement definition. Weevaluate our approach by an example of an advanced railwaytransportation system.

Keywords Mechatronic systems · Communicationprotocols · Model checking · Compositional verification ·Refinement · MechatronicUML

1 Introduction

Today’s mechatronic systems, which consist of mechanical,electrical, and software parts, are increasingly interconnectedvia software [51]. That enables to realize advanced function-ality where systems coordinate with each other for realizingfunctions that they cannot implement alone. The coordina-tion is typically specified by application-level communica-tion protocols that define messages that the systems need toexchange, message buffers, and communication connectors.Such communication protocols often underlie real-time con-straints, i.e., it is not only important that messages are sent,but it is also of vital importance at what time they are sentand received.

Interconnected mechatronic systems run under hard real-time constraints [44]. Therefore, the communication pro-tocols have to meet safety and liveness properties [8] thatmake their development complex. Traditional testing-basedapproaches cannot guarantee the necessary safety becauseevery possible protocol trace must be analyzed. A com-mon approach is to develop such communication protocolsusing a model-driven approach where formal models, timedautomata [5,12] in our case, of the software are built insteadof implementing the software code directly. After specifyingthe software models, we can check them by formal verifica-tion techniques such as model checking [6,8,12] to ensure

123

C. Heinzemann et al.

Normal TrackSection (ts1)

Switch (ts3)

RailroadCrossing (ts4)


RailCab 2

RailCab 1

: at most oneRailCab on a switch

Fig. 1 Example of two RailCabs approaching a switch and a railroadcrossing afterwards

correctness of the communication protocols. For obtainingcorrect verification results, we need to consider messagebuffers as well as properties of the underlying communi-cation channel such as transmission delays. The communi-cation channels can be represented by using timed automataas well. However, model checking of timed automata doesnot scale for large systems because of the state-explosionproblem [20].

Examples of interconnected mechatronic systems thatrequire formal verification include smart cars or public trans-portation systems employing vehicle-2-X (V2X) communi-cation as well as advanced production systems. In this paper,we use the RailCab system1 [36] as one representative of thisclass of interconnected mechatronic systems. The vision ofthe RailCab project is a railway transportation system whereautonomous vehicles, called RailCabs, travel on a track sys-tem. The track system is subdivided into sections includ-ing switches and railroad crossings. In this system, collisionavoidance on track has to be realized by the system itself.In particular, collision avoidance requires communication ofthe RailCab with various track systems or other RailCabsbecause sensors cannot detect other RailCabs if they are hid-den behind a bend or some other obstacle. In our example,each RailCab must query an upcoming track section whetherit is allowed to enter this track section. Considering the situ-ation shown in Fig. 1, both RailCabs want to enter the switchts3. They communicate with the switch by adhering to a com-munication protocol. This protocol is safety-critical becauseit must ensure that only one of the two RailCabs may enterthe ts3 at a time to avoid a collision. Therefore, the commu-nication protocol must obey real-time constraints to ensurethat the RailCab comes to a stop before the switch if it is notallowed to enter. Therefore, we need to apply formal verifi-cation to guarantee safety of the RailCab system. However,the state space of the software models of the RailCab and thetrack system is too large to be assessed by standard modelchecking approaches based on timed automata.

1 http://www.railcab.de.

The MechatronicUML ethod [9,24,29] provides themodel-driven development of software of interconnectedmechatronic systems (as the RailCab system) and, especially,their communication protocols. MechatronicUML ollowsa component-based approach [54] that enables the scalablecompositional verification of the system model for tacklingthe state-explosion problem. In particular, Mechatron-icUML eparates the communication protocol, called abstractprotocol, and the component implementation, called refinedprotocol, thereby enabling to verify both individually. Thisseparation, however, requires to verify whether the refinedprotocol is refined correctly according to a formal refinementdefinition. This guarantees that safety and liveness propertiesthat have been proven for the abstract protocol are still sat-isfied by the refined protocol. Verifying such refinement isfaster than verifying the refined protocol because buffer andconnector behavior specifications do not need to be takeninto account within the refinement check [34].

In literature, a number of different refinement definitionshave been proposed [34,40,56]. Examples include timedsimulation and timed bisimulation [56]. Depending on theparticular type of protocol that is refined, all refinement def-initions might be useful when building a system. A suitablerefinement definition for a compositional approach needs tobe as weak as possible for enabling reuse of an abstract pro-tocol in as many different components as possible but asstrong as necessary for guaranteeing that all verified prop-erties hold for the refined protocol. If the refinement defini-tion is too weak, it is not guaranteed that verified propertiesstill hold for the refined protocol. If the refinement definitionis too strong, the refinement check might reject the refinedprotocol although it fulfills all properties. This may happen,for example, if the refined protocol removes behavior that isirrelevant for the properties, but which is checked by the toostrong refinement definition. The existing refinement defini-tions provide different compromises between reuse and pre-served properties. As a consequence, there does not exist onerefinement definition that is suitable for all possible proto-cols. Instead, a compositional verification approach shouldsupport several refinement definitions where each of whichmay be suitable for a particular abstract and refined protocoland a set of verified properties. However, the selection of asuitable refinement definition is currently left to the devel-oper and his expertise without giving him any further toolsupport.

In this paper, which is an extended version of Brenneret al. [17], we supplement our compositional verificationapproach in two ways. First, we consider in-buffers and prop-erties of the communication channel during verification ofthe abstract protocols and the refinement check. Second,we extend the compositional verification of Mechatron-icUML ith five additional kinds of refinement definitions.Up to now, it only applies timed simulation [28,29]. Sup-

123

http://www.railcab.de


porting different kinds of refinement definitions increasesthe number of valid refined protocols for one protocol and,therefore, increases the reusability of one (abstract) com-munication protocol. This is, for example, the case for theRailCab system where RailCabs register at different types oftrack sections as shown in Fig. 1. We provide an automaticselection algorithm selecting a suitable refinement definitionbased on the type of protocol, for example timed vs. untimed,as well as the specification of safety and liveness properties.As a basis, we identify the commonalities and differencesof the six most relevant existing refinement definitions forinterconnected mechatronic systems.

Along with our refinement selection, we present, as ourmain contribution, an approach that supports automaticchecking whether the abstract protocol has been refined cor-rectly by the component. Our approach extends the approachby Jensen et al. [40]. In their approach, a so-called testautomaton is automatically constructed to verify correctrefinements. The test automaton encodes both, the abstractprotocol and the conditions of the selected refinement defi-nition. The constraints specify the allowed deviation of therefined protocol from the abstract protocol. If (and only if)the refined protocol violates one of the constraints, the testautomaton enters a special error state indicating that the con-ditions of the refinement definition are not satisfied. However,that approach is restricted to just one refinement definition(namely timed ready simulation, which is explained below).Our extensions of the approach by Jensen et al. [40] enablethe construction of test automata for all the mentioned dif-ferent refinement definitions. They include, in particular, thenotion of asynchronous communication via message buffersand thus a very important type of communication and cor-responding refinement definition for interconnected mecha-tronic systems. Checking refinement definitions for that casehas not been considered before.

We evaluate our approach using the RailCab system intro-duced above as a case study. In particular, we will show howwe use the same (abstract) communication protocol for Rail-Cabs to register at normal track sections, switches, and rail-road crossings. Each type of track section requires the proto-col behavior to be refined differently. Using our approach, wesucceeded in showing the correctness of the refinements byusing different refinement definitions for the different typesof track sections.

The paper is structured as follows: We briefly review theconcepts of MechatronicUML n Sect. 2 before describinghow we verify abstract protocols in Sect. 3. In Sect. 4, weprovide examples of how we refined the abstract protocol forthe three types of track sections that we consider. In Sect. 5,we review six existing refinement definitions and describethe selection of a suitable refinement definition based on theabstract and refined protocol. Section 6 explains the construc-tion of test automata for the different refinement definitions.

We evaluate our approach in Sect. 7 before discussing relatedwork in Sect. 8. Section 9 concludes the paper and describesour future work.

2 Modeling with MechatronicUML

MechatronicUML s a method for the model-driven designof safe software for interconnected mechatronic systems. Inparticular, it focuses on the coordination and communicationbetween such systems and within each system. For this pur-pose, the method defines a formal modeling language, whichuses concepts of the unified modeling language (UML, [46]),as well as a fine-grained development process. The completemethod specification can be found in [10].

In MechatronicUML we use components to representsystem elements (e.g., RailCabs, track sections) that coordi-nate each other using message-based asynchronous commu-nication (cf. Sect. 2.1). We define each coordination betweentwo components separately using Real-Time CoordinationProtocols (cf. Sect. 2.2). The behavior of components andprotocols is defined in a state-based manner using Real-TimeStatecharts (RTSCs) (cf. Sect. 2.3). Separating componentsfrom the protocols enables scalable model checking via ourcompositional verification approach (cf. Sect. 2.4). In thispaper, we only focus on platform-independent models basedon particular assumptions on the underlying communicationhardware (cf. Sect. 2.5).

2.1 Component model

Each component encapsulates a part of the software. Due tothe domain of interconnected mechatronic systems, compo-nents do not work in isolation, but they heavily coordinatetheir actions for achieving the intended functionality of thesystem. For this circumstance, each component defines a setof external interaction points, which we call ports.

As an example, Fig. 2 shows the components of our Rail-Cab example. Each system element (RailCab, normal tracksection, switch, and railroad crossing) is represented by onecomponent. Component RailCab has two ports: sec1 com-municates with the section the RailCab is currently on; sec2

Normal

TrackSection

rightleft

RailCab

sec2sec1

RailRoadCrossing

rightleft

Switch

left right

bottom followingSection precedingSection

Fig. 2 Components of the RailCab Example

123


ts3:Switchr1:RailCab :sec2 :left :right:sec1

:bottom :followingSection

Fig. 3 Excerpt of the component instance configuration of the RailCabexample which uses the protocol EnterSection

communicates with the section the RailCab will drive onnext. The components NormalTrackSection, Switch andRailRoadCrossing have a port left to communicate withRailCabs that drive from left to right and a port right to com-municate with RailCabs that drive the opposite way. Compo-nent Switch must also be able to communicate with a thirdRailCab. Therefore, the component has a third port bottom.Additionally, the components Switch and RailRoadCross-ing shall communicate with each other. Thus, Switch has aport followingSection and RailRoadCrossing has a portprecedingSection.

In MechatronicUML components are instantiable.Thus, a developer can define component instance configura-tions, which contain a set of instantiated components. Com-ponent instances can communicate via their port instances ifa connector instance connects them. Each connector instanceconnects exactly two port instances. Figure 3 shows anexcerpt of the component instance configuration of the Rail-Cab scenario. Here, an instance of component RailCabnamed r1 and an instance of component Switch named ts3,can communicate with each other via their connected portsinstances sec2 and left.

The developer defines the behavior of each port usingReal-Time Statecharts (cf. Sect. 2.3). The behavior of a com-ponent constitutes of the joint behavior of the port Real-TimeStatecharts . In addition, the component may provide addi-tional internal behavior in terms of a Real-Time Statechart ,e.g., for resolving dependencies between different ports.

2.2 Real-time coordination protocols

Real-Time Coordination Protocols are abstract protocolson application level that define the coordination between apair of communicating roles and a connector that connectsthese roles. The communication is always asynchronous andmessage-based, i.e., the sender can send its message indepen-dent of the receiver’s state, the sender of a message does notblock while sending, and the receiver does not block whilereceiving. The behavior definition of a Real-Time Coordina-tion Protocol is part of our refinement check (cf. Sect. 2.4).The informed reader might know that refinement checks areusually used for synchronous systems. However, they are alsoapplicable to asynchronous systems as we explain in Sect. 5.

Figure 4 shows an example of a Real-Time CoordinationProtocol named EnterSection. It consists of the roles rail-

railcab section

EnterSection

in-buffer size : 1 in-buffer size : 1delay: 20ms

Fig. 4 Real-time coordination protocol EnterSection

cab, which represents a RailCab, and section, which rep-resents various kinds of track sections, e.g., the sections ofour running example: a normal track section, a switch, and arailroad crossing. Both roles may send and receive messagesto realize this coordination (indicated by the two black trian-gles). The purpose of this protocol is to enable a coordinationfor traversing a section in a safe and efficient manner.

In Real-Time Coordination Protocols , each role that mayreceive messages has a message buffer for incoming mes-sages, which we call in-buffer. The in-buffer always enqueuesmessages in FIFO-style (first in first out) and can only storea fixed number of messages. Moreover, the in-buffer maynever overflow although the sender can send a message inde-pendently of the in-buffer’s state. Therefore, the developerhas to apply timed model checking, to verify that a bufferoverflow never occurs (cf. Sect. 3). In summary, the devel-oper only has to specify the size of each in-buffer. In contrastto related work, this is a quite restricted buffer specification.However, our experience shows that our buffer specificationis sufficient for most systems. In our example, both roles havean in-buffer with size 1.

Furthermore, we explicitly consider that a transmissionof a message from sender to receiver takes time. Therefore,connectors have a required message transmission delay. Thedelay is defined as an interval with a minimum and maxi-mum bound because the message delay within the commu-nication of wireless mechatronic system is subject to consid-erable fluctuations. Moreover, the developer has to specify ifthis required delay interval must always be fulfilled. If not,then the Real-Time Statecharts of the Real-Time Coordina-tion Protocol must handle those messages that may get lost.For example, the Real-Time Coordination Protocol Enter-Section assumes that all message transmissions must fulfillthe required transmission delay interval. The interval has thesame minimum and maximum bound which is 20 ms.

The message exchange and the timing constraints that themessage exchange needs to adhere to are formally defined.We describe the behavior of each role with a Real-Time Stat-echart (cf. Sect. 2.3).

2.3 Real-time statecharts

MechatronicUML efines the coordination behavior in astate-based manner using Real-Time Statecharts . They tackletypical aspects of interconnected mechatronic systems likehard real-time requirements and asynchronous message-

123


variable and clocks definitions

Statechart1 variable int i, bool b clock c1, c2

SimpleState1invariant c1 < 15, c2 5entry / {action1} {reset: c0}exit / {action3} {reset: c1}

state side effects

urgent transition

non-urgent transition

[c1<=10] [i < 5] msg1 ch1? / {i++;} msg2 {reset: c1,c2}

clock constraint

variable guard

receiver message synchronization

sendermessage

transition action

clockresets

State2

[c2 20] / msg3 {i := int<0,3>; b:=false}

non-deterministic choice

Fig. 5 Excerpt of the syntactical elements of a Real-Time Statechart

based coordination. Their bases are hierarchical UML statemachines [46] and timed automata [5,12]. Using Real-TimeStatechart, the developer defines the behavior of a role, a port,or a component.

Figure 5 shows an excerpt of the syntactical elements ofa Real-Time Statechart that are necessary for understandingthe example used in this paper. A Real-Time Statechart hasa name and consists of states and transitions. Moreover, itdefines a finite set of variables that enable calculations anddata exchange. Like timed automata, a Real-Time Statechartmay also define a finite set of continuous clocks that enableclock-based timing requirements like guards, state invariants,and worst-case execution times. Clocks can be reset and com-pared to a natural number.

A statechart has exactly one initial state. Each state has aname and may additionally define state invariants and sideeffects. Each invariant defines an upper-bounded clock con-straint that refers to a clock of the statechart. All invari-ants must be true as long as the state is active, otherwisea time stopping deadlock occurs. Two possible side effectsare entry- and exit-events. An entry-event is triggered if astate gets active; an exit-event is triggered if a state is left.Both events may reset a list of clocks and execute a setof actions. Some possible actions are variable assignments(including non-deterministic choices), and operation calls.Non-deterministic choices enable to choose a number out ofa certain range non-deterministically.

A transition connects a source and target state. It definesconditions and effects. If all conditions of a transition arefulfilled, then the scheduler enables the transition, and even-tually fires it. While firing, all defined effects are executed.Regarding the concrete syntax, conditions and effects arelisted within one transition label separated by a slash.

Possible conditions of a transition are clock constraints,variable guards, a receiver message, and a synchronization.For enabling a transition, the following facts must be ful-filled: (1) Clock constraints and variable guards must be true.(2) If a receiver message is defined, then this message mustbe consumable from the in-buffer. (3) If a synchronizationis defined, then another transition with the same synchro-

nization must be able to fire together with this transition.However, this is only possible if the second transition is con-tained within a parallel statechart within the same compo-nent. Therefore, parallel behavior of a component can besynchronized.

Possible effects of a transition are transition actions, asender message, and a list of clock resets. A transition actioncan access the same structural elements as state actions. Thesender message defines which asynchronous message (andwhich message parameter values) is sent to the communica-tion partner.

A transition may be urgent or non-urgent. If it is urgent,then no time may elapse between enabling and firing thetransition; if it is non-urgent, then time may elapse betweenenabling and firing. In addition, urgent transitions have prece-dence over non-urgent transitions, i.e., as long as an urgenttransition is enabled, no non-urgent transition may fire. If twotransitions synchronize via a synchronization channel, thenthey only fire urgently if both transitions are urgent.

Real-Time Statecharts need to be deterministic except forexplicitly specified non-deterministic choices and the pointin time where non-urgent transitions fire.

Figure 6 shows the Real-Time Statecharts of the two rolesrailcab and section of the Real-Time Coordination ProtocolEnterSection (cf. Fig. 4). As they belong to one protocol,they are able to exchange messages with each other.

The informal behavior definition for these roles is as fol-lows: Initially, both roles are in state Idle. As soon as rolesection recognizes the RailCab (this behavior is not part ofthe protocol because it shall be defined within the sectioncomponent), it sends the message newSection to role rail-cab to inform that a new section is approaching. Afterwards,it switches to state RailCabApproaching. Here, it is waitingfor a request for at most 100 ms. When role railcab receivesand consumes the message, it requests for entering this sec-tion by answering with the message request and switching tostate WaitForAnswer. According to the invariant, the answermust be available after 2 s. Role section receives and con-sumes message request at most 100 ms after this state wasactivated. Then, role section switches to state CheckRe-quest. In this state, the section checks within 1,980 ms ifthe RailCab may enter. This check is not part of the proto-col but of the concrete component because each section kindmust execute different checks. However, the result is storedin variable free and may be true or false. If the section isfree, then the role section sends the message enterAllowedand switches to state EnterAllowed, else it sends the mes-sage enterDenied and switches to state EnterDenied. Forthe latter case, the role will check repeatedly, if the sectionis free. As soon as this is the case, it will send enterAl-lowed and switch to the eponymous state. As long as rolesection did not answer if entering is allowed, role railcabremains in state WaitForAnswer. However, after 2 s, it will

123


railcab

Idle

clock c1

WaitForAnswerc1 2s

Approvedc1 2min

enterAllowed /{reset: c1}

DriveOnSectionLeaveSectionc1 100ms

/ leaveSection(){reset: c1}

confirmExit /

newSection /request(){reset: c1}

Waiting

enterDenied /

enterAllowed /{reset: c1}

EnterSectionc1 100ms

confirmEntry /

/ enterSection(){reset: c1}

section

Idle RailCabApproachingc2 100ms

CheckRequestc2 1980ms

request /{free := int<0,1>}

RailCabOnSectionWaitPostActionc2 1s

leaveSection /confirmExit() {reset: c2}

[c2 1s] /

/ newSection() {reset: c2}

EnterDeniedc2 1980ms [not free] /

enterDenied(){reset: c2}

[free] /enterAllowed() {reset: c2}

EnterAllowedc2 120040ms

enterSection /confirmEntry()

[free] /enterAllowed(){reset: c2}

[c2 1s] [not free] /{free := int<0,1>}

variable boolean freeclock c2

Fig. 6 Real-Time Statecharts of role railcab and role section of Real-Time Coordination Protocol EnterSection

either receive message enterAllowed or enterDenied. Ifentering is denied then it will wait until message enterAl-lowed arrives. For simplicity reasons, we assume that enter-ing will eventually be allowed within the 1,980 ms. As soonas this happens, role railcab switches to state Approved. Asdepicted by the state invariant, the approval is valid for 2 min.Within this time, the RailCab must enter the section. As soonas this is the case, message enterSection will be sent. Rolesection will receive this message at most 120,040 ms (=2 min40 ms) after it allowed to drive on its section and will answerwith message confirmEntry. Here, the invariant of 2 min and40 ms constitutes of the 2 min the RailCab had to drive to thesection and two times the message delay for the two messagesenterAllowed and enterSection. Role railcab will consumemessage confirmEntry at most 100 ms after it sent messageenterSection. As soon as the RailCab leaves the section,it will send message leaveSection. Role section will con-firm this with the message confirmExit. After one second,the coordination for this drive through is finished and a newcoordination with the same RailCab can start again. Rolerailcab will consume message confirmExit within 100 msafter message leaveSection was sent. Then, it is also readyto enter this section again.

2.4 Compositional verification approach

The compositional verification approach of Mechatron-icUML yntactically decomposes the software model of aninterconnected mechatronic system into Real-Time Coordi-nation Protocols and components. For deriving correct verifi-cation results, it imposes one critical syntactical requirementto the MechatronicUML odel. Any connection betweentwo ports in our component model needs to be specified by aReal-Time Coordination Protocol. Each port of a component

1. Verify Abstract Protocol via Model Checking|= 1, , n

3. Verify each Component seperately via Model Checking(at least for deadlock freedom)

2. Verify Refinement|= 1, , n

AG (A ¬railcab.enterSection W section.enterAllowed) 1

ts3:Switch

r1:RailCab

delay: 20ms

:sec2 :left

railcab section

EnterSection

«refines» «refines»

locotor

P tcartsb

Al

ocotor

P denife

Rin-buffer size : 1 in-buffer size : 1

Fig. 7 Overview of the refinement approach

needs to implement one of its roles. That enables to verifythe software model in three steps as shown in Fig. 7.

In the first step, we verify each Real-Time CoordinationProtocol for safety and liveness properties (cf. Sect. 3). TheReal-Time Coordination Protocol is the abstract protocol inour approach. In our example, we verify the Real-Time Coor-dination Protocol EnterSection as we explain in Sect. 3.

In the second step, we verify whether the ports of thecomponents refine the roles of the Real-Time CoordinationProtocol correctly (cf. Sect. 4). The behavior of a port mustbe compliant to the specified role behavior, i.e. it must be alegal refinement regarding the chosen refinement definition(cf. Sect. 5). The result is the refined protocol. Moreover, thespecification of the message buffer for incoming messagesand the message transmission delay must conform to the pro-tocol specification. In our example in Fig. 7, the connectionbetween the ports sec2 and left must be compliant to theReal-Time Coordination Protocol EnterSection. In partic-ular, port sec2 must be compliant to role railcab; port leftmust be compliant to role section. Thus, we have to check ifthe two Real-Time Statecharts of Fig. 6 are refined correctly

123


by their corresponding port Real-Time Statecharts using theapproach presented in Sect. 6.

In the third step, we need to verify for each componentthat it is free of deadlocks. We may verify additional safetyand liveness properties referring to a correct interaction of thedifferent ports of a component if necessary. In our example,only one RailCab may receive permission to enter a track sec-tion. Such properties may only be verified on the componentlevel because they depend on the interaction of the differentports of one component, e.g., the ports left and right of theNormalTrackSection in Fig. 2. Eckardt and Henkler [23]introduced ideas for an approach for resolving such depen-dencies between ports automatically. In this paper, however,we rely on resolving these dependencies manually becausethe existing approach of Eckhardt and Henkler [23] has onlybeen defined for timed automata and has not yet been adaptedto Real-Time Statecharts.

2.5 Assumptions on quality-of-service characteristics

Using MechatronicUML we define platform-independentmodels that belong to the application layer of the mecha-tronic system. Thus, we assume that the system has additionalunderlying network layers that are not part of our specifi-cation. In particular, we do not consider how messages aretransported from the sender to the receiver via the underlyingnetwork layers and the physical medium. Thus, two commu-nication systems are not necessarily connected directly butmay be connected via several hops. Moreover, we abstractfrom the fact whether the two communicating componentsbelong to the same system or different systems. As a conse-quence, we do not distinguish between wired and wirelesscommunication.

Nevertheless, our models and, in particular, their verifi-cation and refinement cannot entirely ignore the timing andquality-of-service characteristics of the underlying network-ing layers and the hardware. We capture these quality of ser-vice characteristics by a set of assumptions. Then, a Real-Time Coordination Protocol may be safely executed on anetworking hardware for coordinating two systems (or com-ponents in a system) if this networking hardware guaranteesto fulfill the assumptions that were used for verification andrefinement checking. We present our assumptions in the fol-lowing.

A fundamental assumption for both, verification andrefinement checking, is that the clocks within the two rolesof the Real-Time Coordination Protocol run synchronouslyat the same rate. This also holds for any two ports thatcommunicate according to the Real-Time Coordination Pro-tocol. This assumption is realistic because there exist stan-dards like the precision clock synchronization protocol [39]that may synchronize clocks with a precision of a few

microseconds. There also exist approaches regarding hetero-geneous and adaptive hardware platforms [16].

In addition, we consider several assumptions regarding thetransmission of messages. We introduce them by followinga message from the sender to the receiver.

For a firing transition that defines a sender message, weassume that this message is immediately handed over to theunderlying network layer. This layer does the job of sendingthe message and—if needed—buffering the message beforesending. Thus, we do not use buffers for outgoing messageson the level of MechatronicUML .

As stated in Sect. 2.2, the transmission of a message fromthe sender to the receiver takes time. Therefore, the devel-oper has to define a message delay. We assume that the delaydefines the time between sending the message from the levelof MechatronicUML nd storing the message within thereceiver’s in-buffer. Thus, this delay is not just the transmis-sion via the physical medium but also the transport betweenthe underlying network layers. As a consequence, we allowthat a message is retransmitted via the physical medium if itgets lost during the transmission as long as it arrives in thereceiver’s in-buffer within the delay. However, if the under-lying network layer assumes by mistake that a message gotlost, duplicate messages may arrive at the underlying networklayer. We assume that the underlying network layer detectssuch messages using duplicate message detection mecha-nisms [42]. Thus, we assume that duplicated messages willnever be enqueued into the in-buffer.

To ease the behavior specification at the level of Mecha-tronicUML we assume that messages are never reorderedduring communication. This is realistic because we assumethat the underlying network layers are able to identify andrestore a wrong message order, e.g., by numbering outgoingmessages in ascending order.

As the developer defines the required transmission delaywith a minimum and maximum bound, we assume that themessage may only be stored within the receiver’s incomingbuffer within this interval. Thus, if the message arrives ear-lier at the receiver’s underlying network layer, the message isdelayed until the minimum bound. However, if the messagearrives later than the bounded interval at the receiver’s under-lying network layer, then the message will not be stored inthe message buffer. Additionally, it may be the case that themessage never arrives at the receiver, e.g. due to an unstablecommunication network. At the level of MechatronicUMLwe do not distinguish between a message that arrives too lateand failures in the physical transmission that lead to messageloss. In both cases, the message transmission failed and themessage is lost. However, the developer may define that theunderlying networking layer must guarantee that all trans-mitted messages eventually reach the receiver’s in-bufferwithin the transmission delay. In this case, messages do notget lost.

123


During transmission, a message may get corrupted, i.e.,(accidental) changes happen to its raw data. We assume thatunderlying network layers can detect corrupted messages andcorrect them or demand a retransmission using, for example,cyclic redundancy checks (CRCs) [42]. Thus, we assumethat corrupted messages will not be enqueued into the buffer.Moreover, on the level of MechatronicUML we do notconsider security issues like a man-in-the-middle attack [42]that can change the message’s content. For reducing thepossibility of such an attack, we assume that, for exam-ple, encryption techniques are applied in the lower networklayers.

3 Verifying real-time coordination protocols

We formally verify each Real-Time Coordination Protocolvia timed model checking to prove that each protocol fulfillsits safety and liveness properties. Instead of defining a modelchecker for Real-Time Coordination Protocols , we reuse anexisting timed model checking that is capable of verifying ourprotocols. In detail, we achieve this by a semantics preservingtransformation of the Real-Time Coordination Protocol andits Real-Time Statecharts into a network of timed automata.The timed model checker Uppaal [11] is then capable ofverifying each property. In the following, we will only givea brief insight into this topic. A detailed explanation of ourtransformation is given by Gerking [26].

Transforming Real-Time Coordination Protocols toUppaal timed automata is a challenge because timedautomata of Uppaal only support a subset of the languageelements of Real-Time Statecharts . Thus, our transformationengine has to transform all non-supported Real-Time State-chart elements into valid Uppaal models. Among others,Uppaal does not support asynchronous message exchange,state events, urgent transitions, and hierarchical states. Espe-cially in the context of asynchronous message exchange, wehave to consider the in-buffer specification and the quality-of-service assumptions of the message transmission (like mes-sage transmission delay and message loss) that lower net-working layers (including the hardware) have to fulfill (cf.Sect. 2.5).

Figure 8 illustrates our transformation approach. Foreach role and its corresponding Real-Time Statechart, a setof timed automata is generated (among others one timedautomata for each hierarchy level) and all states and tran-sitions are adapted. Similar to Knapp et al. [43], we gen-erate for each communication direction an additional timedautomaton based on a communication template. Afterwards,we transform the aforementioned language elements thatUppaal does not support into elements of Uppaal. Whiletransforming these language elements, the number of states

and transitions is typically multiplied in the resulting timedautomata.

A developer could also model the behavior of the Real-Time Coordination Protocol using timed automata instead ofmodeling the behavior using Real-Time Statecharts. How-ever, as stated before, the size of the network of timedautomata specification is much larger than the two cor-responding Real-Time Statecharts, the in-buffers, and thequality-of-service assumptions. By providing our automaticmodel transformation, we ease the manual specificationeffort and reduce the probability for failures in recurringmodels, e.g., the buffer and connector automata.

Along with the generated timed automata, the modelchecker requires as a second input safety and liveness prop-erties, which shall be verified. Therefore, in a first step, thedeveloper has to specify its requirements as safety and live-ness properties by using the timed computation tree logic(TCTL, [6]). These properties relate to the Real-Time Coor-dination Protocols and their Real-Time Statecharts. There-fore, in a second step, the properties have to be transformedso that they comply with the timed automata of Uppaal (e.g,if a state of a Real-Time Statechart is transformed into sev-eral locations of a timed automata then the TCTL propertiesneeds to replace the state with this set of locations). More-over, Uppaal does not support full TCTL (e.g., Uppaal doesnot support all variants of nested properties). Therefore, theTCTL properties at the level of MechatronicUML lso needto be transformed such that Uppaal accepts them. At present,the developer has to manually transform the safety and live-ness properties.

In our example, the Real-Time Coordination ProtocolEnterSection has the following informal requirement: “Themessage enterSection will never be sent from role railcab,until message enterAllowed is sent by role section.” Thedeveloper formalizes this into the TCTL property ϕ1 (cf.Fig. 8), which states the following:

AG (A not railcab.enterSectionMsgW section.enterAllowedMsg)

AG denotes that the formula in parentheses holds glob-ally in all states of all execution paths. Using an expressionA φW ρ form a weak until on all paths and denotes that φ

holds on all paths until ρ holds, though ρ must never be true.railcab and section represent the two roles; enterSection-Msg and enterAllowedMsg represent the two messages.

The developer manually transforms this property into thefollowing Uppaal TCTL expression:

A[] (railcab.enterSectionSent==trueimply section.enterAllowedSent==true)

Here, railcab and section are the names of two timedautomata. enterSectionSent and enterAllowedSent aretwo Boolean variables. Both are initially false. They are

123


AG (A ¬railcab.enterSectionMsg W section.enterAllowedMsg)

AG (railcab.enterSectionSent==true imply section.enterAllowedSent==true)

noitcesbacliar

EnterSection

role railcab

role section

railcab to section

section to railcab

φ1

1

formalized safety and liveness properties

delay: 20ms1 :ezis reffub-ni1 :ezis reffub-ni

Legend: RTSCTimed Automata

Automatic Model Transformation... Safety / Liveness

PropertyManual Model Transformation

Fig. 8 Transforming Real-Time Coordination Protocol EnterSection into Uppaal timed automata

set to true when their respective message was sent andset to false when location Idle is activated. These vari-ables are necessary because Uppaal does not support theoperator W and is not able to reference a message withinits TCTL expression but only locations, variables, andclocks.

The second safety property that shall be verified is “Therewill never be a deadlock in the protocol”. This safety prop-erty is formalized by the TCTL expression ϕ2: AG (notdeadlock). Using the keyword deadlock, we enforce themodel checker to search for a deadlock. If no deadlock isdetected, the property is fulfilled. The corresponding Uppaalexpression is A[] (not deadlock).

For proving that all in-buffers of the Real-Time Coor-dination Protocol never overflow, the developer specifiesthe safety property ϕ3: AG (not overflow). The corre-sponding Uppaal expression is A[] (not overflow).Here, overflow is a global variable of type boolean that isinitially false. If an in-buffer overflows, the variable is set totrue. Thus, the property states that setting to true will neverhappen on all execution paths.

The developer may also define liveness properties forproving that progress is possible within a protocol, e.g., “ARailCab can be on a section”. The developer can formal-ize this into ϕ4: EF (section.RailCabOnSection).Here, the operator E F denotes that the formula in parenthe-ses holds in the future on at least one execution path. Thus,the developer expresses this property in a state-based mannerby verifying that role section is able to access its state Rail-CabOnSection. The corresponding Uppaal expression isE<> (section.RailCabOnSection).

For each transformed safety or liveness property, thedeveloper will start the timed model checker Uppaal to ver-ify if the given network of timed automata fulfills the propertyor not. For each safety property that is not fulfilled, Uppaalcan give a counter example (a trace that leads to the viola-tion). In addition, for each liveness property that is fulfilled,Uppaal can give a trace that leads to the fulfillment. There-fore, this helps the developer to correct errors in the roleReal-Time Statecharts . In our example, Uppaal proves thatthe four properties are fulfilled.

4 Refining real-time coordination protocols to portimplementations

This section presents different possibilities of refining arole of a Real-Time Coordination Protocol according to theneeds of the component. The result of this refinement is therefined protocol (cf. Fig. 7). Typical refinement steps includeadding data exchange between different ports of a compo-nent, adding component specific functions, and accessingshared variables inside the component. That, in turn, mayrequire to add additional states and transitions to the Real-Time Statechart of the role. The behavior of the refined pro-tocol is defined by the port Real-Time Statechart. As we illus-trate below, the ports of different components may refine arole of a Real-Time Coordination Protocol differently.

In our RailCab example, normal track sections, switches,and railroad crossings are special types of track sections asshown in Fig. 1. From the point of view of a RailCab, the typeof the track section should be opaque. As a consequence, all

123


normal_section

Idle


RailCabApproachingc2 1800ms


request /{free := sectionFree}

RailCabOnSectionWaitPostActionc2 1s


[c2 1s]release! /


EnterDeniedc2 1980ms

[not free] /enterDenied(){reset: c2}

[free] acquire! /enterAllowed() {reset: c2}



[free] acquire! /enterAllowed(){reset: c2}

[c2 1s] [not free] /{free := sectionFree}

Fig. 9 Refined protocol behavior for normal sections

types of track sections refine the behavior of the role sec-tion specified by the Real-Time Statechart in the right part ofFig. 6. That enables RailCabs to register at any kind of tracksection using the Real-Time Coordination Protocol Enter-Section without needing to distinguish the types. However,each of the three types of track sections requires the behaviorto be refined differently as we illustrate in the following.

We start with the normal track section. A normal tracksection is a track section that has only tracks but no switches,stations, or any kind of crossing. A normal track section mayneed to communicate with more than one RailCab at a time,e.g., if the track section succeeds a switch. Then, the decisionwhether the track section is free does not only depend on thecommunication of a single port with a RailCab, but it dependson the communication of several ports with RailCabs. This isbecause if one port permits a RailCab to enter the track sec-tion, all other ports have to deny. Thus, the decision whetherthe track section is free can only be made within the com-ponent but not within the Real-Time Coordination Protocol .As a consequence, we need to refine the track section behav-ior as shown in Fig. 9. We highlighted the parts that werechanged or added with respect to the Real-Time Statechartin the right part of Fig. 6 in a different color. In particu-lar, the Real-Time Statechart for ports of the normal tracksection reads the variable sectionFree at the transition fromRailCabApproaching to CheckRequest which is declaredinside the component. If the track section is free, then theReal-Time Statechart needs to synchronize via the synchro-nization channel acquire with the internal Real-Time Stat-echart of the component for reserving the track section. Aspart of this synchronization, the internal Real-Time State-chart changes the value of sectionFree to false.

Having consumed the message newSection, the Real-Time Statechart of the role section gives a limit of 1,980 msfor deciding whether the section is free. The normal track sec-tion, however, only needs to read the variable sectionFreethat is defined in the internal behavior of the component Nor-


Switch (ts3)

RailroadCrossing (ts4)


RailCab 2

RailCab1

Fig. 10 Deadlock resulting from RailCab stopping on a switch

malTrackSection for that decision. This only takes a smallamount of time. Therefore, we relax the invariant of the stateRailCabApproaching from 100 to 1,800 ms to increase theprobability that a RailCab currently driving on that sectionhas already left. As a result, the normal track section willstore the request in the in-buffer beyond the point in timethat was allowed by the abstract protocol.

The second type of track section is the switch. In additionto the requirements of a normal track section, switches havethe requirement that a RailCab must not stop on a switch.In particular, a RailCab must stop before entering the switchif the subsequent section is not free. Consider the situationshown in Fig. 10. RailCab 1 entered the switch ts3 driving tothe right. It needs to stop because the subsequent section ts4is occupied by RailCab 2 driving to the left. Since RailCab1 blocks the switch, RailCab 2 cannot pass. If RailCab 1waited on ts1, i.e. before the switch, RailCab 2 would havebeen able to pass.

For preventing such situations, we only allow RailCabs toenter a switch if the subsequent track section is free as well.As a consequence, the switch needs to communicate withthe subsequent track section if it receives a request from aRailCab.

Figure 11 shows the resulting Real-Time Statechart fora switch. The switch also uses an additional state, which iscalled WaitForTrack. At the transition from RailCabAp-proaching to WaitForTrack, the Real-Time Statechart syn-chronizes with the port followingSection of the switch (cf.Fig. 2) via the synchronization channel nextSectionFree.Then, the port followingSection communicates with the sub-sequent track section for checking whether that track sectionis free. If it is, the port synchronizes via sectionFree, oth-erwise it synchronizes via sectionOccupied. Only if theswitch itself and the subsequent track section are free, thenthe Real-Time Statechart may switch to EnterAllowed andgive permission to enter the switch to the RailCab.

Finally, we consider railroad crossings where cars andpedestrians cross the tracks. In addition to the requirementsof a normal track section, we must close the gates beforeallowing a RailCab to enter. The gates needs to remain closed

123


Fig. 11 Refined protocolbehavior for switches

switch

Idle

variable boolean free, boolean firstclock c2



request nextSectionFree! /{first := true}

RailCabOnSectionWaitPostActionc2 1000ms


[c2 1000ms]release! /



[first and (not free)] /enterDenied() {reset: c2}

[free] acquire! /enterAllowed() {reset: c2}




WaitForTrackc2 1900ms

exit/ {free := sectionFree}

sectionFree? /sectionOccupied? /{free := false}

[free] nextSectionFree! /{first:= false; reset: c2}

[(not first) and (not free)] /{reset: c2}

rail_road_crossing

Idle





RailCabOnSection

WaitOpenGatec2 1s

openGate!leaveSection /confirmExit(){reset: c2}

[c2 1s]gateOpened? /

/ newSection(){reset: c2}


[not free] /enterDenied() {reset: c2}




ClosingGatec2 1980ms

[free] closeGate! /{reset: c2}

gateClosed? /enterAllowed(){reset: c2}

[free]closeGate! /

Fig. 12 Incorrectly refined protocol behavior for Railroad crossingsdue to a timing error in state CheckRequest

as long as the RailCab drives on the railroad crossing andneed to be opened after the RailCab left.

Let us suppose that an inexperienced developer had thetask to implement the component RailRoadCrossing inFig. 2. As part of this task, he refined the Real-Time Stat-echart for the track section as shown in Fig. 12. In particular,he added an additional state ClosingGate where the rail-road crossing waits for the gates to close. At the transitionfrom CheckRequest to ClosingGate, the Real-Time Stat-echart synchronizes with the internal Real-Time Statechartof the railroad crossing using the synchronization channelcloseGate for closing the gate. After the gates have beenclosed, the internal behavior synchronizes via gateClosed

and the Real-Time Statechart switches to EnterAllowed.Although the specified behavior looks fine at a first glance,it has not been refined correctly due to a timing error in stateCheckRequest. The timing error is subtle, but it causes theinteraction of railroad crossings with RailCabs to be unsafe.In particular, the example shows that such timing errors arehard to detect manually. We will show in Sect. 6 how wedetect such incorrect refinements using our automatic ver-ification procedure. In addition, we will derive a correctlyrefined Real-Time Statechart.

Although each of the three Real-Time Statecharts intro-duced above refines the same abstract protocol behavior, theresulting refined Real-Time Statecharts look quite different.Even though the Real-Time Statecharts are only of mediumsize, it is already very hard to decide manually whether theyhave been refined correctly. We will show in the followingsections, how we automatically derive a suitable refinementdefinition for each of the three track sections and verify therefinement using our automatic refinement check. A suitablerefinement definition guarantees that all verified safety andliveness properties are preserved by the refined protocol, butit restricts the developer building the refined protocol only asmuch as necessary.

5 Refinement definition and selection

The refined protocols introduced in the previous section needto fulfill the same properties that have been verified for theabstract protocol in Sect. 3. We can conclude that the refinedprotocol fulfills these properties if it is refined correctly withrespect to a formal refinement definition.

123


In general, a refinement definition relates an abstractmodel and a refined model of the same system. In ourapproach, the abstract model is given by the abstract pro-tocol while the refined model is given by the refined protocolas shown in Fig. 7. The refinement definition defines how thebehavior defined by the refined protocol may deviate from thebehavior defined by the abstract protocol such that verifiedproperties still hold. That means, if the refinement defini-tion is fulfilled, we can avoid any explicit verification of therefined protocol.

In Sect. 5.1, we present the six most relevant refine-ment definitions for interconnected mechatronic systems.They differ in the properties that they preserve and mod-ifications that they allow. In a little more detail, a restric-tive refinement definition guarantees that verified safetyand liveness properties, like properties ϕ1, ϕ2, and ϕ3 inSect. 3, still hold for the refined protocol. This is crucialfor our compositional verification approach. A less restric-tive refinement definition leaves developers with more flex-ibility to adapt the abstract protocol to a component and,thus, allows for more possible refined protocols. Finding asuitable refinement definition is, thus, a trade-off betweenflexibility upon building the refined protocol and propertiesthat are preserved by the refined protocol. In Sect. 5.2, wepresent an automatic approach for selecting a suitable refine-ment definition for refinements of a given abstract proto-col.

5.1 Refinement definitions

In this section, we explain the six most relevant refinementdefinitions for interconnected mechatronic systems. Four ofthese, simulation [8], bisimulation [8], timed simulation [56],and timed bisimulation [56], are especially well-known defi-nitions. Each of them has been shown to preserve a particularclass of verified properties. We additionally consider the lesswell-known timed ready simulation [40] and relaxed timedbisimulation [34] because they are particularly useful forrefining MechatronicUML odels. In this paper, we keep thedescriptions of the refinement definitions informal becausethe formal definitions are not required for understanding thepresented concepts. We refer the interested reader to theliterature given above for formal definitions of all refine-ments.

All of the considered refinement definitions only allow therefined protocol to include sequences of sent and receivedmessages that are already specified in the abstract protocol.None of them allows the refined protocol to add additionalsequences of messages. As a minor extension to the exist-ing definitions, we require that the refined protocol correctlyrefines non-deterministic choices contained in the abstractprotocol. That means after a choice, the refined protocol

Simulation

Finite Automata

ACTL*

Bisimulation

Finite Automata

CTL*

Timed Simulation

Timed Automata

ATCTL

Timed Bisimulation

Timed Automata

TCTL

Timed Ready Simulation

Timed Automata with urgent Transitions

ATCTL + urgent Sem.

Relaxed Timed Bisimulation

Timed Automata

CTL, ATCTL, TCTL for output events

Legend: applicable for … modelspreserves … formulas A is less restrictive than B

Name of Refin. Def. A B

Fig. 13 Overview of the considered refinement relations

needs to conform to the abstract protocol that made the samechoice.

For the informed reader who is an expert in refinements,please note that we only consider so-called weak variantsof the refinement definitions [56]. These weak refinementsabstract from any internal behavior which is defined by tran-sitions not carrying a message but performing an internalcomputation except for non-deterministic choices. For inter-connected mechatronic systems, it is sufficient to consideronly weak variants of refinement definitions. The internalcomputations of a component that result from the messageexchange are not visible to a communication partner and,thus, are not relevant for the message exchange defined bythe protocol. In particular, the refinement only needs to ensurethat the next message after such internal computation is sentin the right time interval.

Figure 13 shows how the different refinement definitionsintroduced in the following paragraphs relate to each other.If an arrow points from refinement definition a to b, then ais less restrictive than b. That means b imposes additionalrestrictions on the refined behavior thereby allowing fewermodifications. For each refinement, the second row of thecorresponding box lists the types of automata models thatthe refinement can be used for. The third row indicates whichclasses of properties are preserved by the refinement. We willexplain these aspects shortly when introducing the individualrefinements.

The upper part of Fig. 14 shows a timing diagram foran excerpt of the role behavior defined by the Real-TimeStatechart of the role section in Fig. 6. The timing diagramshows when (in which time interval) the messages new-Section, request, enterAllowed, and enterDenied can besent or received. Here, section may send the message new-Section at an arbitrary point in time. After sending new-Section, the clock c2 is reset to 0 and request must bereceived within 100 ms. Then, either enterAllowed or enter-

123


t

Refined Protocol RTBSBS TS TBSTRS

c20

0100ms 1980ms

/ newSectionrequest /

enterAllowed, /enterDenied

S

Abstract Protocol

Legend:

1800ms

role section

example 2/ newSection

request //enterAllowed, /enterDenied





normal section/ newSection


switch & crossings



TBS: Timed Bisim., TRS: Timed Ready Sim., RTBS: Relaxed Timed Bisim., TS: Timed Sim., BS: Bisim., S: Simulation

/ enterAllowed, / enterDenied : intervals in which transitions sending enterAllowed (upper line) or enterDenied (lower line) are enabled

: point in time of sending/receiving : extended activation interval of a transition : reduced / removed enabled interval of a transition

request / : interval in which a transition receiving request is active /enterDenied: the transition sending enterDenied has been removed

/ newSectionrequest /

enterAllowed, /enterDenied

: refinement definition is fulfilled for the example : refinement definition is violated for the example

Fig. 14 Example for illustrating the differences between refinement definitions

Denied must be sent until c2 reaches 1,980 ms. The lowerpart of Fig. 14 gives six examples for port Real-Time Stat-echarts. Each refines the role section in a different way,resulting in different intervals for sending or receiving theaforementioned messages. Each of the examples showcasesa different combination of changes to the intervals, e.g, theextension of intervals for received messages but not for sentmessages. As a consequence, each example fulfills a dif-ferent set of refinements as indicated in the correspondingrow in the table on the right. In the following, we introduceall six refinement definitions from left to right with respectto the table in Fig. 14. Along with the description of eachrefinement definition, we will refer to Fig. 14 to illustrate thedifferences.

5.1.1 Simulation

The refinement definition simulation requires that the refinedprotocol only includes sequences of messages that are alreadyspecified by the abstract protocol. The refined protocol, how-ever, may remove sequences of messages. Thus, simulationpreserves any CTL*2-formulas [8] only containing ∀-pathquantifiers. We refer to this subset of CTL* as ACTL* as the∀-path quantifier is written A in CTL*. ACTL* includes alllinear temporal logic (LTL) formulas and all exclusively ∀-quantified CTL formulas. Formulas with an ∃-path quantifierare not preserved because the paths fulfilling the property

2 Computation tree logic (CTL), generalization of CTL (CTL*).

might be removed. As shown in Fig. 13, simulation is theleast restrictive refinement considered here. All other refine-ment definitions at least require a simulation to hold andadditionally define further restrictions on the refined behav-ior.

In example 1 in Fig. 14, the message enterDenied isremoved in the refinement, while enterAllowed can still besent later. The interval for receiving the message request,on the other hand, is shortened. All these modifications, i.e.the removal of messages and arbitrary changing of the tim-ing, are allowed by simulation. However, all other refinementdefinitions explained here are violated by this example.

5.1.2 Bisimulation

When general CTL* formulas need to be preserved for therefined protocol, including those with ∃-path quantifiers, sim-ulation is not restrictive enough. In those cases, we usebisimulation. Bisimulation preserves full CTL* by allow-ing neither addition nor removal of message sequences dur-ing refinement. In other words, bisimulation requires thatthe refined protocol includes exactly the same sequences ofmessages as the abstract protocol. Only the timing of mes-sages may be different, since bisimulation only constrains theorder of messages. Example 2 in Fig. 14 fulfills this refine-ment, unlike example 1. This is because no communicationis removed by the refinement in example 2, while changingthe timing is allowed.

123


5.1.3 Timed Simulation

For systems with real-time behavior, variants of simulationand bisimulation have been developed that impose condi-tions on the timing of messages. These conditions are nec-essary to refine protocols of mechatronic systems that definereal-time behavior. In particular, they also preserve temporallogic formulas regarding the timing of messages which canbe expressed, e.g., in TCTL. Like the (untimed) simulation,variants of a timed simulation only preserve TCTL proper-ties containing ∀-path quantifiers. We refer to this subset ofTCTL as ATCTL. Variants of a timed bisimulation, on thecontrary, also preserve TCTL properties containing ∃-pathquantifiers.

Timed simulation [56] requires that the refined protocolonly includes sequences of messages that are already spec-ified by the abstract protocol. In addition, the refined proto-col may only specify sending or receiving a message in thesame or a reduced time interval. In Fig. 14, the refinement inexample 3 and those in the following examples fulfill timedsimulation because time intervals are only reduced but neverextended.

5.1.4 Timed Ready Simulation

If the abstract protocol uses urgent transitions, timed sim-ulation does work properly for compositional verificationapproaches. Consider, for example, the abstract protocolEnterSection in Fig. 7. If, according to timed simulation,port sec2 correctly refines role railcab, and port left cor-rectly refines role section, then usually the combination ofsec2 and left also correctly refines the abstract protocolEnterSection. However, with urgent transitions in railcabor section, this conclusion is not valid anymore, as shown byJensen et al. [40]. As a solution, [40] presents a new refine-ment definition: the timed ready simulation. In addition tothe conditions of a timed simulation, it requires the refinedprotocol to preserve all urgent transitions including their tim-ing. In Fig. 14, example 4 fulfills the timed ready simulationbecause the interval of the urgent transition for receiving themessage request is not changed. In additions, the behaviorof the switch and the crossing fulfills the timed ready simu-lation because it sends and receives all messages in the sametime intervals as the role section.

5.1.5 Timed Bisimulation

A timed bisimulation requires that the refined protocolincludes exactly the same sequences of messages and speci-fies exactly the same time intervals as the abstract protocol.Therefore, timed bisimulation is a very strong refinementdefinition (cf. Fig. 13) and preserves all TCTL properties.The timed bisimulation is only fulfilled if the intervals of the

refined behavior are identical to that of the abstract behav-ior (last row). Still, the timed bisimulation allows to modifythe abstract protocol during the refinement step by insertinginternal computations between the sent and received mes-sages.

5.1.6 Relaxed Timed Bisimulation

If two mechatronic systems coordinate on a specific task, itoften does not matter when messages are received but onlythat the answer is on time. In our example, it is irrelevant fora RailCab at what point in time the track section processesits request. For the RailCab, it only matters that it receivesthe answer in time. This observation enables to relax thestrict requirements of a timed bisimulation for such scenar-ios. We call this relaxation relaxed timed bisimulation [34].The relaxed timed bisimulation enables to extend the timeintervals for received messages, but requires that the upperbounds of time intervals for sending messages are exactlythe same as in the abstract protocol. It preserves all CTL*-formulas and all TCTL formulas only referring to the latestsending of messages.

A consequence of delayed receiving of messages in therefined protocol is that messages are taken out of the in-bufferlater than in the abstract protocol. To prevent a buffer over-flow, we require the refined protocol to have an in-buffer thatis sufficiently larger than that of the abstract protocol. Oth-erwise, the relaxed timed bisimulation cannot be applied.Another precondition is that the verified protocol is bidi-rectional. In unidirectional protocols, there is one port thatexclusively receives messages and relaxed timed bisimula-tion would, consequently, not restrict its timing at all.

In the refinement of section to the normal track section,the Real-Time Statechart (cf. Fig. 9) will still receive requestafter 1,800 ms, which violates the timed bisimulation. Also,it violates the timed ready simulation because the transitionfor request is urgent in this case and its interval may, there-fore, not be changed. The relaxed timed bisimulation andweaker refinements, however, allow this delayed receivingof request.

All of the refinement definitions mentioned above rely onthe assumptions stated in Sect. 2.5. If a system does not fulfillthese assumptions, the refinement definitions presented inthis section cannot guarantee that the verified properties stillhold for the refined system.

5.2 Selection procedure

We summarized the characteristics of the different refine-ments in a decision tree. Based on this decision tree, weimplemented an automatic selection procedure for support-ing the developers in selecting the most suitable refinementdefinition for their given role Real-Time Statechart and the

123


Fig. 15 Decision tree forselecting a refinement definition no clocks clocks

Simulation Bisimulation

only∀-quantifiers else

only ∀-quantifiers

Timed Ready Simulation

urgent transitions

no urgent transitions

Relaxed Timed Bisimulation

Timed Simulation

same buffer

larger buffer

Timed Bisimulation

larger buffer

same buffer

else

bidirec-tional

unidirec-tional

Legend: ... Refinement Definition Conditional EdgeChoice

properties to preserve. We illustrate the selection of a refine-ment definition using the three refinements of the abstractprotocol behavior of section explained in Sect. 4 as exam-ples.

Figure 15 summarizes the selection algorithm in the formof a decision tree. The algorithm selects the most suitablerefinement definition among the six definitions consideredhere. The most suitable refinement definition is the one thatis the least restrictive for the given kind of models while stillpreserving all properties that were verified for the abstractprotocol.

We can extract the necessary information for deriving adecision based on the decision tree by a syntactical analy-sis of both, the properties and the Real-Time Statecharts .For the first decision in the tree, we need to analyze whetherthe Real-Time Statecharts use clocks or not. Untimed refine-ments are not suited for models that define time-dependentbehavior. Second, we check whether the properties onlycontain ∀-path quantifiers as, e.g., Property ϕ1 and Prop-erty ϕ2 in Sect. 3, or whether they also contain ∃-path quan-tifiers as, e.g., Property ϕ3. As discussed above, a variantof bisimulation is required to preserve formulas with ∃-path quantifier. Third, for timed refinements we need to takeinto account whether the port Real-Time Statechart uses alarger buffer for incoming messages than the role Real-TimeStatechart it refines or whether the buffer size remains thesame. While our relaxed timed bisimulation is less restric-tive than the alternatives, it can only be used in cases wherea larger buffer is available. To decide whether to select timedready simulation or timed simulation we also need to ana-lyze if the role Real-Time Statechart uses urgent transi-tions. Finally, relaxed timed bisimulation is only applica-ble for bidirectional protocols. If the protocol is unidirec-tional, we need to apply the more restrictive timed bisimula-tion.

In our example in Sect. 3, all three refined Real-Time Stat-echarts for section use clocks. Therefore, the decision algo-rithm selects the second branch when checking for clocks in

all three cases. All automata need to preserve Properties ϕ1,ϕ2, and ϕ3. As Property ϕ3 contains an ∃-path quantifier, thedecision algorithm selects the else-branch when checkingfor “only ∀-quantifiers”. Therefore, the only suitable refine-ments remaining are relaxed timed bisimulation and timedbisimulation.

The refined Real-Time Statechart of the normal sectionshown in Fig. 9 uses a larger buffer than the abstract sec-tion because it needs to store received messages longer thandefined in the abstract protocol (cf. Sect. 4). As a result,the decision algorithm selects relaxed timed bisimulation forchecking this refined Real-Time Statechart . The other refinedReal-Time Statecharts of switch (cf. Fig. 11) and crossing(cf. Fig.12) do not use a larger buffer. Therefore, the deci-sion algorithm selects timed bisimulation as the refinementto check.

6 Verifying refinement

We verify refinements from roles to ports (cf. Sect. 4) by usingan approach based on test automata. Test automata have beenintroduced by Jensen et al. [40] as an approach for verify-ing refinements for UPPAAL timed automata. The basic ideaof their approach is to encode an abstract automaton A andthe conditions for a correct refinement as an automaton TA,called test automaton. Test constructs in TA encode whichchanges are allowed and which are not, according to the con-ditions of the particular refinement definition (cf. Sect. 5).The test automaton TA is then used to verify whether a refinedautomaton R is a correct refinement of A according to thegiven refinement definition. If and only if the conditions ofthe refinement definition are not fulfilled by R, a special errorstate Error in TA becomes reachable via the test constructs.They use a reachability analysis for deciding whether Erroris reachable or not.

Figure 16 gives an overview of our process for refinementchecking based on test automata in MechatronicUML Our

123


Role RTSC A Port RTSC R

Test RTSC T A

Parallel Test System (TA || Radj)

[Error State Reachable+ Counterexample ]

Construct Test Automaton

Parallel Composition

Reachability Analysis

[else]

false true

Refinement Definition

Adjust Refined System

RTSC Radj

Refinement Selection

Safety/Liveness Properties

Legend: ... Artifact Control/Data Flow... Algorithm

Fig. 16 Refinement check using test automata

test automaton construction generalizes and extends the con-struction as given by Jensen et al. [40]. The original construc-tion only checks for a timed ready simulation. Our approach,in contrast, supports checking all six refinement definitionsthat we explained in Sect. 5. Moreover, we extend the originalapproach of [40] by introducing additional test constructs.

As described before, the developer needs to define theReal-Time Statecharts A and R. A is a Real-Time Statechartof a role of a Real-Time Coordination Protocol while R is aReal-Time Statechart of a port of a component that refines A(cf. Sect. 2). These Real-Time Statecharts and the safety andliveness properties of the Real-Time Coordination Protocolof A serve as the input for our approach. Then, we select asuitable refinement definition automatically using our deci-sion tree in Fig. 15. Next, we construct the test automatonTA based on A and the selected refinement definition. In ourapproach, the test automaton is a Real-Time Statechart aswell. Therefore, we call it the Test RTSC. We explain its con-struction in Sect. 6.1. In addition, we need to adjust R to Rad j

for checking the conditions of the different refinement defini-tions. In particular, TA needs to communicate synchronouslywith R, i.e., without the additional delay of asynchronouscommunication, for testing the intervals in which R sends orreceives messages. Hence, R needs to be adjusted accord-ingly as described in Sect. 6.2. Thereafter, we compose TA

and Rad j to the parallel test system TA ‖ Rad j using the ‖-operator of UPPAAL [12]. Finally, we insert TA ‖ Rad j intoa reachability analysis [12] that checks whether the specialerror state Error is reachable (Sect. 6.3). If the error state isreachable, the port Real-Time Statechart is not refined cor-rectly and our algorithm returns a counterexample. If the

error state is not reachable, the refinement is fulfilled. Allalgorithms shown in Fig. 16 have been entirely automatized.

6.1 Construction of the test automation

Figure 17 presents the schema for the construction of the partof TA which is derived from a single transition S −→ S′ ofthe role Real-Time Statechart A. The construction schemaneeds to be applied to each transition S −→ S′ of A.Figure 18 shows an excerpt of a test RTSC SectionTA_TBSthat has been constructed by applying the constructionschema to each transition of the role section (cf. Fig. 6)for checking a timed bisimulation. In the following, we willrefer to this example to illustrate the constructs created aspart of TA.

TA contains test constructs for checking the different con-ditions of the refinement definitions. In particular, the testconstructs check for allowed communication (Case 1), for-bidden communication (Cases 2a and 2b), and required com-munication (Cases 3a, 3b, and 3c) in R. Which of these testconstructs are used in TA depends on the refinement defini-tion to be checked as we describe below.

Case 1 includes allowed communication in TA, i.e.,sequences of messages that are defined by A. We includeallowed communication in TA because all refinement defini-tions allow these sequences of messages to be included in R.The white states ST A and S′

T A in the schema correspond to thestates S and S′, respectively, of A. The transitions betweenwhite states correspond to the role behavior. For each tran-sition S −→ S′ in A, we add a corresponding transitionST A −→ ST A

′ to TA. The transition labels are explained inSect. 6.1.1. The white states in the example in Fig. 18 andthe transitions between them have been created to handleallowed communication.

Case 2 checks for forbidden communication, i.e., mes-sages that may not be sent or received by R if A is instate S. Therefore, we add the special error state Error toTA and create transitions from white states to Error. Here,we need to distinguish Cases 2a and 2b. Case 2a checkswhether R sends or receives a message that is not definedby any outgoing transition of S in A. These messages mayalso not appear in R because all refinement definitions for-bid to add new sequences of messages to R. Therefore,we add one transition ST A −→ Error for each messageμ that is not specified at any outgoing transition of S inA. If R adds a forbidden message, these transitions makeError reachable. Case 2b checks whether a message μ thatis indeed offered by an outgoing transition of S in A issent or received in the right time interval by R. We addone transition ST A −→ Error for each time interval inwhich μ may not be sent or received in R according to thegiven refinement definition. This case is only checked byrefinement definitions that impose conditions on the timing

123


Fig. 17 Construction schema for our test automata

SectionTA_TBS

Error

RailCabApproachingTA

CheckRequestTA

[c2 100ms] request! /{reset: cTA}

EnterDeniedTA

[not free] [c2 1980ms]enterDenied? /{reset: c2, cTA}

[free] [c2 1980ms]enterAllowed? /{reset: c2, cTA}

EnterAllowedTAenterAllowed? /{reset: c2, cTA}

...

variable boolean freeclock c2,cTANeutral

Error

newSection! request! request? ...

C3aIdle_newSection?

newSection?C3aRailCabApproaching_request!

[c2 100ms]

request!

IdleTA newSection? / {reset: c2, cTA}

request?newSection!newSection?...

...

...

C3aCheckRequest_enterDenied? C3aCheckRequest_enterAllowed?

Neutral

enterDenied!enterAllowed!request! ...

[c2 1980ms][free]

[c2 > 1980ms] enterDenied?

[c2 > 1980ms] enterAllowed?

[c2 1980ms][not free]

enterDenied?

enterAllowed?

[c2 > 100ms]request!

Error

enterAllowed!enterDenied!enterDenied?...

C3aEnterDenied_enterAllowed?

enterAllowed?

[not free] enterAllowed?

[free] enterDenied?

Fig. 18 Example test RTSC (excerpt) for checking the timed bisimulation for section

123


Table 1 Cases checked for each refinement definition and definition of widen function

Sim. Bisim. Timed sim. Timed ready sim. Relaxed timed bisim. Timed bisim.

Cases 1, 2a 1, 2a, 3c 1, 2a, 2b 1, 2a, 2b, 3a (urgent) 1, 2a, 2b, 3b (sending), 3c (receiving) 1, 2a, 2b, 3a

Widen true true cc ∧ I cc ∧ I cchigh ∧ I (sending), true (receiving) cc ∧ I

of messages, e.g., timed simulation and timed bisimulation.In Fig. 18, we included several Error states to improve thereadability of the figure. All transitions from white states toError in Fig. 18 have been created according to Cases 2aand 2b. We explain the transition labels of these transitionsin Sect. 6.1.2.

Case 3 checks for required communication, i.e., sequencesof messages that must be included in R according to therefinement definition. In particular, all variants of bisimula-tion and the timed ready simulation require that R containsparticular sequences of messages that are contained in A.We add a neutral state Neutral to TA that is reached when arequired message is correctly sent or received by R. Case 3 isfurther subdivided into Cases 3a to 3c. Each case is associatedwith one particular kind of test state C X (X ∈ [3a, 3b, 3c])for checking the corresponding conditions. TA contains onesuch state for each required message μ that needs to beincluded in R. In addition, we add transitions ST A −→ C X ,C X −→ Neutral, and C X −→ Error to TA.

The Cases 3a–3c check for different time intervals whereμ needs to be sent or received by R. Which case is useddepends on the particular refinement definition that is applied(cf. Table 1). Case 3a with the associated state C3a checksthat R sends or receives μ in exactly the same time inter-val as A. Case 3b with the associated state C3b checks thatR does not send or receive μ later than A. Finally, Case 3cwith the associated state C3c checks that R eventually sendsor receives μ not checking for time intervals. If R violatesthe conditions imposed by the refinement definition, transi-tions C X −→ Error are enabled and make Error reach-able. Otherwise, the transitions C X −→ Neutral lead tothe neutral state. In the example in Fig. 18, the state Neu-tral, the C3a-states and all in- and outgoing transitions of theC3a-states have been created according to Case 3a to checkfor required communication according to the timed bisimu-lation. We define the labels of the transitions from and to C Xin Sect. 6.1.3.

Table 1 summarizes which of the aforementioned casesneed to be checked for which refinement definition. In addi-tion, Table 1 summarizes the definition of the function widenused at the transitions ST A −→ ST A

′ in TA. We explain thisfunction along with the labels of the transitions in the follow-ing (Sects. 6.1.1–6.1.3). Finally, we illustrate how we con-sider non-deterministic choices, which may be contained inrole Real-Time Statecharts , in our construction (Sect. 6.1.4).

6.1.1 Label definitions for allowed communication (case 1)

We need Rad j to be able to synchronize with TA when-ever the corresponding communication in R is allowed bythe refinement definition. Then, the parallel compositionTA ‖ Rad j can synchronously execute all allowed communi-cation sequences. This is necessary to check all allowed com-munication behavior for deviations forbidden by the refine-ment definition. Thus, we create the labels for the transitionsST A −→ ST A

′, modeling the message sequences allowed inR, as follows. For the abstract transition S −→ S′ with thesent message μout or the received message μin , we createcorresponding synchronizations μout ? or μin !, respectively,for ST A −→ ST A

′. For simplicity, we assume that transi-tions do not both send and receive messages at the sametime. However, this is not a general limitation, as transitionswith two messages can be split into two transitions with onemessage each and an intermediate state. As the transitionST A −→ ST A

′ should only be enabled if the conditions forS −→ S′ are fulfilled, we assign the same guard g to it.

In the example SectionTA_TBS (cf. Fig 18), the tran-sition from IdleT A to RailCabApproachingT A defines thesynchronization newSection?. It has been derived from thetransition Idle to RailCabApproaching in the role Real-Time Statechart for section A that can send newSection. If aport Real-Time Statechart R can send newSection on a tran-sition leaving the initial state, then Rad j will define the corre-sponding synchronization newSection! (cf. Sect 6.2). Then,in TA ‖ Rad j , both Real-Time Statecharts can synchronizeon newSection and (synchronously) move to the next state.

Untimed simulation and bisimulation as well as relaxedtimed bisimulation allow R to extend the time intervalsdefined in A. The clock constraint cc of each transitionST A −→ ST A

′ in TA is extended or removed accordingly bythe function widen (cf. Fig. 17). Depending on the refine-ment definition to check, given by re f , widen returns a mod-ified clock constraint.

To identify forbidden communications in R that areoffered after the invariants of states in A, these invariantsmay not be carried over to ST A. Otherwise, they would pre-vent TA from reaching the time at which the violation of therefinement occurs. The intersection of the clock constraint ccwith the original invariant I of S within the widen functionensures that the removal of the invariants does not add addi-tional behavior (except where allowed by the refinement). For

123


a similar reason we create all transitions ST A −→ ST A′ car-

rying a message non-urgent, even if the transition S −→ S′is urgent in A. Otherwise, TA would only check the transi-tion for the earliest point in time and not for the full interval.Again, this could prevent TA from detecting violations ofrefinements by R.

Table 1 shows the definition of the function widen forthe different refinement definitions. For untimed simulationand bisimulation, widen returns a clock constraint that isalways true because these refinement definitions do not con-sider timing. For timed simulation, timed bisimulation, andtimed ready simulation,widen returns the original clock con-straint cc, intersected with the invariant I of S (or true, ifthere is no invariant). This clock constraint defines the sametime interval as specified for the abstract transition S −→ S′,because these refinements do not permit R to extend any timeintervals of A.

For relaxed timed bisimulation, the clock constraintreturned by widen depends on the transition S −→ S′. If thetransition S −→ S′ receives a message, the returned clockconstraint is always true. For these transitions, the relaxedtimed bisimulation allows to extend time intervals arbitrar-ily. If S −→ S′ sends a message, the returned clock constraintis the intersection of cchigh , i.e. the upper bound of the clockconstraint cc of S −→ S′, and the invariant I of S. This clockconstraint models the condition of relaxed timed bisimula-tion that messages in R may not be sent later than in A. Earliersending, however, is permitted by this clock constraint.

Since SectionTA_TBS in Fig. 18 checks for a timedbisimulation, the widen function is defined as cc ∧ I . Sincethere are no clock constraints at the transitions in the excerpt,the clock constraints are set to the invariant for the out-going transitions of RailCabApproachingT A and Check-RequestT A. As IdleT A and EnterDeniedT A also have noinvariants, their outgoing transitions have no clock con-straints at all.

6.1.2 Label definitions for forbidden communication(case 2)

There are two kinds of forbidden communications in anystate S of A that we need to check for R. We marked theseas 2a and 2b in Fig. 17. First, if S has no outgoing transitionthat sends or receives a message, R may not send or receivethis message either while TA is in S (Case 2a). Second, if Shas an outgoing transition that sends or receives a message,R may send or receive this message while TA is in S but notoutside of the allowed time interval (Case 2b).

Case 2a: illegal messageWe create transitions to check for additional messages in R,which are not defined by A in the current state S. If any suchmessages are sent or received by R, Error becomes reachable

in TA ‖ Rad j via these transitions. We need this check for allrefinements because none allows adding additional messagesequences. In more detail, one transition ST A −→ Error isdefined for each message m in the alphabet of A which isnot sent or not received by any outgoing transition S −→ S′in S (cf. Fig. 17, 2a). These transitions must synchronizewith Rad j if Rad j sends or receives the forbidden messagem. Note that Rad j (cf. Sect. 6.2) defines the synchronizationm? if R receives m and m! if R sends m. Therefore, the tran-sition defined for a message m carries a synchronization m!if m is not received in S to synchronize with m? defined byRad j . Accordingly, the transition defined for a message mcarries a synchronization m? if m is not sent in S to synchro-nize with m! defined by Rad j . If both applies, one separatetransition S −→ Error is created for each case. We definethe clock constraint of ST A −→ Error to be always truebecause Rad j may never send or receive m, regardless oftime.

In SectionTA_TBS in Fig. 18, the transitions from whitestates to Error represent the transitions constructed fordetecting forbidden communications. Transitions visualizedwith thick lines represent a set of transitions containing alltransitions created according to (2a), i.e. they represent onesending and one receiving transition for each message in thealphabet of A, except for the allowed communications. Forinstance, there is no transition with newSection? createdfrom IdleT A to Error because A can send newSection inIdleT A and it is, thus, also allowed for R.

Case 2b: legal message at illegal timeFor each message μ in the alphabet of A, which is sent(μout )or received(μin) by a transition S −→ S′ in S (cf. Fig. 17, 2b),further transitions ST A −→ Error are defined. These transi-tions check whether messages are sent in R when the precon-ditions for sending them would not be fulfilled in A. We createtwo sets of transitions to check this. First, we create transi-tions to check for messages that are sent or received eventhough the guard g of the corresponding transition S −→ S′is not fulfilled. Second, we create transitions to check whetherthe time intervals for sent or received messages in R areextended in comparison to the time intervals defined in A.We need this check for all timed refinements because they donot allow R to extend the time intervals of A. Relaxed timedbisimulation allows extended time intervals for received mes-sages in R but forbids later sending of messages.

For both cases, each transition defined for μin carries asynchronization μin ! and each transition defined for μout

carries a synchronization μout ?. If R sends or receives themessage μ when no transition defining μ in S is enabled inA, Rad j can synchronize with one of the transitions ST A −→Error in TA. Then, Error becomes reachable in TA ‖ Rad j .

The transitions that check if messages that require g aresent when g is not fulfilled are assigned a guard not g. Besides

123


the guard and the synchronization these transitions do notcarry any further labels.

The transitions for detecting messages that violate theallowed time intervals are assigned a clock constraint whichis computed as follows. To determine the time intervals whereR may not send or receive μ, we consider all outgoing tran-sitions with μ of S. We write cci to refer to the clock con-straint of the i-th transition with message μ in S. We createthe conjunction of the negations of all these clock constraintscci , each one modified by widen (see above). The result arethose time intervals in which μ is not defined in S. One tran-sition ST A −→ Error is defined for each of the computedintervals. In more detail, for (modified) guards of the formwiden(re f, cci , I ) = ∧

j lowi j ≤ c j ≤ upi j , the negationis ¬widen(re f, cci , I ) = ∨

j (c j < lowi j ∨ c j > upi j ).Consequently, the new clock constraint is the result of

∧

i

⎛

⎝∨

j

(c j < lowi j ∨ c j > upi j

)⎞

⎠.

For a simple example, consider a state S with two out-going transitions that send a message a, one with the clockconstraint 10 ≤ c ≤ 20 and one with 50 ≤ c ≤ 60. Then,the resulting clock constraint is

(c < 10 ∨ c > 20) ∧ (c < 50 ∨ c > 60)

= (c < 10 ∧ c < 50) ∨ (c > 20 ∧ c < 50)

∨(c > 20 ∧ c > 60)

= (c < 10) ∨ (20 < c < 50) ∨ (c > 60)

As clock constraints may only contain conjunctions, indi-vidual transitions are created for c < 10, 20 < c < 50, andc > 60. They each carry the synchronization a? because ais sent by the original transitions. Therefore, if Rad j definesthe synchronization a! within, e.g., the interval 20 < c < 50,then Error becomes reachable.

In SectionTA_TBS in Fig. 18, the transitions from whitestates to Error have been created according to (2b). The func-tion widen is defined as cc ∧ I , like for the allowed com-munication (cf. 6.1.1). The states RailCabApproachingT A

and CheckRequestT A define invariants, so R may not sendany messages after these invariants, even those that are gen-erally allowed in these states. These are the received messagerequest in RailCabApproachingT A and the sent messagesenterAllowed and enterDenied in CheckRequestT A. Forthese, transitions have been created to Error with clock con-straints c2 > I .

6.1.3 Label definitions for required communication (case 3)

All supported refinements except simulation and timed sim-ulation require that R preserves communications of A (cf.Sect. 5.1). For checking whether required communicationsare still contained in R, we create states C X (X ∈ {1, 2, 3})

that make Error reachable in TA ‖ R whenever R does notsend or receive a required message. Which CX states are useddepends on the particular refinement definition as shown inTable 1. In any case, we create one CX state for each tran-sition that sends or receives a required message. We explainthe construction of these states in the following.

Case 3a: message in same time intervalCase 3a including state C3a is needed for timed bisimula-tion and timed ready simulation. Timed bisimulation doesnot allow R to reduce the time intervals for messages thatwere defined in A. Timed ready simulation requires the samebut only for messages defined for urgent transitions. Conse-quently, a message μ which is defined in A by a transitionS −→ S′ must also be defined in R for the whole time inter-val in which S −→ S′ is enabled. If at any point in thetime interval cc ∧ I , in which S −→ S′ is enabled, R doesnot send or receive μ, Error becomes reachable via C3ain TA ‖ Rad j . C3a is reachable during the time interval inwhich S −→ S′ is enabled. Thus, to define the transitionlabel for ST A −→ C3a, we take over the clock constraintcc of S −→ S′ and intersect it with the invariant I of thestate S. Additionally, we set the guard of ST A −→ C3ato g, the original guard of S −→ S′. The urgent transitionC3a −→ Neutral carries the message μout ? if μ is sentand μin ! if μ is received. Whenever R can send or receiveμ, Rad j synchronizes with C3a −→ Neutral, leading toNeutral in TA ‖ Rad j . For C3a −→ Error we defineno clock constraint. Since C3a −→ Neutral is urgent, ithas precedence over C3a −→ Error and prevents it fromtriggering while Rad j sends or receives μ. Error becomesreachable via C3a −→ Error in TA ‖ Rad j , wheneverC3a −→ Neutral is not enabled.

Case 3b: message obeys upper boundCase 3b including state C3b is needed for relaxed timedbisimulation. This refinement definition requires that theupper bounds of time intervals for sending messages in Rare exactly the same as in A. The test construct (2b) alreadychecks that these time interval bounds are not raised in R.C3b checks that they are also not lowered, i.e. R must be ableto send μ at least up to the upper bound in A. In other words,a message μ which is sent in A by a transition S −→ S′must also be sent by R at the end of the time interval inwhich S −→ S′ is enabled, or later. If R never sends μ afterthis time, Error becomes reachable via C3b in TA ‖ Rad j .The latest time at which S −→ S′ is enabled is defined bythe upper bound cchigh of the clock constraint cc and theinvariant I of S, whichever is more restrictive. To ensure thatC3b is entered only up to this time, we set the clock con-straint of ST A −→ C3b to cchigh ∧ I . We set the guard ofST A −→ C3b to g. The urgent transition C3b −→ Neutralcarries the synchronization μout ? or μin ! to synchronize with

123


Rad j if R sends or receives μ. We set the clock constraint ofC3b −→ Error to cT A = tmax , to only allow reachabilityof Error after the maximum amount of time tmax has passed.The value tmax is chosen high enough not to be reached in anyactual execution of the system. If Rad j , after reaching C3b,still sends μ, the urgent transition C3b −→ Neutral forcesTA to enter Neutral in TA ‖ Rad j . Reachability of Error isprevented in this case. Otherwise, cT A = tmax eventuallybecomes true and Error becomes reachable.

Case 3c: message eventually sent or receivedCase 3c including state C3c is needed for untimed bisimula-tion and (the untimed condition of) relaxed timed bisimula-tion. These refinements require message sequences definedby A to also be defined by R but do not restrict timing. Errormust become reachable in TA ‖ Rad j if R never defines themessage μ after TA entered state ST A. In other words, a mes-sage μ which is defined in A by a transition S −→ S′ mustalso be defined by R at an arbitrary time. In the clock con-straint of ST A −→ C3c, we check cT A = 0 to make C3creachable only right after TA entered ST A. The special clockcT A is reset with every transition ST A −→ ST A

′. CheckingcT A = 0 ensures that the time interval, in which R may fulfillthe check by sending or receiving μ, starts directly after thelast message exchange. It can not be reduced by TA enter-ing C3c at a later time. Like for C3b, we intersect the clockconstraint of ST A −→ C3c with cchigh ∧ I . This intersec-tion ensures that C3c is not reachable after the latest time theabstract transition S −→ S′, defining μ, is enabled. This isthe case when S is entered with clock values already higherthan the clock constraint of S −→ S′. Then, R is not requiredto define μ either and C3c is not reachable. We set theguard of ST A −→ C3c to g. As above, the urgent transitionC3c −→ Neutral carries the synchronization μout ? or μin !to synchronize with Rad j when R defines μ. We set the clockconstraint of C3c −→ Error to cT A = tmax (see above). Ifμ is eventually defined by R, the urgent transition C3c −→Neutral synchronizes with Rad j and forces TA into Neutral.Otherwise, when cT A = tmax , Error becomes reachable.

Since SectionTA_TBS in Fig. 18 checks a timed bisimu-lation, it only contains C3a-states for checking the requiredcommunication. The names of the C3a-states include thestate S for which they have been created and the synchro-nization μ! or μ? that they check. There is one such state foreach message sent or received by the transitions between thewhite states, i.e. all allowed communication is also requiredcommunication. Note that this is not the case for all refine-ment definitions but only for the variants of bisimulation.

6.1.4 Handling non-deterministic choices

Role Real-Time Statecharts may contain non-deterministicchoices as described in Sect. 2. These are used to model deci-

sions that cannot be made within the Real-Time CoordinationProtocol but influence the message exchange of the two roles.In our example, the role section of the Real-Time Coordina-tion Protocol EnterSection cannot detect itself whether thesection is free and, therefore, uses a non-deterministic choiceat the transition from RailCabApproaching to CheckRe-quest for assigning the variable free. As a result, both cases(true and f alse) are verified in the model checking step (cf.Sect. 3). Consequently, they also need to be considered in therefinement check.

When there are non-deterministic choices in the role Real-Time Statechart A, then the port Real-Time Statechart Rneeds to correctly refine A for all of these choices. In par-ticular, both need to show the same behavior for any choice.However, after making such a choice, R should not needto correspond to an A that made a different choice. Con-sequently, TA and Rad j need to make the same choices inTA ‖ Rad j . In our example, the Real-Time Statechart for rolesection in Fig. 6 and the Real-Time Statechart for port nor-mal_section in Fig. 9, both non-deterministically assign thevariable free. Then, A and R need to show the same behav-ior if the section is free (sending enterAllowed) and if thesection is not free (sending enterDenied). However, they donot need to show the same behavior if free is f alse in A andtrue in R (or vice versa).

To enforce that TA and Rad j both make the same non-deterministic choices, we consider all variables with non-deterministic assignments as global in TA ‖ Rad j . Therefore,there are no two variables with the same name in TA and Rad j

but only one that is accessed by both. Furthermore, we ignoreany non-deterministic assignments in A when constructingTA, while keeping any reading references to these variables.As a consequence, only Rad j makes the non-deterministicchoices and TA follows these choices.

SectionTA_TBS in Fig. 18 still references the variablefree in its guards, but all assignments to free that were con-tained in A have been removed.

6.2 Adjusting the refined system

The refined system needs to be adjusted such that it may becombined with TA to the parallel test system. The adjustmentsdo not change the behavior of R but only ensure that the testconstructs may correctly identify forbidden deviations of Rfrom A. The result of this step is the adjusted refined systemRad j .

The test constructs of the test RTSC demand a synchro-nous communication between TA and the refined systemR such that TA can precisely identify in which intervalsR may send or receive messages. Therefore, the sent andreceived messages for all transitions are replaced by cor-responding synchronizations, i.e. a sent message mout isreplaced with mout ! and a received message min is replaced

123


Fig. 19 Adjusted variant of therefined behavior for railroadcrossings

rail_road_crossingadj

Idle


RailCabApproaching CheckRequest[c2 100ms] request? /{free := int<0,1>;}

newSection! / {reset: c2}

[c2 120ms] [not free]enterDenied! / {reset: c2}

[c2 120ms][free] /

... ... ...

with min? This is necessary for synchronous communi-cation with the test RTSC in the parallel system TA ‖Rad j . With asynchronous communication, TA could not testthe real communication intervals of R because messagescould be delayed. Figure 19 shows an excerpt of an exam-ple for Rad j as constructed for the railroad crossings (cf.Fig. 12).

Due to the semantics of the ‖-Operator in UPPAAL [12],any invariants of states of Rad j can stop time from progress-ing in TA ‖ Rad j . This can force TA to leave a state in which itshould remain to check Rad j for required communication thathas to be possible at a later time. Thus, the missing requiredcommunication in R could not be detected by TA. To solvethis problem, the guards of all outgoing transitions of allstates Rad j are intersected with the invariant of their sourcestate. Then all invariants of all states in Rad j are removed.This ensures that Rad j cannot stop the time in TA anymore.The modification does neither add nor remove externally vis-ible behavior of R because a transition is only enabled if istime guard is fulfilled and if the invariant of the source state isfulfilled. In the example in Fig. 19, this modification affectsthe states RailCabApproaching and CheckRequest andtheir outgoing transitions.

Usually, R contains internal synchronizations with theReal-Time Statecharts of other ports of the component. Anexample is given by the synchronization closeGate! at thetransition from CheckRequest to ClosingGate in Fig. 12.In our refinement check, we only check whether the exter-nally visible behavior of R is correct with respect to Aand the selected refinement definition. Checking that theintegration with the remaining ports has been done cor-rectly is subject to Step 3 of our compositional verifica-tion approach (cf. Sect. 2.4). Therefore, we remove anysynchronizations with other ports from all transitions ofRad j .

Furthermore, all transitions carrying a message are madeurgent in Rad j . This is necessary for the test constructs check-ing for required communication (Cases 3a, 3b, and 3c). Theysynchronize with the urgent transitions from the C X statesto the Neutral state. Then, the transitions from the C X statesto Error are only enabled if Rad j cannot send or receivethe corresponding message in the required time interval. Thetransitions in Rad j , however, still synchronize non-urgentlywith the transitions between white states in TA, because thelatter are all non-urgent (cf. Sect. 6.1.1).

Finally, R may read and write variables of the componentReal-Time Statechart . An example is given by the variablesectionFree that is read by all refined protocols introducedin Sect. 4. From the perspective of R, such variables maychange at arbitrary points in time. Verifying their correctusage by the component and all of its ports is, again, subjectto Step 3 of the compositional verification approach. There-fore, we replace read accesses to component variables bynon-deterministic choices, i.e., we assume that the variablemay have any allowed value when it is accessed. In addition,we completely remove write accesses to component vari-ables because they are irrelevant if the written value is neverread. Then, we treat the resulting non-deterministic choicesas described in Sect. 6.1.4.

6.3 Parallel composition and reachability analysis

The test RTSC TA and the adjusted refined protocol Rad j

are combined to the parallel test system TA ‖ Rad j beforeexecuting the reachability analysis. We use the ‖-operatorof UPPAAL [12] that avoids the explicit generation of theproduct automaton. Instead, the two Real-Time Statechartssynchronize via the common set of synchronization channelssuch that the product system is constructed implicitly duringthe reachability analysis.

The reachability analysis computes the state space ofTA ‖ Rad j using the concepts of UPPAAL [12]. The statespace is represented by a so-called reachability graph whereeach path corresponds to an execution trace. Therefore, werefer to the states of the reachability graph as trace states.

Each trace state contains the active states of TA and Rad j .In addition, it contains the values of all variables and allclocks of the Real-Time Statecharts . The clock values arestored in so-called clock zones [4] that store clock valuesbased on intervals. We refer to [4] and [12] for a detailedtechnical description of the reachability analysis.

In the reachability analysis, we search for a trace wherethe Error state of TA is active in a trace state. If such tracestate can be found, we return the trace from the initial tracestate to this trace state as a counterexample. Thus, the coun-terexample represents an execution of the parallel test systemTA ‖ Rad j where the conditions of the selected refinementdefinition are violated by R. We provide an example of acounterexample in Sect. 7.

123


7 Case study

We evaluate our automatic refinement check based on aReal-Time Coordination Protocol of the RailCab system. Weconducted a case study based on the guidelines defined byKitchenham et al. [41]. In our case study, we investigate thecorrectness of our method for a realistic example within ourdomain and do not aim at generalizing this statement in thispaper.

7.1 Case study context

Our objective of the case study is evaluating whether ourautomatic refinement check returns correct results for a real-istic Real-Time Coordination Protocol and correspondingcorrectly and incorrectly refined protocols on a platform-independent model. We do not have the objective to show howthe protocols can be deployed and executed on a hardwareplatform. This is subject to an ongoing research project [47]and outside the scope of this paper.

We conduct our case study based on a Real-Time Coor-dination Protocol of the RailCab system [36]. The RailCabsystem is one realistic example in the domain of intercon-nected mechatronic systems. This system is currently underdevelopment, but a prototype in scale 1:2.5 has already beenbuilt on the campus of the University of Paderborn. The pro-totype system includes a track system with the different kindsof track sections mentioned before. Figure 20a shows theRailCab prototype on the test track system while Fig. 20bshows the test track system itself. One sub-task for buildingthe prototype system is to create the Real-Time CoordinationProtocol EnterSection presented in Sect. 2 and the refinedprotocols for the different types of track sections presentedin Sect. 4.

7.2 Setting the hypothesis

In Sect. 4, we presented three refined protocols. Accordingto our expertise, two are correctly refined (the ones for nor-mal sections and switches) and one is incorrectly refined (theone for railroad crossings). In addition, we consider a refined

Fig. 20 The RailCab prototype

protocol of the role railcab where we did not apply any mod-ification. This is a correct refinement with respect to anyrefinement definition.

For our case study, we define two evaluation hypotheses.Our first evaluation hypothesis is that our automatic refine-ment check correctly identifies the correctly and incorrectlyrefined protocols. Our second evaluation hypothesis is thatthe counterexample that is produced for an incorrectly refinedprotocol enables to identify the reason for the violation of theconditions of the checked refinement definition.

For evaluating our hypotheses, we manually calculate thestate spaces of the role section and of the three refined pro-tocols. Based on the state spaces we manually check whetherthe conditions of the corresponding refinement definition aresatisfied. We will compare the results of our refinement checkto the results of our manual calculations. In addition, wewill derive a correctly refined protocol for railroad cross-ings based on the counterexample returned by the refinementcheck. We consider our evaluation to be successful, if theautomatic refinement check returns the same results as ourmanual calculation and if we succeed in correcting the refinedprotocol for railroad crossings based on the counterexample.

7.3 Preparing the input models

In preparation of the case study, we specify all models pre-sented in this paper that our automatic refinement check shallverify. For the specification, we use the Fujaba Real-TimeTool Suite [48] that implements the concepts of Mecha-tronicUML All our models (including the Uppaal models)are available on our website [35].

As a first step, we define a component for each commu-nicating system including their ports (cf. Fig. 2). By instan-tiating the components, we can model various componentinstance configurations. For example, Fig. 21 shows the con-figuration for the situation of Fig. 1.

Then, we define the Real-Time Coordination Protocols .Among others, we specify the abstract protocol EnterSec-tion including the Real-Time Statecharts for each role. Next,we formally verify all safety and liveness properties of theprotocols using our Uppaal -based timed model checking(cf. Sect. 3). As soon as all protocols fulfill all properties, we

ts3:Switchr1:RailCab:sec2

:left

r2:RailCab

:bottom

ts4:RailRoadCrossing

ts1:NormalTrackSection

ts2:NormalTrackSection

:right

:right

:sec2

:sec1

:sec1

:followingSection

:precedingSection

Fig. 21 Complete component instance configuration of the RailCabexample

123


assign the roles of the Real-Time Coordination Protocols tothe ports of the components for specifying the message-basedcoordination of the components.

We continue by specifying the refined protocols behav-iors as well as the internal component behavior for all com-ponents. Thus, for the abstract protocol EnterSection, werefine its role section at the ports NormalTrackSection.left,NormalTrackSection.right, Switch.left, Switch.right,Switch.bottom, RailRoadCrossing.left, and RailRoad-Crossing.right as stated in Sect. 4. Therefore, the ports ofRailRoadCrossing are refined incorrectly. In addition, werefine the role railcab of EnterSection at the ports Rail-Cab.sec1 and RailCab.sec2. We do not modify the Real-Time Statechart of the role upon refinement such that theresulting refined protocol is correct with respect to any of theconsidered refinement definitions. Finally, we verify the cor-rectness of the refinement by applying our automatic refine-ment check on the abstract protocols, their safety and livenessproperties, and the refined protocols.

7.4 Validating the hypothesis

We apply our refinement check (cf. Sect. 6) including therefinement selection (cf. Sect. 5.2) to all ports of RailCaband all ports of NormalTrackSection, Switch, and Rail-roadCrossing that refine the role section of protocol Enter-Section.

We started by verifying the refinement for the ports ofRailCab. Our decision tree selects a timed bisimulationand the verification succeeds. Thereafter, we temporarilyremoved the existentially quantified formula such that thedecision tree selects the timed ready simulation. Again, theverification succeeds as expected.

Concerning the ports of NormalTrackSection, our deci-sion tree selects a relaxed timed bisimulation as stated inSect. 5.2. According to our refinement check, the Real-TimeStatechart shown in Fig. 9 is a valid refinement of the sec-tion Real-Time Statechart in Fig. 6 with respect to the relaxedtimed bisimulation. The behavior, however, is not valid withrespect to a timed bisimulation because the message requestat the transition from RailCabApproaching to CheckRe-quest may be received later as in the section Real-TimeStatechart .

Next, the verification returns that the refined Real-TimeStatechart for the ports of the Switch is valid with respect toa timed bisimulation.

Finally, we check the Real-Time Statechart of the ports ofthe RailroadCrossing. Again, our decision tree demandsto check for a timed bisimulation. In this case, however,the refinement is invalid with respect to timed bisimulation.Therefore, our refinement check returns the counterexampleshown in Fig. 22 for this violation.

S1States: SectionTA_TBS.IdleTA

rail_road_crossing.IdleVars: free = trueClocks: SectionTA_TBS.c2 = 0

rail_road_crossing.c2 = 0cTA = 0

S2States: SectionTA_TBS.RailCabApproachingTA

rail_road_crossing.RailCabApproachingVars: free = trueClocks: SectionTA_TBS.c2 = 0


newSection

S3States: SectionTA_TBS.CheckRequestTA

rail_road_crossing.CheckRequestVars: free = falseClocks: SectionTA_TBS.c2 = 0


request

S4States: SectionTA_TBS.CheckRequestTA

rail_road_crossing.CheckRequestVars: free = falseClocks: SectionTA_TBS.c2 0

rail_road_crossing.c2 0cTA 0

delay

S5States: SectionTA_TBS.C3aCheckRequest_enterDenied?

rail_road_crossing.CheckRequestVars: free = falseClocks: SectionTA_TBS.c2 1980

rail_road_crossing.c2 1980cTA 1980

tau

S6States: SectionTA_TBS.Error

rail_road_crossing.CheckRequestVars: free = falseClocks: SectionTA_TBS.c2 > 120

SectionTA_TBS.c2 1980rail_road_crossing.c2 > 120rail_road_crossing.c2 1980cTA > 120cTA 1980

tau

Fig. 22 Counterexample for the incorrectly refined behavior for Rail-road crossings

123


The counterexample consists of six trace states. It has beenobtained by performing a reachability analysis on the par-allel composition of the test RTSC shown in Fig. 18 andthe adjusted Real-Time Statechart of rail_road_crossingshown in Fig. 19. In the counterexample, the test RTSCis denoted as SectionTA_TBS while rail_road_crossingdenotes the adjusted Real-Time Statechart of rail_road_crossing.

In the first trace state of the counterexample, both Real-Time Statecharts are in their initial Idle states and all clocksare zero. Please note that we convert all time units to mil-liseconds in our implementation and, therefore, do not visu-alize time units in the counterexample. Then, the Real-TimeStatecharts synchronize via the newSection synchroniza-tion channel and enter the RailCabApproaching states. Inthe next step, the Real-Time Statecharts synchronize via therequest synchronization channel and enter the CheckRe-quest states. In both trace states, all clocks are still zero.In S3, the variable free receives the value false. The nexttransition in the counterexample is a delay transition, i.e.,time passes and the active states of the Real-Time State-charts do not change. If time passes, the values of all clocksincrease up to the maximum value that fulfills all invariantsof the currently active states (cf. [12]). Since we removed allinvariants and moved the corresponding clock constraints tothe outgoing transitions (cf. Sect. 6), the clock values arenot restricted. Thus, all clocks have an unbounded valuegreater or equal to zero. The transition from S4 to S5is a so-called tau transition where the test RTSC fires atransition without synchronization (cf. [12]). In particular,it enters the C3aCheck Request_enter Denied? state that checkswhether rail_road_crossing may send the message enter-Denied in the same time interval as the section role. Whenentering the state, all clocks have a value less or equal to1,980 resulting from the clock constraint of the transitionfrom CheckRequestT A to C3aCheck Request_enter Denied?.In the final trace state S6, the test RTSC is in stateError and, thus, the refinement does not hold. The clockvalues show that the Error state has been reached withall clocks having a value in the interval 120 < c2 ≤1,980.

From the counterexample, we can deduce that the refine-ment is violated by the transition from CheckRequest toEnterDenied in rail_road_crossing that sends the messageenterDenied. Since the Error state has been reached via theC3aCheck Request_enter Denied? state, we also know that therefined Real-Time Statechart of the railroad crossing doesnot support sending enterDenied in the whole time inter-val that is required by the section Real-Time Statechart . Inparticular, the transition enables to send the message enter-Denied only until c2 is at 120 ms, while the Real-TimeStatechart for role section allows sending until c2 is at1,980 ms.

rail_road_crossing

Idle

variable boolean free, boolean firstclock c2




RailCabOnSection

WaitOpenGatec2 1s

openGate!leaveSection /confirmExit(){reset: c2}

[c2 1s]gateOpened? /

/ newSection(){reset: c2}


/ enterDenied(){reset: c2}




ClosingGatec2 1980ms

[free] closeGate! /{reset: c2}

gateClosed? /enterAllowed(){reset: c2}

[free]closeGate! /

SendDenialc2 1980ms

[not free]

Fig. 23 Correctly refined behavior for Railroad crossings

Using this information, we derived a correctly refinedReal-Time Statechart for the railroad crossing that is shownin Fig. 23. In particular, we corrected the error by introducingthe state SendDenial. If the railroad crossing is not free, wedo not immediately switch to EnterDenied, but we switch toSendDenial. This state enables to send enterDenied untilc2 is at 1,980 ms as it is required by the timed bisimulation.The resulting Real-Time Statechart fulfills the conditions ofthe timed bisimulation.

7.5 Analyzing the results

The results of our case study show that our refinement checkcorrectly identifies for all given refined protocols whetherthey are refined correctly or not. Therefore, our first eval-uation hypothesis is fulfilled. In addition, we were able toidentify the cause of the incorrect refinement based on thecounterexample that was returned by our automatic refine-ment check. That enabled us to correct the refined protocoland, as a result, our second evaluation hypothesis is ful-filled as well. This gives rise to the assumption that ourapproach is also applicable to other realistic examples withinour domain.

In our case study, the most important threats to validityare as follows: (1) We might have made mistakes in the man-ual calculation that identified which refined protocols area correctly refined and which are not. (2) We only consid-ered one abstract protocol and four different refinements.Even though we consider this example as realistic, otherrealistic protocols could be highly different. (3) We did notcheck all possible refinement definitions but only timed readysimulation, timed bisimulation, and relaxed timed bisimula-tion. However, checking for a timed bisimulation includeschecks for a (timed) simulation and a bisimulation. In par-ticular, the refinement definitions that we checked explicitly

123


cover all test constructs introduced in Sect. 6. (4) We areexperts for verification and refinement checking. Therefore,we could easily derive the cause for the violation of the refine-ment from the counterexample which might not be true fornovices.

8 Related work

Related work to our approach stems from four research areas.First, we review other approaches for compositional verifica-tion (Sect. 8.1). Then, we discuss related work on verifyingReal-Time Coordination Protocols (Sect. 8.2) and refinementchecking (Sect. 8.3) in more detail. Finally, we review relatedworks that use test automata for verification (Sect. 8.4).

8.1 Compositional verification

Compositional verification approaches [14] verify complexcomponent-based systems by verifying single componentsin isolation using assumptions on, or abstractions of, theirenvironment. Many of these approaches are based on theassume/guarantee principle [20, Chap. 12]. They verify thecorrectness of a component based on assumptions that mustbe guaranteed by the environment of the particular com-ponent. One of the main difficulties of assume/guaranteeapproaches is deriving good assumptions automatically [21].In contrast, our component model decomposes the systemsyntactically into components and Real-Time CoordinationProtocols specifying the communication of the components.Thus, the Real-Time Coordination Protocols formalize theinteraction with the environment. That enables to verify thecorrectness of components under the assumption that theinteraction via Real-Time Coordination Protocols is correct.The verification of Real-Time Coordination Protocols andour refinement check guarantee that the interactions speci-fied by the port of the component is correct. As a result, wedo not need to compute assumptions for components as it isrequired by related works, e.g. by Hung et al. [38], Bensalemet al. [13], or Feng et al. [25]. In addition, these approaches donot consider real-time properties that are essential for inter-connected mechatronic systems.

8.2 Verification of real-time coordination protocols

Several approaches support the formal verification ofmessage-based coordination in real-time systems. Like ourapproach, they support asynchronous message exchange,hard real-time constraints, message delay, and messagebuffering by applying a model transformation from theirmodeling language to the Uppaal model checker. However,they either differ in their quality-of-service assumptions orthey do not provide a scalable approach. One example is the

work of Knapp et al. [43]. They extend UML collaborationsand UML state machines [46] by time constraints and enabletheir formal verification using the real-time verification toolhugo/RT.3 However, the approach of Knapp et al. has differ-ent quality-of-service assumptions than MechatronicUMLecause we assume—in contrast to them—that messages mayget lost, have a correct message order, and have a minimal andmaximal delay for each message (cf. Sect. 2.5). Thus, theirformal verification approaches are not directly applicable toMechatronicUML As a second example, Xing et al. [57]define a formal verification for parallel object-oriented spec-ification language (POOSL), which enables the modeling ofconcurrent systems that communicate asynchronously. How-ever, they do not support the explicit modeling and verifica-tion of separated protocols. Instead, they have to verify thecomplete system, which results in a non-scalable verification.

Moreover, various approaches exist that do not supportfull-fledged asynchronous communication, i.e., they partiallymiss important characteristics like asynchronicity, messagedelay, or buffering. For example, Hooman [37] defines averification of distributed real-time and fault-tolerant pro-tocols including message delay but only for a direct synchro-nous communication. Our approach instead enables the veri-fication of asynchronous communication. Although, Uppaaldoes not directly support asynchronous communication, weare able to model it by combining synchronous communica-tion and data exchange via global variables. As another exam-ple, Uppaal partial order reduction techniques (PORT) [30],an extension of the Uppaal environment that is based onthe component modeling language Savecomp componentmodel (SaveCCM), enables the formal verification of mes-sage transmission while considering message delay, but doesnot enable to verify a buffering of messages [19].

8.3 Refinement checking

Reeves and Streader [49,50] identify commonalities and dif-ferences of refinement definitions for process algebras andunify them in a generalized definition but provide neither aselection nor a verification algorithm. Sylla et al. [53] presenta refinement definition including a refinement check wherethe refinement is parameterized by a particular LTL for-mula [8] such that only this particular formula is preserved.In contrast to our approach, both do not consider real-timeproperties.

In [15], Beyer introduces timed simulation for CottbusTimed Automata which are a special kind of timed automata.We cover this refinement definition in our refinement check.

In addition, there exist refinement definitions based on(timed) I/O automata [2,3] as, e.g., (timed) alternating sim-ulations and bisimulations [7,22]. These approaches use a

3 http://www.pst.informatik.uni-muenchen.de/projekte/hugo/.

123

http://www.pst.informatik.uni-muenchen.de/projekte/hugo/


two player game for deciding whether a refined compo-nent behaves in the same way as the abstract componentin an unknown environment. In our approach, the behaviorof the environment is not unknown but formally defined bythe Real-Time Coordination Protocols . Therefore, we donot need to check refinement based on a two player game.Instead, we may use a simple reachability analysis using ourtest-automaton.

The FOCUS approach [18] supports the specification ofembedded systems. It defines the behavior of componentsby stream-processing functions on streams of messages [52]and uses, according to [18], three kinds of refinements. Twoof them, namely interface refinement and conditional refine-ment, enable to modify the input/output behavior of the sys-tem. In particular, they allow to change the number of mes-sages, the types of parameters, and the encoding of data.These refinements support a top-down refinement of the sys-tem’s behavior including, in particular, the modification ofcomponent internal behavior. In contrast, we only refine theinterface behavior of our components, which is more restric-tive. As a result, their approach requires to consider the inter-nal behavior of the sending and receiving component in addi-tion to the interface behavior. That makes refinement check-ing much more expensive compared to our approach andscalability becomes a problem. The third refinement, which iscalled behavioral refinement, defines the conditions for simu-lation and bisimulation. According to [32], interface abstrac-tions of component behavior are equivalent to statemachinesthat, in turn, correspond to I/O automata. Refinements forI/O automata have been discussed in the previous paragraph.In contrast to our approach, [32] supports completely non-deterministic specifications.

8.4 Test automata-based verification

Test automata are used by Aceto et al. [1] for model checkingtemporal properties specified in safety model property lan-guage (SBBL) on timed automata rather than verifying cor-rect refinements. Their test automata construction encodes atemporal logic formula. Consequently, they use a differentset of test constructs compared to our approach.

The approaches by Gerth et al. [27] and Tripakis et al. [55]perform LTL model checking [8] on (timed) Büchi automataand encode the properties in automata as well. Again, theyuse a different construction because they encode a temporallogic formula instead of a refinement definition.

Li et al. [45] specify safety and liveness properties fortimed automata as live sequence charts (LSC, [31]). Theytranslate the LSC into an observer timed automaton thatenters a special error location if the property is violated.Since they encode a LSC, they also use different test con-structs compared to our approach.

9 Conclusion and future work

In this paper, we extend the compositional verificationapproach of MechatronicUML n two ways. First, we illus-trated how we treat message buffers and properties of thecommunication channel, like message delay, for the veri-fication of Real-Time Coordination Protocols. Second, wesupport six different refinement definitions for refining suchReal-Time Coordination Protocols to component implemen-tations. In this step, we automatically select the most suitablerefinement definition based on the properties of our Real-Time Coordination Protocol and the properties that have beenverified for that Real-Time Coordination Protocol . In partic-ular, we select the least restrictive refinement definition thatpreserves all verified properties. Using the selected refine-ment definition, we automatically generate a so-called testautomaton which encodes the (abstract) model of the Real-Time Coordination Protocol and the conditions of the corre-sponding refinement. Our construction extends the construc-tion of Jensen et al. [40] by additional test constructs. Usingthe test automaton, we verify whether all relevant propertiesstill hold for the refined protocol.

Our approach enables software engineers of intercon-nected mechatronic systems to prove that all requirementsformalized as safety and liveness properties are fulfilled byapplying a scalable compositional verification. In particular,we relieve the developer from choosing a suitable refinementdefinition necessary for this approach by automatically iden-tifying the most suitable refinement based on the given modeland the verified properties.

Future works will provide further extensions for our com-positional verification approach. At present, both the verifi-cation of the Real-Time Coordination Protocol using Uppaaland the refinement check return a tool-specific error trace ifeither the safety/liveness property or the refinement is notfulfilled. Understanding these traces still requires in-depthknowledge about the verification tools that have been used.Therefore, we aim to transform our counter-examples backto MechatronicUML To realize this, we plan to reuse con-cepts of Hegedüs et al. [33]. For the verification of properties,we aim at providing a MechatronicUML pecific languagefor expressing properties to be verified. Thereafter, we wantto extend our mapping to Uppaal such that it also automati-cally translates properties to Uppaal. In addition, we plan toextend the concepts of Eckhardt and Henkler [23] for auto-matically synthesizing component implementations from therefined ports. This completes Step 3 of our compositional ver-ification approach. Then, we plan to develop further refine-ment definitions for cases that are currently not covered by thesix refinement definitions, e.g., delaying messages in a unidi-rectional Real-Time Coordination Protocol. Furthermore, weplan to investigate how arbitrary kinds of message buffers,reordering of messages and message loss can be considered

123


for the verification and refinement check to relax some ofour assumptions. In the next step, we want to extend thepresented construction of refinements and test automata todynamic communication structures. In a dynamic communi-cation structure, the concrete communication topology maychange during run-time which requires timed automata tobe instantiated and deinstantiated dynamically [24]. Finally,we intend to deploy our platform-independent models to aplatform [47] such that all assumptions on quality-of-servicecharacteristics are met by the resulting system.

Acknowledgments This work was developed in the course of the Col-laborative Research Center 614—Self-optimizing Concepts and Struc-tures in Mechanical Engineering—University of Paderborn, and waspublished on its behalf and funded by the Deutsche Forschungsgemein-schaft. Christian Brenner is supported by the International GraduateSchool Dynamic Intelligent Systems. We thank Marie Christin Plate-nius for useful comments on draft versions of the paper. Moreover, wethank David Schubert for implementing the algorithms presented in thispaper and Christopher Gerking for setting up the Eclipse update site.

References

1. Aceto L, Bouyer P, Burgueño A, Larsen KG (2003) The power ofreachability testing for timed automata. Theor Comput Sci 300(1–3):411–475. doi:10.1016/s0304-3975(02)00334-1

2. de Alfaro L, Henzinger TA (2005) Interface-based design. In: BroyM, Gruenbauer J, Harel D, Hoare T (eds) Engineering theories ofsoftware intensive systems, vol 195. Springer, Netherlands, NATOScience Series, pp 83–104. doi:10.1007/1-4020-3532-2

3. de Alfaro L, Henzinger TA, Stoelinga M (2002) Timed interfaces.In: Sangiovanni-Vincentelli A, Sifakis J (eds) Embedded software,Lecture notes in computer science, vol 2491. Springer, Berlin Hei-delberg, pp 108–122. doi:10.1007/3-540-45828-x_9

4. Alur R (1999) Timed automata. In: Halbwachs N, Peled DA(eds) Computer aided verification, lecture notes in computer sci-ence, vol 1633. Springer, Berlin Heidelberg, pp 8–22. doi:10.1007/3-540-48683-6_3

5. Alur R, Dill DL (1994) A theory of timed automata. Theor ComputSci 126(2):183–235. doi:10.1016/0304-3975(94)90010-8

6. Alur R, Courcoubetis C, Dill DL (1993) Model-checking in densereal-time. Inf Comput 104(1):2–34. doi:10.1006/inco.1993.1024

7. Alur R, Henzinger TA, Kupferman O, Vardi MY (1998) Alternatingrefinement relations. In: Sangiorgi D, Simone R (eds) CONCUR’98concurrency theory, lecture notes in computer science, vol 1466.Springer, Berlin Heidelberg, pp 163–178. doi:10.1007/bfb0055622

8. Baier C, Katoen JP (2008) Principles of model checking. MITPress, Cambridge

9. Becker S, Dziwok S, Gerking C, Heinzemann C, Schäfer W, MeyerM, Pohlmann U (2014a) The MechatronicUML method–model-driven software engineering of self-adaptive mechatronic systems.In: Proceedings of the 36th international conference on softwareengineering (posters), ACM, ICSE’14, accepted

10. Becker S, Dziwok S, Gerking C, Heinzemann C, Thiele S, SchäferW, Meyer M, Pohlmann U, Priesterjahn C, Tichy M (2014b)The MechatronicUML design method—process and language forplatform-independent modeling. Tech. Rep. tr-ri-14-337, HeinzNixdorf Institute, University of Paderborn, version 0.4

11. Behrmann G, David A, Larsen KG (2004) A tutorial on uppaal.In: Bernardo M, Corradini F (eds) Formal methods for the designof real-time systems, no. 3185 in lecture notes in computer

science, Springer, Berlin Heidelberg, pp 200–236. doi:10.1007/978-3-540-30080-9_7

12. Bengtsson J, Yi W (2004) Timed automata: Semantics, algorithmsand tools. In: Desel J, Reisig W, Rozenberg G (eds) Lectures onconcurrency and petri nets, lecture notes in computer science,vol 3098. Springer, Berlin Heidelberg, pp 87–124. doi:10.1007/978-3-540-27755-2_3

13. Bensalem S, Bozga M, Nguyen TH, Sifakis J (2010) Composi-tional verification for component-based systems and application.IET Softw 4(3):181–193. doi:10.1049/iet-sen.2009.0011

14. Berezin S, Campos S, Clarke EM (1998) Compositional reasoningin model checking. In: Roever WP, Langmaack H, Pnueli A (eds)Compositionality: the significant difference, lecture notes in com-puter science, vol 1536. Springer, Berlin Heidelberg, pp 81–102.doi:10.1007/3-540-49213-5_4

15. Beyer D (2001) Efficient reachability analysis and refinementchecking of timed automata using bdds. In: Margaria T, MelhamTF (eds) Correct hardware design and verification methods, lecturenotes in computer science, vol 2144. Springer, Berlin Heidelberg,pp 86–91. doi:10.1007/3-540-44798-9_6

16. Bojic I, Kusek M (2013) Self-synchronization of nonidenticalmachines in machine-to-machine systems. In: IEEE 7th interna-tional conference on self-adaptive and self-organizing systems,IEEE computer society, SASO’13, pp 265–266. doi:10.1109/saso.2013.39

17. Brenner C, Heinzemann C, Schäfer W, Henkler S (2013) Automata-based refinement checking for real-time systems. In: Proceedingsof software engineering 2013—Fachtagung des GI-FachbereichsSoftwaretechnik, Gesellschaft für Informatik e.V., lecture notes ininformatics (LNI), vol P-213

18. Broy M, Stølen K (2001) Specification and development of interac-tive systems: focus on streams, interfaces, and refinement. Springer,New York

19. Carlson J, Håkansson J, Pettersson P (2006) Saveccm: ananalysable component model for real-time systems. Electron NotesTheor Comput Sci 160:127–140. doi:10.1016/j.entcs.2006.05.019

20. Clarke EM, Grumberg O, Peled DA (2000) Model checking. MITPress, Cambridge

21. Cobleigh JM, Avrunin GS, Clarke LA (2008) Breaking up is hard todo: an evaluation of automated assume-guarantee reasoning. ACMTrans Softw Eng Methodol (TOSEM) 17(2):1–52. doi:10.1145/1348250.1348253

22. David A, Larsen KG, Legay A, Nyman U, Andrzey W (2010)Timed I/O automata: a complete specification theory for real-timesystems. In: Proceedings of the 13th ACM international conferenceon Hybrid systems: computation and control, ACM, New York, NY,USA, HSCC ’10, pp 91–100. doi:10.1145/1755952.1755967

23. Eckardt T, Henkler S (2010) Component behavior synthesis for crit-ical systems. In: Giese H (ed) Architecting critical systems, lecturenotes in computer science, vol 6150. Springer, Berlin Heidelberg,pp 52–71. doi:10.1007/978-3-642-13556-9_4

24. Eckardt T, Heinzemann C, Henkler S, Hirsch M, Priesterjahn C,Schäfer w (2013) Modeling and verifying dynamic communicationstructures based on graph transformations. Comput Sci Res Dev28(1):3–22. doi:10.1007/s00450-011-0184-y (published online)

25. Feng L, Han T, Kwiatkowska M, Parker D (2011) Learning-based compositional verification for synchronous probabilisticsystems. In: Bultan T, Hsiung PA (eds) Automated technologyfor verification and analysis, lecture notes in computer science,vol 6996. Springer, Berlin Heidelberg, pp 511–521. doi:10.1007/978-3-642-24372-1_40

26. Gerking C (2013) Transparent Uppaal-based verification of Mecha-tronicUML models. Master’s thesis, University of Paderborn

27. Gerth R, Peled D, Vardi MY, Wolper P (1996) Simple on-the-flyautomatic verification of linear temporal logic. In: Proceedingsof the fifteenth IFIP WG6.1 international symposium on proto-

123

http://dx.doi.org/10.1016/s0304-3975(02)00334-1

http://dx.doi.org/10.1007/1-4020-3532-2

http://dx.doi.org/10.1007/3-540-45828-x_9

http://dx.doi.org/10.1007/3-540-48683-6_3

http://dx.doi.org/10.1007/3-540-48683-6_3

http://dx.doi.org/10.1016/0304-3975(94)90010-8

http://dx.doi.org/10.1006/inco.1993.1024

http://dx.doi.org/10.1007/bfb0055622

http://dx.doi.org/10.1007/978-3-540-30080-9_7

http://dx.doi.org/10.1007/978-3-540-30080-9_7

http://dx.doi.org/10.1007/978-3-540-27755-2_3

http://dx.doi.org/10.1007/978-3-540-27755-2_3

http://dx.doi.org/10.1049/iet-sen.2009.0011

http://dx.doi.org/10.1007/3-540-49213-5_4

http://dx.doi.org/10.1007/3-540-44798-9_6

http://dx.doi.org/10.1109/saso.2013.39

http://dx.doi.org/10.1109/saso.2013.39

http://dx.doi.org/10.1016/j.entcs.2006.05.019

http://dx.doi.org/10.1145/1348250.1348253

http://dx.doi.org/10.1145/1348250.1348253

http://dx.doi.org/10.1145/1755952.1755967

http://dx.doi.org/10.1007/978-3-642-13556-9_4

http://dx.doi.org/10.1007/s00450-011-0184-y

http://dx.doi.org/10.1007/978-3-642-24372-1_40

http://dx.doi.org/10.1007/978-3-642-24372-1_40


col specification, testing and verification XV, Chapman & HallLtd, London, pp 3–18. http://dl.acm.org/citation.cfm?id=645837.670574

28. Giese H (2003) A formal calculus for the compositional pattern-based design of correct real-time systems. Tech. Rep. tr-ri-03-240,Software Engineering Group, University of Paderborn, Paderborn,Deutschland

29. Giese H, Tichy M, Burmester S, Schäfer W, Flake S (2003) Towardsthe compositional verification of real-time uml designs. In: Pro-ceedings of the 9th European software engineering conferenceheld jointly with 11th ACM SIGSOFT international symposium onfoundations of software engineering, ACM Press, ESEC/FSE’03,pp 38–47. doi:10.1145/940071.940078

30. Håkansson J, Carlson J, Monot A, Pettersson P, Slutej D (2008)Component-based design and analysis of embedded systems withUppal port. In: Cha S, Choi JY, Kima M, Lee I, ViswanathanM (eds) 6th international symposium on automated technologyfor verification and analysis, Springer, pp 252–257. doi:10.1007/978-3-540-88387-6_23

31. Harel D, Marelly R (2003) Come, let’s play: scenario-based pro-gramming using LSC’s and the play-engine. Springer, New York

32. Harhurin A, Hartmann J, Ratiu D (2009) Motivation and formalfoundations of a comprehensive modeling theory for embeddedsystems. Tech. Rep. TUM-I0924, Institut für Informatik, Technis-che Universität München

33. Hegedüs Á, Bergmann G, Ráth I, Varró D (2010) Back-annotationof simulation traces with change-driven model transformations.In: Fiadeiro JL, Gnesi S, Maggiolo-Schettini A (eds) SEFM, IEEEcomputer society, pp 145–155. doi:10.1109/SEFM.2010.28

34. Heinzemann C, Henkler S (2011) Reusing dynamic communica-tion protocols in self-adaptive embedded component architectures.In: Proceedings of the 14th international symposium on componentbased software engineering, ACM, CBSE ’11, pp 109–118. doi:10.1145/2000229.2000246

35. Heinzemann C, Brenner C, Dziwok S (2013) Evaluation-models.https://trac.cs.upb.de/mechatronicuml/wiki/JournalCSRD2013

36. Henke C, Tichy M, Schneider T, Böcker J, Schäfer W (2008) Orga-nization and control of autonomous railway convoys. In: Proceed-ings of the 9th international symposium on advanced vehicle con-trol (AVEC ’08), pp 318–323

37. Hooman J (1997) Verification of distributed real-time and fault-tolerant protocols. In: Johnson M (ed) Algebraic methodologyand software technology, lecture notes in computer science, vol1349. Springer, Berlin Heidelberg, pp 261–275. doi:10.1007/BFb0000476

38. Hung PN, Nguyen VH, Aoki T, Katayama T (2010) Assume-guarantee tools for component-based software verification. In: Sec-ond international conference on knowledge and systems engineer-ing, IEEE Computer Society, KSE’10, pp 172–177. doi:10.1109/kse.2010.18

39. IEEE (2008) IEEE standard for a precision clock synchronizationprotocol for networked measurement and control systems. IEEEStd 1588–2008 (Revision of IEEE Std 1588–2002) pp c1–269.doi:10.1109/ieeestd.2008.4579760

40. Jensen HE, Larsen KG, Skou A (2000) Scaling up uppaal—automatic verification of real-time systems using compositional-ity and abstraction. In: Mathai J (ed) Formal techniques in real-time and fault-tolerant systems, lecture notes in computer science,vol 1926. Springer, Berlin Heidelberg, pp 19–30. doi:10.1007/3-540-45352-0_4

41. Kitchenham B, Pickard L, Pfleeger SL (1995) Case studies formethod and tool evaluation. IEEE Softw 12(4):52–62. doi:10.1109/52.391832

42. Kizza JM (2005) Computer network security. Springer, US

43. Knapp A, Merz S, Rauh C (2002) Model checking timed uml statemachines and collaborations. In: Proceedings of the 7th interna-tional symposium on formal techniques in real-time and fault-tolerant systems, Springer, FTRTFT ’02, pp 395–416. doi:10.1007/3-540-45739-9_23

44. Kopetz H (1997) Real-time systems: design principles for distrib-uted embedded applications, 1st edn. Kluwer Academic Publishers,Boston, Dordrecht, London

45. Li S, Balaguer S, David A, Larsen KG, Nielsen B, PusinskasS (2010) Scenario-based verification of real-time systems usinguppaal. Form Methods Syst Des 37(2–3):200–264. doi:10.1007/s10703-010-0103-z

46. Object Management Group (2011) Unified modeling language(UML) 2.4.1 superstructure specification. Document formal/2011-08-06

47. Pohlmann U (2013) Safe deployment for reconfigurable cyber-physical systems. In: Proceedings of the 18th international doctoralsymposium on components and architecture, ACM, New York, NY,USA, WCOP ’13, pp 31–36. doi:10.1145/2465498.2465503

48. Priesterjahn C, Tichy M, Henkler S, Hirsch M, Schäfer W (2010)Fujaba4eclipse real-time tool suite. In: Giese H, Karsai G, Lee EA,Rumpe B, Schätz B (eds) Model-based engineering of embeddedreal-time systems (MBEERTS), lecture notes in computer science,vol 6100. Springer, Berlin Heidelberg, chap 12, pp 309–315. doi:10.1007/978-3-642-16277-0_12

49. Reeves S, Streader D (2008) General refinement, part one: inter-faces, determinism and special refinement. Electron Notes TheorComput Sci 214:277–307. doi:10.1016/j.entcs.2008.06.013

50. Reeves S, Streader D (2008) General refinement, part two: flex-ible refinement. Electron Notes Theor Comput Sci 214:309–329.doi:10.1016/j.entcs.2008.06.014

51. Schäfer W, Wehrheim H (2007) The challenges of buildingadvanced mechatronic systems. In: future of software engineer-ing, IEEE computer society, FOSE ’07, pp 72–84. doi:10.1109/FOSE.2007.28

52. Stephens R (1997) A survey of stream processing. Acta Informatica34(7):491–541. doi:10.1007/s002360050095

53. Sylla M, Stomp F, de Roever WP (2005) Verifying parameterizedrefinement. In: Proceedings of the 10th IEEE international confer-ence on engineering of complex computer systems, IEEE computersociety, ICECCS 2005, pp 313–321. doi:10.1109/iceccs.2005.82

54. Szyperski C, Gruntz D, Murer S (2002) Component software—beyond object-oriented programming, 2nd edn. Addison-Wesley,Boston, MA, USA

55. Tripakis S (2009) Checking timed büchi automata emptiness onsimulation graphs. ACM Trans Comput Logic (TOCL) 10(3):1–19. doi:10.1145/1507244.1507245

56. Weise C, Lenzkes D (1997) Efficient scaling-invariant checkingof timed bisimulation. In: Reischuk R, Morvan M (eds) Proceed-ings of the 14th annual symposium on theoretical aspects of com-puter science (STACS ’97), lecture notes in computer science,vol 1200. Springer, Berlin Heidelberg, pp 177–188. doi:10.1007/BFb0023458

57. Xing J, Theelen B, Langerak R, van de Pol J, Tretmans J, Voeten J(2010) From POOSL to Uppal. In: Gomes L, Khomenko V, Fer-nandes J (eds) Tenth international conference on application ofconcurrency to system design, IEEE Computer Society Press, pp47–56. doi:10.1109/ACSD.2010.21

123

http://dl.acm.org/citation.cfm?id=645837.670574

http://dl.acm.org/citation.cfm?id=645837.670574

http://dx.doi.org/10.1145/940071.940078

http://dx.doi.org/10.1007/978-3-540-88387-6_23

http://dx.doi.org/10.1007/978-3-540-88387-6_23

http://dx.doi.org/10.1109/SEFM.2010.28

http://dx.doi.org/10.1145/2000229.2000246

http://dx.doi.org/10.1145/2000229.2000246

https://trac.cs.upb.de/mechatronicuml/wiki/JournalCSRD2013

http://dx.doi.org/10.1007/BFb0000476


http://dx.doi.org/10.1109/kse.2010.18

http://dx.doi.org/10.1109/kse.2010.18

http://dx.doi.org/10.1109/ieeestd.2008.4579760

http://dx.doi.org/10.1007/3-540-45352-0_4

http://dx.doi.org/10.1007/3-540-45352-0_4

http://dx.doi.org/10.1109/52.391832

http://dx.doi.org/10.1109/52.391832

http://dx.doi.org/10.1007/3-540-45739-9_23

http://dx.doi.org/10.1007/3-540-45739-9_23

http://dx.doi.org/10.1007/s10703-010-0103-z

http://dx.doi.org/10.1007/s10703-010-0103-z

http://dx.doi.org/10.1145/2465498.2465503

http://dx.doi.org/10.1007/978-3-642-16277-0_12

http://dx.doi.org/10.1007/978-3-642-16277-0_12



http://dx.doi.org/10.1109/FOSE.2007.28

http://dx.doi.org/10.1109/FOSE.2007.28

http://dx.doi.org/10.1007/s002360050095

http://dx.doi.org/10.1109/iceccs.2005.82

http://dx.doi.org/10.1145/1507244.1507245



http://dx.doi.org/10.1109/ACSD.2010.21

automata-based refinement checking for real-time systems

Documents