Speaker: Colin Wright

of Denbridge Marine Ltd

Introduction

At a well-attended meeting of the RISC OS User Group of London on 15 September 2008, Colin Wright gave a lively illustrated talk about using RISC OS on the Iyonix pc and RiscPC in commercial radar systems.

He is Director of Innovation and Engineering at Denbridge Marine, and was in London with his wife Rachel (she came along too). He brought a hard drive which was fitted (comparatively) painlessly into the Iyonix kindly provided by Charles Barraball.

He also had Windows and Linux laptops, but his talk principally illustrated the RISC OS application suite which he has helped develop at Denbridge Marine in Cheshire. Although all recent and new systems are supplied on commercially available PC hardware running Linux, the RiscPC and RISC OS heritage continues to ensure that the latest systems are secure, stable, maintainable, and cost-effective.

The business is (according to its website) a global provider of the industry's most advanced marine vessel traffic systems (VTS), which present port and seaway authorities with processed information from their radar stations. Colin's job includes managing the existing programming effort and code base, and planning for the next five to eight years in the future.

This report includes some diagrams not presented in the original talk, but which help set the scene and explain some of the principles involved.

History

RADAR - Radio Detection And Ranging - could originally be used only to detect and range targets. A pulse was transmitted, and the strength of the return signal was plotted on a cathode ray oscilloscope. This gave a graph of the return from a single direction, or "Azimuth", hence this plot was called an "A- Scan". A later refinement was to vary the intensity of the trace, so that when the signal was of lower strength, the trace was less intense, and vice versa.

An "A-Scan" An "A-Scan" with intensity of plot proportional to intensity of return

As the radar antenna rotates, A-Scans are obtained for successive angles. The pulses are spaced anywhere between 0.1 and 0.5 degrees apart, depending on the rate of rotation and the range at which the radar is operating. Longer operating ranges imply waiting longer between pulses to allow the previous pulse to die away and avoid confusion with the next. To show the A-Scans from successive pulses we can "stack" the traces one above the other. Offsetting each A-Scan slightly to the right then gives a pseudo-3D effect, showing the range and azimuth of targets. In this diagram we have left space between the A-Scans to show them individually.

A-Scans packed tightly against each other. A B-Scan

As the A-Scans are packed more and more tightly, the pseudo-3D effect can increase. However, the "height" of the trace of the return pulse from some objects can be obscured by later returns, and the exact position of each return pulse is distorted somewhat by the offsetting and pseudo-perspective view. Viewing the traces from directly above gives a much less distorted view, with the exact disposition of each return shown more clearly. Thus we are using brightness of pixel to show intensity of return, and now putting the A-Scans side-by-side gives a B-Scan, a polar plot of intensity of returns.

A C-Scan section, showing "Spoking"

There are problems with the obvious conversion technique of simply plotting each data point on a Cartesian plane. The first is shown above, where we run out of data points as we get close to the maximum range. In short, the distance around the circle is greater than the number of samples taken, so we plot the data in a series of "spokes", and the question is - what should we put between the spokes? There are several answers, and sometimes the more theoretically sustainable answer doesn't actually look as good as a more "rule-of-thumb" but less justifiable method.

The opposite problem happens when we take a wider view. When we fit the entire image on the screen there aren't enough pixels to give one each to the radar samples. Then as the radar antenna rotates, new data samples overwrite the previous, giving a "scintillation" effect (which we can't show here).

These problems are well-known in the industry and are often specifically mentioned in system specifications and bid documents. Careful analysis and sophisticated techniques are required to generate a view that is both accurate, and "pretty".

In summary:

• A-Scan - one azimuth of data on a trace
• B-Scan - stack the azimuths, using brightness for strength of return
• C-Scan - converted from polar co-ordinates to cartesian
• (a process known as "Scan Conversion")

System deployment

Radars work by "line-of-sight", and hence need to be up high to get a good view. Appropriate sites are often inhospitable and inaccessible - sometimes a boat ride of several hours from the nearest settlement. The command and control centre, however, is best placed in a comfortable location to make it easier for staff. Hence the radar data needs to be sent back over cost-efficient communication links, and the radar needs to be controlled remotely.

The radar data handling required by VTS, remote from the radar antennae stations, has been implemented in Denbridge's systems by RISC OS based methods for over fifteen years, and they now have customers in many countries around the world: the UK, Scandinavia, Spain, France, Central America, Asia, the Middle East, and more. Currently operational systems use Kinetic RiscPCs in the earliest installations (50%), Iyonix PCs in more recent ones (40%), and as mentioned later, are now using Commercial Off-The-Shelf (COTS) PCs running Linux. The earliest systems were deployed before COTS hardware was sufficiently powerful to run such demanding applications. Like every other manufacturer Denbridge therefore used a bespoke solution. In Denbridge's case they used bespoke electronics (based on EPLDs) for the remote sites, and ARM3 based systems for the displays. These included A4 laptops that could be provided to pilot boats accompanying large cargo vessels. Installations in the UK once included Plymouth and Milford Haven, but these systems have now been upgraded and now use RiscPC based system at the remote sites, and Linux PCs at the Command and Control centres. Over time the remote systems will be upgraded as a part of the regular maintenance schedule and replaced with COTS hardware.

All recent and new systems are based on the COTS solution, providing complete future-proofing.

The system

Denbridge's RTS4000 system is RISC OS based and captures, digitises and transmits the radar image. It can also track targets on the image, and control the radar (although this wasn't demonstrated, not having a radar to hand!)

The software is comprised of many programs/applications communicating via an anonymous message passing protocol. This architecture ensures that each application is small (usually between 500 and 1000 lines) and does one thing well. The communications system allows eavesdropping and message injection, making debugging easier. Up to 100 "applications" could therefore be seen on the unusually long icon bar.

Significant performance aspects were described, including:

• The ability of the Iyonix to restart its operating system and all radar applications in 70 seconds on the rare occasions that that is needed. No other platform yet achieves this.
• The proprietary data compression methods developed at Denbridge to support the necessary real-time data capture, transmission and recording.

Each radar would have one RiscPC or Iyonix to handle the incoming data from the radar itself, with additional RiscPCs or Iyonix computers to present the data to the operators. The RiscPC would have four custom podules to collect the data from the radar system. When the Iyonix was introduced, this made the task much easier due to the availability of off the shelf capture cards for its PCI bus, and also the much greater speed of the PCI bus compared to the podule backplane, as well as the greater speed of the computer as a whole.

The demonstration

A radar data sequence was used to show the system operating as if in real time, displaying a period of marine traffic in the Storebælt strait between the Danish islands of Fyn and Sjælland. At the time of recording, the second longest bridge in the world was in the process of construction across the strait, as well as a constant variety of shipping traffic including cargo vessels navigating specific one-way lanes through the partially blocked strait, and local ferries crossing between the islands at right angles to these shipping lanes.

Data had been collected from radar in the X (3cm) frequency bands, and was displayed on the Iyonix as:

• a B-scan (R-θ where R is distance and θ is azimuth), or
• a C-scan (converted into conventional X,Y Cartesian co-ordinates, so it looks like a map)

In shallow waters objects submerged beneath a tidal race can be detected using returns from surface perturbation.

One of the hazards of displaying radar returns is the occurrence of phantom traces caused by reflections of the radar pulse off a sequence of vessels and bridges. These can be recognised by an experienced operator, but Denbridge has developed filtering logic to clean the display.

Demonstrating the vessel tracking facilities, Colin showed how, if two radar returns merged or a phantom trace caused the software to lose track temporarily, it would still revert back to tracking the originally specified vessel when its movement and course made it apparent.

The software even has an alarm system for alerting radar operators if a vessel is moving in the wrong direction in a one-way shipping lane like those used in the Storebælt strait.

Another difficulty arises when overlaying a represention of coastlines when atmospheric conditions and tidal movements can radically change their appearance.

Colin commented how vital such a radar based system is, in particular when the transponder on a vessel is broadcasting incorrect position information. He also explained that a ship's reported course and its heading are not the same thing, and its reported speed might not always be meaningful. For example, a ship could be pointing in one direction, but travelling backwards at speed in the other direction; or could be steaming full ahead but be stationary in a tidal race. Likewise, although times of high and low tides are widely published, under some extreme combinations of wind and atmospheric pressure, the tide can be as much as twenty minutes early or late - this can be double-checked if the radar operator is aware of certain rocks that become visible in certain tidal conditions. If you're managing the seaway, you'd better believe the radar!

Colin also showed how radar-active buoys (RACONs) appear to the radar. These buoys actually shout back in morse code when hit by a radar beam, thus conveying a small amount of information back to the radar display, which is displayed at the RACON's position.

As a curiosity, it was mentioned that Denbridge systems have also been used to track aircraft, with an ARM7 based system in Hong Kong being used on an experimental basis for recording air traffic movements. However, such systems have a wide range of requirements and priorities that are different to those of marine traffic, so Denbridge decided to follow Colin's programming philosophy and "do one job and do it well."

The system is also sensitive enough to track vessels as small as a kayak or canoe.

Software development

Development of Denbridge's software was started in 1993 using ARM3 based computers and custom EPLD chips.

Colin expressed much appreciation for the ease of programming (in BASIC, C and Assembler, but recently primarily in C) under RISC OS. He also had nothing but praise for the technical support from Castle's John Ballance. A specific recent example was an intermittent failure in the networking support of OS 5.12 under very high load and constant load. By working together the problem was identified and fixed. Much of the load placed on the Iyonix by Denbridge's software is unique to their application; in fact Castle even used portions of it to stress-test new Iyonixes.

Although all systems are based on standard implementations of standard languages such as C++ and Python, Denbridge continues to experiment with a wide variety of languages that also include:

• D ( http://www.digitalmars.com/d/index.html ),
• Haskell ( http://www.haskell.org/learning.html ) and
• O'Caml ( http://caml.inria.fr/ ).

Colin explained that the early software made heavy use of "lovingly hand-crafted assembler" that used the ARM chip's L1 cache very carefully. However, as the software moved from the ARM3 onto the ARM7, the StrongARM and then the X-Scale, specific speed advantages became less important than maintainability of the increasingly sophisticated software. Colin joked that after three or four maintenance cycles on an assembly language program, "both the code and the comments will be wrong."

The technique of off-loading some of the required processing onto the computer's graphics card was tested on the Iyonix, but the advantages were found to be relatively small. The technique is still being explored in the Linux version of the software.

Questions from the floor included one about how well the system, being networked, could protect itself from being hacked into. With the Iyonix systems the risk is negligible, because there are no remote login facilities such as telnet or ssh installed. For the Linux systems great care is taken to ensure that the various facilities are only accessible to specific user logins, and the passwords are spectacularly difficult to remember. Monitoring software logs all attacks, and in special circumstances the system can raise alarms, and even shut itself down.

Mostly these precautions are unnecessary as the network is separated from any external access, often physically so. No attacks have been recorded so far.

Finally, all communications are classed as either open, proprietary, or secure. In the case of secure communications, well-known, well-understand off-the-shelf encryption techniques are used to ensure a known level of security. There are difficulties associated with the data being multicast UDP instead of the more usual TCP, because most encryption techniques assume a reliable stream of data. Nevertheless, standard techniques can be adapted, and are provably as strong.

Almost all competing systems use either DOS or some variant of UNIX or Linux.

The Future

Denbridge's potential customers rely increasingly on out-sourcing their requirements definition, with the result that the proven performance of their existing systems sometimes appeared of lesser importance. Futher, the very nature of the business requires that they be "risk-averse", so novel software and hardware is rightly viewed with suspicion.

The latest news is, sadly indeed, that Iyonix Ltd will no longer be supplying Iyonix pcs after 30 September other than what they have in stock, although support for existing customers will continue. News of this was apparently in an Iyonix Newsletter, or some other mailing list, but no specific forewarning was given. Fortunately Denbridge has motherboards in stock, and is looking to purchase a small buffer stock to augment their current holding. As existing systems in the field get upgraded to the Linux PC version, the Iyonix systems can then be held as spares. This will suffice to meet expected future needs, especially as history suggests that there are very few failures in the field.

One consequence is that hardware would in many cases have to be available from more than one supplier, and this would eventually make it impossible to continue building RISC OS based systems. The platform would become Linux in due course, though Colin emphasised that porting application code from RISC OS to Linux was proving fairly straightforward due to the very modular design of the software.

Development continues for dual-support of both RISC OS and Linux systems, and all components of the software still compile cleanly on both platforms. This will continue for the next few years, as the majority of existing customers prefer to stay with their known and trusted RISC OS systems when installing upgraded versions of the software.

Colin said that he would miss the ease with which code can be developed under RISC OS. At the start of the evening he also joked that in the manner of all demonstrations, he had Windows, Linux and RISC OS systems, and only the RISC OS one worked properly, as there were unfortunate failures with the other two. At the GUI level, like many others, Colin said that what he missed about most windowing systems other than RISC OS, was not needing to have the input focus in the window at the front. The ability to drag the scroll bars in both dimensions by using a right drag is also sorely missed.

One advantage of running under Linux will come from doing so on a multi-core processor. This will introduce some parallel processing since the many processes in the suite would get assigned across the available processor cores, without any complicated re-programming (or overhead).

Denbridge are currently using the SUSE Linux distribution, but Colin made it clear that choice of distribution was never a fixed decision, so it could change in the future is appropriate.

Reporters: Bernard, Dan and Colin himself.