Edit made on October 19, 2008 by ColinWright at 19:25:02
Deleted text in red /
Inserted text in green
MM
WM
HEADERS_END
[[[>50
I can provide some screen shots and other images.
Moved to http://www.solipsys.co.uk/ROUGOL_2008_09_15.html
!# Yes, please do. !#
----
* Let me know with a note here when you think it's nearly complete.
!# I've made lots of additions and a few edits. Please check, as I have left the part about the end of Iyonix manufacture rather more disjointed, and I'm not clear on the status of the encryption clarification. - dgs/rougol3 !#
!# Editing now done by Bernard, Dan and Colin. Ready for release? !#
]]]
!! 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 Innovation Director of 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.
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.
!!! 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".
Stacking A-Scan traces one above the other gives a pseudo-3D effect, showing the
range and azimuth of targets. This rapidly changed to 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.
Finally, converting the polar plot to cartesian co-ordinates gives a true
indication of location, a "Plan Position Indication" (PPI), and the returns can
be overlaid on a map. This is a "Scan Converted" image, which Denbridge refers
to as a "C-Scan". 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.
This is often inhospitable and inaccessible - sometimes a boat ride of several
hours from the nearest settlement. The command and control centre 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 ten years, and they now have customers in many countries around the
world: the UK, Scandinavia, Spain, France, Mexico, Malaysia, Egypt and more.
Currently operational systems use Kinetic RiscPCs in the earlier installations
(80%), and Iyonix pcs in the more recent ones (20%). ARM3 based systems were
used in early versions, which included A4 laptops that could be provided to
pilot boats accompanying large cargo vessels. Among installations in the UK are
Plymouth and Milford Haven.
!!! 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 less than 800 kilobytes and often about 700 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 real-time data capture and transmission needed.
Data throughput requirements for radar capture are substantial, with a single
radar typically providing up to 50 megabytes per second of data on a constant
basis round the clock. Many sites would use multiple radars, and some would also
be required to retain the data for up to six months, thus making extremely
efficient data compression even more essential. It is possible to use !JPEG
compression for radar data, but the Denbridge algorithms provide greater speed
and higher rates of compression for the particular characteristics of the radar
data.
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 ( EQN:R-\theta plot where /R/ is distance and EQN:\theta is azimuth), or
* a C-scan (converted into conventional X,Y cartesian co-ordinates, so it looks like a map)
The rolling C-scan impressively showed the changing patterns of activity in the
strait. Craft moved and even their wake could sometimes be discerned.
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 beam 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 mainly 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.
Denbridge continues to experiment with a wide variety of languages that also
include Haskell and O'Caml. 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 offloading 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.
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.
[[[>50 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. ]]]
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 two 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 he had Windows, Linux
and RISC OS systems present on which to run the demonstration, 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.
One advantage of running under Linux may 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.
!!! Epilogue
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. !/
If you have sufficient authority, edit here to leave a message.