Distributed Multiplexers for an ROV Control and Data System

 

Edward Mellinger, Andrew Pearce, Mark Chaffey

 Monterey Bay Aquarium Research Institute
Moss Landing, California 95039, USA

E-mail: meed (at) mbari.org

 

 Abstract Remotely Operated Vehicle (ROV) control and data systems require that many specialized Input/Output (I/O) functions be reliably performed in the hostile ocean environment. MBARI's new scientific ROV Tiburon uses a system of I/O multiplexers that are distributed around the vehicle, and connected to the main vehicle computer by high-speed serial links. The multiplexers perform fairly typical ROV I/O functions, but their hardware, software, and packaging has been specifically optimized for the ROV mission. This paper describes the design and application of these multiplexers, dubbed "Data Concentrators", aboard MBARI's new vehicle.

I. INTRODUCTION

Modern computer-controlled ROVs require electrical connections between electronic subsystems and a variety of sensors and actuators. These connections are the "nervous system" of the ROV and are used for functions that range from scientific data acquisition to actuation of lights and propellers. The signal levels involved vary from milli- to kilowatts, the frequencies from DC to megahertz, and the sample rates from once per day to kilohertz. These electrical requirements are interesting but not unusual; however they must be met in hostile shipboard and underwater environments. In particular, the electronics, and the myriad of electrical connections, must be safe for personnel, reliable in the presence of seawater corrosion and large hydrostatic pressures, and easy to maintain and modify under tight operational time constraints.

To meet these requirements for its new 4000 meter depth rating scientific ROV Tiburon [1], MBARI evaluated several architectures for the data, control, and communications system. In addition to the constraints listed above, candidate architectures required high data bandwidth (consistent with the vehicle's science mission), universal accessibility of all vehicle and science parameters throughout the data system, and adherence to existing industry standards where feasible. The architecture selected by MBARI [2] is based on a fast central computer aboard the vehicle, connected globally by fiber optic telemetry to the surface ship (and the Internet beyond), and connected locally by fast serial links to embedded microcontrollers in each vehicle subsystem. The central vehicle computer is a VME based 68040 central processor (CPU) running the VxWorks realtime operating system, with dedicated hardware for up to 24 serial links. This computer handles communications with the microcontrollers, controls the vehicle's state, and runs one node of the "Data Manager", a distributed network application that allows access to all ROV system data from any node connected to the network.

Each of the local embedded controllers (there are presently 17) performs one or more local I/O intensive functions. The functions range from controlling a thruster motor, i.e. issuing a torque command signal and monitoring motor speed and status, to operating the vehicle's science sensor suite, which requires reading analog voltages and serial data streams from several sensor modules. Each controller effectively multiplexes all of these local I/O functions onto its single serial link to the central computer, which reduces the wire and penetration count into the main computer housing, and offloads low-level device-specific tasks from the main CPU.

Each of the embedded controllers is application specific in the sense of containing the I/O hardware and software needed to interface to its local peripheral devices. Some are single-board custom designs, such as the motor controller, which is submerged in oil within the pressure-tolerant motor control electronics stack. This paper describes a more general purpose controller, the "Data Concentrator" (or "DCon"), which is actually a family of I/O boards, software routines, and interconnection hardware, designed for the ROV environment. Each of Tiburon's DCons is configured, using components from this family, to perform a specific set of I/O functions. These functions support the bulk of the general purpose computer I/O aboard the vehicle, as shown by the following roster of DCons that have been implemented or planned to date:

 

    1. Sensor: Power supplies and data interfaces for temperature, pressure, conductivity, oxygen, and transmissivity sensors.
    2. Sonar: Power supplies and control signals for Doppler sonar, altimeter, and navigation responder.
    3. Camera: Power supplies and camera and lens control signals for video camera suite.
    4. Emergency Recovery: Backup battery, backup depth sensor, power and interface for acoustic modem surface link, drivers for variable buoyancy system actuators, and driver for emergency ballast drop actuator.
    5. Power Control A and B: Switches and current sensors for 240 VDC and 48 VDC feeds to all major loads on vehicle (two redundant units).
    6. Lighting: Switches and current sensors for feeds to lights and sizing lasers.
    7. Main Housing: Power supplies and interfaces for clinometer, fluxgate compass, and directional gyro; control for video switcher; status monitor for main computer and telemetry electronics.
    8. Toolsled: Interface to mission-specific sensors and actuators on each toolsled; board complement varies with mission.

In all, the vehicle typically uses 65 boards of ten different designs in nine Data Concentrators to perform these functions. In addition to offloading the main vehicle computer and minimizing wire and penetration count, this architecture segregates like functions into separate enclosures, which minimizes personnel exposure to hazardous voltages and improves the overall fault tolerance of the vehicle.

The Data Concentrator system can be conveniently divided into electronic hardware, control software, and interconnection hardware. Each of these is described in turn below.

II. HARDWARE COMPONENTS

The Data Concentrator hardware [3] is based on the Instrument Bus Computer (IBC) circuit board, rack, and backplane [4]. The IBC specification provides a cylindrical board rack optimized to fit 15 cm (6 in) inside diameter pressure housings, a "D" shaped circuit board form factor that fits the board rack and housing, and a 96 pin connector and backplane that provides power and data connections to each board. The boards provide CPU and I/O functions and can be mixed and matched as required for the specific application aboard the vehicle.

Circuit board design was driven by the general principle that any input or output signal passing through seawater be either optically isolated, or capable of being isolated via a double pole switch. These provisions add fault tolerance and greatly aid ground fault tracing, which can consume significant maintenance time on an operational vehicle. Selection of the IBC approach and design of the board set was undertaken after review of commercial alternatives, which revealed that most of the Tiburon I/O functions would require custom designs to implement these principles, regardless of the backplane standard (e.g. PC-104, Gespac, STD) chosen.

The original IBC architecture provided a 16-bit backplane and was optimized for micropower instrumentation applications. The ROV DCon applications are largely control oriented, with modest data rates, small code and data sizes, and minimal power constraints. This fact coupled with modern IC capability allowed the CPU, memory, and basic serial I/O to be placed on a single IBC board. This in turn demoted the backplane to a simple 8 bit I/O expansion bus, reducing the bus interface complexity on each I/O board and allowing more room for the I/O functions. (As a historical note, similar fates have overtaken the computer industry's standard 1980's backplane buses, as data rates have gone up and IC sizes have gone down.) Each board type is assigned an I/O address block within the backplane I/O address space, facilitating the software auto-identification feature described further below.

To date nine types of IBC boards have been designed and built at MBARI for use aboard Tiburon, with one board from the original WHOI instrumentation set in use as well. A brief description of the nine MBARI boards follows:

 

    1. IBC-196: Microcontroller board with Intel 87C196KC micro, 8k static RAM, 32k EEPROM; interrupt controller; isolated RS-485 serial I/O port; moisture sensor.
    2. Quad Serial I/O: Four isolated RS-485 serial ports, or two RS-485 and two RS-232 with RTS/CTS handshaking; data rates to 38.4 kbaud.
    3. Navigation Interface: Special purpose interface to navigation sensors: clinometer, fluxgate compass, and directional gyro.
    4. Quad A/D: Four isolated 16-bit A/D converters; digital antialias filters with 10 Hz bandwidth; input scaling for bipolar or unipolar, 0 - 2.5 V or 0 - 5.0 V signals.
    5. Quad Low Power Switch: Four double pole switches rated 4 A at 60 VDC, optional onboard 30 W DC-DC converter with available 5 V to 48 V outputs, and A/D converter for monitoring switch currents and output voltage.
    6. Dual "Vicor": Two 100 W DC-DC converters, or one 200 W; on/off control; available output voltages from 5 V to 48 V; provision for heat sinking through end wall of pressure housing.
    7. 5 V/Ground Fault: 5 V, 25 W DC-DC converter for backplane logic supply; four channel "floating ammeter" ground fault sensor [5].
    8. High Power Switch: Single 30 A at 300 VDC power switch, using hybrid solid state/mechanical relay for arc suppression and low on-state loss; shunt and A/D converter for overcurrent trip and current sense.
    9. Regen Controller: Special purpose circuit for dumping high power motor regeneration events from vehicle 240 VDC power bus; in effect a 300 V, 18 kW zener diode.

III. SOFTWARE COMPONENTS

The Data Concentrator software provides access to the hardware I/O functions from the central computer and higher levels, and supports quick reconfiguration of the hardware in the field. With ten IBC board designs in nine different DCons, the software must also provide a consistent interface between the IBC hardware and the application software and end users.

A. Generic Drivers

Each IBC board type is supported by a generic software driver that is compiled and linked into each DCon's resident software module. The generic drivers provide access to the basic functionality of each board, e.g. "turn on switch", "read A/D channel", or "send serial character string". These basic functions are accessed by application software in the central computer to perform the bulk of the I/O functions in the DCon. The functions can also be accessed over the network by application software, or from the operator console, which allows new IBC boards to be installed, tested, and operated in the field without changes to the resident code in the DCon.

Some DCons also contains application specific software which provides additional functionality. This software can be used to close tight control loops, monitor special I/O devices, or implement autonomous functions such as emergency recovery sequences.

B. Initialization

After a power-up or software reset, the DCon software searches the IBC board I/O address space and identifies each board installed and functioning in the backplane. While searching, the software performs a benign read or write to each defined address, and tests for the Transfer Acknowledge (XACK) signal returned by any board present. Since each board type is pre-assigned a block of addresses, the software can determine the function type of each board present. The software then allocates a data structure in RAM for each board recognized, and places a pointer to the structure in an IBC Board Table. Each structure includes generic items such as board type, base address, and interrupt level, as well as board-specific items such as baud rate and parity settings for serial channels, and voltage and current alarm levels for switches. All data items are initialized to safe default values, which can then be inspected and modified from the central computer for specific applications.

C. Steady State Operation

After initialization the DCon software enters a simple round robin loop where various status monitoring functions are executed depending on the board descriptions in the Board Table. These functions include monitoring temperature, voltage, current, power supply status, and ground fault resistance, and sending alarms to the central computer if any values exceed set thresholds. The main loop also processes commands received over the serial link from the central computer. These commands allow all IBC I/O functions to be exercised, and can also be used to examine and change default values and alarm thresholds in the DCon software.

D. Interrupts

Each IBC board that supports interrupts can be asked to assert its backplane interrupt under software control. This facility is used by the software during initialization to identify the interrupt level assigned by the on-board jumper settings. This again allows boards to be added or removed without software modifications in the DCon. The eight backplane interrupt request lines are processed by an Intel 8259A interrupt controller on the CPU board, which provides hardware priority encoding (and several other features of use known only to the chip's designers).

E. Central Computer

Each DCon communicates over its serial link with an application specific software module running on the main vehicle computer, which provides the bridge between the DCon and all other software in the system. Each module consists of a minimum of three cooperating tasks: data input, data output, and exception/alarm monitoring. An additional data input task, running at higher priority, is used when very time-precise input sampling is required, as with the navigation sensors which are input to a Kalman state estimator. An additional function of the exception/alarm task is to maintain a list of expected IBC boards in each DCon, and to generate an alarm if the board set reported by the DCon initialization software does not match the expected list maintained in the central computer.

IV. ENVIRONMENTAL PACKAGING

Three of Tiburon's Data Concentrators, specifically the two Power units and the Main Housing unit, are installed as part of larger electronic assemblies inside of 26.7 cm (10.5 in) pressure housings. The remaining six DCons are "standalone" units with their own packaging. In addition to the safety, reliability, and maintainability issues mentioned in the Introduction, a major design goal of the Data Concentrator system was for the packaging to offer flexibility equal to that provided by the electronic hardware and software. Many if not all of the peripheral devices -- sensors, cameras, lights, motors -- come from the manufacturer with a unique interface cable, or with a unique connector required to mate with the device housing. It was our goal to accommodate this wide and unpredictable variety of interconnections without requiring custom cable or connector molding, and to do so as readily and simply as possible, thus speeding pre-dive integration of new or replacement equipment aboard the vehicle.

The packaging solution adopted is to house the IBC boards and rack within a 15 cm (6 in) inside diameter titanium pressure case, to connect to the IBC circuit boards through the case endcap with a fixed 55 pin penetrator, and to connect to the penetrator with a screw terminal circuit board located within an oil filled, ambient pressure junction box mounted directly to the housing endcap. Cables from peripherals (or other vehicle systems) enter the junction box via compression gland fittings, and connect via crimp lugs to screw terminals on the terminal board. The overall package is diagrammed in Fig. 1 and pictured in Fig. 2.

Cutaway of Data Concentrator
Figure 1
DC Components
Figure 2

A. Pressure Housing

Titanium was chosen for the DCon housing and endcap due to its high strength-to-weight ratio and relative freedom from corrosion, both factors which minimize the weight and volume of the housing. The single endcap also serves as the main point of attachment to the vehicle, allowing the housing to be removed for easy access to the IBC without disturbing either wiring or electronics, which remain electrically connected to other vehicle systems.

B. Pressure Penetrator

Electrical penetrations through the endcap are provided by a standard high-pressure glass/metal seal connector. The connector, however, is modified with reversed pins, meaning that the mating half plugs into the inside face of the endcap. All wires connecting to the IBC boards are soldered to the back of this mating half, which is attached to the end of the IBC chassis. This allows the chassis to be electrically and mechanically "plugged into" the inside face of the endcap, which permits the chassis to be unbolted from the endcap (and hence the vehicle) without altering any electrical wiring in either the chassis or the vehicle.

C. Junction Box and Terminal Board

The external side of the DCon endcap penetrator enters a pressure compensated electrical junction box filled with mineral oil. Although oil compensated systems are messy to work with, mineral oil is an environmentally and electrically benign substance that cleans up easily, and the pressure compensated junction box allows both troubleshooting and extensive wiring reconfiguration without having to disturb or modify high-pressure connections.

The 55 electrical connections through the endcap are directly soldered via short jumpers to a printed circuit board (PCB) containing 55 screw terminals for connection of external wiring. The PCB traces and spacing are sized for 4 A at potential differences up to 500 VDC; terminals can be paralleled when higher currents are required. All traces run on interior layers of the multilayer PCB to reduce the possibility of dielectric breakdown due to surface contamination.

Connections common to all DCon applications, such as 48 VDC input power and RS-485 serial communications, are located on dedicated terminals on the terminal board. Two light emitting diodes are mounted on the board and monitor the input power and serial communications signals. These indicators are visible through the clear acrylic junction box cover and give a quick indication of the operational status of the DCon, i.e. "powered up and talking". Opaque covers are also available when stray light could be a problem, as during bioluminescence studies.

D. Gland Fittings

External wiring is routed into the junction box through up to fifteen separate compression sealing gland fittings. These use custom machined through-bolting aluminum feedthroughs, with standard commercial compression-seal elastomer bushings and clamps. By changing to different standard bushing sizes, any cable diameter from 8 mm to 19 mm can be accommodated. Peripheral cables can be ordered and stocked with unterminated pigtails in arbitrary long lengths, and then cut to the exact length needed, stripped back, and terminated with ring terminals for connection to the terminal board. This feature eliminates the extra loops of cable on the vehicle that inevitably result from specifying cables whose length is fixed by molded connectors at each end.

V. TEST RESULTS

As of this writing, four Data Concentrators have been assembled and tested as part of the test program for the prototype Tiburon vehicle. The two Power DCons and the Main Housing DCon are installed as part of other electronic assemblies inside large pressure housings. The Sensor DCon is installed in the DCon packaging described here. All four units have accumulated roughly 500 operational hours including 60 hours on 15 test dives off the MBARI dock in Moss Landing, CA. The only problem encountered to date has been slight seepage of oil where the gland fitting feedthrough threaded into the Junction Box. This problem was solved by redesigning the gland fitting feedthroughs in aluminum, deleting the threads into the plastic junction box and incorporating a through-bolting arrangement with an o-ring seal. Also, small commercial dessicant packs were found to maintain the housing internal humidity at a lower level than the planned dry nitrogen purge, and were adopted as standard practice. These design changes will be evaluated during further vehicle tests in 1994.

ACKNOWLEDGMENTS

Michael Matthews designed the Quad A/D and High Power Switch boards, Luke Coletti designed the Quad Serial board, and Dave Wright designed the Nav Interface and Dual Vicor boards. Bill Kirkwood designed and tested the titanium pressure housings. Carolyn Todd and Fitzgerald Smith procured and built the electronic hardware. Funding was provided through the generosity of the David and Lucile Packard Foundation.

REFERENCES

      1. J. Newman and D. Stakes, "Tiburon: development of an ROV for ocean science research," IEEE Oceans '94, Brest, France, September 1994 (in press).
      2. M. Chaffey, A. Pearce, and R. Herlien, "Distributed data and computing system on an ROV designed for ocean science," IEEE Oceans '93, Victoria, BC, October 1993.
      3. M. Chaffey, et al., Instrument Bus Computer for New ROV Data Concentrators, Vol. 1, MBARI Technical Report 93-13, Monterey Bay Aquarium Research Institute, Pacific Grove, CA, 1993.
      4. E. Mellinger, K. Prada, R. Koehler, and K. Doherty, Instrument Bus, An Electronic System Architecture for Oceanographic Instrumentation, WHOI Technical Report 86-30, Woods Hole Oceanographic Institution, Woods Hole, MA, 1986.
      5. E. Mellinger, "Power System for New MBARI ROV," IEEE Oceans '93, Victoria, BC, October 1993.

Oops!