Development of a PC Based Generic Radar Display Simulator

Development of a PC BasedGeneric Radar Display SimulatorCommander Ian Curl, RAN and Mr. Andrew Weisz, Serco Australia Pty LtdRoyal Australian Navy Surface Warfare SchoolHMAS WATSONSUMMARYSurface Warfare training for Royal Australian Navy (RAN) personnel is undertaken at HMAS WATSON in Sydney. Individual operator, command team and task group level tactical training is conducted on a variety of systems, including functional simulators, Milspec equipment and CBT suites. Most of the smaller training systems have been developed at WATSON by personnel from the RAN and Serco Australia Pty Ltd, the major on-site engineering support contractor. Even though these training systems have been developed and built in-house at very low cost, they have proven to be extremely effective for shore based operator training.This paper discusses the development of a medium fidelity PC based Generic Radar Display Simulator that has been designed to provide shore based radar operator instruction for training functions that previously could only be carried out at sea. The simulator was developed to run on a ‘standard’ PC, and incorporates an emulated UPA-59 IFF (Identify Friend or Foe) panel. The simulator provides the ability to generate emulated radar displays incorporating features such as sea clutter, atmospheric interference, coast lines, hostile jamming, mutual interference as well as surface and air contacts.The performance and fidelity achieved on a PC with SVGA display adapter, the design approach taken and the various development tools utilised are described. The impact of the new RAD (Rapid Application Development) tools like Delphi is also discussed.INTRODUCTION1.1 Initial User RequirementIn January 1995, the Combat Systems (CS) faculty at HMAS WATSON raised the requirement for a training tool that would facilitate the introduction of novice radar operators to the display unit and controls of typical radars in use by the RAN. Based on this request, WATSON’s on-site Systems Engineering contractor looked at the feasibility of developing a low to medium fidelity Radar Display Simulator. As only introductory training was involved, fidelity issues were considered relatively unimportant. However, with both the RAN and the RAAF having very limited access to active jamming equipment, the ability to simulate the effects of various types of hostile jamming was identified as one of the major priorities.The incorporation of an emulated UPA-59 IFF (Identify Friend or Foe) Panel was mentioned in passing as a possible future enhancement, if a satisfactory simulator could be developed.As WATSON already had a CBT (Computer Based Training) classroom with ten PC’s available, part of the requirement was to run the simulator on standard PC’s. Furthermore, the CS faculty was encouraged to consider a PC based simulator as a result of a number of PC based simulators developed earlier at WATSON, as described in a SimTecT-96 paper [1] by the authors.1.2 The Developers ReactionEven though the on-site development team had been very enthusiastic supporters of the PC platform up to this time, the immediate reaction was that the PC had been ‘over-sold’. Even though the suitability of PC’s for training systems has been pointed out by various authors, including Sweet [2] and Moriarity [3], t he consensus of opinion was that the standard PC of the time, namely a 486DX-66 running DOS would not be capable of supporting an acceptable radar simulator. However, in early 1995 two fortuitous events were to change this attitude.Firstly, while up till the end of 1994, all PC development work at WATSON had been undertaken for DOS, with the expectation of being able to by-pass 16 bit Windows by changing over to Windows-95, the constant delays to Windows-95, was making it imperative to make the change to Windows 3.1. So 16 bit Windows development had to be tackled. The Radar Display Simulator project was considered a good project to begin with. If an acceptable simulator could be developed, anything else in the future would be a ‘breeze’, and if the project failed; well, everyone had been warned that it couldn’t be done.The second event that influenced the project, was a chance encounter with an American developed DOS based Radar Display Simulator. While this particular package left a lot to be desired, it did provide the inspiration required to start WATSON’s development work.1.3 Initial Investigation of the PlatformWith the recently acquired conviction that the project was feasible, a study of the minimum hardware platform required was undertaken.It was very quickly determined that acceptable fidelity would require as a minimum, SVGA resolution (800x 600) with 256 colour palette depth. Minimum memory required was thought to be 8MB, thus the required platform emerged as a 8MB 486DX-66, with a 256 colour SVGA adapter. This configuration was not too far removed from the ‘standard’ PC of the day.STAGE 1 OF THE PROJECT2.1 Detailed User RequirementThe development proper began with detailed discussions with the subject matter experts, the radar instructors. The requirements for a useful training tools were identified as....• Low fidelity reproduction of a radar display • Provision of controls for On/Off, Video Intensity, Sweep Intensity, Focus, Range Ring Intensity, Range Selection (2 to 512 nautical miles), Range Gate On/Off, Range Gate Size, Ball Tab (cursor) On/Off & Position Control• Selectable Aerial Rotation (6 & 12 r.p.m.)• Selectable Beam Width (2 & 11 dgs)• Sector Blanking (inside & outside sector)• FTC & STC filtering• Air & Surface Contacts (with movement)• Sea Clutter and Atmospheric Interference• Coast Lines (with own ship movement)• Various types of Active Hostile Jamming• Effects of Mutual Interference from other radars• Display of Identification Friend or Foe (IFF )• Provision of ‘Out the Window’ visualsFigure 1.The OJ-194 Multi Function Display ConsoleFigure 1. shows a typical command and control console with radar display used by the RAN. The IFF control panel may be seen adjacent and to the right of the console.2.2 Design ApproachDetailed software design began with a crash course in Radar Displays for the developers. The instructors explained basic radar operation, demonstrated a typical radar display, the OJ-194 as fitted to the DDG’s and FFG’s, and passed on several ancient Royal Navy radar training videos produced in the fifties.With this new found knowledge about radars, a project Impact Analysis was undertaken, which indicated that most of the facilities detailed by the user requirements would be achievable, with the exception of the Focus Control and the provision of ‘Out the Window’ visuals. These two requirements were immediately identified as being beyond the scope of WATSON’s limited resources. However the remainder were considered not too demanding to implement.2.3 The ImplementationThe development tool chosen was Microsoft’s Visual C/C++, and the preferred approach was quickly determined as a combination of pre-computed meta-files for the selected image, and palette animation for the sweep rotation and the simulation of phosphor decay. This approach turned out to be virtually identical to that taken by Sawler & Mielke [4] in their development of a low cost PC based Simulated Ground-Based Radar System.The computation of the meta-file data was found to require around 10 seconds of processing on a 486DX-66, but after the initial computation, simulation of the sweep could be achieved with practically zero processor load by the use of palette animation.Even though a circular sweep was being simulated, surprisingly it was found to be unnecessary to use anything but small straight lines, albeit, a lot of small straight lines.2.4 Palette AnimationPalette animation in the context of the Radar Display Simulator, refers to the technique of splitting the display into 72 sectors representing 5 degree sections, and allocating different colour codes (of the 256 available) to the various lines within each section. Animation of the display then consists simply of varying the actual colour (in reality the shade of colour, as the display is monochrome), as the simulated sweep makes it’s way around the display. The intensity controls are simply implemented by varying the ‘colour’ corresponding to each code. As only the 256 entry colour palette needs to be updated for each movement of the sweep, it can be achieved with very little processor load. 2.5 Functionality AchievedOf the original functionality promised, only one item was found to be too difficult to implement. Because of the approach chosen, with all of the image computation being performed when the Radar Display is turned ‘ON’, it became impossible to allow Own-Ship motion relative to coast lines and other major portions of the image (like clouds). As the image computation was taking 10 seconds on the chosen platform, it was out of the question to perform the computation ‘on-line’ with the emulated radar display operating. Other minor deficiencies included having to re-compute the image whenever the range was changed.The major shortcoming was the somewhat large amount of memory required (12MB, 8MB for the application and 4MB for Windows).2.6 Fidelity AchievedWhile the functionality achieved was simple to quantify, questions of fidelity are much more difficult to measure. Furthermore, evaluations of fidelity tend to become subjective, with some people considering a given level of fidelity relatively low, while others might consider the same fidelity medium or even relatively high. Suffice to say that the users were more than satisfied with the fidelity achieved, and while it does not reproduce the fidelity of military radar displays, it is undoubtably a useful training tool. Some idea of the fidelity achieved may be gained from the greyscale image shown below.Figure 2.The Emulated Radar ImageThis partial screen capture shows the emulation of the sweep, with the range rings, a coast line, clouds and some jamming towards the bottom of the screen.2.7 Implementation EffortThe simulator was implemented with approximately 4 man-months of effort, and stage one was completed by the middle of 1995. Emboldened by the ease with which implementation of the Radar Display Simulator had been achieved, it was decided to extend the project to Stage 2, and evaluate the requirements for the UPA-59 Panel IFF emulation.STAGE 2 OF THE PROJECT3.1 The IFF PanelThe UPA-59 panel is a small (6 inch by 12 inch) but complex device. The panel is shown in figure 3. It consists of....• 16 two & three position toggle switches• 14 push buttons• 14 single digit mechanical displays• 5 indicator lamps (with engraving)• 4 five digit numeric LED display unit (not shown) • Complex engravings on the panelFigure 3.The UPA-59 IFF Control PanelWhile several possible approaches to the emulation of this panel were being considered, an event occurred which has since turned out to be one of the major advances regarding Windows programming. Borland released a product that took an entirely new approach to Windows software development. That product was Delphi, a visual software development tool based on Borland’s object orientated version of Pascal.3.2 Rapid Application Development (RAD) ToolsDelphi became available just as the preferred solution for the emulation of the panel was emerging as the animation of a scanned image. As Delphi immediately caught the imagination as the most powerful development tool encountered, and the animation of the switches using traditional C/C++ tools was quite daunting, it was decided to try Delphi by prototyping possible approaches to the emulation. Thus by getting a ‘feel’ for what would be required for the emulation, an estimated time for the implementation could hopefully be arrived at.To provide the scanned image, a photograph of an actual panel was taken in the Milspec FFG Ops Room at WATSON. The animation of the toggle switches was undertaken as the first attempt at using Delphi. The power of Delphi exceeded our wildest expectations, and instead of providing an estimate of the effort that would be required for the implementation, stage 2 of the project was completed entirely in a single week.The animation of the switches on the panel was implemented in two days, and only three days were required for the logical interconnection of the emulated IFF panel with the emulated Radar Display.3.3 Other RAD PackagesIt should also be noted that Delphi is not the only RAD tool available for Windows. There are similar packages like Visual Basic, Protogen, Power Builder, Authorware, IconAuthor and the latest offering, Optima++ from Powersoft. At the time of writing Optima++ was not yet available in Australia, but all the others have been evaluated and we have found Delphi vastly superior for the types of projects undertaken.3.4 Problems with Stage 2Even though stage 2 of the project was a great success, there was one significant problem. Up to this time, it was confidently thought that a 256 colour video adapter would be adequate for the complete simulator. It had already been established that 256 colours were sufficient for the Radar Display emulation, and during the development of the IFF panel emulation, 256 colours were also sufficient. Unfortunately, the two emulations required different 256 colours, so to handle both simultaneously, a video adapter with 65,000 colour depth was essential.By the end of 1995, with the ever increasing power and video resolution available for PC’s, the final platform requirements were not that outrageous. However it did mean an upgrade to the 10 PC’s in the CBT classroom, but the utility of the completed simulator was sufficient justification for the cost involved.FUTURE ENHANCEMENTS4.1 Improved PerformanceIn the first quarter of 1996, the development PC’s used at WATSON were upgraded from 486DX-66’s to Pentium-90’s with accelerated video cards. Executing the simulator on these new machines had the effect of reducing the image computation and initial display time from the earlier 10 seconds to around 3 seconds. This immediately raised the possibility of achieving the original requirement of allowing own-ship motion. It is felt that once sub one second computation time has been achieved, ‘real-time’ image computation will become feasible. Only minor additional processing power, together with minor optimisation of the software, should enable this goal to be achieved shortly.4.2 Networking with Other SimulatorsAs a ‘proof of concept’, several demonstrations have already been held at WATSON, with the Radar Display Simulator networked with some of the PC based trainers, like the AN/SLQ-32 Electronic Warfare Countermeasures simulator. If the networking were to be implemented using the DIS (Distributed Interactive Simulation) Protocol, rather than proprietary protocols it would be possible to use very low cost PC’s as additional radar displays attached to the major Command Team Trainers at WATSON. The ANZAC and FFG/DDG Trainers are to be linked in 1998 using DIS.LESSONS LEARNED5.1 Constant Increase in PC Computation PowerEven though we thought we were well aware of the ever increasing computational power of PC’s, the pace of the increase caught us by surprise. Our experience with the development of the Radar Display Simulator demonstrated yet again, that even if you feel that PC’s are not powerful enough for a given application, develop the software anyway. By the time the software is complete, chances are PC’s will provide the required power.5.2 You Never Know Until You TryAs has been the case on several occasions in the past, the major hurdle to be overcome with the project was to be convinced that it was possible to achieve. Once that conviction had been arrived at, a way was found to solve the problem. In the case of the Radar Display Simulation project, that conviction was supplied by a totally unacceptable implementation, but it was enough to convince us that a solution was possible.5.3 Never be Afraid to Change to New ToolsEven though we had been using C/C++ development tools for five years at WATSON, the benefits of the new Delphi were compelling. Naturally enough, there was some resistance on the part of some individuals to the change, based on the argument that we would be loosing all the experience gained over the past years. This is a false argument, as any new tool that requires this decision to be faced will by necessity be of compelling superiority. It only took several weeks for the sceptics to concede the advantages of the new tools, and wholeheartedly embrace the new approach to software development.We are finding that using Delphi, implementation time has been typically reduced by half, and sometimes by a significantly greater percentage.5.4 Concentrate on the Actual Training NeedThe Radar Display Simulator project has reinforced the lessons from all earlier development projects, namely the importance of concentrating on the training requirement. In the case of the Radar Display Simulator, the operative word was display. We were not trying to simulate a radar set, that was not the training requirement. Thus we did not have to concern ourselves with issues such as detection range, radar horizon, the effect of atmospheric conditions on the radar beam etc. We only produced an emulated radar display, showing the typical sorts of images that will be produced, if the given items are detectable.5.5 Use Rapid Prototyping and DemonstrateAs for all other development projects undertaken at WATSON, rapid prototyping was used for the software development, with constant demonstrations to the subject matter experts. Verbal or written descriptions of the proposed system were minimal, with system design heavily based on user feedback. Only through demonstration will the two way communication between the subject matter experts and the developers become a reality, and only with that will the minimum effort solution to meet the training needs be achievable.To make the Rapid Prototyping approach a practical proposition for Windows, it is essential to use RAD tools like Delphi. This enables ‘proof of concept’ implementations to be achieved in hours, or sometimes even minutes. Thus several alternatives may beprototyped for consideration by the subject matter experts.CONCLUSIONS6.1 The Power of the PCWe have found that by the middle of 1995, the processing power and display resolution of the ‘standard’ PC’ had reached the stage where relatively complex real-time simulations like a Radar Display Simulator were easily achievable.While initially Windows programming was quiet demanding due to the high housekeeping overheads and the phenomenal complexity of the API, recent progress with development tools like Delphi has changed the situation dramatically. With these new tools and the coming of age of 32 bit Windows (both Windows-95 and Windows-NT), software development for Windows has become simple and extremely rapid. It is conceded that Windows-NT has been around for quite a while, but the earlier lack of 32 bit development tools and it’s large memory requirements (we find 32MB a minimum) has only recently made NT suitable for mainstream applications.6.2 RecommendationsBased on all of our development activities at HMAS WATSON, and the Radar Display Simulator project in particular, we would recommend the consideration of the PC platform for all training applications. In particular, we very strongly recommend that Delphi under Windows-NT be evaluated for all projects involving the development of training systems, especially for relatively small projects of the type undertaken at HMAS WATSON.ABOUT THE AUTHORS7.1 Cmdr Ian Curl, RANCommander Ian Curl is the Deputy Director of Systems Support and Development, HMAS WATSON. He is a Weapons Electrical Engineering specialist in the Royal Australian Navy and holds a degree in Electronic Engineering from the University of South Australia. During his twenty years service with the RAN, Commander Curl has served in a variety of Combat Systems engineering positions, both at sea and ashore. The majority of his sea experience has been in US designed and built Guided Missile Frigates (FFG-7) and Destroyers (DDG-2). More interesting shore postings have included three years with NAVSEA in Washington DC working within the USN FFG-7 CDS Program and more recently, OIC of the RAN’s Test & Evaluation organisation in Sydney. Commander Curl has presided over the development of numerous Part Task Combat Systems Operations Training Simulators during his three years at WATSON and as a consequence, he is a strong advocate of the PC for use in this type of application.7.2 Mr Andrew Weisz, Serco Australia Pty LtdAndrew Weisz is the Contract Manager for WATSON’s on-site Systems Engineering Contractor, Serco Australia Pty Ltd. He has been employed in that capacity since 1991, prior to which he was the Technical Director with a small SCADA (Supervisory, Control and Data Acquisition) System manufacturer for 15 years. Since he has been at WATSON, he has applied the Man-Machine Interface design experience gained in his previous position to the development of numerous Part Task Trainers for the Royal Australian Navy. In 1995 he was the recipient of a Commanding Officer’s Commendation in recognition of his contribution to the development of training facilities at HMAS WATSON. Mr. Weisz has a Bachelor of Electrical Engineering degree from the University of New South Wales, Sydney Australia.REFERENCES[1] Curl, I., Weisz, A. Training Systems Development at HMAS WATSON. 1st International SimTecT Conference, March 25-26, 1996 - Melbourne Australia.[2] Sweet, P.E. Cost Effective Air Traffic Control Training Systems. 4th ITEC Conference, May 4-6, 1993 - London UK.[3] Moriarity, T.M. PC-Based Electronic Combat Simulators. 17th I/ITSEC Conference, November 13-16, 1995 - Albuquerque NM USA.[4] Sawler, R.J., Mielke, D.J. A Low-Cost Solution to Simulated Ground-Based Radar Systems. 17th I/ITSEC Conference, November 13-16, 1995 - Albuquerque NM USA.。