Virtual Prototyping of Large-Scale IoT Control Systems UsingDomain-Specific Languages

Jacques Verriet1, Lennart Buit1, Richard Doornbos1, Bas Huijbrechts1, Kristina Sevo2, Jack Sleuters1

and Mark Verberkt21ESI (TNO), Eindhoven, Netherlands

2Signify, Eindhoven, Netherlands{jacques.verriet, richard.doornbos, bas.huijbrechts, jack.sleuters}@tno.nl, {kristina.sevo, mark.verberkt}@signify.com

Keywords: Domain-specific languages, Model transformations, Virtual prototyping, System validation, Simulation,Model checking, Distributed control systems, IoT systems, Lighting systems

Abstract: IoT applications and other distributed control applications are characterized by the interaction of many hard-ware and software components. The inherent complexity of the distributed functionality introduces challengeson the detection and correction of issues related to functionality or performance, which are only possible todo after system prototypes or pilot installations have been built. Correcting these issues is typically very ex-pensive, which could have been avoided by earlier detection. This paper makes four main contributions. (1) Itpresents a virtual prototyping approach to specify and analyze distributed control applications. The approachis based on a domain model, which can be configured for a specific application. It consists of eight domain-specific languages (DSLs), each describing one system aspect. (2) The DSLs provide each stakeholder inthe application’s lifecycle a natural and comprehensible way to describe his/her concerns in an unambiguousmanner. (3) The paper shows how the DSLs are used to automatically detect common configuration errors anderroneous behavior. (4) The virtual prototyping approach is demonstrated using a lighting domain case study,in which the control system of an office floor is specified and analyzed.

1 INTRODUCTION

The cost of system development is dominated by ver-ification and validation, which is typically done in thelater development phases. Errors are often not de-tected until system prototypes or pilot installations re-veal them and repairs have become costly. Correct-ing the issues found during these late phases is typi-cally very expensive, whereas correction in the earlierphases of development has much lower cost (Haskinset al., 2004). The extra effort spent on early fault de-tection is much lower than the cost of fault detectionand correction in the latest phases of development.Mellegard et al. (2016) and Broy et al. (2012) reportsimilar findings.

Many errors are caused by ambiguity of require-ment specifications. As requirements are typicallyspecified in natural language, they can be interpretedin many ways. Similarly, design and architectureconcepts are often described in an ambiguous man-ner (Theelen and Hooman, 2015; Volter, 2010).

This paper presents a virtual prototyping approachfor IoT applications and similar distributed control

applications. The approach allows unambiguous ap-plication specification as well as detection and cor-rection of behavioral errors and performance issuesin the early phases of development. The virtual pro-totyping approach is based on a domain model con-sisting of eight domain-specific languages (DSLs).These languages allow different aspects of an IoT ap-plication to be described in a non-ambiguous mannerthereby avoiding misinterpretations. Each DSL de-scribes one aspect of an IoT application and its envi-ronment. The behavior of an IoT application is de-scribed using DSLs describing (1) system topology,(2) system functionality, and (3) deployment of func-tionality onto the topology. Besides DSLs for systembehavior, the domain model includes languages to de-scribe the application’s environment, i.e. the inputs itreceives via its sensors.

As IoT applications may consist of thousands ofcomponents, their functionality cannot be tested eas-ily. The systems are simply too large for a humanto maintain overview of the state of the entire system.For this reason, the domain model includes a Require-ment DSL in which one can specify the desired be-

havioral properties. These properties are monitoredas the prototype is running; violations of the specifiedproperties are detected automatically. The scenariosleading to the property violation allow developers todiagnose the situation.

The domain model’s DSLs form a configurablecore, which describe an IoT system, its environment,and its requirements. This core can be extended us-ing front-ends and back-ends for specific types of sys-tems. We demonstrate this for the lighting domain.A real-life indoor lighting case study shows that thetrade-off between lighting system performance anduser comfort can be analyzed using a combinationof (1) the domain model’s DSLs, (2) usage profilesof people’s activities in buildings, and (3) a lighting-specific interactive visualization.

1.1 Contributions

We make the following contributions to the state ofthe art. We present a virtual prototyping approachfor distributed control applications, which can be con-figured for specific applications by defining specificevent and structure types and coupling to custom en-vironment models and visualizations. The domainmodel is based on a domain model consisting ofeight DSLs, thereby providing each stakeholder inthe application’s lifecycle a natural and comprehensi-ble way to describe his/her concerns in an unambigu-ous manner. The approach allows automatic detec-tion of behavioral errors using executable models thatare monitored for violation of specified requirements.The virtual prototyping approach is demonstrated us-ing a real-life case study from the lighting domain.

1.2 Outline

The remainder of this paper is structured as follows.Section 2 provides an overview of related work. Thedomain model is introduced in Section 3. The valida-tion capabilities of the domain approach are describedin Section 4. The virtual prototyping approach isdemonstrated using a real-life indoor lighting appli-cation case in Section 5. Conclusions are discussed inSection 6, future work in Section 7.

2 RELATED WORK

In this paper, we follow a similar approach asHooman (2016), who proposes an approach to gen-erate formal models from domain-specific languages.However, we use a modular domain model consist-ing multiple DSLs instead of a single DSL. Intro-

ducing modularity allows a separation of concerns,better quality, and increased reuse (Rieger et al.,2018). Reuse of model elements is especially rel-evant for distributed control systems, as they typi-cally have many components but only few compo-nent types. Like Hooman (2016), we combine our do-main model with custom visualizations. Such graph-ical models have shown to improve communicationbetween stakeholders (Broy et al., 2012) and speedup design (Beckers et al., 2007) in industry.

From our domain model, we automatically gen-erate simulation models and model checking models.Simulations of large-scale IoT systems exist in liter-ature, but they typically address the communicationaspect, not the behavioral aspect of IoT systems. Anexample is the work of D’Angelo et al. (2017). To al-low simulation of large-scale IoT systems, they applya multi-level simulation. They combine a high-levelsimulator that operates on a wide scope and a coarse-grained level and low-level simulators that operate ona narrow scope and a fine-grained level. The latter areonly used if fine-grained analysis is necessary.

DiaSuite (Bertran et al., 2014) does consider thebehavioral aspect of IoT systems; it is a tool suite todevelop, simulate and deploy sense-compute-controlapplications. It is based on Java-embedded DSLs,which describe the devices in a system including theirattributes and interfaces. From this specification, ab-stract Java classes are generated. To allow simulation,programming skills are required: the desired behaviorneeds to be programmed.

Serral et al. (Serral et al., 2010) present PervML, alanguage to specify context-aware pervasive systemsin a platform- and technology-independent manner.To specify pervasive systems, they distinguish tworoles and multiple UML-based views. From a sys-tem specification, Java and OWL code is generatedautomatically.

France and Rumpe (France and Rumpe, 2007) ob-serve that the specification and verification of systemproperties is important. This is another way in whichour approach differs from that of Hooman (2016). Asdistributed control systems may contain thousands ofcomponents, it is practically impossible for a personto maintain overview of the system’s behavior. Forthis reason, we include run-time monitors in the sim-ulation and model checking models generated fromour domain model. These monitors are used for auto-matic requirement checking.

There are many formalisms to describe these spec-ifications. In the ComMA framework (Kurtev et al.,2017), specifications are based on MTL (Koymans,1990), the real-time extension of LTL. Hendriks et al.(2016) uses MTL to check timed properties using ex-

ecution traces. As it is difficult to specify and checkLTL and MTL properties directly, there have beenseveral initiatives to specify common monitoring pat-terns. Dwyer et al. (1998) defined a collection oftemporal patterns; these were extended with timedpatterns by Konrad and Cheng (2005) and Gruhnand Laue (2006). Meyers et al. (2013) describe aDSL-based method to specify system properties bycombining temporal patterns. These are translatedinto LTL formulas that are checked using SPIN. Buit(2017) applies a similar technique for timed proper-ties, which are translated into Uppaal timed automata.His work is used in this paper.

3 DOMAIN MODEL

We have developed a domain model consisting ofeight DSLs to describe IoT applications and theirenvironment. The languages and their usage rela-tions are shown in Figure 1; this figure also showsthe model-to-text transformations from the domainmodel’s DSLs. We have used Xtext1 and Xtend2

for the development of the DSLs and transformationsshown in Figure 1.

Figure 1 distinguishes three categories of lan-guages: (1) Domain DSLs, (2) System DSLs, and(3) Validation DSLs. The Domain DSLs allow thegeneric domain model to be configured for a spe-cific application; the Domain DSLs make the domainmodel a metamodel for distributed control applica-tions. The System DSLs use the Domain DSLs todescribe the structure and behavior of an IoT system.The Validation DSLs allow the validation of a speci-fied system in its environment.

To explain the DSLs, we use a running examplefrom the lighting domain. It involves a building withthree rooms: two offices and a central lobby. Eachroom has one occupancy sensor and one light point.

The intended behavior in the offices can be speci-fied in two rules: (1) When an office’s occupancy sen-sor detects human presence and its light is off, thenthe office’s light should switch on. (2) If the light inan office is on and no office occupancy is detected fora period of five minutes, then the office’s light shouldswitch off.

The behavior in the lobby is different: (1) If itslight is off and occupancy is detected in an office orthe lobby, then its light should switch on. (2) If thelobby’s light is on and no occupancy is detected any-where for a period of five minutes, then the lobby’slight should switch off.

1http://www.eclipse.org/Xtext/2http://www.eclipse.org/xtend/

Figure 1: DSLs and model transformations.

3.1 Domain DSLs

As distributed control systems can be very extensive,it is beneficial to describe their structure hierarchi-cally. Structure DSL allows the definition of such a(logical or physical) hierarchy. Instances of StructureDSL describe the types of structures in a distributedcontrol system and the hierarchical containment ofthese structures.

For the reference example, we can use the logi-cal structure of a building to describe a light controlsystem. For this, we distinguish two types of struc-tures: buildings and rooms. Rooms are assumed to becontained in buildings.

Event DSL describes the events that are commu-nicated in the system. This includes the events thatare sent from sensors and to actuators. Each event hasa name and optional arguments.

For our running example, two types of events aredistinguished: occupancy events are used to commu-nicate occupancy and light level events are used tocommunicate a desired light level. Occupancy eventsdo not have arguments; light level events have one, alight level represented by an integer value between 0and 100 percent.

3.2 System DSLs

Topology DSL describes the (logical or physical)structure of a system in terms of the structure typesdefined in a Structure model. The class diagram of

Figure 2: Topology DSL class diagram.

Topology DSL is shown in Figure 2. Topologies arebuilt up hierarchically; each element of a topology hassensors and actuators, a physical geometry (used forvisualization), and optional subordinate topologies.

Visualization is supported by a model transforma-tion: for documentation purposes, Topology modelscan be translated into HTML pages with an SVG vi-sualization of a system’s hierarchical structure.

The running example’s topology consists of fourtopological elements: a building and three rooms.The rooms are subordinate topologies of the building.

The specification of topology models for buildingsneed not be done manually; if information is stored ina Building Information Model (BIM) (Eastman et al.,2011), then a Topology model can be extracted froma BIM model automatically.

The desired behavior of an IoT system is realizedby controllers that respond to sensory inputs. An IoTsystem may consist of thousands of controllers, butthese typically have similar behaviors. This is ex-ploited by Behavior DSL, which describes param-eterized behaviors that can be instantiated for manydifferent controllers. Behavior DSL is based on theSense-Think-Act paradigm. The main classes of Be-havior DSL are shown in Figure 3. System behaviorsare described in terms of timed state machines. Tran-sitions between states are triggered by input events orby timers and may be guarded by conditions. A tran-sition involves issuing output events, updating localvariables, and resetting timers.

A transformation to PlantUML3 is used to visual-ize behaviors; this transformation generates a graphi-cal representation of the specified timed state machinefrom a (textual) Behavior model.

For the running example, we have specified thetimed state machine shown in Figure 4. It involvestwo states and four transitions, two of which are self-transitions. The Vacant state is the behavior’s ini-tial state; this is the state in which the lights are off.

3http://www.plantuml.com/

Figure 3: Behavior DSL class diagram.

Figure 4: Behavior model.

When an occupancy event is received, a transition tothe Occupied state is made. The transition also in-volves switching on the lights by issuing a light levelevent with argument LOcc. In addition, two timers arestarted, an occupancy timer and an update timer. Inthe Occupied state, an occupancy event is issued eachtime the update timer expires. This allows a controllerto act as an occupancy sensor for other controllers.For example, the office controllers can provide occu-pancy input to the lobby controllers. In the Occupiedstate, the occupancy timer is reset each time an oc-cupancy event is received. A timeout of the occu-pancy timer triggers a transition back to the Vacantstate; this includes switching off the lights by issuinga light level event with argument LVac.

Variation of a specific behavior is possible using abehavior’s parameters, which can be set for each dif-ferent instance. This is done in Control DSL, whichinstantiates behaviors for a given system. These in-stantiated behavior instances are called controllers.Control DSL also describes the mapping of behavioronto a system’s topology. This is done by defining

connections between sensors, controllers, and actua-tors. Sensors can be connected to controller inputs,actuators to controller outputs, and controller outputsto controller inputs. To allow analysis of the influenceof network behavior, edges can be attributed withprobability distributions for message loss and mes-sage latency. The class diagram of Control DSL isshown in Figure 5. To visualize the system structure,we have implemented a model transformation fromControl DSL to GraphViz.4

We have also implemented code generators forlighting systems; these are model-to-text transforma-tions from Control DSL. These transformations areless generic than the other transformations shown inFigure 1. This is because the specifics of the underly-ing technology are part of the model transformation.The generation of system configurations is outside thescope of this paper.

In our running example, we distinguish three con-trollers, one for each room. These controllers imple-ment the behavior shown in Figure 4. The coupling ofthe sensors, controllers, and actuators of our referenceexample is shown in Figure 6. It shows the inputsand outputs of the room controllers. A room’s sensoris connected to the room controller’s occupancy in-put and the room controller’s light level output to theroom’s actuator. In addition, the occupancy outputs ofthe office controllers are connected to the occupancyinput of the lobby controller. This allows the lobby torespond to occupancy in the offices. In other words,the office controllers act as occupancy sensors of thelobby controller. The same can also be achieved bydirectly coupling the office sensors to the lobby con-troller, but this would involve many connections forlarge systems.

3.3 Validation DSLs

Scenario DSL provides a way to describe the behav-ior of the environment of a system; it describes sen-sor events at given moments in time. As each sensorevent needs to be specified explicitly, Scenario DSLis suited for the specification of simple scenarios, e.g.test case scenarios. More complex scenarios can bespecified using usage profiles, which should be cali-brated using data from existing buildings. The pro-files can be used to generate Scenario models or exe-cutable models that generate sensor triggers.

For our reference example, we do not include aScenario model, because we validate the system usinginteractive simulation and exhaustive analysis usingmodel checking.

4http://www.graphviz.org/

Figure 5: Control DSL class diagram.

Figure 6: Control network.

Behavior DSL describes an IoT system’s behaviorin a procedural manner using states and transitions. Inother words, it describes how the system should act.As specifying timed state machines is challenging, es-pecially for large-scale systems and complex behav-iors, we use Requirement DSL that describes whatthe system should do, i.e. in a declarative manner. Forinstance, Requirement DSL can specify what a sys-tem’s response to a specific user scenario specifiedusing Scenario DSL should be. It can, however, beused in a much wider setting. The separation of whatand how also makes communication between techni-cal and non-technical stakeholders easier, as accep-tance requirements are not mixed up with technicaldetails.

The main classes of Requirement DSL are shownin Figure 7. The language describes requirements interms of propositions. Two types of propositions are

distinguished: (1) event propositions hold for an in-finitesimal time and (2) state propositions hold forlonger time periods. Basic propositions can be com-bined in composite propositions, e.g. using Booleanoperators and, or, and not. The circumstances underwhich these propositions should hold are described bya requirement’s scope and pattern. Requirement DSLallows five scopes (Globally, After, Before, After-Until, Between) and seven patterns (Response, Prece-dence, Absence, Universality, Existence, Recurrence,Invariance), making a total of 35 pattern-scope com-binations. Most patterns and scopes are based onthose of Dwyer et al. (1998) and Konrad and Cheng(2005).

As IoT systems can become very extensive, it isvery labor-intensive to specify requirements for allsystem components. Because such systems typicallyhave many instances of the same behavior, Require-ment DSL allows requirements to be specified forcombinations of sensors, controllers, and actuatorsthat adhere to a set of constraints. These combina-tions and the corresponding constraints are specifiedin a Requirement’s header, which describes a patternthat is to be matched in a Control model. As such, Re-quirement DSL allows a highly efficient specificationof system requirements: a requirement that shouldhold throughout an entire system needs to be speci-fied only once.

For our reference example, we want to specify thatwhen any office sensor detects occupancy, the lightsin the lobby should switch/be on for at least five min-utes. This requirement is shown in Figure 8. Therequirement starts with a header specifying the sen-sors, controllers, and actuators that are to be con-sidered. This example involves a sensor, two con-trollers, and an actuator; the sensor is connected to thefirst controller, the first controller to the second, andthe second controller to the actuator. There are twosuch combinations: (1) Office1’s sensor, Office1’scontroller, the Lobby’s controller, and the Lobby’slight point, and (2) Office2’s sensor, Office2’s con-troller, the Lobby’s controller, and the Lobby’s lightpoint. For large-scale systems, there are typicallymany combinations that can be addressed using a sin-gle requirement.

In the requirement’s body, two propositions aredefined: the first proposition is an event proposition,which defines the occurrence of an occupancy eventfrom the sensor; the second is a state proposition,which defines the actuator/light being fully on. Thebottom statement is the actual requirement. This re-quirement uses the combination of the Globally scopeand the Invariance pattern. This instance of the In-variance pattern specifies that each time the sensor is-

Figure 7: Requirement DSL class diagram.

Figure 8: Requirement model.

sues an occupancy trigger, the actuator should be at100% on for 300 seconds. The Globally scope indi-cates that this property should be satisfied under allcircumstances.

Experiment DSL combines all information spec-ified in the other DSLs; it combines instances of Con-trol DSL, Scenario DSL, and Requirement DSL. Thelatter two are optional. As it includes the full systemspecification, Experiment DSL is the starting pointfor the transformation to analysis models. There aretwo transformations from Experiment DSL, one to aJava co-simulation framework and one to the modelchecker Uppaal (Larsen et al., 1995). These are ex-plained in Section 4.

For the running example, an Experiment modelis the combination of a Control and a Requirementmodel. It does not include a Scenario model.

4 SYSTEM VALIDATION

With our domain model, we support two typesof system validation. Static system validation is dis-cussed in Section 4.1. As not all system propertiescan be validated statically, we also support validationusing executable models. Simulation is explained inSection 4.2, model checking in Section 4.3, and theircombination in Section 4.4.

4.1 Static Validation

Correctly specifying a large-scale IoT system is ahuge challenge, as many concepts and settings haveto be specified and it is difficult to keep overview. Be-cause there are typically many similar structures andbehaviors, people easily make specification errors,e.g. copy-paste errors. Our domain model providessupport for avoiding errors and keeping overview,while the system is being specified.

For the DSLs introduced in Section 3, specific val-idation rules have been defined. Naming rules ensureuniqueness of model element names. This is relevantfor nearly all languages, as the concepts introducedare used several times. For instance, event types areused by nearly all other DSLs.

Structure rules validate the structure of DSL in-stances. For a Behavior model’s state machine, thereachability and leavability of all states is checked.For Topology models, it is checked whether the phys-ical containment matches the logical containment.Control models are checked for cyclic dependenciesbetween sensors, controllers, and actuators.

Usage rules validate usage and redundancy of de-fined concepts. For instance, it is checked whether thesensors and actuators in a Topology model and all in-puts and outputs of a Control model are used. More-over, it is checked whether actuators are connectedto more than one controller, as this may cause non-deterministic behavior.

Type rules check type consistency. For instance, itis checked whether sources and destinations of edgesin a controller network have the same event type.Moreover, it is checked whether controller parametersand event arguments are within the specified ranges.

4.2 Simulation

Simulation is used to validate the behavior and per-formance of IoT control systems. These systemsmay have thousands of sensors and actuators. Tobe able to run a simulation of an IoT system, oneneeds a platform that allows the simulation of manysimultaneously executing and communicating simu-lators. To accomplish this, we have developed alightweight Java co-simulation framework (JCoSim)providing timing and publish-subscribe services, sim-ilar to HLA’s RTI (Dahman, 1997). We decided todevelop our own services as the open-source versionsof HLA did not offer the desired functionality at thattime and the cost of the commercial versions wereconsidered too high.

The transformation from Experiment DSL toJCoSim generates simulators from the components of

Figure 9: Timed automaton for Globally scope and Invari-ance pattern.

the specified IoT system. This involves separate sim-ulators for sensors, controllers, and actuators. More-over, edge simulators are generated to handle thecommunication in the control network; there is onesimulator for each edge in a Control model. The Sce-nario model specifies the moments at which sensorstrigger. This requires a scenario player simulator thattriggers each sensor simulator to fire a sensor event atthe right time.

Besides simulators for sensors, controllers, andactuators, the JCoSim model contains monitoringsimulators, which are derived from a Requirementmodel. For the propositions and requirements speci-fied in a Requirement model, proposition and require-ment monitors are generated. Requirement DSL dis-tinguishes basic and composite propositions; monitor-ing simulators are generated for both types. The mon-itoring simulators for the basic propositions monitorthe controller simulators that are specified in a Con-trol model; those for composite propositions observeother proposition simulators.

For each of the 35 pattern-scope combinations ofRequirement DSL, a separate automaton has been de-fined and these are transformed into simulators inJCoSim. Figure 9 shows the automaton for the Glob-ally scope and the Invariance pattern; the automata forthe other scope-pattern combinations were defined byBuit (2017). The requirement simulators distinguishnormal and forbidden state; the forbidden states rep-resent requirement violations. During simulation, it ischecked whether they enter a forbidden state. If theydo, e.g. the Error state in the automaton in Figure 9,then the user is notified of the requirement violation.

For our running example, the transformation fromExperiment DSL to JCoSim results in a model with23 simulators: 3 sensor simulators, 3 controller sim-ulators, 3 actuator simulators, 8 edge simulators, 4proposition simulators, and 2 requirement simulators.

4.3 Model Checking

Co-simulation provides a scalable system analysismethod; it allows thousands of components to be sim-ulated simultaneously. A drawback of simulation isthe fact that it is limited to a single scenario, typicallya good-weather scenario. As IoT systems may be verylarge and may have a lifespan of several decades, theanalysis of good-weather behavior is not sufficient tofind all errors that appear in a system’s lifetime. Weuse model checking to analyze a system’s behaviorunder all possible input scenarios. This has been re-alized by a transformation from Experiment DSL in-stances to Uppaal models (Larsen et al., 1995).

With respect to the generated automata, the trans-formation is very similar to the transformation toJCoSim. The only difference is that the generated Up-paal models do not have actuator automata; actuatorsare modeled using global variables. So whereas theJCoSim model for the reference example involves 23simulators, the corresponding Uppaal model has only20 automata.

There are some conceptual differences betweenthe timed state machines specified in Behavior DSLand Uppaal’s timed automata. The main differencesare: (1) Uppaal does not allow multiple synchroniza-tions per transition and (2) Uppaal does not allowsynchronizations with data. The former has been ad-dressed by introducing sequences of synchronizationsbetween committed states; these committed statesmake sequences of transitions atomic. We addressedthe latter by communication using global variables.

The Uppaal model contains the same propositionand requirement automata as the JCoSim simulationmodel. JCoSim is restricted to monitoring whetherforbidden states are entered. Besides entering of for-bidden states, the Uppaal models allows other typesof analysis. An overview of the properties that can bechecked is given by Buit (2017).

For our running example, an Uppaal model with20 automata and 2 queries is generated, one query perrequirement automaton. Uppaal’s exhaustive analysisshows that both queries are satisfied: i.e. when a sen-sor in an office detects occupancy, then the lights inthe lobby are/switch on for at least five minutes.

4.4 Simulation and Model Checking

Model checking provides an exhaustive system anal-ysis; this means that it finds requirement violationseven under very unlikely circumstances. Unfortu-nately, model checking is not sufficiently scalable toanalyze the (possibly) huge state space of an IoT sys-tem. This does not mean that model checking does

not provide value for the analysis of complex systems.To manage complexity, our approach breaks downthe system into manageable subsystems using the theControl model as a basis. Instead of analyzing all con-trollers and all requirements simultaneously, one can,similar to the approach of Doornbos et al. (2015), it-eratively analyze all combinations of one controllerand one requirement. The state space of these combi-nations is typically small enough to allow exhaustiveanalysis.

A second way in which model checking addsvalue is by combining the strengths of simulation andmodel checking. Simulation is sufficiently scalableto simulate large-scale systems, but large-scale sim-ulations provide limited diagnostic capabilities. Ifsimulation detects a requirement violation in a sys-tem, then model checking can be used for diagnosis.Model checking should zoom in on the controllerscausing the violation. As a requirement violation isknown to exist, model checking’s exhaustive analy-sis will find it and provide a minimal trace leading tothe violation. This trace is translated into a Scenariomodel that can be used to identify the underlying rootcause.

5 CASE STUDY

The domain model introduced in Section 3 has beenapplied for intelligent lighting systems. Such systemstypically consist of devices connected via an IP com-munication network. These devices need not be re-stricted to the lighting domain as lighting systems aremore and more integrated with other building man-agement systems, such as HVAC, blinds, and eleva-tors. The input devices include a variety of sensors(e.g. occupancy and light level sensors), buttons forscene selection or dimming, but also mobile devicesfor personalized control. A lighting system’s outputdevices are light points, units consisting of one ormore LED units with all necessary parts and wiring.

An existing building has been used as the basisfor a case study of our domain model: Witte Dame5

is a renovated factory in the center of Eindhoven. Inthe context of the OpenAIS project,6 the traditionallighting system on the building’s fifth floor has beenreplaced by a new intelligent lighting system. Thissystem was modeled and simulated using our domainmodel. The light system covers 367 light points withover 1,300 behavioral functions. The floor plan isshown in Figure 10.

5http://www.dewittedame.nl/6http://www.openais.eu/

Figure 10: Floor plan of Witte Dame’s fifth floor.

The first step in the case study involved the val-idation of the intended Behaviors. This was doneby deploying a Behavior on a relevant part of WitteDame and validating whether the deployed Behaviorwas as expected. For this, we used the simulation andmodel checking as explained in Section 4. To allowdiscussion with stakeholders, we developed visualiza-tion tooling that allows interactive simulation. A usercan trigger sensors in the interactive visualize and ob-serve the resulting system behavior.

The combination of Requirement DSL and theinteractive visualization has shown its great value.While simulating a lighting system, the status of thesensors and light points is visualized. For instance,the status of sensors and buttons is shown and the lightlevel of light points. In addition, the status of the re-quirements is shown using a transparent overlay overthe corresponding devices. A requirement’s overlaystarts green and turns red when the requirement is vi-olated.

The second step involved the validation of the sys-tem. Manually creating DSL instances for hundredsof light points would be a lot of effort and would beextremely error prone. Hence we developed a pipelineof model transformations (Rieger et al., 2018). Dedi-cated tooling has been developed to generate Controlmodels. The corresponding work flow is visualized inFigure 11. There are two inputs: (1) a Microsoft Visiofile describing the geometry of the floor plan includ-ing the location of the sensors and light points, and(2) a Microsoft Excel document describing the systembehavior and their deployment onto the devices in thesystem. From this and manually created Structure,Event, and Behavior models, two models are gener-ated: (1) a Topology model and (2) a Control model.From these generated models, Java simulation modelsare generated as explained in Section 4.2.

To thoroughly test a lighting system using simu-lation, elaborate scenarios need to be specified. Be-cause Scenario DSL is not suited to manually spec-ify long scenarios and manually triggering a gener-

Figure 11: Generation of co-simulation models.

ated lighting system is both tedious and inefficient,we have developed Usage DSL and Occupancy DSLspecifically for human behavior in buildings. Theselanguages allow people’s activities and their mappingonto locations in a building to be specified. The sim-ulation of people’s movement and activities in thebuilding generate sensor triggers that automaticallytrigger the generated lighting simulation.

A screenshot of the interactive simulation isshown in Figure 12. It shows Witte Dame’s floor planand the status of the light points in the system. Apartfrom lighting behavior, the simulation also considersthe system’s performance with respect to energy us-age, an important KPI for lighting systems (Baum-gartner et al., 2012). The virtual prototype allows anassessment of the energy usage for different behaviorsand behavior settings. For instance, one can analyzethe influence of occupancy timeout periods on a light-ing system’s energy usage.

The co-simulation has proven to be very useful inthe design of the large-scale virtual prototype. Dur-ing the verification of the control behavior of WitteDame more than ten errors have been identified andcorrected. These included (1) incorrect or missingcontrol group allocations of light points, (2) incorrectsensor linking, and (3) missing or incorrect linkingof controllers. Although these errors could have beenfound by manual inspection, co-simulation greatly ac-celerated the errors’ detection and correction.

Furthermore, the validation of the behavior withlighting experts has led to renewed discussions oncustomer-desired behavior leading to several adapta-tions to the initial control design for the Witte Dameprototype including improved controller linking andbetter behavior specification. These results clearly il-lustrate the power of the co-simulation environment.

Figure 12: Simulation of Witte Dame case study.

6 CONCLUSION

In this paper, we have presented a domain model fordistributed control systems, which comprises eightDSLs that each capture one system aspect. Forinstance, it includes two languages that allow thegeneric domain model to be adapted for a certain do-main. Moreover, the system’s structure is separatedfrom its behavior, allowing reuse of behavior in mul-tiple locations.

The domain model is the basis for a virtual pro-totyping application, which supports both simulationand model checking. For both kinds of analysis, wehave separated what the system should do from howit does this. This provides powerful analysis supportfor large-scale distributed control systems: Require-ment DSL is the basis for the generation of monitor-ing automata that are included in the generated sim-ulation and model checking models. These automataobserve the system and notify the user of requirementviolations. The combination of simulation and modelchecking is of especially great value: (1) simulationallows large systems and many requirements to beanalyzed simultaneously, and (2) model checking al-lows diagnosis of an identified requirement violationby zooming in on the violating subsystem.

Our co-simulation framework allows scalablesimulation of thousands of sensors, controllers, andactuators. In the lighting domain, we have shown thatthe combination of our generic co-simulation withdomain-specific front-ends and back-ends is veryvaluable: (1) usage and occupancy front-ends wereused to generate realistic building occupancy patterns,and (2) a visualization back-end was used to visualizesystem behavior and allow users to interact with a run-ning simulation. The interactive visualization allowsearly feedback of system behavior, possibly alreadyduring a system’s sales phase.

7 FUTURE WORK

The domain model described in Section 3 is focusedon the interaction between distributed sensors, con-trollers, and actuators. Implicitly, it is assumed thatthis interaction does not involve complex data beingshared. For some distributed control systems, dataplays a prominent role. For instance, in the logisticdomain, one needs to keep track of orders and re-sources. To include such concepts, our domain modelneeds to be extended by a Data DSL, which is usedto define data structures, which can be used by theother DSLs. This would allow analysis of logisticcontrol systems such as the ones studied by Verrietet al. (2012).

The system validation described in Section 4 pro-poses simulation and model checking to detect andcorrect system errors. Not all errors can be addressedusing these techniques: e.g. configuration errors canbe found, but hardware failures cannot. To allow moretypes of errors to be found, a root cause analysis ap-proach is proposed. This approach feeds our virtualprototype with actual sensor data and compares theresponse of the virtual prototype’s actuators to the ac-tual actuator responses. In case of differences, a rea-soning framework is to be used to identify the mostprobable root cause.

The domain model described in this paper al-lows the specification of distributed control systems.The desired system behavior can be realized in manyways. For instance, one may decide to have redundantcontrollers to improve system reliability. The neces-sary communication of the redundant controllers canbe specified in terms of Behavior models. This mixesfunctional and non-functional system aspects. A chal-lenging open issue is the separation of these aspects.Specifically, we would like to specify system behav-ior in a deployment-agnostic manner and describe de-ployment, and the corresponding communication, ina separate Deployment DSL. This would allow ef-ficient analysis of different deployment strategies, asthe behavior needs to be specified only once.

ACKNOWLEDGEMENTS

The research is carried out as part of the Prisma pro-gram and H2020 OpenAIS project under the respon-sibility of Embedded Systems Innovation (ESI) withPhilips Lighting as the carrying industrial partner.The Prisma program is supported by the NetherlandsMinistry of Economic Affairs, the OpenAIS projectis co-funded by the Horizon 2020 Framework Pro-gramme of the European Union under grant agree-

ment number 644332 and the Netherlands Organisa-tion for Applied Scientific Research TNO.

REFERENCESBaumgartner, T., Wunderlich, F., Jaunich, A., Sato, T.,

Bundy, G., Grießmann, N., and Hanebrink, J. (2012).Lighting the way: Perspectives on the global lightingmarket. Technical report, McKinsey & Company, Inc.

Beckers, J. M. J., Muller, G. J., Heemels, W. P. M. H.,and Bukkems, B. H. M. (2007). Effective indus-trial modeling for high-tech systems: The example ofhappy flow. In 17th INCOSE International Sympo-sium, pages 1758–1769, San Diego, CA. INCOSE.

Bertran, B., Bruneau, J., Cassou, D., Loriant, N., Balland,E., and Consel, C. (2014). Diasuite: A tool suite to de-velop sense/compute/control applications. Sci. Com-put. Program., 79:39–51.

Broy, M., Kirstan, S., Krcmar, H., Schatz, B., and Zimmer-mann, J. (2012). What is the benefit of a model-baseddesign of embedded software systems in the car indus-try? In Emerging Technologies for the Evolution andMaintenance of Software Models, pages 343–369. IGIGlobal, Hershey, PA.

Buit, L. J. (2017). Developing an easy-to-use query lan-guage for verification of lighting systems. Master’sthesis, University of Twente, Enschede.

Dahman, J. S. (1997). High level architecture for simula-tion. In 1st International Workshop on DistributedInteractive Simulation and Real Time Applications,pages 9–14, Eilat. IEEE.

D’Angelo, G., Ferretti, S., and Ghini, V. (2017). Multi-levelsimulation of internet of things on smart territories.Simul. Model. Pract. Theory, 73:3–21.

Doornbos, R., Verriet, J., and Verberkt, M. (2015). Ro-bustness analysis for indoor lighting systems: An ap-plication of model checking in large-scale distributedcontrol systems. In 10th International Conference onSystems, pages 46–51, Barcelona. IARIA.

Dwyer, M. B., Avrunin, G. S., and Corbett, J. C. (1998).Property specification patterns for finite-state verifica-tion. In 2nd Workshop on Formal Methods in SoftwarePractice, pages 7–15, Clearwater Beach, FL. ACM.

Eastman, C., Teicholz, P., Sacks, R., and Liston, K. (2011).BIM Handbook: A Guide to Building InformationModeling for Owners, Managers, Designers, Engi-neers and Contractors. Wiley, Hoboken, NJ.

France, R. and Rumpe, B. (2007). Model-driven develop-ment of complex software: A research roadmap. In2007 Workshop on the Future of Software Engineer-ing, pages 37–54, Minneapolis, MN. IEEE.

Gruhn, V. and Laue, R. (2006). Patterns for timed propertyspecifications. Electron. Notes Theor. Comput. Sci.,153:117–133.

Haskins, B., Stecklein, J., Dick, B., Moroney, G., Lovell,R., and Dabney, J. B. (2004). Error cost escalationthrough the project life cycle. In 14th INCOSE In-ternational Symposium, pages 1723–1737, Toulouse.INCOSE.

Hendriks, M., Geilen, M., Behrouzian, A. R. B., Basten,T., Alizadeh, H., and Goswami, D. (2016). Checkingmetric temporal logic with trace. In 16th InternationalConference on Application of Concurrency to SystemDesign, pages 19–24, Torun. IEEE.

Hooman, J. (2016). Industrial application of formal modelsgenerated from domain specific languages. In The-ory and Practice of Formal Methods, volume 9660 ofLecture Notes in Computer Science, pages 277–293.Springer, Berlin.

Konrad, S. and Cheng, B. H. (2005). Real-time specifi-cation patterns. In 27th International Conference onSoftware Engineering, pages 372–381, St. Louis, MO.ACM.

Koymans, R. (1990). Specifying real-time properties withmetric temporal logic. Real-Time Syst., 2:255–299.

Kurtev, I., Hooman, J., and Schuts, M. (2017). Run-time monitoring based on interface specifications. InModelEd, TestEd, TrustEd, volume 10050 of LectureNotes in Computer Science, pages 335–356. Springer,Berlin.

Larsen, K. G., Pettersson, P., and Yi, W. (1995). Model-checking for real-time systems. In International Sym-posium on Fundamentals of Computation Theory, vol-ume 965 of Lecture Notes in Computer Science, page62–88. Springer, Berlin.

Mellegard, N., Ferwerda, A., Lind, K., Heldal, R., andChaudron, M. R. V. (2016). Impact of introducingdomain-specific modelling in software maintenance:An industrial case study. IEEE Trans. Softw. Eng.,42:245–260.

Meyers, B., Wimmer, M., van Vangheluwe, H., and De-nil, J. (2013). Towards domain-specific property lan-guages: The promobox approach. In 2013 Work-shop on Domain-specific Modeling, pages 39–44, In-dianapolis, IN. ACM.

Rieger, C., Westerkamp, M., and Kuchen, H. (2018).Challenges and opportunities of modularizing textualdomain-specific languages. In 6th International Con-ference on Model-Driven Engineering and SoftwareDevelopment, pages 387–395, Funchal. SciTePress.

Serral, E., Valderas, P., and Pelechano, V. (2010). Towardsthe model driven development of context-aware per-vasive systems. Pervasive Mob. Comput., 6:254–280.

Theelen, B. and Hooman, J. (2015). Uniting academicachievements on performance analysis with industrialneeds. In Quantitative Evaluation of Systems, volume9259 of Lecture Notes in Computer Science, pages 3–18. Springer, Berlin.

Verriet, J., Liang, H. L., Hamberg, R., and van Wijngaar-den, B. (2012). Model-driven development of logisticsystems using domain-specific tooling. In ComplexSystems Design & Management 2012, pages 165–176,Paris. Springer.

Volter, M. (2010). Architecture as language. IEEE Softw.,27:56–64.