The Glider Instrument Manager Features and Demo DORII AHM Giorgio Bolzon OGS October 22 th 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 physical forcings (u, T, S, K V, wind, IRR…) data OPATM-BFM (MPI on 32 PEs) float

The OGS 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)  Glider Trieste_1  sensors on board: about 1700! INGV MFS circulation model physical forcings (u, T, S, K V, wind, IRR…) data OPATM-BFM (MPI on 32 PEs) float Access to: float data OPATM-BFM Glider

The OGS 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)  Glider Trieste_1  sensors on board: about 1700! INGV MFS circulation model physical forcings (u, T, S, K V, wind, IRR…) data OPATM-BFM (MPI on 32 PEs) float 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 SERVERCLIENT Serial Port Ad hoc server Serialtcp 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 = volts = = volts 000 volts

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: = 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? (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 $)!

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 information system  commands procedures are now under an 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 IEIM gliderSIM

DEMO Glider management

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 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 at/out.png 6. Retrieve ASCII data at at/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