Skip to content


Switch branches/tags

Latest commit


Git stats


Failed to load latest commit information.
Latest commit message
Commit time

Lighting DSL

The Lighting DSL is a Domain Specific Language (DSL) that is used to describe a lighting system for a building. From a building description made in the Lighting DSL, a co-simulation description in CoHLA is generated. This co-simulation description is used to generate source code for a running HLA co-simulation of the lighting system in OpenRTI.

The Lighting DSL is implemented using Xtext and Xtend for Eclipse. The project sources can be imported as an existing project by using the extension building in package

Disclaimer The sources included in this project are provided as-is. These sources are currently still lacking proper comments and documentation. This may be added in the future. Also, this README is known to be incomplete.

Project structure

The project structure is as follows.

  • sources: Contains the project sources for the Lighting DSL, including the grammar and code generators.
  • samples: Contains a couple of sample projects of the Lighting DSL.
    • MediumFloor.building was used for the first experiment in the paper.
    • Floor.building was used for the second experiment in the paper.
    • ManyRooms.building was used for the third experiment in the paper and generates multiple federate classes.
  • models: Contains the models that can be used in the Lighting DSL.
  • plugin: Contains the plugin for direct installation in Eclipse.
  • distribution_script: Contains the script that was used to execute the benchmarks regarding distributed execution.


The Lighting plugin can be used by either creating a runtime workspace for the provided project sources or by installing the plugin. A compresses Eclipse feature is included in the plugin directory. You may also install the plugin from a software repository by adding our repository. Keep in mind that the software is unsigned and will therefore ask for confirmation upon installation.

The URL of the software repository is the following:

The plugin depends on the Xtext and Xtend plugins to be installed.

Grammar structure

While the Building.xtext file contains the full grammar, some of the components will be explained here. Every file according to the Lighting DSL starts with a Configuration block, followed by one or more Building definitions.


The configuration block specifies which components to generate CoHLA code for and some other settings. The block looks like the following.

Configuration {
  // Options/settings here

The following options are available. Keep in mind that the order is important.

  • #Actors: INT: Specifies the number of actors that should be generated.
  • OccupancySensorRanges: INT+: Specifies the sensor range configurations to generate. Values should be separated by whitespace.
  • HasLogger: Optional. When provided, a logger will be generated.
  • MeasureTime: INT: Optional. Specifies the simulation time of scenarios. If (a) logger(s) are generated, this will also be the time measured by the logger(s).
  • HideSensorRange: Optional. When provided, the generated images of the building will not display their vision radius.
  • Distributions: INT+: Optional. Provides a list of integers that specify for which size of node sets to generate a distribution.
  • SeparateClasses: Optional. When provided, every area will have its own federate classes.
  • SeparateActors: Optional. When provided, every area will have its own actor(s), performing all exactly the same scenario. This option is only available when SeparateClasses is also provided.
  • ModelDir: STRING: Optional. Used to specify the relative directory in which the models are located. This path is relative to the directory in which the executables are generated from the sources generated by CoHLA.


Every building consists of a set of areas, each of them including a set of devices. Also, scenarios may be specified for each building. A building block in general looks like the following. As can be seen, Scenarios are optional.

Building ID {
  (Scenarios {


Every area may either be a Room or a Corridor. Although the precise grammar for each of these two is a little different, both blocks contain a couple of shared attributes. These are the following.

  • Area: COORD+: Optional. A whitespace-separates list of coordinates having the form of (x,y) to indicate the corners of the area.
  • Devices { DEVICE+ }: Optional. A block containing all devices in the area.

Every device is either a Light or a Sensor. In general, a device looks like the following.

(Light|Sensor) TYPE? ID (on COORD)?

The type is optional and can be used to indicate which model to use. Currently, there is only support for Dimmable and OnOff for Lights and Occupancy for Sensors. By default, Lights are of type Dimmable.


A Room is specified by the following.

Room TYPE? ID {

Here, a type can be specified. There are three types: Basic, Office and OfficeSpace. By default, the type is Basic. Area and Devices are specified as displayed above.


A Corridor is specified by the following.

Corridor ID {
  Rooms: ROOM_ID+

The list of rooms that is added here is the list of rooms connected to this room.

Generated code

The generated code consists of three components.

  • CoHLA code from which a runnable co-simulation can be generated. Scenarios are included.
  • An image displaying the building for each of the sensor ranges provided.
  • A web page that is capable of executing log files resulting from running the co-simulation and graphically showing the movements of the actors and state of the sensors and lights.


Lighting DSL that can be used to quickly generate CoHLA co-simulation definitions for buildings.







No releases published


No packages published