Skip to end of metadata
Go to start of metadata

Operate Marine Observatory

Monitoring the operations of a marine observatory and its assets, and command observatory assets.


The Operate Marine Observatory activity encompasses monitoring the operations of a marine observatory and its assets, and commanding observatory assets. It is the core marine activity supported by the Release 2 system.


Review Status Ready for OOI Review
AS Priority 5
AS Version 3.2.1

(The diagram does not reflect CG additions to the scenario.)

Issues Status (Jira) OverviewAllUnresolved
Custom Issues Lists Marine IO ReviewMarine IO ProcessesCI IO Verify


Related Use Cases

Use Cases Mapped to This Scenario

The following Use Cases have been mapped to this Acceptance Test Scenario:

Use Cases Cited by This Scenario

This Acceptance Test Scenario cites the following Use Cases:


This text style = background material
This text style = priority <3> (not required).

( ) Indicates footnoted material targeted for Release 3.
( ) Indicates footnoted material targeted for Release 4.
[MI] , [Ops] Provided by MI or Ops team (has no use case).
[NoUC] indicates material for which no Use Case exists.

Overview Diagram

The following diagram has not been updated to reflect CG additions to the scenario.

Click on the thumbnail image to pop-up a full-width image, or see image on its own page.


These positions were identified for the RSN material submitted as the first version of this scenario. The positions are mapped to the corresponding Integrated Observatory roles (in parentheses) when those exist.

RSN Operations Center Technician (Observatory Operator) — This is an RSN employee working normal business hours to monitor the health of the system, schedule any maintenance and to respond to CI and Science User issues. One technician will always be on call 24/7 to respond to high priority situations in the RSN system that are detected automatically by the OMS or by CI’s operation center.

OSU Operations Center Technician (Marine Asset Operator) — This is an OSU employee, analogous to the RSN equivalent role but supporting OSU-specific equipment.

CGSN Marine Operator (Observatory Operator) — This is a CGSN employee working normal business hours to monitor the health of the system, schedule any maintenance and to respond to CI and Science User issues. One technician will always be on call 24/7 to respond to high priority situations in the CGSN system that are detected automatically by the system or by CI’s operation center.

CI Operations Center Technician (Integrated Observatory Operator) — This a UCSD employee working normal business hours to monitor the health of the system, schedule any maintenance, respond to CI, RSN, CG and Science User issues.

Site Coordinator (Observatory Manager, or Site Manager could be a customized variant) — Person responsible to make sure that proposed science experiments do not interfere with other ongoing experiments at the site. For example if one user wanted to increase the gain on an acoustic modem, this coordinator would check with other instrument Managers that could be affected, before authorizing the change. Each site can have a coordinator assigned from the IO responsible for the site.

RSN Core Instrument Manager (Marine Asset Operator) — This person (project scientist) either works directly for the RSN or is contracted to manage one or more Core Sensor Types. They are responsible for managing (along with the RSN field engineers) any calibrations, repairs or refurbishing of the instruments they are responsible for. They also are responsible for verifying the data received from the instruments is valid, that the calibrations are being applied correctly and that the calibration data being used is correct.

CSPP Operator (Marine Asset Operator) — This is the Coastal Surface Piercing Profiler operator, responsible for commanding the CSPPs and monitoring their operational performance.


Trouble Ticket — When an error is detected either manually or automatically that can not be automatically or immediately corrected, information is filled out with the circumstances of the error, affected infrastructure, severity of error and who discovered the error. The form can be filled out manually via a Web Based Data Entry Form, or automatically by software that detects the problem (for example, the RSN OMS). Tickets filed on resources that are the responsibility of a particular IO will be directed to that IO's Operations Center Technicians, who will work to resolve all their open trouble tickets. Trouble tickets will be stored/updated and tracked in a database. Operators will have views into the trouble ticket system to keep track of all ongoing issues with the system and a historical record of all past issues.

Science Pod — A collection of instruments in a frame that can be mounted to the Surface Piercing Profiler as a unit.

End-to-End Scenario

Relevant Use Cases
Material from relevant source use cases is presented in a box with prefixes like this. Each reference can be expanded.
CG.OMC.nn — OMC use case
CG.WS-SC.n.n.n — CGSN OMC workshop notes (scenario number)
CI.UC.nn — CI Release 2 Use Case
CI.CO.n.n — CI Instrument Life Cycle Operational Concept, Version 1-00, 2115-00001, 10/28/2008

Log in as operator

Relevant Use Cases
UC.R2.40 --- Monitor ION resources
UC.R2.46 --- Operate integrated observatory network
UC.R2.55 --- Manage help ticket
An RSN Operations Center Technician, Andy, arrives to work at 8:00 am and sits down at his computer in his office. He and his coworker Cindy are responsible for the daily monitoring of the state of the cabled marine observatory, troubleshooting and fixing any issues within their responsibility, participating in any scheduled maintenance activities, communicating any issues with the rest of the team, and making any changes/updates to the system configurations. They act in support of the observatory management and the technical teams working on observatory assets. They have been working on the project for 3 years and were hired before the commissioning of the system and helped bring the system online and to its current steady state.

Andy accesses the Integrated Observatory system via its web address. He logs in using his own credentials from his institution, and is granted authorized access to the Integrated Observatory system, according to his role as Marine Observatory Operator. With this role, Andy accesses marine observatory controls that would otherwise not be visible or enabled. (See UC.R2.46 Operate Integrated Observatory Network.) ( 1 )

The system identifies Andy's selected dashboard configuration (the page he sees upon login) and restores it. ( 2 ) Next Andy scans the list of Alarm, Warning, and Message notifications that have been filtered to pertain to the RSN Observatory. He also looks at another list of notifications for all of OOI that has been preconfigured to show only the most significant alarms in the last 24 hours. (See UC.R2.40 Monitor ION Resources.)

There are no severe issues that Andy must take action on immediately. This is no surprise as he was on call last night and would have been alerted by his smart phone if something on the RSN network needed immediate attention. (See UC.R2.40 Monitor ION Resources.) All operators can access and support the system from any location that supports reasonable Internet access, including their home. [Ops]

With no immediate issues to deal with Andy goes through the RSN Operations Center email list mail seen by all of the technicians. In it there are emails from the Integrated Observatory Manager, announcing changes to the system upgrade schedule, and the Principal Investigator of the RSN Observatory, asking the technicians to be in tip-top shape on Friday for a visit from the press. ( 3 )

Andy can create a trouble ticket automatically from any mail message, by forwarding it to the appropriate Jira-serviced mail account, but he does not have to do so in this case. Back at the dashboard web page Andy selects the button that brings him to the list of trouble tickets (by opening up a web page displaying a Jira filter). He sees that there are no high priority trouble tickets, but a number of moderate priority ones that he will need to respond to by the end of the day. (See UC.R2.55 Manage Help Ticket.)

Then Andy goes back to the dashboard and reviews planned activities for the day, displayed a 'news' text message. This afternoon CG will be doing an operation to replace the Surface Piercing Profiler at the Shelf site.
R3 Features

Monitor routine operations

Relevant Use Cases
CI Scenarios as features
TBD --- Manage RSN element
UC.R2.14 --- Monitor an Instrument
UC.R2.18 --- Visualize Data Product
UC.R2.23 --- Ingest Data Supplement
UC.R2.26 --- Navigate Resources and Metadata
UC.R2.55 --- Manage Help Ticket
At 8:45 Cindy comes into the office and gets a verbal status of the system from Andy before she logs into her account and reviews her similar dashboard.

At 8:55 Cindy uses a tree selection widget (or similar navigational tool) of installed instruments on OOI to navigate to the Instrument page for the HD Video Camera at Axial. It is scheduled to turn on the lights and record 10 minutes of data. (Actually, since there is no ability to script a cross-instrument operation, there is one instrument schedule that turns on the lights for 15 minutes at the appropriate time window, and another schedule that takes the HD camera video, while the lights are on.) They have had some issues in the past with this operation so she has been tasked with monitoring it daily. (See UC.R2.26 Navigate Resources and Metadata and UC.R2.14 Monitor an Instrument.)

Cindy also brings up a window showing the RSN EMS (element management system) system for the Junction Box at Axial that the HD Camera is attached to. At 9:00 Cindy observes a message on the Integrated Observatory screen for the HD Video Camera Instrument that commands have been executed for the Instrument.

Cindy sees in the Integrated Observatory that the Junction Box current limits have been explicitly adjusted ( 1 ) to allow for the power needed by the lights, and then the current levels increase for the port the camera is on. ( 1 )

At 9:05 the video stream stops and the Junction Box is returned to the state it was in. ( 2 ) She sees a message (log event) from operator #JohnD@Seattle in the Instrument Page asking if anyone knows why the video stream only lasted 5 minutes and not 10 minutes.

( 3, 4 )

Meanwhile, CGSN Marine Operator Joe has returned to the Pioneer array operations center after a long weekend. He logs into his account and looks at the Pioneer array status screen.

The information on the array status screen has flowed from the instruments, through their respective platforms (gliders or moorings), through a satellite or other communication link (typically wireless), to a shore aggregator of data from that platform. (Multiple platforms can be aggregated on one shore system.) The Integrated Observatory communicates with the shore aggregator to obtain the science data, engineering data, and corresponding metadata that has been transferred to shore, and represents that information on the array status screen and other screens of the Integrated Observatory. (See UC.R2.13 Acquire Data From Instrument.)

Joe's initial concern is to verify that the various moorings with telemetry have all called in at their allotted times. The Integrated Observatory system is aware of when each mooring is scheduled to call in, and will automatically generate an event if the mooring fails to contact shore within the specified time window. Joe verifies there were no alarms indicating the mooring fails to connect to shore.

As an indication of how well the system is working he chooses to graph (using his own computer's graphing tools) the times at which each mooring connected over the past three days. Viewing the graph he determines that the Pioneer central mooring was 15 minutes late connecting to shore on Saturday.

Seeing no other errors he calls up a graph of the buoy's motion data (the graph having been previously configured by an Integrated Observatory Operator for display on the buoy's facepage) ( 5 ), and sees the buoy was subjected to considerable wave action at the time. (See UC.R2.18 Visualize Data Product.) He notes the situation in the "operator's log" for the mooring, by entering a text comment associated with the buoy resource.

Then Joe chooses to graph buoy connection failure events versus wave height, and sees that the buoy consistently fails to connect the shore when the wave height (buoy motion) exceeds certain limits. Because the effect was unexpectedly frequent, he creates a trouble ticket and describes his findings. This communicates the important points to the rest of the team, including those not on duty at this time, (See UC.R2.55 Manage Help Ticket.)

( 6 )

During operations the CI software on the surface mooring is continually logging all data and messages to and from the instruments. Periodically the mooring connects to shore at which time decimated data sets can be sent. Data sets are decimated primary by downsampling (sending only one sample out of every n samples). Datasets can also be decimated by calculating new products, such as selected values, minimum/maximum values, average values, or composite values (e.g., to summarize multiple conditions). ( 7 )

When downsampled data from a particular instrument is ingested, it populates the data stream associated with that instrument, and the downstream products associated with that instrument's signals from that platform. Each granule (set of packets communicated as one message) is treated as a data supplement. Later, when the entire collection of data from the instrument is recovered, it is also treated as a data supplement on that instrument's data stream. (The transmission mechanism does not affect which data stream a packet contributes to.) While duplicates may result, these have to be accepted by the Integrated Observatory in any case. ( 8 ) (See UC.R2.23 Ingest Data Supplement.)

( 9 )

R3 Features (click to expand)
R4 Features

Respond to request(s) and problem(s)

Relevant Use Cases
TBD --- Manage RSN element
UC.R2.06 --- Command Instrument
UC.R2.07 --- Direct Instrument Access
UC.R2.08 --- Manage Instrument Lifecycle
UC.R2.13 --- Acquire Data From Instrument
UC.R2.14 --- Monitor an Instrument
UC.R2.18 --- Visualize Data Product
UC.R2.24 --- Search for Resource
UC.R2.40 --- Monitor ION Resources
UC.R2.55 --- Manage Help Ticket
UC.R2.60 --- Troubleshoot Deployed Instrument

At 11:13 Andy gets an automated text message saying that there was a High Priority Alarm on the system. Andy navigates to his dashboard and sees there is an unacknowledged alarm that came in at 11:00. (Since it was not acknowledged within 10 minutes, the notification system escalated the notification process to contact team members via additional means.) (See UC.R2.40 Monitor ION Resources.) It says that a pressure instrument at Hydrate Ridge has stopped sending data back to the system. Before Andy can acknowledge the alarm, he sees that a CI Operations Center Technician #Matt@UCSD has done so . Andy knows that #Matt@UCSD will have started to debug the issue but Andy still navigates to the Instrument page to see if there are any clues there as to what is going on. He can see from the graph on the page that it has been reporting pressure uninterrupted for the last 2 weeks, until 15 minutes ago, but there is no mention of any current ongoing issues with this instrument in its event logs. (See UC.R2.14 Monitor an Instrument.)

Andy opens up the facepage for the JBox EMS that the pressure instrument is connected to and sees that the power to the device has been turned off and on a couple of times starting at 11:00, but that before that it was constant and all the other instruments on it seem to be working fine. Andy knows from previous experience that when the power is turned off and on several times, it is often someone trying to restart a instrument that may be in a hung state. ( 1 ) (See UC.R2.14 Monitor an Instrument.)

At 11:30 Andy sees that a new trouble ticket has been opened by #Matt@UCSD. It states that this instrument has been taken off line while they try and diagnose the problem, and try to find a way to get the instrument back into operational state. (See UC.R2.55 Manage Help Ticket.)

At 11:45 Andy receives an instant message from #Matt@UCSD who gives an update to Andy and to Chris the RSN Instrument Manager for the Pressure Sensors. He says they have tried restarting the Instrument Agent a number of times but can not get a response from the Instrument. Andy and Chris say they will take a shot at talking directly to the Instrument and ask #Matt to not command the Instrument Agent for now.

Chris goes to the Admin Page for the Instrument and requests Direct Access mode from his laptop. (This supports direct socket connection to the instrument, and precludes any control interactions from the Observatory, including automated scripts.) He then clicks a button to get an IP Address that will let them open a socket directly to the instrument serial port on the JBox. He verifies that he has a virtual port on his PC ('Com4'), and associates the IP address with Com4 using software on the laptop. ( 1 ) (See UC.R2.07 Direct Instrument Access.)

Chris runs the Pressure Sensor software application that came with the instrument and tells it to use Com 4. At first the software reports that it can not see the instrument.

Andy goes to the EMS software (via a non-ION window) and sees that the power had been left in the off state by the Instrument Agent. Andy confirms that he has the correct current limits plugged in and that he is talking to the right port and instrument, with Cindy looking over his shoulder, and then turns power on to the port using the EMS software. ( 2 ) The Pressure Sensor software still cannot talk to the instrument. Andy runs an Instrument Reconnect command from the Pressure Sensor software and establishes comms with the Pressure Sensor at 9600 baud. Apparently somehow the Pressure Sensor had changed baud rates from 115200 to 9600 and that is why the Instrument Agent lost communications with it. Andy changes the baud rate to the correct value and saves it, checks to make sure all other parameters are correct, and then Chris cycles power on the instrument to make sure the changes were saved correctly.

Once this is confirmed, Andy closes his EMS application. Chris goes back to the Instrument Page admin page and takes the instrument out of Direct Access mode. (See UC.R2.07 Direct Instrument Access.)

Chris and Andy call #Matt@UCSD and tell him their findings and ask him to restart the Instrument Agent. #Matt@UCSD does so, and the instrument is back in its normal state.

Chris fills in information about the action in the trouble ticket and then Resolves the ticket as Fixed.

Chris then adds a message commenting on the Pressure Instrument, indicating that it is back on line and describing what happened. This message is automatically displayed to the log messages for the instrument on the Pressure Instrument page, as are all comments made about a device. ( 3 )

At another point, an alarm appears on a CGSN platform management facepage indicating that the meteorological package has stopped sending data.

Joe calls up the meteorological data and graphs the past 48 hours. Seeing no indication why the instrument stopped working, he graphs the power consumption for that instrument port over the same past 48 hours. (See UC.R2.18 Visualize Data Product.)

He sees the instrument's power consumption is consistent even during the time when no data is being reported, and that the instrument abruptly stops sending data at 2:15 PM. Seeing that there is nothing he can do until the mooring connects to shore, he sets up a high priority notification to be issued as soon as the mooring is connected.

At 4:00 PM the mooring connects to the shore station, and Joe receives a notification on the platform management facepage and in his email. He immediately sends a command to the instrument agent to reconfigure the meteorological package and return the results. The reply is an error, indicating the instrument is not responding. (See UC.R2.06 Command Instrument.)

Joe then starts the instrument direct access capability, and tries to send a status request command to the instrument. Seeing no result he stops direct access.

He then sends a command via the instrument agent facepage telling it to power off the instrument port (the platform agent performs the actual command), and receives a visual confirmation that the port is powered off. He then powers on the port and receives confirmation that the port has been powered on. His (non-OOI) platform management console indicates that the instrument agent has received the instrument start-up preamble from the meteorological package.

He then asks the instrument agent to send a status command to the instrument. The response indicates the instrument responded to the status command. Finally he sends a command to the instrument to reconfigure it back to its required state to continue data acquisition. (See UC.R2.06 Command Instrument and UC.R2.13 Acquire Data From Instrument.)

Over the next few days he continues to monitor the instrument and verify that he is collecting data, the data looks appropriate, and that the instrument has no alarms associate with that. (See UC.R2.14 Monitor an Instrument.

Somewhat later, Joe's colleague Jim arrives and logs into the system.

He immediately sees that the Pioneer central mooring has had a leak detection event. The leak detection event occurred on Saturday, but while the event was generated, there are no notifications associated with this event (the sensor is extremely sensitive) a notification was never sent out. (See UC.R2.14 Monitor an Instrument.

Jim opens a trouble ticket for the leak detect, by clicking on an 'Open Ticket' option in the platform facepage. This causes key information in the Jira ticket, including the unique ID of the platform, to be pre-configured. Joe fills in the details of this ticket and submits it. (See UC.R2.55 Manage Help Ticket.)

For several other events, Joe configures a notification that includes a URL reference (text he manually added to the notification) to the leak detection ticket. With these notifications set up, in the event of a number of different alarms occurring, people will be aware of the leak detection ticket.

Later he gets a battery temperature alarm. ( 2 ) Jim opens an additional trouble ticket, and describes the alarm and the potential cause. He links each ticket to the other using the 'Possibly relates to' link in Jira.

Two hours later Jim sees a warning that the bus voltage is dropping. This also creates a notification referencing the leak detect trouble ticket. Jim further logs this problem, indicating that the cause appears to be the result of salt water entering the well.

An hour later the battery voltage being reported by the mooring shows alternating positive and negative voltages. Jim concludes that the cause is leaking of salt water into the mooring well, and creates a ticket for that issue. He links all the previous tickets to this one using the 'caused by' link, so that all are associated. Because he gives this ticket the highest urgency rating, his managers and all the CGSN marine operators receive notification of it via email as a result of the Jira ticket reporting configuration. [See UC.R2.55 Manage Help Ticket.)

The next time the mooring calls in no data is reported and the transmission fails. Jim gets notified by the CG platform management system the buoy has failed to call in. All attempts to contact the buoy are not working, and the only information available is the data collected from the Beacon, which has not been logged to the Integrated Observatory. Jim notifies his managers of this final failure indication, and configures the mooring to prevent the Integrated Observatory or other users from attempting to contact or control the mooring, or the instruments on it. (See UC.R2.08 Manage Instrument Lifecycle for context.) On another occasion, Jim gets an SMS on his cell phone on Saturday morning that the Pioneer central mooring has failed to call in over the three last periods it was scheduled. Jim knows it is not unusual for the mooring to not be able to call in, but missing three consecutive scheduled calls generates an event, and he has set up notifications to send him an IMS on that type of event. Since he's only 15 min. away from the management center he chooses to drive in, and logs into the system. (See UC.R2.60 Troubleshoot Deployed Instrument.)

( 4 )

He immediately sees that the high speed telemetry has failed to connect, but that the mooring Beacon data as well as the iridium-based engineering interface is currently functioning. Typically Jim does not concern himself with the information collected over these auxiliary engineering interfaces, as it is exactly the same as what he gets when the fleet broadband is working. In this case, though, he must look at the data from the alternate sources in the Integrated Observatory. These are separate engineering data streams, creating separate Integrated Observatory products, because the information in them is organized differently than the primary streams.

The engineering information is synced automatically from the CGSN management system to shore, and then acquired by the Integrated Observatory. He instructs his own computer to download the information from the Integrated Observatory, and meanwhile views basic plots of it from within the Integrated Observatory. While the data are limited, he is able to see from his display that the mooring is operating properly, but there has been no connectivity from the high speed telemetry. (See UC.R2.18 Visualize Data Product.)

For example, he is able to see the power is normal on the ports, data is being collected by instruments, and the power system seems to be running properly. He is also able to see that the mooring is trying to connect to shore. (See UC.R2.60 Troubleshoot Deployed Instrument].)

He then looks to see what the other moorings in the general vicinity are doing and sees that they too, while able to connect, are achieving far lower connection bandwidth than usual. (See UC.R2.24 Search for Resource.)

He determines the weather conditions are such that the high speed telemetry is having difficulty, and gives the trouble ticket a low priority for the time being.

After 24 hours he returns to the office and sees that the mooring has successfully connected to shore. A review of the weather and motion data indicates that during the period when the mooring was not connecting, it was being subjected to very harsh weather conditions. He determines that this was the reason for the connection failures. He logs this into the trouble ticket and resolves the ticket as Won't Fix. ( 5 )

( 6 )

Finally, there are two operational monitoring requests. Joe is asked to perform basic data quality analysis for the various CTDs on the OOI network. For the global arrays that have CTDs, as well as the coastal arrays and the regional scale nodes, the operator creates a geographical view that shows all the CTDs he is interested in. At the highest level his geographical view basically encompasses most of North and South America. He can mouse over an icon for each CTD (space permitting) to see a summary of its health, status, and recent data. ( 7 ) He can also present similar information by searching for all the CTDs of interest, which will give him a collection of resources and some key information about the status and characteristics of each. ( 8 ) (See UC.R2.40 Monitor ION Resources for general information.)

In addition, he is asked to compile a list of core OOI sensors in North America producing meteorological data. Knowing this data is produced by MET sensors, he selects all the MET sensors available on the various platforms within the geographic region of interest, and his geographical view shows him an overview of the deployed sensors for North America. The list of actual sensors is available in another window, and he is able to copy and paste this information to quickly produce the desired list. To confirm he hasn't missed any sensors of other types, he does a second search for core sensors containing 'air pressure' or 'wind' parameters, confirming it has the same list of MET sensors. (See UC.R2.24 Search for Resource.)

Release 3
Release 4

Perform scheduled activities

Relevant Use Cases
TBD --- Manage RSN element
UC.R2.10 --- Manage Marine Platform
UC.R2.11 --- Define Marine Observatory Resources and Policy
UC.R2.14 --- Monitor an Instrument
UC.R2.20 --- Annotate Resource in Registry
UC.R2.33 --- Enroll in an Org
UC.R2.40 --- Monitor ION Resources

Throughout the day, Jay (the acting operator of the Coastal Surface Piercing Profilers, or CSPPs) has been monitoring the state of the CSPPs. Several uncabled CSPPs have just been deployed, and they each require human monitoring and operation throughout the day. The CSPP Operator must command the profilers (for example)

  • go up to the surface and stay long enough to transfer data,
  • go up to the surface briefly,
  • go up to 10m below the surface, and
  • stay at the seabed.

This will be automated to some degree, but during rough seas and during the first few deployments the CSPPs are not left unattended for long. [MI]

The CSPP Operator reads the wind, wave, and ocean current data from the neighboring surface moorings, and query the CSPPs for engineering data, in order to make operational decisions. (See UC.R2.10 Manage Marine Platform.)

On most occasions Jay queues operational commands for transmission (via Iridium) when the CSPP is at the surface, and data is read from the platform via the Iridium communication pathway. During periods of rough seas, the platforms are kept below the surface, and an acoustic modem on the neighboring surface mooring is used to transmit commands and obtain critical engineering data. (This is also a useful technique if a winch failure precludes surfacing, or an immediate change of plans is required.) After lunch, Andy returns to his desk and logs back into the system. He had been automatically logged out after 5 minutes of inactivity because of his high level of permissions. ( 1 )

Andy then calls into a WebEx that will be open for the next 4 hours as CG is running a ship operation to replace an Instrument Package on their Surface Piercing Profiler at the Shelf site. On the call is the Endurance Site Coordinator #BobC@OSU, OSU Ops Center Tech #Dan@OSU, CI Tech Ops #Matt@UCSD, and via a Satellite phone from the ship, #EdD@OSU. There was a call a week ago to review the operation plan (the operation plan was stored as an attachment in the Integrated Observatory system associated with this cruise). (See UC.R2.20 Annotate Resource in Registry.) #EdD@OSU reports that the weather is good enough for the deployment but that the Satellite phone has been in and out. The new equipment has been checked out on the deck of the ship and they are ready to proceed. #BobC@OSU agrees and gives verbal permission to start the operation.

#BobC@OSU navigates through a view of system resource associations to get to the Integrated Observatory platform page for the Surface Piercing Profiler at the Shelf site. (See UC.R2.10 Manage Marine Platform.) He issues an on-line notification to all registered users of the platform and attached instruments that these systems will be taken off line in 5 minutes. ( 2 )

#Dan@OSU then commands the Surface Piercing Profiler to put the Science Package up on the surface of the water. Using both the Platform page, and the EMS for the platform (running at OSU) he verifies that the engineering instruments indicate that the science package is fully extended. From the ship #EdD@OSU reports visual contact with the science package.

#Dan@OSU then gives the platform a shutdown command. A window pops up on his screen indicating that he does not have adequate permissions. #Dan@OSU clicks on the included 'Request permissions' button, which results in a notification to #BobC@OSU requesting the change. #BobC@OSU approves the processing of this change (alternatively, he could go to the User Admin Page on the Integrated Observatory and adds Shelf Site Surface Piercing Profiler platform admin privileges to #Dan@OSU), which results in an invitation being issued to #Dan@OSU with the appropriate privileges and any constraints. (See UC.R2.33 Enroll in an Org.)

After accepting the invitation, #Dan@OSU is able to successfully press the button on the Profiler platform page for a shutdown. After he does that, BobC, Dan, and Matt can see the system shut down all of the instruments and put the platform in an idle state. [MI]

At this point Andy puts the LVNode at the Shelf site into a power command restriction mode. This will prevent Power requests from coming in through the OMS instrument agents or platform agents to the LVNode while the operations are ongoing. Andy uses the LVNode Platform page to manually turn off the port that the Surface Piercing Profiler is plugged into.

Andy also confirms through the RSN EMS for the LVNode that power has been removed from the port and that the power relays have disconnected the power contacts from the system. #BobC@OSU gives #EdD@OSU permission to start the ship operations.

At 3:00 #EdD@OSU confirms that they will start operations. #Dan@OSU Changes the state of the removed Surface Piercing Profiler S/N 342343234 from Deployed to Integrated to reflect the fact it is no longer a reputable source of data, and to prepare for its imminent removal from the water, at which point it will clearly not be deployed.

At 4:00 #EdD@OSU confirms that they have the old Science Pod on board the ship and removed from the Surface Piercing Profiler, and that the new Surface Piercing Profiler has been lowered into the water.

#Dan@OSU Changes an attribute of the newly deployed Surface Piercing Profiler S/N 342343234 to indicate it is now in the water.

At 5:00 #EdD@OSU reports the connector to the new Science Pod was damaged and they have removed it from the water and are repairing it. Andy notes this as a comment related to the new Science Pod.

#Dan@OSU Changes an attribute of the newly deployed Surface Piercing Profiler S/N 342343234 to indicate it is out of the water.

Communications between the ship and shore were lost for 3 hours. All WebEx participants stayed on line waiting for the satellite link to come back. Notes were taken by the participants on the ship while the shore communications were lost; after the shore communications return, these notes were transmitted to the logging operator for addition to the appropriate logs. (See UC.R2.20 Annotate Resource in Registry.)

At 8:00 # EdD@OSU is able to communicate again and confirms that they have the new Science Pod connected to the Surface Piercing Profiler, and the entire platform has been placed back in the water. #Dan@OSU Changes the state of the newly deployed Surface Piercing Profiler to indicate it is now in the water.

#Dan@OSU Selects the Surface Piercing Profiler with Reference Designator CE02SHSP and associates the new Science Pod (with S/N 342343235) to it. All of the new instruments on the Science Pod have previously been entered into the system during their pre-deployment test and configuration phase at the logistics depot, and were configured as part of the Science Pod at that time. (See UC.R2.11 Define Marine Observatory Resources and Policy.) (For more information on how platforms and instruments are managed, see the AS.R2.01C Operate Integrated Observatory Network scenario.)

Andy requests the Surface Piercing Profiler be powered on and tested before they leave station. #BobC@OSU gives verbal authority to start testing.

Andy uses the LVNode Integrated Observatory Platform Page to take the LVNode out of the power command restriction mode.

#Dan@OSU uses the Surface Piercing Profiler page in the Integrated Observatory to verify that its mobility systems are powered and acting normally. (See UC.R2.40 Monitor ION Resources.) He then uses the Integrated Observatory to command the Surface Piercing Profiler to the seafloor.

#Dan@OSU uses the Integrated Observatory's Surface Piercing Profiler Page to start each platform component. ( 3 )

( 4 )

No Errors are reported during the startup process on the Platform Page. From the Platform Page #Matt@UCSD navigates to each of the connected instrument Pages and verifies that the data is being received and they are in normal operational mode. (See UC.R2.14 Monitor an Instrument.)

#Dan@OSU Changes the state of the newly installed and tested Surface Piercing Profiler S/N 342343234 to indicate it is ready for use.

#BobC@OSU gives verbal authority for #EdD@OSU to leave the site and return home.

At 10:00 pm the WebEx is ended. Throughout the WebEx, #Dan@OSU has used the operations log web interface in the platform's facepage to capture the events. By default these events are associated with the platform, though they could also be associated with other resource, like the cruise. Dan can also tag individual entries to the instruments and platforms that were directly affected. ( 5 )

Meanwhile, Jim had received a message that the Pioneer global moorings need a critical software update. Deciding that he does not have time to wait for the moorings to call in their own he logs onto the CGSN management system and sends a SBD (Iridium satellite communication) message to each of the three platforms asking it to call the shore. Because he does not know how long it will take for the software to download, and he has some tests to run once it is done, he needs to first configure each of the moorings to keep their connection open for six hours. He sets this configuration up by queuing commands to the mooring management system, to be executed once each mooring calls in. He sets his system to send him a notification when any one of the Pioneer global moorings calls into shore. A few minutes later he is notified that a mooring has called in. He downloads the software to the mooring by issuing commands directly to the operating systems via an encrypted remote session. In the meantime the other two moorings have also called in and he downloads the software to them. He runs various tests to be sure the software is working as it should, the restarts normal operations on each mooring. Most of the restart is a manual operation requiring CG mooring expertise, but the final stages can be coordinated through platform agents in the Integrated Observatory system. Finally he sends a message to each of the platforms telling them they can release the telemetry connection.
Release 3

Log out as operator

Relevant Use Cases
UC.R2.57 --- Configure Start Page

Before logging out, Andy saves a configuration change he made to his start page, so that it remains the configuration for future log ins. (See UC.R2.57 Configure Start Page.)

Finally, Andy logs out of his workstation.

( 1)

Release 3


r2-acceptancescenariodetail r2-acceptancescenariodetail Delete
Enter labels to add to this page:
Please wait 
Looking for a label? Just start typing.