Data Collection System for Condor Ferries

  Read in   |   Print Print

"The high-speed deterministic nature of the LabVIEW code deployed on the CompactRIO FPGA helped us meet the demanding inline data processing requirements of the application."

- Adrian Brixton, SSDC Ltd

The Challenge:
Develop a condition monitoring system that can connect to the incumbent data collection system and transfer all data to a shore-based database for future analysis.

The Solution:
Using the LabVIEW reconfigurable I/O (RIO) architecture to develop a bespoke data analysis system capable of interpreting data from the custom communication protocol and transmitting the data to an onshore server for further processing.

Author(s):
Adrian Brixton - SSDC Ltd

Condor Ferries operates a fleet of three fast ferries providing a year-round service connecting the Channel Islands through Poole and Weymouth to the north and to St. Malo in France to the south. The three sister ships are 86 metre variants of the design and were constructed in Tasmania in the late 1990s. They each use four 12-cylinder diesel engines driving water jets that give each craft a capability of up to 34 knots, carrying 175 vehicles and 740 passengers.

The challenge for Condor Ferries is to maintain a punctual and reliable service to the Channel Islands while running the vessels at their optimum efficiency. Condor Ferries achieves maximum efficiency by ensuring that the catamaran hulls are planing in the water rather than displacing, which can only happen when the vessels are travelling at a high speed. The multiport nature of the routes operated and the need to run at high speeds creates a tough environment for the engines, which require regular maintenance checks to ensure they are performing correctly.

Condor Ferries entrusted Structured Software Design Consultants (SSDC) to develop a bespoke system capable of hooking into the incumbent data collection system and transferring all data to an onshore database for analysis later. These systems would be fitted to the bridge console of each of the three vessels.

SSDC is an NI Alliance Partner and supplies custom-designed functional test laboratory management, industrial control systems, and logging and database systems to the aerospace, military, academic research, automotive, and manufacturing industries.

Figure 1. Condor Ferry Planing in the Water

Application Requirements

To keep schedule disruption to a minimum, Condor Ferries required a data collection system that could monitor engine and ship conditions over an extended period. The data would then be analysed to identify any trends leading to failure and change components before failure occurs. Each vessel was fitted from the outset with a data collection system that monitored up to 600 parameters and reported them to a display unit on the bridge. However, the system had minimal trending capability and no easy method for transferring data to the shore.

Existing System

Racal-Dana supplied the data collection system fitted to each vessel. Each one, typical of a distributed monitoring system, utilised a multidrop network and included a PC with specific serial communication cards acting as the host and communicating with 8-bit microcontrollers acting as slaves. The physical layer of the network is based the on the RS485 standard. To reduce loading on each of the network nodes, the system uses a 9-bit communication protocol that adds an ‘address’ bit onto the standard data byte. This ensures that each node only has to interrogate data packets with the address bit set to 1, and then only responds if the address is that of itself. All data packets with the address bit set to 0 are deemed to be data bytes from other nodes and ignored.

Design

Communication protocol information was not available and had to be determined by using a storage scope hooked onto the RS485 lines and protocol analysis software. At this stage, we had to come up with a hardware solution that we could place onto the RS485 network to collect the data.

Figure 2. CompactRIO (left) Mounted in Unit

Our main obstacle was the 9-bit protocol, which posed a problem because all PC Universal Asynchronous Receiver/Transmitter (UART) chips work on the basis of expecting 8 bits of data. SSDC created a workaround which allows a standard 8-bit UART to receive and process 9-bit data. This method made use of the parity bit which was appended to the byte of data in normal 8-bit protocol. The transmitter appended this bit and set it to 0 or 1 depending on the parity type in use. The Racal system did not actually use parity, but by setting our receiver to space parity meant that for every 9-bit data packet with the address bit set to 1, we got a parity error from the UART, so we could detect each address data packet by seeing a parity error.

We tested the validity of this theory using a standard PC with a small LabVIEW test code. We injected a waveform into the serial port and monitored the response using our parity trick. The result proved the theory, but we were missing far too many address packets to make it a viable solution. The reason for the losses was that the PC could not keep up with the 9,600 baud data stream. For the system to work, each and every byte in the stream needed to go through the UART to be individually tested for parity, which was simply not possible on the Windows platform.

Implementation

To solve our problem, we used a CompactRIO system that included a cRIO-9075 controller and an NI 9871 RS485/RS422 serial module. We used the FPGA on the CompactRIO, which is reconfigurable hardware that allows for inline processing at very high speeds, to process the serial data. This speed ensured that we could analyse each individual byte in the serial stream and detect each address bit. The data was then simply converted to 16-bit numbers with one byte for data and one for address indication and then passed up to the real-time computer on the CompactRIO system for further processing.

Figure 3. Top View of Data-Logging Unit

We solved the 9-bit problem, but still needed to process the data stream so that packages from each node were stored and ultimately sent to a database on a shore-based server. We used the CompactRIO real-time processor to package the data and then sent it on to a small embedded PC running a LabVIEW application. Our software on the PC provided a live data display of all parameters and stored the collected data on a TDMS file for the voyage. On completion of the voyage, the TDMS file is sent to the shore-based server through a WiFi link from the ship to the port of arrival. Another LabVIEW application on the server then processed the TDMS file to determine scaled real values from the raw data bytes and this data was sent to a database. The customer has a front end onto the database and can query data from each of the three ships to undertake data trending and predictive maintenance.

Conclusion

Condor Ferries is successfully using the system to collect and log data to aid in the preventive maintenance of its three fast ferries.

Taking advantage of the cross-platform nature of LabVIEW, we could prototype our application on a standard PC before scaling it to implement the full application on the CompactRIO platform. The high-speed deterministic nature of the LabVIEW code deployed on the CompactRIO FPGA helped us meet the demanding inline data processing requirements of the application.

For more information on Condor Ferries and its fleet, visit www.condorferries.co.uk.

Author Information:
Adrian Brixton
SSDC Ltd
Unit 6, West Farm Popham
Hampshire SO21 3BH
United Kingdom
abrixton@ssdc.co.uk

Bookmark and Share


Explore the NI Developer Community

Discover and collaborate on the latest example code and tutorials with a worldwide community of engineers and scientists.

‌Check‌ out‌ the‌ NI‌ Community


Who is National Instruments?

National Instruments provides a graphical system design platform for test, control, and embedded design applications that is transforming the way engineers and scientists design, prototype, and deploy systems.

‌Learn‌ more‌ about‌ NI