Collaborative Model-based Developmentof a Remote Train Monitoring System

Peter Herrmann1, Alexander Svae1, Henrik Heggelund Svendsen1 and Jan Olaf Blech2

1Norwegian University of Science and Technology, Trondheim, Norway2RMIT University, Melbourne, Australia

herrmann@item.ntnu.no, {alexasv, henrihs}@stud.ntnu.no, janolaf.blech@rmit.edu.au

Keywords:Cyber-physical systems, software engineering, collaborative development

Abstract:The model-based engineering technique Reactive Blocks supports the development of reactive sys-tems by UML-based graphic modeling of control and data flows, model checker supported analysis,and automated code generation. Moreover, it facilitates the cooperation of teams of engineers byenabling the definition of formally precise behavioral interfaces that make the separation of themodelling process into various work packages easy. In this paper, we illustrate the use of ReactiveBlocks for a joint student project that realized the monitoring and control of Lego Mindstorms-based trains in Norway through a control center in Australia. In particular, we explain how theReactive Blocks interfaces and the applied communication protocols were used to split the projectinto work packages separately handled by the students involved.

1 Introduction

Development, operation and maintenance oflarger software systems is often done using teamsof software engineers often working in distantplaces. Different companies may develop, deploy,maintain or operate different components of a sys-tem. Capabilities may be distributed over severallocations, such as off-shore service centres and op-erations in other places. This is, e.g., the casein oil, gas and mining. In this paper, we regardtransport systems which are spatially distributed.Trains and track controllers are inherently geo-graphically separated from each other.

Well-defined responsibilities as well as clear in-terfaces between tasks help the work organisationand the documentation of system componentsfor maintenance. The benefit may be increasedby using modelling and formal techniques (Lee,2008). For instance, with respect to software de-velopment in the transportation domain, we candistinguish two levels in which formal specifica-tions can assist the collaboration of various stake-holders. On the software component specificationlevel, formal specifications assist the engineeringteams in developing, deploying and maintaining

different software components. Often the teamsneed only limited coordination and can thereforebe geographically distributed. In contrast, on theoperation model level, the operation of trains maybe formally modeled which assists us in conduct-ing the control of a railway system in practice.Both levels have some interdependencies. For ex-ample, protocols may be derived from softwarecomponent interfaces that influence the operationmodel level.

In this paper, we concentrate on the softwarecomponent specification level and investigate theuse of the model-based technique Reactive Blocksfor cooperation of engineering teams. We illus-trate the approach with the development of adistributed system that enables the remote mon-itoring and control of a Lego Mindstorms-basedtrain system (Hordvik et al., 2016) residing inTrondheim through the visualization infrastruc-ture VxLab (Blech et al., 2014) in Melbourne.

Below, we will discuss related work followedby an introduction to Reactive Blocks in Sec. 3and a discussion in Sec. 4 how this technique canbe used to coordinate different teams of engineers.Thereafter, we describe our train demonstrator inSec. 5 and explain the ways, the involved students

24 8. IMPLEMENTATION OF THE TRAIN MONITORING MODULE

Figure 8.1: The train monitoring block used in the monitoring system

Figure 1: Building block TrainMonitoringModule.

Figure 2: ESM of building block TrainMonitoring-Module.

coordinated in Sec. 6. We complete the paper bya short discussion about future work.

2 Related Work

Tool support for the collaboration of differentstakeholders has been studied for various engi-neering domains. Early examples comprise toolsupport for document sharing, e.g., (Toye et al.,1994) and work on collaborative software devel-opment environments, e.g., (Booch and Brown,2003). Another study (Feiler et al., 2006) listschallenges for the development of ultra-large-scalesystems. The analysis of collaboration patternsusing social networks has been studied in (Crosset al., 2002). Results can be used to suggest team

structures.On the formal side of our work, methodolo-

gies for specifying components or work entitiesare of importance. Overall, we follow a design-by-contract approach (Meyer, 1992). We are pri-marily interested in contracts that specify thebehavior of a component or an interface suchas interface automata (De Alfaro and Henzinger,2001). The work described in this paper inte-grates with behavioral types. Behavioral typeshave been used for the specification of real-timesystems (Lee and Xiong, 2004). Furthermore, be-havioral types are a formal description methodthat have been applied for software components(Blech et al., 2012), industrial automation sys-tems (Blech et al., 2014) and cyber-physical sys-tems (Blech and Herrmann, 2015). The idea is tohave descriptions that allow for automatic checksof interactions between entities in very much thesame way as type compatibility and compliancechecking works in higher programming languages.

Furthermore, a connection of the work de-scribed in this paper to the collaborative engi-neering project is envisaged (Blech et al., 2015).Collaborative engineering provides means for dif-ferent stakeholders to interact with each other fo-cusing on maintenance and operation of large in-dustrial systems.

3 Reactive Blocks

Reactive Blocks (Bitreactive AS, 2016; Krae-mer et al., 2009) is a model-based engineering

technique for reactive systems. It is Java-basedand uses UML activities (Object ManagementGroup, 2011) to specify control and data flow be-havior. To make the approach scalable, an activ-ity may be enclosed in a so-called building block.Further, one can represent a building block asnodes in other activities that are named call be-havior actions in UML terminology. Thus, onecan describe models as hierarchies of buildingblocks and their activities.

As an example, Fig. 1 depicts the activity ofthe building block TrainMonitoringModule. Atits edges, the activity is provided by parameternodes that are sources and sinks of flows, e.g., aparameter node init through which flows con-taining objects of the Java class HashMap maypass. The call behavior actions of a building blockare endued with pins that correspond to the pa-rameter nodes of its activity. For instance, ouractivity contains a call behavior action of buildingblock RabbitAMQP that shows all the parameternodes of its activity as pins (e.g., init, ready,and publish).

The parameter nodes of an activity are usedto model flows from the activity of a buildingblock to the one enclosing its call behavior ac-tion and vice versa. Our example specifies aflow that is started somewhere in the environ-ment of building block TrainMonitoringModuleand passes through pin/parameter node init ofthis block. Thereafter it continues in the activ-ity in Fig. 1 and reaches the operation actioninit which is a container of a Java method ofthe same denominator being carried out when theflow passes. Afterwards, the flow reaches the pinof call behavior action RabbitAMQP such that itcontinues within the activity of the correspondingbuilding block.

The building block concept makes it possibleto specify functionality, that recurs in various ap-plications, only once in one building block and toreuse its call behavior actions at various places.The Reactive Blocks tool contains hundreds ofbuilding blocks covering aspects reaching fromflow control via communication protocols and en-cryption to domain-specific functions, e.g., for theInternet of Things, see (Bitreactive AS, 2016).To alleviate this reuse capability, each buildingblock is accompanied by an External State Ma-chine (ESM) (Kraemer and Herrmann, 2009). AnESM is a UML State Machine that models whichpins/parameter nodes may be traversed in a cer-tain state of the building block. As an example,we depict the ESM of building block TrainMoni-

toringModule in Fig. 2. It consists of two states,i.e., an initial one showing that the block is notactive, as well as active. By tags on the edges,one describes which flows may appear in a cer-tain state of the block and into which state theblock changes. For instance, a flow through pa-rameter node init is only allowed in the initialstate and afterwards the block will be in stateactive. Tags within a state designator1 (e.g.,removeTopic /) describe that the correspondingflows may occur in the particular state but donot change the state. Several flows may enterand leave a block within a single atomic transi-tion which is described by a list of parameter nodeidentifiers (e.g., stop / stopped).

Reactive Blocks is provided by formal seman-tics (Kraemer and Herrmann, 2010) such that thetool uses a model checker verifying whether both,the activity enclosed in a block and the one usingits call behavior action, indeed, comply with theESM of the block. Moreover, the tool contains acode generator creating automatically executableJava code (Kraemer et al., 2006; Kraemer andHerrmann, 2007).

4 Coordinating Engineers withReactive Blocks

The building block concept seems ideal to fos-ter cooperative software engineering carried outby various teams of software engineers. In partic-ular, it allows to structure the software architec-ture into several work packages. A building blockcan be used to define such a work package whileits call behavior actions refer to places in whichthe results of this work package are used. TheESM of the building block provides then a be-havioral interface description that facilitates thecoordination between a team carrying out a workpackage and one using it.

The project planning corresponds to defining ahierarchy of building blocks that each describes awork package. In this phase, only an initial frameof a block is constructed. It does not contain thecomplete activity but only the parameter nodesto be used as well as the ESM. Moreover, theJava classes assigned to the parameter nodes areestablished at this stage.

1The position of the / symbol describes whethera flow is triggered in the building block itself (left ofthe parameter node name, e.g., / failed) or by itsenvironment (on the right side, e.g., init /).

8.2. TESTING THE IMPLEMENTED SYSTEM 55

Figure 8.5: Railroad layout used for testing the deployed system. The colored areasshows which EV3 smart brick each point switch is physically connected to. Eachpoint is tagged with the port of the EV3 it is connected to, and the identifier of therespective point.

Figure 8.6: Plot showing the flow of messages through the AMQP broker during atest run.

As shown in Figure 8.6, messages are sent to the broker and distributed to theappropriate clients. As the figure shows, the number of outbound messages arealways equal or greater than the number of inbound messages. This is due to thepublish-subscribe pattern, i.e. if a message is published by one client (inbound tothe broker) with a topic that four other clients subscribe to, the broker will publishfour messages as a consequence.

Figure 3: The Lego Mindstorms train layout used.

After defining the building block hierarchy,the block frames are handed over to the variousteams that develop the activities of the blocksand program the Java methods to which the op-eration actions of the activity refers. Here, morecomplex behavior will lead to the separation ofsub-functions in other building blocks that arealso developed by the particular team or takenfrom the tool libraries. In addition, call behavioractions of blocks referring to other work packagesmay be used. When a team completes a buildingblock, it verifies with the model checker of Re-active Blocks that their solution fulfills its ESM.Further, the model checker proves that the ESMsof the blocks referring to other work packages arepreserved as well.

When all work packages are completed, thebuilding blocks are assembled and the code forthe entire system is generated. It can be usedto test that the used objects conform with eachother. Due to the comprehensible graphical UMLmodels, these tests are usually easy.

The coordination of engineers is particularlyimportant for geographically distributed systems.It profits from the fact that communication istraditionally service-oriented, see, e.g., (Tanen-baum and Wetherall, 2011). That means, dis-tributed applications access the communicationfeatures via a communication service, that definesa set of functions like connection establishmentor data transfer. The functions are provided bycommunication protocols. The engineers of dif-ferent physical components can negotiate suit-

able communication services and protocols. Theyguarantee a correct communication by developingtheir applications such that the communicationservices are fulfilled.

Traditionally, communication services andprotocols are specified formally using establishedtechniques like SDL (ITU-T, 2011). ReactiveBlocks is an alternative to these techniques. Thelocal unit of a protocol can be realized as a build-ing block while its ESM forms the correspondingcommunication service. For instance, the build-ing block RabbitAMQP, used in the activity inFig. 1, realizes a stack of the Advanced MessageQueueing Protocol (AMQP), see (AMQP.org,2016), that is popular in the Internet of Thingsdomain. By following its ESM and by using thecorrect Java objects in the flows through its pinsresp. parameter nodes, the correct usage of theprotocol is guaranteed.

5 A Train Demonstrator based onReactive Blocks

As mentioned in the introduction, a LegoMindstorms-based train system, see (Hordviket al., 2016), positioned in Trondheim, Norway,was connected to the visualization infrastructureVxLab (Blech et al., 2014) in Melbourne, Aus-tralia. Thus, the trains can be remotely moni-tored and, with some limitations, controlled. Thework was done by some master student projects.

Figure 4: A Lego train.

Figure 5: The remote AMQP infrastructure

One project (Svendsen, 2016) covered the de-velopment of the autonomous train control unitwhile a second one (Svae, 2016) realized the trans-fer of sensor data from Trondheim to Melbourneand the control commands the other way around.A third task, i.e., the access of the monitor andcontrol data on the VxLab is still under progress.

In Fig. 3, we depict the layout of the tracksthat connect five separate stations. The colorsrefer to four Lego EV3 controllers that are usedto operate the switches in the layout. A train in-cludes a motor, an EV3 controller unit as wellas a color sensor that may detect the color ofthe sleepers, the train passes (see Fig. 4). Asdescribed in (Svendsen, 2016), the trains oper-ate autonomously. To guarantee a correct andsafe operation, the EV3 controller of a train hasto communicate with the controllers of the othertrains as well as the ones operating the switches.For that, the AMQP protocol (AMQP.org, 2016)is used based on a local server.

To be flexible in defining track layouts, a lay-out to be used is modeled with the freeware layouteditor BlueBrick (McKenna and Nanty, 2015).The model is automatically transformed into aninternal map applied by the train controllers tostate the current position of a train.

AMQP is also used for the remote monitoringand control of the trains (Svae, 2016). Besides tothe local server, the EV3 controllers of the trainsand switches keep also a connection to a remote

AMQP server residing on the Australian cloudinfrastructure Nectar (Nectar, 2016). Status in-formation like the current position and speed ofa train on a track or the settings of the switchesis sent to the remote AMQP server allowing usto monitor train systems from the VxLab andother places “in the cloud”. Likewise, controlcommands from the VxLab are sent via the re-mote server to the train controller and can be di-rectly executed. The used AMQP infrastructureis shown in Fig. 5.

6 Collaboration between theStakeholders

To coordinate the student projects, the inter-faces between the work packages had to be de-fined. As discussed in Sec. 4, building blocksand communication protocols are suitable formalmeans to facilitate this coordination. We usedboth methods. For the transfer of monitoringand control data between Trondheim and Mel-bourne, the involved students agreed about thecommunication protocol and service to be used.To coordinate the control and remote communi-cation parts within the EV3 controllers, the af-fected stakeholders negotiated a building blockinterface and the Java classes used in the con-trol flows via this interface. Both interfaces aredescribed in the following.

6.1 The Remote ControlConnection

We discussed in Sec. 5 that the stakeholdersagreed on using the Advanced Message Queue-ing Protocol (AMQP) (AMQP.org, 2016) with aremote server running in the Australian Nectarcloud (Nectar, 2016). Moreover, it was decidedto use the JavaScript Object Notation (JSON)(ECMA International, 2013) as data interchangeformat. In JSON, information units can be de-fined as objects of sequences of pairs containing aname string and a value. Agreement on the exactJSON object formats for the various train param-eters (e.g., train identifier, position, train length,speed, direction, switch position) as well as forthe protocol control information (e.g., sequencenumbers and time stamps) was reached.

Tests revealed that sending all train param-eters in each communication message consumesmuch bandwidth. Therefore, the students de-cided to send only monitoring data that has

Figure 7: Measured round trip time delays between Trondheim and Melbourne

{” id ” : 1 ,

” timestamp” : 1449832076300 ,”sequenceNumber” : 334 ,” event ” : ”SPEED” ,” speed ” : 15

}

Figure 6: A JSON communication object example

changed in update messages. As an example,Fig. 6 lists the JSON object to be transmitted ifa train changed its speed. Its pairs are the iden-tifier of the train ("id" : 1), a time stamp andsequence number as protocol control information,event information ("event : "SPEED"), and themeasured speed ("speed" : 15). To make thecommunication more reliable, the update mes-sages are accompanied by confirmed synchroniza-tion messages that are sent in certain time inter-vals. By checking the sequence numbers of thesynchronization messages, one can find out whichupdate messages were lost and resend the cor-responding data. Further, remote control com-mands for the trains are sent via the AMQP link.

The handling of the update and synchroniza-tion messages in the EV3 controllers is real-ized by the building block TrainMonitoringMod-ule (see Fig. 1). For instance, the Java methodencapsulated in the operation handleProperty-ChangeAndCreateUpdateMessage receives a listof all train parameters and checks which of themwere changed since sending the last update mes-sage. For the altered parameters, an update mes-sage is created and sent via the communicationblock RabbitAMQP.

To find out about delays of the AMQP con-

nection, the students carried out intensive roundtrip time tests. Figure 7 refers to a test checkingif the round trip delay is fluctuating. For that,ping messages were sent every other second for 24hours. As the figure shows, the delays were verystable between 350 and 360 ms with only very fewfluctuations that never exceeded 880 ms.

6.2 Linking Train Control andCommunication

The building block TrainMonitoringModule de-picted in Fig. 1 defines the interface between thecontrol and communication software part in theEV3 controllers. The involved students agreedon the data formats: The Java hashmap sent viaparameter init contains the information neces-sary to build up AMQP connections. The Javaclass TrainPropertyChange used in parameternode propertyChange includes the relevant trainand switch parameters to be send when updated.Messages received from the remote control arehanded over to the block environment via param-eter node receiveMessage.

Knowing about these formats as well as aboutthe ESM of block TrainMonitoringModule, it wasnot difficult to build its call behavior action intothe control software (Svendsen, 2016). The fol-lowing issues had to be solved:

• Maintaining the link to the AMQP server inthe Nectar cloud,

• after the change of at least one train resp.switch parameter, sending the parameter val-ues in a Java object of class TrainProperty-Change via parameter node propertyChange,

• interpreting the JSON objects in messages, re-ceived via parameter node receiveMessage,

and adjusting the train or switch control ac-cordingly.

After incorporating the call behavior action ofblock TrainMonitoringModule and conductingthe necessary changes, the model checker of Reac-tive Blocks verified that the ESM of this block issatisfied by the control software embedding it2.Thereafter, Reactive Blocks automatically gen-erated an executable Java bundle that can beloaded into the EV3 controller and carried outthere. Finally, some conformance tests were car-ried out revealing that the Java objects were cor-rectly programmed.

7 Conclusion and Future Work

We explained the capabilities of ReactiveBlocks to facilitate collaboration for developmentand maintenance of software systems. In partic-ular, we have been looking at transportation sys-tems that, with respect to their software control,have a cyber-physical flavour. We demonstratedthe capabilities using a remote train monitoringcase study.

Future work comprises extensions for formal-izing cyber-physical aspects and components andautomatic tools to suggest tasks and supportinginformation for different distributed teams.

REFERENCES

AMQP.org (2016). Advanced Message QueuingProtocol (AMQP). www.amqp.org/. Ac-cessed: 2016-02-01.

Bitreactive AS (2016). Reactive Blocks. www.bitreactive.com. Accessed: 2016-01-28.

Blech, J., Peake, I., Schmidt, H., Kande, M.,Rahman, A., Ramaswamy, S., Sudarsan, S.,and Narayanan, V. (2015). Efficient IncidentHandling in Industrial Automation throughCollaborative Engineering. In IEEE 20thConference on Emerging Technologies Fac-tory Automation (ETFA). IEEE Computer.

Blech, J. O., Falcone, Y., Rueß, H., and Schatz,B. (2012). Behavioral Specification BasedRuntime Monitors for OSGi Services. InLeveraging Applications of Formal Methods,

2Further, the developer of block TrainMonitoring-Module used the model checker to prove that theblock fulfills its own ESM.

Verification and Validation. Technologies forMastering Change, LNCS 7609, pages 405–419. Springer-Verlag.

Blech, J. O. and Herrmann, P. (2015). BehavioralTypes for Component-Based Development ofCyber-Physical Systems. In Software Engi-neering and Formal Methods, LNCS 9509,pages 43–52. Springer-Verlag.

Blech, J. O., Spichkova, M., Peake, I., andSchmidt, H. (2014). Cyber-Virtual Systems:Simulation, Validation & Visualization. In9th International Conference on Evaluationof Novel Approaches to Software Engineering(ENASE), pages 1–8. IEEE.

Booch, G. and Brown, A. W. (2003). Collabora-tive Development Environments. Advancesin Computers, 59:1–27.

Cross, R., Borgatti, S. P., and Parker, A. (2002).Making Invisible Work Visible: Using SocialNetwork Analysis to Support Strategic Col-laboration. California Management Review,44(2):25–46.

De Alfaro, L. and Henzinger, T. A. (2001). In-terface Automata. ACM SIGSOFT SoftwareEngineering Notes, 26(5):109–120.

ECMA International (2013). Standard ECMA-404 — The JSON Data InterchangeFormat. www.ecma-international.org/publications/standards/Ecma-404.htm.Accessed: 2016-02-03.

Feiler, P., Gabriel, R. P., Goodenough, J., Linger,R., Longstaff, T., Kazman, R., Klein, M.,Northrop, L., Schmidt, D., Sullivan, K.,Wallnau, K., and Pollak, B. (2006). Ultra-Large-Scale Systems: The Software Chal-lenge of the Future. Software EngineeringInstitute.

Hordvik, S., Øseth, K., Blech, J. O., and Herr-mann, P. (2016). A Methodology for Model-based Development and Safety Analysis ofTransport Systems. In 11th InternationalConference on Evaluation of Novel Ap-proaches to Software Engineering (ENASE).To appear.

ITU-T (2011). Z.100 : Specification and Descrip-tion Language - Overview of SDL-2010. www.itu.int/rec/T-REC-Z.100/en. Accessed:2016-02-01.

Kraemer, F. A. and Herrmann, P. (2007). Trans-forming Collaborative Service Specificationsinto Efficiently Executable State Machines.In 6th International Workshop on GraphTransformation and Visual Modeling Tech-

niques (GT-VMT 2007), Electronic Commu-nications of the EASST 7. EASST.

Kraemer, F. A. and Herrmann, P. (2009). Auto-mated Encapsulation of UML Activities forIncremental Development and Verification.In Model Driven Engineering Languages andSystems (MoDELS), LNCS 5795, pages 571–585. Springer-Verlag.

Kraemer, F. A. and Herrmann, P. (2010). Reac-tive Semantics for Distributed UML Activi-ties. In Joint WG6.1 International Confer-ence (FMOODS) and WG6.1 InternationalConference (FORTE), LNCS 6117, pages17–31. Springer-Verlag.

Kraemer, F. A., Herrmann, P., and Bræk, R.(2006). Aligning UML 2.0 State Machinesand Temporal Logic for the Efficient Execu-tion of Services. In 8th International Sym-posium on Distributed Objects and Applica-tions (DOA06), LNCS 4276, pages 1614–1632. Springer-Verlag.

Kraemer, F. A., Slatten, V., and Herrmann, P.(2009). Tool Support for the Rapid Compo-sition, Analysis and Implementation of Reac-tive Services. Journal of Systems and Soft-ware, 82(12):2068–2080.

Lee, E. (2008). Cyber Physical Systems: De-sign Challenges. In 11th IEEE InternationalSymposium on Object Oriented Real-TimeDistributed Computing (ISORC), pages 363–369. IEEE Computer.

Lee, E. A. and Xiong, Y. (2004). A BehavioralType System and its Application in PtolemyII. Formal Aspects of Computing, 16(3):210–237.

McKenna, A. and Nanty, A. (2015). BlueBrick —Version 1.8.0. bluebrick.lswproject.com/help_en.html. Accessed: 2016-02-02.

Meyer, B. (1992). Applying “Design by Con-tract”. Computer, 25(10):40–51.

Nectar (2016). NectarCloud. cloud.nectar.org.au/. Accessed: 2016-02-02.

Object Management Group (2011). OMG UnifiedModeling LanguageTM (OMG UML), Su-perstructure — Version 2.4.1. www.omg.org/spec/UML/2.4.1/Superstructure/PDF/.Accessed: 2016-01-28.

Svae, A. (2016). Remote Monitoring of Lego-Mindstorm Trains. Project thesis, Norwe-gian University of Science and Technology,Trondheim.

Svendsen, H. H. (2016). Model-based Engineer-ing of a Distributed, Autonomous Control

System for Interacting Trains, deployed ona Lego Mindstorms Platform. Project thesis,Norwegian University of Science and Tech-nology, Trondheim.

Tanenbaum, A. S. and Wetherall, D. J. (2011).Computer Networks. Prentice Hall, 5 edition.

Toye, G., Cutkosky, M. R., Leifer, L. J., Tenen-baum, J. M., and Glicksman, J. (1994).SHARE: A Methodology and Environmentfor Collaborative Product Development. In-ternational Journal of Intelligent and Coop-erative Information Systems, 3(2):129–153.