From: "Tom O'Reilly" To: "Software Infrastructure and Applications for MOOS Discussion List" Subject: [siam] Operational interactions with MOOS; meeting notes Date: Thursday, January 30, 2003 3:08 PM On January 29 the SIAM team held a meeting with representatives of OSG and Support Engineering; the goal of the meeting was to stimulate discussion of how these groups will interact with MOOS systems, given new MOOS features and functionality (pucks, Linux nodes, undersea networks, etc...) These discussions were extremely useful to the SIAM team, and will generate "operational" use cases, which will influence the functional software requirements. Following are notes from the meeting. ------------------------------------------------------------------- Present: Mike Kelley, Zorba, Craig Okuda, Dan Davis, John Graybeal, Kevin Gomes, Kent Headley, Mike Risi, Tom O'Reilly O'Reilly gave overview of some new MOOS features; distributed objects and pucks. Rest of the meeting was devoted to presentation of proposed methods of system and sensor integration, deployment, and maintenance in the MOOS context. Headley presented ideas for system build-up and integration. Several steps to load a MMC's operating system and configure it. Zorba noted that we should make maximum use of automation provided by Linux scripts and configuration files. It was also noted that OSG/Support Eng must have capability to configure a new MMC *at sea*. Although actual configuration platform may be Linux, configuration must be achievable using Windows machine as user interface (e.g. via 'telnet'). Text-base configuration is preferred for remote operations in low bandwidth circumstances. Also, ASCII text is portable to a variety of platforms (in the event of computer failure). Configuration tools should be generic, small and capable of working on a variety of platforms, should they need to be emailed and installed on alternate computers (it would be great if all configuration could be done using a serial terminal and a text editor). The Sidearm flash loader utility also needs to be portable (useable at sea) and operate on a variety of platforms, preferably without special cables. Qualification Procedure use case needs to be worked out -- how do developers verify that their software works under a variety of configurations? How does the qualification process work if non-pucked instruments are allowed? How are any system resources they use managed (bandwidth, power, mass storage, program memory...)? We need to develop a use case for fault recovery; a tiered configuration rollback scheme was mentioned... Off-line, End-to-end pre-deployment test should exercise actual communication link and complete path to SSDS. Should include cable backbone segment and any wireless segments. Is there a need for a portable SSDS or will other means of accessing data remotely be sufficient? Version consistency between pucks, puck contents, and node infrastructure (e.g. port-scanner) is absolutely critical. There needs to be a utility for determining an unknown pucks contents that may be used in-situ and does not require special equipment. A wireless (short haul maybe OK) link is desirable, to begin troubleshooting while en route, or if it is possible only to get near to mooring site. How would power/use of the power for this link be managed? -- some sort of remote switching mechanism was suggested. Regarding user control of drivers, it was noted that some drivers may take a long time to shut down, either by design or through malfunction. An "immediate shutdown" option is highly desirable, as time can be a critical and/or expensive factor. Okuda notes that the deployment vessel should a portal on board for system test purposes. Question: during on-shore and on-ship end-to-end testing, how will SSDS be used? Will there be a "test instance" of the SSDS for this purpose? Zorba notes that design must accomodate unexpected power outages; ramifications include file system integrity, capability for "rollback" to previous instrument configuration(s). Regarding "hot swap" issues, Kelley notes that OSG *always* powers off any underwater port before unplugging device. OSG sometimes hot-swaps when the port is above water. Unused underwater ports are *always* dummy-plugged. SIAM presented "manually initiated discovery" scenario for swapping an instrument; operator first runs "uninstall" on port's driver, then swaps instruments, then runs port scan. Manual steps are intended to give operator complete control over electrical safety factors. Kelley states that it is essential to minimize manual steps for instrument swap if personel are working on the mooring itself. Note that a short-range easy-to-use RF link would allow manual steps to be performed from ship. Regarding hot-swapping, Davis speculates that a Jini-like "lease" mechanism might enable device discovery without human involvement. Would likely require additional puck capability (e.g. "give me your puck ID" command). Risi suggests a large physical button(s) installed on the node to manually initiate driver disablement and port scanning. Kelley requests indicator lights. Kelley notes that OSG must develop procedures to test instrument cables on both sides of puck. Some discussion of puckless instruments (guest instruments, hardware malfunction work-around). Needs discussion at observatory policy level. Kelley states that OSG must be able to configure and flash new pucks at sea. Discussed installation on benthic nodes at sea. ROV console port on node could be extremely useful (although Okuda notes that ROV bottom time is expensive). In general, system should have redundant communication channels; each system should have long-range RF, short-range RF, console port on each node (ROV console port on subsurface node). OSG/Support Eng discussed use of watchdogs on OASIS. Zorba says watchdog is absolutely essential. OASIS has two watchdogs. Next steps: 1. Document the meeting and distribute 2. Develop use cases and functional requirements based on meeting 3. Further session(s) to discuss multi-node networks, trouble-shooting procedures and fault-trees ---------------------------------------------- Thomas C. O'Reilly Monterey Bay Aquarium Research Institute 7700 Sandholdt Road Moss Landing, California 95039-9644 831-775-1766 (voice) 831-775-1620 (FAX) oreilly@mbari.org (email) http://www.mbari.org (World-wide Web) "The machine does not isolate man from the great mysteries of nature, but plunges him more deeply into them." - ANTOINE DE SAINT-EXUPERY "Wind, Sand, and Stars" (1939)