Lorien:Tutorial - Running the Introductory Demo

From Lorien Documentation
Jump to: navigation, search

This tutorial guides you through the "introducing" Lorien demonstration. It shows how all software on a node can evolve quickly, cheaply, and under a completely uniform and simple model of software evolution.

The demo starts by showing manually evolving the software of a node directly attached to your computer, including hardware drivers, protocols and applications, and then demonstrates an approach to applying the same theory to remotely evolve software over-the-air on other nodes.

To try this demo you'll need at least two TelosB / Tmote Sky sensor nodes. One of the nodes (A) will act as a base station and will be connected to your computer with a USB cable, and the other node(s) (B) will be running on batteries and will not be physically connected to anything.



First, for each of the nodes in the "B" category, connect the node to your computer, open a command line and navigate to the xmakefiles/tmote/ directory, and type:

make recon.u

This will build a collection of components and flash them to the connected node. Wait for the flashing process to finish, then repeat for any other nodes that you intend to run on battery power.

Next, connect the node you're going to use as the base station (A) to your computer. You will keep this node connected to your computer for the remainder of the demo. So next, type:

make shell.u

This will build and flash the interactive shell components to the connected node.

Finally, type:

make demo_intro

This will build the rest of the components we're going to use in this demo.

Uploading extra files

Lorien works by storing components and other files in external flash memory and loading them into program memory as needed. Each Lorien composition tends to be a minimal composition of components needed to perform the currently required tasks.

As such, the shell composition does not actually include a radio driver, or a MAC protocol. The "recon" composition similarly has no temperature sensor driver or LED driver.

The next step is therefore to send all of these extra files we'll be needing to the attached shell node. Some of them will be installed on the shell node itself to allow it to communicate with the rest of the network, and some of them will be sent over the air to the battery powered nodes. The reason we don't start off this demo with a "network capable shell" is to help show how Lorien is able to install drivers, protocols and applications on demand and how it tracks dependencies between them.

To send across all of the extra files needed for the demo to the shell node, open a command window and navigate to the xtools/ directory, then type:

./loriencomm -s ../xmakefiles/tmote/obj/Netcom -s ../xmakefiles/tmote/obj/netcom.so -s ../xmakefiles/tmote/obj/Radio -s ../xmakefiles/tmote/obj/radio.so -s ../xmakefiles/tmote/obj/MAC -s ../xmakefiles/tmote/obj/mac.so -s ../xmakefiles/tmote/obj/Random -s ../xmakefiles/tmote/obj/random.so -s ../xmakefiles/tmote/obj/Blink -s ../xmakefiles/tmote/obj/blink.so -s ../xmakefiles/tmote/obj/LED -s ../xmakefiles/tmote/obj/led.so -s ../xmakefiles/tmote/Blink.evo -s ../xmakefiles/tmote/obj/sht11.so -s ../xmakefiles/tmote/obj/SHT11 -s ../xmakefiles/tmote/obj/sense.so -s ../xmakefiles/tmote/obj/Sense -s ../xmakefiles/tmote/obj/senserep.so -s ../xmakefiles/tmote/obj/SenseReport -s ../xmakefiles/tmote/Sense.evo -s ../xmakefiles/tmote/obj/Deluge -s ../xmakefiles/tmote/obj/deluge.so

These files are sent from your computer to a file transfer component on the sensor node, which writes each file to external flash memory. This procedure can take a while, especially opening a new file on the sensor node. Files are transferred in binary with CRCs.

When upload of new files finishes the loriencomm program will automatically drop into interactive mode from which you can type commands to directly interact with the sensor node. You might like to type "help" and press enter to show what the shell commands are.

Adding components to the shell node

We start by using Lorien's standard software evolution primitives to change the software running on the directly connected sensor node. You can actually issue the following commands in any order and Lorien will do the rest automatically. However, the suggested order offers maximum exposition of Lorien's dependency tracking system.

Start by typing


And press enter to see memory status on the available storage devices. "MCU" memory is program memory, and "mass storage" is the external flash chip.

Using the command


Will show which abstract roles are currently loaded into program memory, while using the command


Will list the files in external flash memory.

We start by adding the "net commander" application component by typing:

add Netcom

This will load and instantiate the associated component and it becomes a persistent member of the system. Lorien provides no feedback to indicate success here - the load/instantiate process is virtually instantaneous. You can try out rs and memstat again to see what's changed. Net commander is basically a user interface on a file dissemination service, as we'll see later.

Although it's an application component netcom didn't do anything obvious when it was installed; this is because it is missing some important dependencies. To see which dependencies are missing in the entire software system, use the command:


This will indicate the Netcom is missing a dependency on something called FileProp (we'll be using an implementation of Deluge to fill the FileProp role in this demo). This is one of the files we sent across earlier, so now type:

add Deluge

Again, the load/instantiate process for Deluge is very fast. Even though we've added Deluge, Netcom still hasn't done anything; use ds again to see why. This shows Lorien's integrity rules at work; even though a FileProp role now exists in the system, Netcom is not permitted to connect to it because FileProp is missing some dependencies of its own. If Netcom was allowed to call functions on FileProp the answer it would get might be something very strange. So, next use add MAC to satisfy the MAC protocol dependency. If we use ds again now we see that although MAC is loaded it has some dependencies of its own that can't presently be satisfied.

So next we use add Radio to install a radio driver. If we use ds again now we see that MAC has less unsatisfied dependencies than it did before; note here that we didn't explicitly tell Lorien to connect MAC to Radio - the connection was automatically made as soon as it was possible.

Finally we use add Random to satisfy the last dependency of MAC. Again, dependencies across all of software are satisfied opportunistically by Lorien, and the effect of adding the random number generator is to be greeted by Net Commander.

Again, it's important to note that we could have added all of these components in any order and the final result would have been the same.

Adding components to other nodes over the air

Net commander is a kind of user interface on a file dissemination service like Deluge. It lets us add and remove files from the file table maintained by the dissemination system; this file table will be made consistent at all nodes running the dissemination protocol.

It takes control of serial port input from the shell, and you can type "help" to see the available commands. Using "exit" will destroy and unload net commander, taking you back to the shell - we'll do this later.

For now we'll add some files to the dissemination system. Issue the following series of commands:

put Blink
put blink.so
put LED
put led.so
put Blink.evo

This collection of files represents all of the files needed to install a blinking light application on all nodes in the network. This includes the blink application itself, the LED driver supporting it (remember nodes don't have LED drivers unless they really need them), and an evolution script which uses the same software evolution primitives that are available in the shell application.

Again, you can add these files to the dissemination service in any order.

After a little while you should see the red LED on your battery-powered nodes blinking on and off, indicating that the components have been installed and the blink application is doing its thing.

Next we'll install a more interesting application in the network that reports the temperature at each node, sending the results back to the shell node where they're printed out.

The temperature sensing application

For this application we need a temperature sensor driver and a sensing application to be sent to the network along with another evolution script. Still in net commander, type:

put Sense
put sense.so
put SHT11
put sht11.so
put Sense.evo

Be aware that issuing commands to the shell node may by this point be a little slow to register, so be patient - the node is pretty busy by now. When you finish issuing this sequence you can exit net commander since we don't need it any more. Do this by typing exit and pressing enter. Press enter again and you'll see you're back in the shell. Don't worry about interrupting file dissemination - Deluge is still running and serving these files to the network.

When all of these files arrive at a node in the network and are installed, they'll start reading their temperature sensor every second or so and will broadcast the value on a particular virtual port. To receive this data we need to install an application on our shell node which listens on the same virtual port and understands the packet format. The SenseReport application can do this for us, so type:

add SenseReport

As soon as any sensor values are broadcast from the network they'll now be printed out at your shell node. Unlike net commander, SenseReport does not take control of serial port input, so you can still issue commands to the shell while data is being received. If you get tired of receiving sensor data for example you can type rem SenseReport and the application component will be removed from the shell node. You can add it back any time later and you'll receive sensor values again.


Software evolution in Lorien is fully persistent. You can see this by removing the batteries from one of your sensor nodes, to simulate a power failure, and putting the batteries back in, perhaps simulating solar recharging the next day. When it boots up the node will return to the exact configuration it was last in - the red LED will be blinking, and it will be broadcasting sensor values.

Personal tools