retour à la page d'accueil du Département d'Informatique  




dSL Information

dSL is a programming language used to program industrial controllers. Industrial controllers have a processing unit, a central memory, and an interface to the environment. With dSL, the environment can be anything from traffic lights to tunnel ventilation systems or assembly lines. Each such a controller can observe the environment through sensors, calculate a reaction to what it sees from the environment and gives feedback through its actuators. Sensors may be of any kind : temperature, presence detection, speed, ... while actuators can change valves, run engines, etc.
dSL is built upon SL (Supervision Language designed and supported by Macq Electronique), and offers transparent distribution to the programmer.
This is a very important aspect of the language, since industrial control must very often be done in a distributed manner. Imagine several controllers cooperating to control the environment. In the SL setup, each controller sees a local part of the environment, sends its view to a central system (which is called the supervisor) which in its turn calculates a reaction and gives feedback to the controllers who apply the changes in the environment. With SL, each of the controllers and the supervisor must be specified separately, and the communications between all parties (controllers and supervisor) must be explicitely added by hand. The controllers are programmed in an assembler like language while the supervisor is specified using SL, an imperative event driven language.
dSL offers transparent distribution, in fact it ignores the difference between supervisor and controllers, and allows the programmer to think about the system as if there is only one enitity. dSL is therefore extended to be able to execute on both the supervisor and the controllers, which allows the designer to only write one piece of code to specify the behavior of an imaginary unique controller. Next, the programmer fills in a localization table, stating which sensor actuator is located on which site (this is done independently from the program), and the dSL distributer generates automatically the necessary code for all sites in the system.
The practical aspects are clear : maintainability, flexibility and simplicity. On the theoretical side, this problem has long been studied before, and many solutions have been proposed, at least from the conceptual or design point of view. However, what is unique in this study, is that we start from an existing and used language, that allows the programmer to program directely the behavior of the system. We added some primitives to handle the distribution aspects, and formalized its semantics. This may lead to some surprises in the theoretical aspects in this work. Since dSL is not intended to be yet another automatically distirbuted design language for reactive systems, some language aspects in dSL (inherited from SL) are not very clean, and could be made better from a theoretical point of view. However, bear in mind that this work goes the other way around: we start from what is used in practice, (a programming lanugage in contrast to a design language), and propose a solution with its practical applicability in mind.

Papers on dSL

An overview of the distribution aspects of dSL can be found in the following paper :
dSL: An environment with automatic code distribution for industrial control systems ; Bram De Wachter, Thierry Massart, Cédric Meuter, Proceedings of the 7th International Conference on Principles of Distributed Systems, December 10-13 2003, La Martinique, France, Volume 3144 of LNCS, pages 132-45, Springer, 2004

Results on the complexity of the distribution problem can be found in the following document:
From static code distribution to more shrinkage for the multiterminal cut ; Bram De Wachter, Alexandre Genon and Thierry Massart, Proceedings of the 4th International Workshop on Efficient and experimental Algorithms, May 10-13, Greece, LNCS, to appear

Preliminary results on the verification of dSL, using the Spin Model Checker can be found in the following paper :
dSL Verification with Spin, A Case Study ; Bram De Wachter, Thierry Massart, Cédric Meuter, Proceedings of the 3rd Automated Verification of Critical Systems (AVoCS03), Technical Report DSSE-TR-2003-2, DSSE, Southampton (GB), April 2-3 2003

An extended overview of the semantics and the properties of the semantics can be found in the following journal paper :
The formal design of distributed controllers with dSL and Spin ; Bram De Wachter, Alexandre Genon, Thierry Massart, Cédric Meuter, AVOCS Special Issue of Formal Aspects in Computing, 2005, to appear.

Technical reports and other information on dSL

A very short introduction on dSL can be found in my DEA work
Code distribution in the dSL environment for the synthesis of industrial process control

The complete dSL grammar can be found here
dSL Grammar

In this master thesis, I assisted Nicolas Devos who made a backend to the dSL compiler in order to make it compile dSL programs with Legos Mindstorm as target platform.
Génération de code de systèmes distribués ; Nicolas Devos.


dSL Demo



A demonstration of the dSL concept has been realised using Lego Mindstorms. We are using a model of two locks that introduces some interesting constraints.

The constraints on the allowed actions for the two locks are :

  • No two subsequent doors may be opened at the same time

  • A door may only be opened when the water level on both sides is the same

  • The water level inside a lock may only be changed when both gates are closed



We realised the model of the two locks using Lego Mindstorms interfaced to 3 PLC (controllers) (A) from Macq Electronique. To command the lego motors, a DC source is used (B), and to inverse its polarity based on one of the outputs of the PLC, a small piece of hardware was realised (C). This was needed to command the direction of the Lego Mindstorms engines. We had to adapt the wires of the Lego Mindstorms connecters to interface to the PLCs (D). And last but not least, the control panel (E) is interfaced to one of the PLCs to issue the commands. Remark the control panel's red not allowed led that indicates actions that do not respect the above constraints.





(A)

(B)

(C)

(D)

(E)





The dSL source code can be found here. The intermediate code (control flow graph) is in binary form and thus not very interesting to look at. The dSL Virtual Machine code produced by the distributer can be found for PLC1, PLC2 and PLC3. Remark that the dSL program does not contain any distribution information. This information (the locations of all input/outputs) comes from the database that is integrated in Macq Electronique's OBviews.

It assigns all buttons (and the led) to PLC1, all I/Os for lock1 to PLC2 and all I/Os for lock2 to PLC3. No other information is needed.





pictures

MPEG



Normal
sequence (11MB)

MPEG



Overview
(7.9MB)

MPEG



Not allowed
(17MB)

MPEG



Components
(14MB)




dSL Software

None available.





dSL Verification

The aim of verifying dSL programs is to offer the programmer a utility that enables to fully test the designed software for bugs. This is done by exploring all execution traces in a simulated environment and check that no bad states are reached.

A model checker is a utility that enables automatic exploration of the global state space (the set of all states reached following all possible execution paths) while looking for violations of two kind of properties :

    Safety properties : nothing bad happens, LTL logic : e.g. [] ! bad

    Liveness properties : eventually something will happen, LTL logic : e.g. [] (send -> <> ack)

The Model Checker answers that the property is verified when there is no execution trace that violates the property, or gives an error trace that violates the property as a counter-example.

Some preliminary results are obtained using the Spin model checker on the canal lock example cited before. The results of these experiments show a real need for the use of verification in safety-critical software design. Indeed, an error was discovered in the canal locks controller, that is caused by bad use of the synchronisation variables in the program. The error first discovered using the model checker, can be classified as improbable since it requires a specific timing on behalf of the operator to open both gates of the same lock. However, the error was actually realised on the Lego model after 10 minutes of hard effort.

These kind of errors are almost impossible to detect in a common testing environment, but can jeopardize equipment and even lifes. Verification is therefore a must.

Read all about it here.




More information

Please, feel free to contact me with any question you may have. Return to my home page to find out how to contact me.





Last updated 02/05/05