This example is a simple implementation of a set of wearable devices, mainly monitors that watch the heart rate, blood pressure etc. and an insulin pump. All the hardware devices are simulated with small windows with simple controls. Adapter managed objects have been written for Ponder2 that will interact with the "hardware" enabling Ponder2 to set scan rates and to receive readings whenever a scan is performed.
To start the BSNs you must start the BSN Controller using the ant command
ant bsn
You will see a window like this
By clicking on the various buttons, you can open and close the sensor windows. When a sensor window is open it is discoverable and can be added into a Ponder2 system if one were running. When a sensor window is closed, it is no longer available and cannot be seen. See the Body Sensor Devices page for a full description of the devices and how to use them.
There are seven PonderTalk files which form the example. They build upon one another, introducing a little bit of the example each time. The tutorial files can be found in the resource directory. The PonderTalk files are those with ".p2" as their suffix. A full description of all the tutorial PonderTalk files can be found below.
These tutorial files can be used with ant commands. To read and execute tut1.p2 run ./ant tut1, to read and execute tut1.p2 and tut2.p2 run ./ant tut2. etc. etc. eventually running all of them with the command ./ant tut6.
Sometimes you may want to interact directly with the Ponder2 SMC and some of the managed objects that you have instantiated. To do this you can start a telnet session into the running SMC. When you do, a shell managed object is created and you can type special shell commands and PonderTalk to it. When the SMC starts up it prints out its shell's port number which is normally 13570. So to connect, start a telnet session, like this one:
telnet localhost 13570
Connected to localhost.
Escape character is '^]'.
Ponder2 Shell Rev: 408 Date: 2007-06-17 22:13:57 +0200 (Sun, 17 Jun 2007)
No wild chars yet
/ $
You will be greeted with a prompt ($) at which you can type special shell commands such as cd and ls. You can also enter PonderTalk which will be immediately compiled and executed. Try this with Alarm Display below.
./ant tut1 will run the PonderTalk that reads the alarm into the Ponder2 SMC. It creates an alarm called root/alarm in the SMC. You can interact with the alarm using the SMC shell as described above. Start the shell and when you get the prompt, try the following (see AlarmDisplay for more information about the alarm PonderTalk commands):
/ $ ls
alarm
policy/
event/
shell/
factory/
/ $ root/alarm show.
net.ponder2.objects.P2Message@46d228
/ $ root/alarm hide.
net.ponder2.objects.P2Message@8ae45a
/ $ ^C
The values you see after the PonderTalk commands are the string representations of the return values from each PonderTalk statement.
To run the full example you need to read and execute all the tutorial .p2 files, tut1.p2 to tut6.p2. You can do this with the command
./ant tut6
Assuming that you have the BSN controller still running (if not, start it now - ./ant bsn) you can cause some policies to be executed. Using the controller buttons, create a Blood Pressure monitor and a Heart Rate monitor.
Now raise the blood pressure. You will see the sample rate of the heart rate monitor increase and an alarm will appear.
Lower the blood pressure and the sample rate of the heart rate monitor will slow doen and the alarm will disappear.
The different files contain:
Tutorial File | Description | PonderTalk Documentation |
---|---|---|
tut1.p2 | Loads the alarm clock managed object and
creates an instance of it. The last four lines show the alarm, sets it going, stops it and hides it again. This is too fast to see but shows how it can be used. |
AlarmDisplay |
tut2.p2 | Creates several event types that the BSN example will be using. The events types created and used later in this example are: newBSN, lostBSN and BSNvalue. After running this PonderTalk file there will be several new entries in root/event | EventTemplate |
tut3.p2 | Imports and instantiates the BSN adapter. This is a managed object that acts as an interface to external BSN devices. As each BSN device is discovered, an event will be generated and a policy will create a new instance of the BSN adapter to handle that particular BSN device. | BSNAdaptor |
ex1/tut4.p2 ex3/tut4.p2 |
Imports and creates the discovery manager.
The discovery manager notices new BSN devices created by the
BSN Controller and then sends a newBSN
event. It also
notices when a BSN device has disappeared, whereupon it sends a lostBSN
event. The discovery manager also picks up values sent from the BSN devices and sends them on as a BSNvalue event within the SMC. In real life this would probably be done by the BSN adapters and this tutorial should really reflect that. Notice that the discovery manager is given the event templates for the events that it is to produce. This is important because events are strongly typed. Policies will use the same event templates and only if an event is generated from that exact event template will a policy accept it. Note that in exercise 3 the creation of the BSN Controller is done inside a PonderTalk block. The code inside the block is not executed until the block is sent the value:value: message. This enables us to create it in different locations for the more complicated nurse (hospital.p2) example. |
DiscoveryManager |
ex1/tut5.p2 ex3/tut5.p2 |
Creates the policies that react to the newBSN and lostBSN events.
The addBSN policy creates an instance of the
BSN adapter (see tut3.p2, above) and places it in the root/bsn domain. The lostBSN policy removes the adapter from the domain. Note that there are no conditions for these policies, they will always perform their action if the event is raised. As above, in exercise 3 we create a block that when executed by the nurse (hospital.p2) example, will create the policies in the appropriate place by the use of arguments. |
Policy ObligationPolicy |
ex1/tut6.p2 ex3/tut6.p2 |
Now here are two policies that actually do some work
with the values from the BSN devices. These policies receive BSNvalue events. The first policy "hearthigh" detects when the value of the heart rate goes over 130. This check is done in the condition part of the policy. If that succeeds then the action block sets the sample rate of the blood pressure monitor to half a second and it sets the alarm ringing and shows the alarm. The second policy "heartnormal" detects when the heart rate drops below 120 with its condition block. The action part of the policy sets the blood pressure sample rate to 5 seconds, turns off the alarm and hides it. Again for exercise 3 this is all declared within a block for later instantiation. |
Policy ObligationPolicy AlarmDisplay |