1 / 29

Instrument and Platform Agent Architecture (IPAA)

Instrument and Platform Agent Architecture (IPAA). Steve Foley, David Everett Life Cycle Architecture Review La Jolla, CA. Agenda. IPAA background Release 1 Product Description Use Case Overview Architectural Overview Technology Challenges and Achievements

virgo
Download Presentation

Instrument and Platform Agent Architecture (IPAA)

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


  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 ?

More Related