|
Click here for another light-hearted story about this application.
 The control
system outlined here concerns an underwater remotely operated vehicle (ROV).
This vehicle comprises a neutrally buoyant framework housing electrohydraulic
thrusters, manipulators, cameras, lights and a controller. The vehicle receives
electrical power and exchanges telemetry signals with a surface control console
via an umbilical cable. Typically vehicles of this class weigh two tonnes
in air and have a depth capability of 2000 metres. The offshore Oil and Gas
industry has become increasingly dependent on ROVs as the global trend in
deep water sea bed installations increases.
The system comprises three control units:
- surface Programmable Logic Controller (PLC)
- vehicle Programmable Logic Controller (PLC)
- surface Graphical User Interface (GUI)
The control system is designed to be straightforward and fast.
The PLC units are dedicated to updating local data input and transferring this
to the remote unit where it is regarded as data to be output. Thus, at any
instant, each controller has global data that 'mirrors' the last state of
the controllers' I/O.
The GUI presents, in visual iconic form, this global data which it reads from
the surface PLC via a serial COM port without affecting the data exchange
between the two PLCs.
1 & 2 Programmable Logic Controllers
The PLCs use peer-to-peer message instructions (MSG instructions) to exchange
a data packet over their serial COM ports via DF1 Protocol and fibre optics
telemetry at up to 115k baud. Analog and digital signals obtained at the surface
from banks of potentiometers and switches (the pilot's control console) are
thus transferred to the vehicle where they drive hydraulic thrusters, relays
and lights. Vehicle sensors provide mostly analogue data which is transferred
to the surface controller and so to the GUI. Autofunctions are calculated
by the vehicle controller using local sensor data such as gyro and depth to
provide auto-heading, auto-depth etc.
The PLCs are comprised of embedded-PC and I/O modules using the industrial
computer PC/104 format and ISA bus standard. The identical surface and subsea
controller 80486 DX2/66 processors run a 32bit real- time, multitasking kernel
operating system: SoftPLC. This operating system, once loaded into RAM, has
complete control of the CPU at all times. This kernel process has a synchronous
scan - input data is read, the "ladder logic" program is executed
and output data is updated in a deterministic manner.
SoftPLC operates identically to proprietary dedicated hardware PLCs but faster
and with more flexibility having the facility of loadable device specific
instructions and driver modules.
The PC/104 format I/O interface cards have device drivers loaded at system
startup.
| Description |
Surface |
Vehicle |
| I/O Totals |
| Digital Inputs |
104 (48+48+8) |
16 (8+8) |
| Digital Outputs |
8 (8) |
88 (48+24+8+8) |
| Analog Inputs |
16 (16) |
32 (16+16) |
| Analog Outputs |
4 (4) |
16 (16) |
| PC/104 Boards |
Quant. |
Quant. |
Configuration |
| Power Supply |
1 |
1 |
|
| Processor |
1 |
1 |
|
| Digital I/O |
2 |
1 |
(48DO) |
| Analog In |
1 |
2 |
(16AI+4AO+8DI+8DO) |
| Analog Out |
0 |
1 |
(16AO+24DO) |
where:
DO/DI - Digital In/Digital Out
AO/AI - Analog In/Analog Out |
3 Graphical User Interface (GUI)
 The
GUI is functionally independent from the PLCs and runs a SCADA graphics application
on a Windows NT platform. The SCADA package complies with the OPC ("OLE
for Process Control") industry standard for communications which enables
it to interrogate the PLC system via a serial COM port. The SCADA application
(Iconics "Genesis32 Graphworx") receives its protocol compliant
information from an OPC server such as Kepserver from Kepware. This product
interfaces between the DF1 protocol built into SoftPLC and any DDE or OPC
compliant package running on the surface computer. The relationship between
these components is shown below:
| Manufacturer: |
SoftPLC |
Kepware |
Iconics |
| Product: |
Kepserver |
Genesis32 software |
Graphworx |
| Function: |
PLC Controller |
OPC Server |
SCADA GUI |
Further Development . . .
Redundant path switching for the communications loops to the PLC has been incorporated
so, if the primary data path fails, a back up fibre or copper pair can be
used to communicate with the other control unit.
The OPC server's OPC compliance allows further expansion of the system to incorporate
remote data access via serial COM port, or TCP/IP ethernet. The SCADA system
is capable of storing data to any OLE compliant application - word-processing,
spread sheet etc.
The SCADA system can alter values held in the surface PLC memory data map -
so providing an input mechanism alternative to that of the pilot console.
At present this is used only to input offsets and gains for sensor and actuator
calibration. This facility has great potential for control and diagnostics.
| 
