Skip to content
Lighting DSL that can be used to quickly generate CoHLA co-simulation definitions for buildings.
Xtend Python
Branch: master
Clone or download

Latest commit

Fetching latest commit…
Cannot retrieve the latest commit at this time.

Files

Permalink
Type Name Latest commit message Commit time
Failed to load latest commit information.
distribution_script
models
plugin
samples
sources/nl/ru/sws/dsl/lighting
.gitignore
LICENSE
README.md

README.md

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 nl.ru.sws.dsl.lighting.building.

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.

Installation

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: https://files.thomasnagele.nl/lighting/plugin

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.

Configuration

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.

Building

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 {
  AREA+
  (Scenarios {
    SCENARIO+
  })?
}

Areas

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.
Device

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.

Room

A Room is specified by the following.

Room TYPE? ID {
  AREA?
  DEVICES?
}

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.

Corridor

A Corridor is specified by the following.

Corridor ID {
  AREA?
  Rooms: ROOM_ID+
  DEVICES?
}

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.
You can’t perform that action at this time.