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.
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-
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.
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.
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.
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.
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".
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.
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:
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.
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:
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.
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:
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.
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.
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.
After a closing slideshow of pictures of Denbridge systems in use all around the world, and a few of Colin supporting them, the session ended with a juggling routine (Colin being part of the duo who wrote the graphical DOS application JuggleKrazy ). He sang Tom Lehrer's Elements (to the rousing tune of the Major-General's song from Pirates of Penzance) all the while juggling with four soft balls. Surely the most concrete demonstration of co-operative multi- tasking this reporter has witnessed.
Postscript for Programmers
Programmers among you may like to know of Colin's promotion of excellence in coding. He recommends a fast coding exercise as part of staff selection, for example to output the sequence from the Fizz Buzz game. You can test yourself against the clock with that example, or else with his interesting Coding Challenge at http://www.solipsys.co.uk/b_search
Reporters: Bernard, Dan and Colin himself.