Http:// The Glider Instrument Manager Features and Demo DORII AHM Giorgio Bolzon OGS October 22 th 2009, LRZ, Munich

http://www.dorii.eu/

The Glider Instrument ManagerFeatures and Demo

DORII AHM

Giorgio BolzonOGS

October 22th 2009, LRZ, Munich

Outlines

OGS application in DORII

Present Glider control system

Description of Glider Instrument Manager

Demo Glider management

Second Evaluation procedure

Demo extended

Future Plans

The OGS pilot application in DORII

Environmental community: Oceanographic and coastal observation and modelling Mediterranean ocean observing network (OCOM-MOON) numerical module: OPATM-BFM parallel off-line coupled 3D physical-

biogeochemical model for MedSea developed under MERSEA-IP observational module:

MedARGO APEX FLOATS managed by OGS sensors on board: Sea-Bird CTD ( T, S, p, Lon, Lat, time)

INGV MFS circulation model

http://bulletin.mersea.eu.org

physical forcings (u, T, S, KV, wind, IRR…)

data OPATM-BFM (MPI on 32 PEs)float

The OGS application in DORII




Glider Trieste_1 sensors on board: about 1700!





Access to:

float data

OPATM-BFM

Glider

The OGS application in DORII




Glider Trieste_1 sensors on board: about 1700!





Access to:

float data

OPATM-BFM

Glider

?

?

The OGS application GLIDER GLIDER sampling and cycle characteristics: transmission to ground station

Saw-tooth motion generated by bouyancy control and internal mass distribution Coastal

observation

Multi-sensor

Autonomy: 40d (200m/1500km) to 5months (1000m/3000km)

Glider Local Control

A freewave device can control one Glider only

Normal I/O with a Serial Port: we can use a common hyperterminal-like interface to send commands and receive outputs

There are not any graphical interfaces It is necessary to know the syntax to communicate with Glider

Distances about 5-7 km

Any PC

Serial Port

Glider Remote Control

Iridium Modem

Webb Research (the Glider Company) provides a client/server pair java applications

SERVER CLIENT

Serial Port

Ad hoc server

Serial tcp tcp

dockserver gliderTerminal

User Command line

Glider Terminal Client

Allows multiple Gliders control

It has other tools and utilities, like simple scripts and event subscribing

It appears exactly like the hyperterminal

ADVANTAGES

No security: many people (actually anyone) can manage the same glider

All the clients get the same answers at the same time

DISADVANTAGES

IM planning

THE PROBLEM WAS SOLVED STEP BY STEP First of all, by sniffing traffic between two hosts we were able to understand something.

Then searching on the web, by chance we found some open source application dealing with Glider and we managed to contact people who implemented it - some very nice people, who helped me a lot.

We got the output protocol, to get the answers from the server, from the open source application we found.

Finally, the next and decisive step was to find out the Input Protocol. Thanks to Lucas Merkelbach.

We cannot manage the Serial Port, there is already the dockServer service using it. Stopping the server means stopping use gliderTerminal: the OGS glider team people could disagree.

NO CHOICE: in order to have the control of the glider we implemented another client application, which does the same work of gliderTerminal (a sort of copy of the existing one).

We did not know the client/server protocol. GliderTerminal is not an open source application, no tutorials are available.

RESTRAINT

PROBLEM

The Protocol

<?xml version="1.0" encoding="UTF-8"?><packet type="request" action="gliderCommand" gliderName="sim_030" command="get m_battery" senderID="gbolzon;michelangelo.ogs.trieste.it;surfalarm.py;3141592653624" senderVersion="surfalarm.py;0.1" ><gliderLink gliderName="sim_030" port="/dev/ttyUSB3" device="direct"></gliderLink></packet>

<?xml version="1.0" encoding="UTF-8"?><packet type="request" action="gliderCommand" gliderName="sim_030" command="get m_battery" senderID="gbolzon;michelangelo.ogs.trieste.it;surfalarm.py;3141592653624" senderVersion="surfalarm.py;0.1" ><gliderLink gliderName="sim_030" port="/dev/ttyUSB3" device="direct"></gliderLink></packet>

= 13.23000 volts

<?xml version="1.0" encoding="UTF-8"?><packet type="response" action="gliderConnect" gliderName="sim_030" senderID="dockserver;ogadock.ogs.trieste.it;Dock Server;1247128964286" senderVersion="Dock Server;4.7"> <gliderLink gliderName="sim_030" device="direct" port="/dev/ttyUSB3" status="1"/><gliderLink gliderName="sim_030" device="direct" port="/dev/ttyUSB3" status="1"/><text> = 13.23 </text></packet>

<?xml version="1.0" encoding="UTF-8"?><packet type="response" action="gliderConnect" gliderName="sim_030" senderID="dockserver;ogadock.ogs.trieste.it;Dock Server;1247128964286" senderVersion="Dock Server;4.7"> <gliderLink gliderName="sim_030" device="direct" port="/dev/ttyUSB3" status="1"/><gliderLink gliderName="sim_030" device="direct" port="/dev/ttyUSB3" status="1"/><text> = 13.23 </text></packet>

<?xml version="1.0" encoding="UTF-8"?><packet type="response" action="gliderConnect" gliderName="sim_030" senderID="dockserver;ogadock.ogs.trieste.it;Dock Server;1247128964286" senderVersion="Dock Server;4.7"> <gliderLink gliderName="sim_030" device="direct" port="/dev/ttyUSB3" status="1"/><gliderLink gliderName="sim_030" device="direct" port="/dev/ttyUSB3" status="1"/><text> 000 volts </text></packet>

<?xml version="1.0" encoding="UTF-8"?><packet type="response" action="gliderConnect" gliderName="sim_030" senderID="dockserver;ogadock.ogs.trieste.it;Dock Server;1247128964286" senderVersion="Dock Server;4.7"> <gliderLink gliderName="sim_030" device="direct" port="/dev/ttyUSB3" status="1"/><gliderLink gliderName="sim_030" device="direct" port="/dev/ttyUSB3" status="1"/><text> 000 volts </text></packet>

Backbone of the IM

Composing strings and sending them to the socket

Reading xml packets from the socket and parsing them (first level parsing)

The IM basic tasks are:

= 13.23000 volts

Parsing this kind of strings to get the numerical value (second level parsing)

Same result of GliderTerminal

GliderTerminal gives results that can be analyzed by a human mind, not by an algorithm

This is a key step for us: now we can use this value in our system (IM).

Glider IM features

Composition

Iteration

Condition

Once we are able to send commands and receive outputs, we can use the commands in the classic way all the programmers do, that is:

getPosition to get longitude and latitude

getStatus to get battery, vacuum, fin, air pump and other attributes

Why an IM can improve the control of the instrument?Why an IM can improve the control of the instrument?

(apart from the access to the Grid infrastructure)

There is no communication between the IE and the instrument unless an user executes a command from VCR. GetAttributes functions access variables in the IE’s RAM.

The IM is absolutely parallel to the GliderTerminal, since they are connected with the same socket. They can be used together.

Saving Iridium’s time

Avoiding conflict

Panic management

If during the phase of surfacing, when glider is receiving commands (out of mission), the glider becomes heavier than sea water for some reason, it submerges and the communication breaks up … it glides softly towards the sea bottom.

…Glider can be lost (cost 80.000$)!

Panic management

With an IM a command can be executed only IF some conditions are verified. Automatically!

Without to be afraid to forget something.

There are also some “dangerous” commands, in the sense that executing them the internal devices can be seriously damaged. Glider is not a robust machine (that’s why Glider Team people do not like other people manage it…).

We introduce standardization system and management We introduce standardization system and management information system information system commands procedures are now under commands procedures are now under

an algorithm control rather than under human controlan algorithm control rather than under human control

They are really afraid!Solution

DEMO Glider management

Since the glider is physically switched on, the IM sends a dummy command to the glider, so that:

IF the command returns something, the IM can switch to the state ON

ELSE it cannot.

Turn ON

Glider is turned off, user manages the simulator actually.

The simulator is not always on. We turn it on on user’s request.

This demo represents scenario 1 for the key users evaluation

OGS IE IM gliderSIM




WARNING! Dangerous command

Second Evaluation procedure

5 Key Users belonging to the oceanographic community

They already have the digital certificates from the previous evaluation

NEW Training Material is going to be prepared to give them info about the new features of VCR and use of the workflow (material under construction at http://www.dorii.eu/resources:communities:training)

NEW SCENARIOS designed to give the opportunity to the key users to experience the new features of the IE/IM:

1. 1st Scenario: control of glider

2. 2nd Scenario: access to float historical data

3. 3rd Scenario: use of workflow

Key users tasks list

Scenario 2:

1. Login to VCR

2. Use IE/IM: turn on one or more Argo floats

3. Refresh data of a float

4. Get information on attributes time-evolution (ex. BatteryVoltage)

5. Retrieve graph output at http://eva.ogs.trieste.it/float/out.png

6. Retrieve ASCII data at http://eva.ogs.trieste.it/float/out.dat

7. Get historical binary data at a specified cycle

8. Download data locally

9. Log-out

Scenario 1:

1. Login to VCR

2. Use IE/IM: turn on the glider

3. Get information on status

4. Get information on position

5. Set fin angle

6. Turn on/off air pump

7. ONLY FOR EXPERT USERS: change status and put command with proprietary glider syntax (ex. ….)

8. Log-out

Scenario 3:

1. Login to VCR

2. Access to WfMS

3. Choose SEs

4. Submit workflow

5. Log-out

New Command to get attribute time-evolution

Example: Latitude position (output from IE not yet integrated in VCR – issue for OGS customized VCR)

New Command to get historical binary data

Arguments have to be specified: cycle number and target on SE

Historical binary data file can be then downloaded locally

DEMO workflow

OGS Float workflow

WfMS query IE for IM

User chooses IM

OGS Float workflow

WfMS lists SEs and browses them

user chooses location for Binary Model of Float

OGS Float workflow

WfMS turns on chosen IM

WfMS performs command to transfer Float’s Binary Model to chosen SE location

OGS Float workflow

WfMS lists SEs and browses them

user chooses location for data processed by OPATM-BFM application

OGS Float workflow

Basing on provided information WfMS prepares job’s files

WfMS submits job and transfer all the files needed

Glider IM Future Plans

Continuous listening to the socket

Alarm management

Implement a graphical interface to set up and run a mission

Hopefully further development in DORII+

SHORT TERM = Open Points

Working with a broken connection (like in mission)

Setting up privileges

MID TERM

OCOM-MOON Future Plans

Glider – see previous slide

OGS customized VCR working

SHORT TERM = Open Points

Further extend float IM: more graphical outputs VCR integrated, instrument geo-reference (with support of ELETTRA)

Full integration of workflow (in collaboration with PSNC)

Full integration of visualization tools (in collaboration with HLRS+LMU)

Hopefully further development in DORII+

MID TERM

…Many thanks for your attention

GLORY TO

Documents

Http:// The Glider Instrument Manager Features and Demo DORII AHM Giorgio Bolzon OGS October 22 th 2009, LRZ, Munich