FRL Radar Displays
Guest
Posts: n/a
FRL Radar Displays
Does anyone else using the increasingly popular FRL Windows NT based displays share my concern over what happens if the Radar data fails?
On 'conventional' long persistance phospher displays, if the Radar failed the information would slowly vanish, giving a few minutes showing where the aircraft were and giving you a chance to work out priorities in achieving procedural separations. I seem to remember from my ATSA days at LATCC that the data would 'freeze' and flash on those displays.
On these FRL displays all the data vanishes on the next 'sweep' after failure, as I found out recently when the contract engineers shut the system down on me by mistake - one minute a screen with aircraft, the next a nice clean map picture only. Another problem I have found with this system (with Watchman Radar) is that if for any reason the scanner stops turning without the TX/RX failing, there are no error messages displayed on the screen, again just a total loss of aircraft data. It certainly managed to confuse a tels engineer at station open one morning who just thought that it was a nice clean picture with no aircraft within 40 miles - I had to ask him to look out of the window at the stationary scanner!
On 'conventional' long persistance phospher displays, if the Radar failed the information would slowly vanish, giving a few minutes showing where the aircraft were and giving you a chance to work out priorities in achieving procedural separations. I seem to remember from my ATSA days at LATCC that the data would 'freeze' and flash on those displays.
On these FRL displays all the data vanishes on the next 'sweep' after failure, as I found out recently when the contract engineers shut the system down on me by mistake - one minute a screen with aircraft, the next a nice clean map picture only. Another problem I have found with this system (with Watchman Radar) is that if for any reason the scanner stops turning without the TX/RX failing, there are no error messages displayed on the screen, again just a total loss of aircraft data. It certainly managed to confuse a tels engineer at station open one morning who just thought that it was a nice clean picture with no aircraft within 40 miles - I had to ask him to look out of the window at the stationary scanner!
Guest
Posts: n/a
The Windows licence agreement says "THE SOFTWARE PRODUCT ... IS NOT DESIGNED, MANUFACTURED, OR INTENDED FOR USE OR RESALE AS ON-LINE CONTROL EQUIPMENT IN HAZARDOUS ENVIRONMENTS REQUIRING FAIL-SAFE PERFORMANCE, SUCH AS IN THE OPERATION OF NUCLEAR FACILITIES, AIRCRAFT NAVIGATION OR COMMUNICATION SYSTEMS, AIR TRAFFIC CONTROL, DIRECT LIFE SUPPORT MACHINES, OR WEAPONS SYSTEMS, IN WHICH THE FAILURE OF JAVA TECHNOLOGY COULD LEAD DIRECTLY TO DEATH, PERSONAL INJURY, OR SEVERE PHYSICAL OR ENVIRONMENTAL DAMAGE". I am quite suprised to be reliant on Windows for the Radar integrity. Any ATCEs able to comment?
Guest
Posts: n/a
I know that the CAA SRG were unhappy about the use of Windows NT for Radar Displays (until they found out that NATS had ordered them in quantity!) - don't get me wrong, I think they're very good and streets ahead of the old type displays. If the display or processor fails it's much like any Radar failure and you can usually just swap to the second display alongside with no problem, it would just be nice if the display processor could recognise a Radar failure and freeze the data on the screen to assist in establishing procedural separation.
I think the Windows NT aspect of this is a bit of a red herring, the original versions of the FRL system ran under DOS and was no better in this respect, indeed, if a re-boot was required it took a lot longer to get going again.
[This message has been edited by ATCOMAN (edited 10 August 2000).]
I think the Windows NT aspect of this is a bit of a red herring, the original versions of the FRL system ran under DOS and was no better in this respect, indeed, if a re-boot was required it took a lot longer to get going again.
[This message has been edited by ATCOMAN (edited 10 August 2000).]
Guest
Posts: n/a
I wouldn't worry unduly about NT, imperfect though it is. I don't have a copy of the standard licence here, but that clip seemed to imply that it applied only to Java components of NT and I doubt very much that FSL has used Java. I don't know what else is in that licence.
In general, the licences of major operating systems are so written that not only is the OS not guaranteed for safety critical apps, but that trying to use it in those invalidates the licence. Where economics dictate that a mainstream OS has to be used, then as I understand it a special licence deal is done with the OS company, and the whole finished product is validated. You find out any glitches in the OS and either remove or work around them during development. That's fine if the systems are never going to be used as general purpose computers... so no Quake deathmatches.
About the specific worry -- that some modes of equipment failure lose important data -- I can think of several ways around this, such as storing n minutes of previous data and allowing backtracking, or taking snapshots, or spotting the case when all a/c disappear in ballistically improbable fashion, or (of course) getting the hardware to tell the system that things aren't right and engaging a different mode. I can also think of reasons why these might not be good ideas...
Is there no feedback mechanism for operators to talk to FRL? Companies in other industries have phone lines, email help, discussion boards and many other mechanisms for communicating with their users, and I can't believe that FRL doesn't want to hear about ways to improve their product. (Well, I could believe it since I know companies that work just that way. But I'd rather not.)
R
In general, the licences of major operating systems are so written that not only is the OS not guaranteed for safety critical apps, but that trying to use it in those invalidates the licence. Where economics dictate that a mainstream OS has to be used, then as I understand it a special licence deal is done with the OS company, and the whole finished product is validated. You find out any glitches in the OS and either remove or work around them during development. That's fine if the systems are never going to be used as general purpose computers... so no Quake deathmatches.
About the specific worry -- that some modes of equipment failure lose important data -- I can think of several ways around this, such as storing n minutes of previous data and allowing backtracking, or taking snapshots, or spotting the case when all a/c disappear in ballistically improbable fashion, or (of course) getting the hardware to tell the system that things aren't right and engaging a different mode. I can also think of reasons why these might not be good ideas...
Is there no feedback mechanism for operators to talk to FRL? Companies in other industries have phone lines, email help, discussion boards and many other mechanisms for communicating with their users, and I can't believe that FRL doesn't want to hear about ways to improve their product. (Well, I could believe it since I know companies that work just that way. But I'd rather not.)
R
