Http:// The Glider Instrument Manager Features and Demo DORII AHM Giorgio Bolzon OGS October 22 th...
-
Upload
trevor-porter -
Category
Documents
-
view
215 -
download
2
Transcript of Http:// The Glider Instrument Manager Features and Demo DORII AHM Giorgio Bolzon OGS October 22 th...
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
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
http://bulletin.mersea.eu.org
physical forcings (u, T, S, KV, 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
http://bulletin.mersea.eu.org
physical forcings (u, T, S, KV, 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
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
DEMO Glider management
DEMO Glider management
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 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