by Jacques Verriet, Jack Sleuters and Richard Doornbos (TNO-ESI)
Modern smart systems are incredibly complicated. Building a digital twin of the system allows engineers to ensure that it works correctly and root out many problems before it is installed.
The internet of things promises a connected world where we can access and control every object around us. But actually building these interconnected systems is a massive challenge. As part of the OpenAIS project [L1], sponsored by the EU Horizon 2020 Programme, ESI (TNO) [L2] along with the TU/e and major industry players including Philips Lighting, developed an open architecture solution for connected lighting systems. The focus for ESI was to develop the tools needed to build digital twins of these complicated systems that would allow them to be validated and tested before being installed and commissioned.
Components of a Digital Twin
When building a digital twin of a system, there is more to consider than the system itself. The environment in which the system will be installed also needs to be modelled, along with interactions with people or other systems. And it needs to be verified against system requirements and tested with user scenarios to ensure it works as intended.
Therefore, to build a useful and accurate digital twin, in addition to specifying the system itself, one needs to define the environment, and create rules and tools to validate it. For each area (environment, system, and validation), ESI developed Domain Specific Languages (DSLs) to define and build the virtual components of the system, the environment, operating requirements, and test scenarios [1]. In total, eight different DSLs were created (see Figure 1).
Figure 1: Domain-specific languages (DSLs) and model transformations.
Domain
The domain is the environment in which the system will operate. Two languages were developed for creating a customisable domain. The Structure DSL defines topology elements and their containment such as “floor” and “office” and that an “office” is part of a “floor”. In the case of the OpenAIS project this was used to define the layout of the fifth floor of the “Witte Dame” (White Lady) building in Eindhoven. The Event DSL is used to specify events in the system such as “occupancy” (when a sensor detects someone in a room) and “light level” (the lights should be on when someone is present or off when the room is empty).
System
For the actual system itself, three domain-specific languages were developed: Topology, Behavior and Control. The Topology DSL defines the structure of the system, the Behavior DSL defines what the system should do, and the Control DSL defines how it should work. Together, these three languages provide a complete system specification.
Using the Domain and System languages, the OpenAIS team was able to develop a complete digital twin of the top floor of the Witte Dame and the planned new lighting system. The next step was to validate and test the model.
Validating the Digital Twin
While the first two sets of languages define the domain and system, the Validation DSLs focus more on the system requirements. Three languages were developed for this area covering: Requirements, Scenario and Experiment.
The Requirement DSL covers the system requirements. The Scenario DSL specifies the behaviour of the system environment. And finally, the Experiment DSL combines the information of all languages.
Using the model transformations from the Experiment DSL, the team was able to automatically generate an interactive simulation and a model checking model. This enabled the team to see how the system worked under the different scenarios. The Requirement DSL was used to generate requirement monitors that were used to automatically identify potential problems and errors.
From Virtual to Actual
Having built and tested the complete virtual system, the next step was to build it for real. The pilot project at the Witte Dame contained some 400 luminaires with embedded sensors. This lighting control system is based on IoT-standards and frameworks, with IP connection to the end node. It combines wired and wireless devices from multiple vendors in a single system connected through a standard IT-network with commercial off-the-shelve IT components.
Using the Digital Twin to Solve Problems with the Real System
For the Witte Dame project, the digital twin was primarily used for development and testing of the system before installation. However, there are many benefits to be had by using digital twins for debugging problems during installation, and throughout the lifetime of the installation to find the real root cause of problems from equipment failures to human errors.
To address this, ESI applied a root cause analysis methodology that combines manual and automatic analysis to solve issues with the system during installation, commissioning, and operation. The methodology comprises four phases: collect, detect, analyse, and resolve.
In the collect phase, data that is relevant to detecting failures, is collected. This can be manual inspection reports and logs, or errors automatically reported by the system. In the detect phase, collected actuator data is compared against the digital twin generated actuator data (see Figure 2): differences indicate anomalies. Now that an error has been detected, the next step is to determine exactly which error has occurred.
Figure 2: Digital twin takes real sensor data (purple) as input to generate reference actuator data. Operational actuator data is compared with the reference actuator data (blue) to detect an anomaly (red).
In the analyse phase, the error is automatically analysed in detail. Expert knowledge in the form of FMEA and HAZOP studies, is used to find the root-cause of the error. The approach taken resembles the Fishbone (Ishikawa) method.
In the Resolve phase, the RCA system provides a list of steps that the user needs to take to solve the problem. This can be used to provide clear instructions to the installer or maintenance personnel, who typically do not have expert knowledge of the system.
Figure 3: Visualisation of the digital twin showing an interactive simulation where sensors can be triggered manually and the corresponding actuator behaviour is shown. Graphs showing the power usage of the system are plotted.
Successfully Tested and Ready for Action
Demonstrated at the OpenAIS Symposium in May 2018, this project showed that the DSLs can be used to create accurate digital twins for development and testing of complex systems and that these models can then be used to automatically detect and determine the root cause of issues in the real system.
Link:
[L1] OpenAIS website: http://www.openais.eu/
[L2] ESI website: http://www.esi.nl/
Reference:
[1] R. Doornbos et al. "A Domain Model-Centric Approach for the Development of Large-Scale Office Lighting Systems", in Proc. CSD&M, 2018.
Please contact:
Jacques Verriet, Jack Sleuters, Richard Doornbos, TNO-ESI, The Netherlands
+31 88 866 5420
