DP Control System Pt3b – Sensor Error Handling

Introduction:? This is an article that I tried to write a year ago and gave up on.? It was lightly touched on in these two articles.? The problem was that each dynamic positioning (DP) control system uses slightly different interfaces and error handling than DP systems from other vendors, and even changes between software revisions.? I did not want to mislead people into thinking that their system must use method “X” with settings “Y”, and still don’t.? This is a high level overview of the protection methods used.? For hints of the specific methods used on your system, read the operator manual associated with the latest software installed on your system.

Software Primacy:? Every time the software is updated, read the new operator manual to see what has changed and test the system.? There can be major changes between software versions.? For example, Kongsberg started using MRUs to correct all position references in the 2000s and suddenly lots of 2 MRU vessels were in trouble and needed to buy a third one (from Kongsberg).? After an unrelated vendor software update, one unusual vessel became pretty much useless, because it was no longer able to keep position after most faults.? This is why DP FMEA and trial writers ask for the operator manuals, and one reason why we keep testing.

Interface:? The first step in error handling is seeing if there is useful information coming in from the sensor and protecting from harm from the sensor.? The information needs to be formatted in a way the controller can understand and protected against faults from the source.? Interfaces have changed over the years from ±10Vdc signals with DP Ready contact, to 4-20mA with DP Ready, to serial interfaces.? The changeovers haven’t always been smooth, and they have all had their problems:

• ±10Vdc signals were easy to make, but hard to validate, as a wire break in a perfect world was 0Vdc.? 0Vdc is a valid signal, so this required extra fault handling, like jump and frozen sensor detection.? Of course anything above 10Vdc or below -10Vdc was an invalid signal and should be automatically rejected.? The DP ready contact from the sensor was an additional protection, as it was supposed to open on loss of power or detection of internal fault.? Some vendors would hide the problem by still using a ±10Vdc source, but using a convertor that sent a 4-20mA signal to the DP system.? This disguised faults, but kept them.? It meant internal equipment wire pulls were needed to find the fault.? We used to convert ±10Vdc pots or signals to 2-10Vdc to allow error detection (assuming electronic noise was below 2Vdc - not always a given).? 2-10Vdc is 4-20mA with 500Ω resistance.? This reduced control precision, but gave fault detection and survival.

• 4-20mA signals had better fault detection.? Breaking the current loop was detected and >20mA or <4mA are invalid signals that need rejected.? The DP ready contact was still needed as an additional protection, because it was supposed to open on detection of internal faults.? Internal faults could send false signals, but controllers can’t detect all of their own faults.

• Serial signals send the data digitally and can contain the DP ready and additional health data.? Initially, the separate DP ready was maintained.? The promise of digital is a pristine error free world of 1s and 0s, but we actually live in an analog world, and mismatches occasionally caused problems with some DP control systems being overcome by single sensor serial errors.? Vendors learned to make it one way rather than 2, to ignore wrong protocols, and to ignore wrong speeds.? DPOs used to be very familiar with resetting serial links.? Occasionally, interesting digital faults still happen, but they are increasingly rare, so long as the systems are well maintained, and kept isolated from external data systems.? Serial doesn’t mean safe.? It means relatively safe, if properly setup and maintained.

• Surges & Spikes:? DGPSs and wind sensors need to have lightning surge protectors to prevent total loss or malfunction of the DP system.? This is something that seems to have been forgotten in recent years, but is still a DP significant failure mode with lots of recorded examples and requiring protection.? Other sensors don’t have a history of blowing out DP control systems, but it’s worth checking for protection against, or damage from, ordinary grounds and over voltages over the years.? One experienced field service engineer who I worked with added extra fuses to the inputs to avoid damage.? It still seems like a good idea - especially when you look at equipment more than 20 years old (yes, equipment used to last a long time).

Initial Rejection:? Once the sensor information is in, an initial sanity check is performed.? Is the sensor selected?? Does the sensor say it is healthy?? Is the sensor data physically possible?? Is the sensor really working??

• Selected:? The sensor data might be displayed and filtered, but unless the sensor is selected then it should have no effect on DP control.? This may not be the case, especially if it influences other selected sensors.? For example, I found gyro jumps to unexpectedly effect one brand of DGPSs, and an MRU will affect the hydro-acoustic position reference it corrects, so that MRU needs monitored for faults.? It’s sometimes worth checking that faults of unselected sensors don’t affect the DP system, even if they don’t influence selected sensors.? Coding and setup errors are occasionally made.

• Healthy:? Sensors, which report they are unhealthy, are normally deselected or de-weighted.? Of course, that depends on the sensor being accurate about its assessment of its own health, and on the DP controller listening.? Third party sensor providers tell us that they could provide more useful sensor health data, but the DP vendors aren’t interested.? (It’s one reason why the sensor screens are sometimes more useful than the DP screens for finding some problems.)? If the DP vendors accept that data from their own sensors, then that looks like an anti-competitive practice.? One DGPS vendor had incidents where their faulted sensors reported perfect health and accuracy, the DP control system believed them, and position was lost.? They aren’t the only ones.? So, it is something that needs balanced.? Trust but verify.? In the same way that people can’t see all their own faults and need others to tell them, sensor controllers can’t recognize all their own faults.? Self-reference can only go so far, then external help is needed.

• Jump Protection:? You can’t drive north from Mexico to Canada without going through the United States, and any sensor that tells you that did is mistaken (or really, really slow).? Sensor speed is limited and environmental effects can be unexpectedly dramatic, so there needs to be some tolerance for jumps between readings, but large, unrealistic jumps need rejected.? This used to be common, but there needs to be some caution in this.? For example, a large wave can swing all the gyros with a powerful bow slap, and they should not be rejected.? On the other hand, all the DGPSs jumping together is not a sign that they should be trusted, but what if that is all the ship is using?? Older systems had 7.5° jump gyro/MRU rejection windows and this declined to 5°.? There were similar position reference jump rejection windows in some systems.? Some systems don’t apparently use either.

• Sensor Limits:? Similar to jump protection, but for higher speed sensor links.? This could be absolute limits or rate limits.? In other words, the ship will never lean further than this, or faster than that, or turn faster than this.? These setting were sometimes improperly used to make old two MRU or two gyro systems pass simple lean or calibration tests by designing the system rejection to pass the DP surveyor test.? This caused problems when the real environment created similar effects to the tests, and all MRUs or gyros were rejected.? Software people aren’t sailors, and the real sea was wilder than they thought.? As a result of this, and most vessels having three MRU and gyros (or INSs), these dangerous pass-the-test settings have mostly disappeared, but there can still be some reasonable limit and rate settings.? These sometimes falsely assume no mistakes, so don’t drop a heavy box in the instrument room during DP (wait until after critical operations).

• Frozen Protection:? A frozen sensor is more dangerous than a jumping one, because the DP control system often values the consistency.? This can lead to reduced correction for the real changing world, and possible rejection of accurate, changing sensors.? This is something that needs balanced and adapted to the type of sensor monitored.? The wind really can stay at 10.4kts from 106°, but unvarying pitch, roll, heading, or position is highly suspect.? Even tied up in the harbor, you can watch those vary.? So, a lack of small scale variation is a valuable rejection test.? It is a fundamental protection for systems that use sensor weighting based on consistency.? It can usually only be tested with software forcing.? Some manuals don’t show this protection.? Electronic noise can defeat the protection if it is set too low.?

• Filtering:? Not all information is used raw.? For example, the wind speed and direction is filtered and adjusted for height, so all wind sensors are measuring the same thing, if healthy and wind flow is laminar and not blocked.? This is usually averaged over a few seconds, which might be a surprise if you are thinking of fast wind force feedforward, but that is fast compared to the DP model (15-30min), and high inertia wind vessel reaction (0.5-2min, depending on vessel).? In addition, thruster reaction speed is limited, and wind direction measurements can sometimes hunt or spin, so the average is more stable and avoids unnecessary adjustment.? The wind speed adjustment takes a few seconds to fully react, which is good for system stability, and allows rapid DPO fault detection and deselection before a sensor failed to full charges a vessel off position, but means that wind compensation always slightly lags the force.

Varying Centers:? Once sensor data has been accepted, it needs compared with other sensors and group rejection or acceptance tests passed.? The point of comparison can vary by system:

• Monarchy:? For some systems, the preferred sensor is king and everything is compared to it.? This is good when you know wind sensor 2 is clear of obstruction with wind from this direction, while wind 1 or 3 have some obstruction, or DGPS 3 has the clearest view of the sky, but means the DPO needs to watch for swinging wind (now, wind 1 is best) and change to the healthiest sensor (e.g. tautwire during a common DGPS fault. Hurry up, Sprint-Nav.).? This has the advantage and disadvantage of forcing DPOs to carefully watch the sensors, diagnose, and correct developing problems.

• Meritocracy?? The current Kongsberg setup is to use the middle of the three system sensors and auto-weight the position sensors with preference given to faster updates and consistency.? This assumes no common system sensor faults (but only two power supplies and wouldn’t work where only wind 2 is clear), and that consistent sensors are correct (remember false health and lack of frozen sensor detection?).? It allows automatic adaption to changing sensor reliability, but favors certain sensor types, and gives them heavy, non-redundant weighting.? When the ‘consistency is good’ assumption is untrue, and the favored sensors are bad, position will be automatically lost unless the DPO recognizes the problem.? Unfortunately, the auto-weighting has taught him or her to trust the biased weightings.? It also needs to be remembered that modern Kongsberg does everything with reference to absolute position references whenever it can, so deselecting and reselecting faulty DGPSs ruins your relative sensor fix.
• Auto All:? One system that I looked at used auto weighting for all sensors and compared each sensor type to the mathematical weighted answer.

• Democracy:? Some systems allow you to set the weightings for each sensor.? I tend to favor this because it is possible to establish redundant position reference settings.? Again, this requires experienced DPOs watching the sensors closely for problems.? If the DGPSs walk away from the HPRs, the vessel averages between the two redundant groups rather than following the DGPSs.? Similarly, the wandering DGPSs aren’t preferred to the accurate, but relative, Fanbeam and RADius, and used to generate false current in the model.?

Group Checks:? With the sensors filtered for faults and the point of comparison set for each sensor type, we can get down to the group checks.? These are based on either the preferred sensor, the median sensor, or the auto or manual weighted average.? New sensors are compared to these and sensors de-weighted or rejected based on this comparison.

• Acceptance:? The most basic of these is the acceptance window check based on staying within 3m or 3° of the comparison target.? Sensors inside the window are applicable for DP control system use, following whichever weighting scheme the system uses (centers).? Sensors that wander or jump outside that acceptance window will no longer be used.? Sometimes, the preferred sensor is the sensor that is primary, but all sensors are used for weighting, so the preferred sensor can lose acceptance, unless it wanders back inside the window.? It’s probably best that sensors outside the window be automatically deselected, but some systems leave that to the DPO.

• Variance:? Too much movement compared to the center can degrade the weighting of a sensor and this can shift the weighting towards a consistent sensor, even one that is too consistent.? Operators need to be aware of this and on guard against it.? Variance tests can include acceptance window, drift, and jump tests.

• Median:? The median sensor provides good protection from a single fault or faulty sensor, if each sensor is truly independent and closely calibrated.? Keeping them truly independent is the problem.? Median tests can include acceptance window, drift, and jump tests.

?

Conclusion:? All these internal tests are based on the assumption of good maintenance and calibration, and are supplemental to the expected DPO oversight.? The DP control system can outperform the operator at low level machine tasks, but depends on the higher level overview, wider insight, and extra information available to the DPO for him or her to correct errors that the DP control system cannot detect.? This overview provided an introduction to some of the sensor interfaces and protective functions found in DP systems.? While insight and cautions can be gained from this, the reader is encouraged to compare the functions shown in the vendor DP control system operator manual, and consider the effects of the functions shown in, and missing from, that document on their vessel’s safe DP operation.? Safe DP operation on one vessel may be improper operation on another.? Know your ship.