Instrument and Platform Agent Architecture (IPAA)

1. Instrument and Platform Agent Architecture (IPAA) • Steve Foley, David Everett • Life Cycle Architecture Review • La Jolla, CA

2. Agenda • IPAA background • Release 1 Product Description Use Case Overview • Architectural Overview • Technology Challenges and Achievements • Progress in Elaboration Phase (from LCO to LCA) • LCA Accomplished Use Cases • Demonstrated Use Cases

3. IPAA Subsystem Overview • Provides interface between instruments and the rest of CI • Configures and commands instruments • Collects data from instruments and publishes into CI • Intended to be more production of drivers than development of CI core concepts after initial data plumbing is complete

4. Release 1 Product Description Use Case Overview • Responsible for: • #18 Command An Instrument • Supporting: • #2 Hello Instrument • #19 Direct Instrument Access • #20 Command a Resource • #24 Version a Resource

5. Command an Instrument Use Case • Initial use case is to command an instrument • User determines commands to apply to an instrument • Instrument Agent has already been created and registered • Commands are issued to Instrument Agent • Commands have been redirected to Instrument Driver specific to the instrument • Commands are applied to the instrument by the driver • Responses are passed back to the user • Does not handle permissions or direct access

6. Architectural Overview • 2 sides to the IPAA black box: • AMQP protocol to talk to CI’s registries, services, agents, UIs, etc. • RS-232/Ethernet with instrument-specific text or binary protocols to communicate with instrument. • Between the 2 sides are the agent and driver that provide access control, locking, translation, buffering across slow links, instrument/driver specific logic

7. Simplified Architecture Overview Instrument Management Services • Basic flow of commands to instruments • Return path is the same AMQP Instrument Agent Instrument Driver Instrument AMQP TCP Instrument Agent Instrument Driver Instrument AMQP TCP

8. Instrument Agent Interface: CI Side • Generic common interface for system-wide interaction • Extensible at lower levels for instrument-specific work • Based on getting and setting parameters and executing commands • Announces capabilities and uses registries for discovery • Potentially capable of transactions and sequences

9. Instrument Agent Interface • Execute commands (CI and Instrument) • Get/Set parameters (CI and Instrument) • Get status (CI and Instrument) • Get capabilities (CI and Instrument) • Get translator function (CI) • Get/Set CI lifecycle state (CI) • Get registry entries (CI)

10. Test Instrument: SBE49 • SeaBird Electronics SBE49 CTD has been our simple, text-based test example instrument, easy to mock up and test. • Some commands: • DS – Status & params • Polled sampling • PUMPON / PUMPOFF • TS – Take single sample • Autonomous sampling • START / STOP • NAVG=x – Samples to average • Settings • BAUD=x • OUTPUTFORMAT=x • …various coefficients to set

11. General Instrument State Model • SBE49 model is already a degenerate form of this, logic is partially there • Will work to generalize instrument agent software to support this model

12. Instrument Driver Interface: Instrument Side S>navg=16 # set a few parameters S>autorun=y S>pumpdelay=30 S>ds # display some settings SBE 49 FastCAT V 1.3a SERIAL NO. 0000 number of scans to average = 16 pressure sensor = strain gauge, range = 10153.0 minimum cond freq = 3273, pump delay = 30 sec start sampling on power up = yes output format = raw HEX temperature advance = 0.0625 seconds celltm alpha = 0.03 celltm tau = 7.0 real-time temperature and conductivity correction enabled, not applied to raw data S>outputformat=2 # Raw Tmp, Cond, Pres, Sal S>ts # Test single sample 290782, 2727.603, 524521, 1.6496 S>start # Start streaming 290782, 2727.603, 524521, 1.6496 290785, 2727.598, 524521, 1.6496 290781, 2727.610, 524521, 1.6496 …

13. Instrument Driver Interface: Instrument Side • Takes Get/Set/Execute based calls • Translates to/from instrument protocol • Maintains necessary protocol state/mode with instrument • Needs to know what commands are valid • SBE49 has very little state to track, other instruments will have more

14. Status of Progress • Elaboration period has been focused on infrastructure for process management, data flow, and proper interaction with registries • End-to-end exchanges of messages demonstrate complete data pathway and interface sanity • “Command An Instrument” use case was addressed and can be demonstrated.

15. Technology and Interface Choices • AMQP between Agent and Driver • May be changed during construction if performance or situation requires it • AMQP between Agent and CI registries • Currently TCP with text protocol to serial device (would be through a serial-to-Ethernet device)

16. Technology Challenges and Achievements • Agent registration  discoverable Instrument Agents • Separation of agent and driver  decoupled processing • Simulated device  testing of data plumbing • Protocol interaction with device  science data flows • Start data flowing from instrument, acquiring by driver, and publishing to subscribers  complete data path coverage

17. Challenges – Registration • Registries did not initially exist, but have been developed with the Data Management team, and their contents defined • Instruments are the first working agents, so plenty of work needed to be done to organize registries • Sequence is a bit involved, but easy to use at higher levels

18. Challenges – Registration

19. Challenges – Separation of Agent/Driver • Having the driver and agent in the same process was problematic for both CI interactions and instrument interactions happening simultaneously • Agent and driver communicate via AMQP messages • Separate agent and driver allows for independent development, testing, profiling, maintenance, and improvement as needed • Messaging layer is added complexity

20. Challenges – Simulation • Did not initially have instruments • Have multiple developers • Need simple, repeatable, controllable, far end for commands/queries • We developed a simulator that handles very simple requests from our code. Allows for a quick guess at compatibility before a test instrument is ready. • Definitely not a substitute for a real instrument

21. Challenges – Interacting with devices • All instruments behave a little differently • Initial simulator should fit protocol spec…but no guarantees • First cut of interaction with a sensor is to a mocked up SeaBird Electronics SBE-49 • Allows for commanding an instrument and flowing data • Rest of instrument agent flows data through completed data plumbing

22. Achievement – Putting It All Together • Initial setup and registration

23. Challenges – Interaction and instrument command

24. Challenges – Interaction and data publishing

25. Early Work Completed - RSN While platform agent work is not on the Release 1 agenda, investigations were made into RSN software platform command and control interfaces to prevent problems in the future. • Initial plans are for the interface to be Python (AMQP?) based, SNMP may also be an option if needed • Interfaces to interact with RSN platform software elements are being specified with RSN team

26. Early Work Completed – CGSN Work has been done to plan integration with the CGSN platforms. • On-board controller will be Linux based embedded ARM processor (Technologic Systems TS-7370) • Python capable, early versions of code function without modifications. • Capability Container is slow, needs tuning • More use case work needs to be done

27. One More Elaboration Iteration • IPAA has one more iteration to go before IPAA moves on to construction. This iteration will include the following work: • Support for direct access mode • Streamline data flow • Generalize and improve instrument state management • Keep up with core CI refactoring and improvements • Continue work with RSN and CGSN teams • Add drivers for an ADCP (binary format) • Add Q330 data logger driver (3rd party Antelope software)

28. Significant Risks • Performance on CGSN embedded device • Profiling indicates that OOI logic in python is fine for the anticipated load, but Capability Container messaging is slow • Other libraries exist and may be worth testing. • If Python is too slow, we may port of some code to C • Common data format is still unspecified, will affect translation complexity and effort • Simulators are only so good…will need real devices soon • Instrument behavior is sometimes surprising/unexpected • Staffing – We need the people to write the drivers

29. Addressing the Key Issues Thanks ! Questions ?