Page 340 - The ROV Manual - A User Guide for Remotely Operated Vehicles 2nd edition

332 CHAPTER 13 Communications
The pipeline is designed with the core gas or liquid in mind (e.g., small pipe for low-volume gas, large pipe for high-volume liquid), but even within the various sample liquids vast differences of materials are likely (e.g., oil may be light sweet crude or sour heavy sludge, water may be fresh or salty, clean or dirty, hot or cold, etc.).
The transmission function of data transfer involves the physical lines, radio waves, data commu- nication channels, and wiring that transmit the data from one point to another. The data communi- cation function is the actual data content transmitted. In the following sections, we will consider the data communication function separate from the physical transmission and then pull it together into a set of standards for use in the ROV World.
13.1.5 The OSI networking model
The data communication function runs the full gamut from the simple light switch (turning on and off the light in a room) to the full intergalactic data communication web (for you Star Trek fans). In order to make some sense of this vast range from the simple to the complex, and to help manage the data communications question, the International Organization for Standardization (ISO) devel- oped its famous “Open Systems Interconnection” (OSI) model. As the reader will notice, the model layers the various aspects of hardware to software in levels of complexity. They begin with the physical layer (in its basic form, the “transmission” layer) through the data-link layer (the begin- ning of “communication”), all the way through to the applications layer. It is in the applications layer where the protocols of communication smooth the flow of data through disparate locations and channels allowing the machines to talk the same language in an effective fashion.
While this model’s applicability to ROVs is somewhat limited to the lower layers in the smaller OCROV sizes, as vehicle complexity evolves in the later iterations (e.g., the larger modern WCROVs display complex computer networking of various sensors, subsystems, and components) the full range of data layering evolves into a complex data communications platform.
In a small OCROV, a simple heading or depth hold application has a routine whereby the com- pass “talks” to the horizontal thrusters to hold a specific heading or the vertical thruster “talks” to the depth sensor to hold a specific depth. These are lower level functions. But as the complexity evolves, a Doppler velocity log (DVL) may “talk” to a positioning system whose acoustic beacon is “talking” to other beacons while further data “feeds” flow from a gyro (slaved to a magnetic compass), altimeter, depth gauge, CTD (conductivity/temperature/depth) sound velocity sensor, etc. The processor for the thrusters may be controlled from a central processor aboard the vehicle or the processing power may be on the surface with all subsea components linked as networked nodes.
In the modern complex MSROV and WCROV, sensors “talk” to vehicle controllers in order to autonomously track pipelines, map grid lines, maintain station, and operate tooling as the control function of the vehicle communicates with vehicle sensors to determine path decisions so as to instruct movers/controllers in a lavish dance of data communications. The OSI model is ISO’s attempt to organize this function into an easily discernible hierarchy.
The OSI model, instead of solving the overall data communications problem, seeks to break the complex question of subsystem communications into levels and components for two reasons:
1. to link disparate elements of a networked system and
2. to mitigate the ripple effect of modification to hardware and software components by
compartmentalizing and layering these various components