SALT

SALT : a Simple Application Logic description using Transducers for the Internet of Things

SALT is a langage that one can use to describe a distributed application over the Internet of Things. As it introduces an Object Hardware Abstraction, SALT is universal. Its expressivity is based on a well-known tool (Transducer).

As a langage, SALT is useful to express the logic to be executed on each element composing your plateform. Transducers described by SALT have input and output messages. These messages are sent to a list of other objects that have subscribed to that one. They react then depending on their own Transducer.

You can describe your own application using SALT by clicking on this link :

This tool is useful to describe the logic you want to deploy on your nodes, and to test it.

When starting, you are asked to enter your XMPP credentials. This is useful to collect all informations of your real DLITe objects, create a graphical representation, and then include them into your applications. For our example, we will not use that capability, so you can cancel.

Then, you access the main Frame of our tool. This screen is separated in 2 parts :

• on the left, the object repository. You can instancied new virtual device, and see your real devices (as collected through XMPP if it has been used and defined in the first screen)
• on the right, the central part that allows you to describe your logic (with a right clic on each object) and to define publish-subscribe dependences between objects (by left-clic on the source, then on the target)

At the beginning, you have no object in the central part, and nothing on the repository (on the left). This is because we don't use here any XMPP identification.

Let's create some object. By clicking on "ADD" in the repository, you can express what kind of object you want to simulate (remember, we don't use real object in that demonstration. If reals objects are used, and application's XMPP capabilities activated, then your real objects are detected and appear on this panel, ready to be integrated in a new application). Talking about objects created by the "ADD" button, these are generic and virtual object that may or not implement some generic features (such as button, led, some mathematical capabilities, etc...)

For our demonstration, we want to create a button and a light, and to see how we can express the logic to make them work together.

Let's first create a Button, with the Button feature. I gave "MyButton" as name

Let's create now a Light. Just to make it more powerfull that a simple light, we give it some other features (LED plus CPU plus timer).

Once the two virtual objects are created, you should have the same repository as this one :

Our two objects are now available on the repository. To begin programming them, you have to drag and drop them on the central part of this tool. Then, each object can be edited.

As you can see, each object tells its name. Depending on its features, you have different panes to access specific options given by each feature. For example, the "MyButton" object gives access to a button that you can press, because this feature has been defined during the creating process.

SALT is now ready to give us the ability to program this button, and in a universal and easy way (just imagine now that you have the same thing to do on a real object, in NesC, or Java, or any language that you have never used before... Or that you just want to use the same code that you have developped for another button, in a different language..)

To start application description, we right click on each object in order to access the FST interpreter. By choosing "Edit rules", you get the next screen

First, you need to create a FST state, depending on what you have in mind. In our case, we just need two states: "Pressed" and "Released". A click on an empty space of this screen gives you the possibility to create a new state. So, we create this :

Now, we need to make the link between the real action and these states. Because we know what standard features each object offers, our tool gives you a simple way to catch that event. A button generates "push" hardware input messages. You must describe the reaction you want to implement when this event is detected. In a Transducer, this is called a 'Transition'. In our case, we want to send a message to the light, to warn it that something has happen on the button. This message is free content, so we choose 'msg' for example.

To create this "transition", let's click on the start state (here it is "released") and drop the mouse on the next state ("pressed"). Then, we express that the Transition goes from 'Released' state to 'Pressed' state when the Transducer received a "push" hardware message. And we generate an event (a message) for listeners (others objects that are interested in our actions and reactions). The content of this message is 'msg'.

In this dialog box, we choose the event category (hardware) for our input message. There is only one input message (green background). Then, we describe our output message (in blue). We can have one or more output messages. Here, we choose an External message, and then define its content (msg).

We can now validate, and define another Transition (Sometimes, we use the word 'rule' for that), from 'Pressed' state to 'Released'. This rule is also a reaction to a "push" Hardware message.

This screen shows the full FST given to our Button. Don't forget to define your initial state (by right click on the state you want to start with).

We can now describe the light behaviour. Using the same tool (by right click on the object light), we express what this object has to do. When receiving the 'msg' message, our light must react and swicth on. Of course, if the light is already on, we need to switch off. This can be easily describe, because this virtual object has 'LED' feature, so we can use a Hardware message to swictch on or off. This order is an Hardware Output message. It has one parameter: On or Off (Don't worry, our tool helps you...)

The full FST for the light is given on next screenshot.

Now, our two objects are configured. The only missing configuration is the publish-subscribe definition. You can describe it by clicking on an object, and then the target. That will create a publish-subscribe constraint between them two (an arrow appears). On the final screen, you can see objects, their dependance, and how many rules(transitions) for each FST.

To test the application, you just have to "Publish Rules" (see the button on bottom left). If you have real objects, they receive their FST, and start running them. Here, because it is only virtual object, you can use them with the right pane. The last screen shows the application running

Project Members

Publications