Simultaneous IR and RF modelling and simulation of ... Convention/Modelling and Simulation...Simultaneous IR and RF modelling and simulation of platforms, threats and countermeasures

Simultaneous IR and RF modelling and simulation of platforms, threats and countermeasures using CounterSim

Richard Ayling, Brian Butters, Nic Millwood, Roy Walmsley,

Chemring Countermeasures Ltd, Salisbury, UK [email protected]

Keywords: 3D target, Open Inventor, infra-red, radar, countermeasures

Abstract

The Chemring CounterSim modelling and simulation application uses 3D target models with both IR and radar cross section (RCS) properties. Therefore simulations are possible where IR and radar threats are present at the same time or where a threat may have dual mode IR and radar capability.

The IR and RCS properties of targets are defined using the Open InventorTM [1] toolkit that uses a standard file format for 3D data interchange. Open Inventor is an object-oriented 3D toolkit, originally developed by Silicon Graphics, Inc as the IRIS Inventor library. It is independent of the window system and the computer platform.

The surface IR properties of the CounterSim model are specified using an extended Open Inventor node in the platform Open Inventor file.

The radar cross section of a platform is defined using a separate Open Inventor file defining a collection of radar scatterers. These are represented by cones and spheres located at fixed positions on the target. Cones have a defined RCS, beam width, direction and phase change. Spheres represent isotropic point reflectors.

The paper describes the Open Inventor file extensions applied to a typical aircraft target using unclassified IR and RCS definitions.

An example scenario is described using MANPAD and fire control radar threats. An aircraft uses IR flare decoys against the generic IR reticle missile seeker. No use is made of counter-countermeasures triggers and methods such as rise rate, spectral ratio or track memory that could be modelled in CounterSim. The aircraft manoeuvers and dispenses chaff to break the lock of a monopulse fire control radar using a Moving Target Indicator (MTI) filter. 1. INTRODUCTION

Chemring Group companies, including Chemring Countermeasures Ltd (CCM), Alloy Surfaces Company and Kilgore Flares LLC, develop

and manufacture a wide range of expendable countermeasures operating in the IR and RF spectrum. Modelling and simulation of these countermeasures, the platforms that deploy them and the threats is an essential capability in the ongoing research and development of expendable countermeasures.

Chemring’s modelling and simulation effort began in 1986 with the modelling of aircraft IR decoys at Pains Wessex Ltd (now CCM). The software was written in Basic and ran under DOS on a PC. A Windows NT application coded in C++ was written in 1986 to cover naval IR and RF missile engagements. This evolved into an air and naval application in 1998 using the experience of the earlier air IR decoy models. CounterSim, introduced in 2003, is a further development of the naval and air application with the addition of models relevant to land warfare including vehicles, smokes and obscurants. It is the principle engagement modelling and simulation software used by the Chemring Group Countermeasures companies. CounterSim is being continuously developed by a team of software engineers at CCM near Salisbury in the UK.

While many other government and commercial organizations have developed specialised modelling and simulation applications many of these have been intended for use in only one domain (air, naval or land) and only one part of the threat spectrum (e.g. IR or RF). Even if they are HLA compliant, running them together in a federation can lead to difficulties including differences in data format, data interchange issues and timing issues [2].

Although the emphasis of early development work was on IR countermeasures, CounterSim and its predecessors were designed to eventually encompass IR and RF countermeasures in the same framework. The development process has been geared towards a range of models with increasing fidelity and validation sufficient for our evolving countermeasure development needs. More recent revision of the overall structure will allow further extensions into the visual and UV spectrum when needed.

Another key feature of modelling and simulation software design is composability. This was defined by Petty [3] as “the capability to select and assemble simulation components in various combinations into simulation systems to satisfy specific user requirements”. CounterSim, and probably other applications, meet the composability aim by being object oriented and having a comprehensive set of models that serve as the building blocks to model a larger system.

The available model set is increased beyond the CounterSim set by the ability to link to external models. An external model can be used as a more efficient compiled dynamic-link library (DLL) and linked to CounterSim by a header file or wrapper so that CounterSim and the external model are blind to one another. This approach has recently developed with MATLABTM algorithms and SimulinkTM models but is equally applicable to any external DLL.

The ability to model threats, countermeasures and platforms in the IR and RF domains in a common framework has many benefits including:-

• The use of common base code and net run time reduction compared with separate simulations.

• A common time base for data and events logged to an output file or sent to an external model during a simulation.

• The ability to carry out data fusion ranging from simple logic to complex signal processing on synchronised sensor data streams. This is necessary, for example, for the use of dual mode or multispectral threat models.

• Improved insight into some IR and RF countermeasure dispensing tactics. If 2 different modelling applications are used separately some effects may not be seen. While the IR decoy may have little or no effect on the RF sensor and vice versa, the successful deployment tactics of one countermeasure could compromise the effectiveness of the other. At worst, for one of the threats, the target platform ends up in the wrong place at the wrong time and in the least favourable aspect.

2. DESCRIPTION OF A JOINT IR AND RF

PLATFORM MODEL. In common with some other modelling and

simulation applications, CounterSim uses 3D models of target platforms and other objects such as scenery.

The platform models need to have appropriate representations of the IR and RF components as part of a common object so that the changing aspect of the platform always presents a correctly rendered 2D IR view and a simultaneous corresponding radar return in amplitude and phase. 2.1. 3D model format

Open Inventor was chosen as the basis for CounterSim 3D models because it has many useful features including :-

• The library of Open Inventor objects can be modified and extended. In CounterSim, derived nodes are used for IR and RCS properties.

• 3D models of platforms are readily obtainable in the public domain in one or more of the many different 3D file formats and can be readily converted to VRML and Open Inventor where necessary. (CounterSim can use VRML and Open Inventor simultaneously.)

• By setting a 0,0,0 reference point for x, y, z in the 3D model, other features such as countermeasure dispensers or launchers can be imported and fixed to the model and oriented in azimuth and elevation. The position coordinates can be read by the CounterSim platform item from the Open Inventor file or written back to it. Dispensers and the countermeasures loaded in them can be named and identified in the Countermeasure Controller item in order to dispense sequences of expendables during the engagement from specific locations on the platform.

• Use of the Open Inventor interpolator features allows engine plumes to be changed in response to different engine settings and hence the IR signature changes dynamically in the simulation.

• Use of Open Inventor animation object nodes (Engines) permit rotation e.g. helicopter rotors.

We have used an AMX fighter-bomber aircraft model shown in Figure 1. Unclassified IR and RCS signatures are used as an illustration of the use of Open Inventor extensions for the AMX IR and radar characteristics.

Because CounterSim does not currently model in the visual spectrum, the colour and texture are conveniently set to grey throughout the model.

The AMX example 3D model was obtained originally with a polygon count of 16,093 with 93 sub-objects. Prior to assigning an IR signature the

file was edited to discard or merge unnecessary sub-objects but also to adjust the number and arrangement of sub-objects consistent with an adequate IR material resolution.

In general the number of polygons and sub-objects need to be optimised to allow the model to fit the measured data while avoiding an unnecessary burden on the IR calculations and the rendering that would slow down the simulation. In the AMX example there are now 49 sub-objects.

Figure 1. Visual image of the AMX aircraft

2.2. IR definition For several years the emphasis of the

CounterSim simulation development was concerned with countermeasures to IR threats, particularly the MANPAD. The early platform model development was therefore focused on IR aircraft models. The first use of extended Open Inventor in CounterSim was the introduction of the SoIRMaterial node to describe temperature and emissivity of a surface as a grey body. Alternatively a normalized spectral radiance file is used if the emissivity is wavelength dependant. When calculating the surface radiance during rendering, the scaled spectrum is integrated over the viewer waveband to determine the radiance. The SoIRMaterial values are conveniently set using the IR Viewer application developed by CCM. This provides an image editor mode and false colour views in any user selected IR waveband. Dialog boxes enable the easy entry of temperature, emissivity or spectral radiance definitions. Alternatively, a more skilled user can set the values in a text editor. CounterSim uses additional IR viewer nodes in the scene-graph to specify waveband, radiance range and other parameters.

Figure 2 shows a false colour view at 3-5µm of the AMX model in the process of being edited. The rear canopy is selected and shows the temperature

set at 20°C and the canopy material emissivity set to 0.5. (Oblique lighting was set in the viewer to allow the different aircraft features to be seen more clearly on the printed page.)

Figure 2. AMX false colour view at 3-5µm showing selection and edit of canopy IR properties

The following boxed 12 line extract from the

Open Inventor file shows the SoIRMaterial parameters for the rear canopy.

The whole file consists of 14,025 lines of text and the file size is 565 Kbytes.

DEF REAR_COCKPIT_CANOPY Separator { SoIRMaterial { spectralType TEMPERATURE ambientColor 0.2 0.2 0.2 diffuseColor 0.2 0.2 0.2 specularColor 0.2 0.2 0.2 emissiveColor 0 0 0 shininess 0.2 transparency 0 temperature 20 emissivity 0.5 }

Engines and engine plume set up can be critical.

Engine exhaust components may need to be broken down to multiple items to obtain the correct IR response.

Plumes are currently modelled as 3 or more concentric cones (shown in Figure 2) with the same temperature and emissivity but with increasing transparencies from the inner to the outer cone. This has been found to work very well although a more physics and chemistry based modelling method may be employed in the near future.

When CounterSim runs a simulation and an IR sensor needs a scene image, the Scene Generator requests the target for its 3D representation. The

target item gets its 3D IR data from the modified Open Inventor (.iv) file. The scene image is then rendered using emissive colour as a 2D view depending on the sensor position, the 3D target orientation and the sensor properties such as waveband, thermal range and resolution. 2.3. Validation of the IR model

Validation of an IR definition is an iterative process involving comparison of the IR model radiant intensity from all aspects and ideally in a least 2 wavebands, e.g. the 2 to 3µm and 3 to 5 µm. wavebands, with calibrated measurement data of the real aircraft. The basic method is to simulate the flight of the aircraft model in a circular path in CounterSim and observe it with a model of an IR imager. The output of the IR imager together with the model azimuth data is used to produce a set of polar radiance plots similar to that shown in Figure 4.

Figure 4. Example radiant intensity polar plot from simulated model measurement

These are compared with calibrated

measurement data of the aircraft and the definition is adjusted until a good match is achieved. Un-calibrated IR images can also be used to identify heat sources and to adjust relative levels. The correct adjustment of the IR model definition is based on knowledge of the position and thermal characteristics of real objects that are identified as sub-objects in the Open Inventor file. This is particularly true of engine components and their effect on plumes. Un-calibrated IR images can also

be used to identify heat sources and to initially adjust relative levels. 2.4. RF definition

During the time when the CounterSim development emphasis was on IR modelling, the RCS modelling was only concerned with the bulk RCS properties of objects. The model included effects such as: aspect angle, scintillation and object extent. The radar seeker model simply tracked on the centroid of RCS within its radar resolution cell and was more applicable to naval scenarios involving early anti-ship missiles. At this time, there was little point in modelling air scenarios where Doppler effects are the key to performance assessment and achieving break lock.

Methods of modelling RCS in engagement simulations with reasonable fidelity and efficiency were researched and it was decided to employ a scheme of directional and isotropic point reflectors developed by Hughes[4]. In his thesis, Hughes states that both radar-echo phase and magnitude must be modelled to allow the effects of glint to be determined. The model must be operated in a scenario where the full 4π steradians may be observed. Hughes used a decision analysis method to choose between 4 modelling methods - Real Data, a Scatterer Model, a Statistical Model and a Structural Model. Of the 4 different methods available for generating a synthetic radar cross section, the most practical appears to be the use of scatterer models. This allows the radar cross section to be calculated quickly for any angle and at any frequency. Any correlations between cross section and motion are inherent in the model. Therefore, complex cross section patterns may be represented easily with a moderate number of scatterers. The effective resolution of the data can be increased by interpolating between measured sample points. The interpolation is non-linear and is related to the arrangement of the scatterers. The interpolated data therefore appear as a realistic radar cross section pattern. If scatterer models are used, they first have to be generated from some known radar cross section data. This data may be measured from a real target or could be synthetic data generated from a CAD surface model.

The Open Inventor reflectors file contains cone and sphere nodes that represent the reflectors. It is separate from the IR definition file because it is the simplest way to avoid the cones and spheres being seen in the IR image. Also, the much smaller reflectors file can be more easily edited when separate from the larger IR definition file. However, when the reflectors file is being developed it is useful

if the reflectors file references a 3D file of the target in a File node. This allows the position of the cone and sphere reflectors to be seen against the target body and show how they correspond to structural features. The 3D file reference can be left out of the reflectors file used by CounterSim but makes little difference to the file size and no difference to the simulation.

Figure 3 shows the reflectors file in the 3D viewer together with the 3D file for the AMX to show the reflectors relative to the aircraft structures.

Figure 3 – AMX reflectors file seen in the 3D viewer

including the separate aircraft file.

Cones are used to represent directional reflection points on the target.

• The position of the apex gives the position of the reflection point.

• The direction of the cone axis gives the direction of peak reflection.

• The cone angle gives the 3dB width of the reflection pattern.

• The height of the cone gives the square root of RCS of the reflector.

• The change in phase on reflection is given by the red value of the cone’s diffuse colour multiplied by 360° - a value of 0.5 gives a 180° phase change and a value of 0.75 gives a 270° phase change.

The reflection pattern is modelled as a single lobe. The reflector’s RCS is reduced by the cosine of the angle between the view direction and the peak direction, raised to a power. The power is chosen to give the specified pattern width. Higher powers produce narrower responses.

Spheres are used to represent omnidirectional reflection points on the target.

• The position of the centre gives the position of the reflection point.

• The radius of the sphere gives the square root of RCS of the reflector.

• In common with the cones, the change in phase on reflection is given by the red value of the sphere diffuse colour.

Figure 3 also shows that the green and blue colour channels can be changed for visual effect to help identify similar reflectors in the IR Viewer.

For the example aircraft, there are 12 cones arranged in pairs symmetrically on both sides and 6 spheres. The cones are in expected positions such as the wing root, the outer pylon wing root and at the engine intakes. (Note that reflectors are not shown for the top surfaces because the model is based on ground based radar observation and validation data.)

A section of 17 lines of the reflectors file is shown in the following box section. The included IR definitions file AMX-A1.iv is referenced followed by Cone0.

In the Material node only the diffuseColor red value affects the RCS properties of the reflector. In the example the red value of 0.51179832 represents a phase change of 184.25°.

Inventor V2.1 ascii Separator { File { name "AMX-A1.iv" } DEF Cone0 Separator { Transform { translation -5.0114899 0.74626905 1.8492652 rotation 0.99979001 0.020486446 0.00054504466 3.0884011 scaleFactor 0.25614116 0.78523439 0.25614116 center 0 0 0 } Material { diffuseColor 0.51179832 0.70113409 0.69077253 } Cone { }

The whole file for the 18 reflectors consists of

302 lines of text and the file size is 5.1Kbytes. When CounterSim runs a simulation with the

monopulse radar model, the Scene Generator scans the file to extract the reflector data for the monopulse radar to process.

CounterSim relies on the reflectors’ direction to define which reflectors are visible at each aspect angle. As the target travels and manoeuvers, reflectors are presented at different angles to the radar. Therefore Doppler, power spectral density, glint and scintillation effects that depend on the target’s movement and interference between reflections can be derived.

2.5. Validation of the RCS model

RCS model validation uses data from aircraft and chaff trials where the aircraft does a dry run (without dispensing chaff) or from specific aircraft RCS measurement trials. An illustration of a typical pair of chaff trial dry runs is shown in Figure 5. It shows trajectories for 2 RCS measurement runs of the same aircraft.

One trajectory is in level fight and in a straight line at 30° to the measurement radar (A). In the second run (B) the aircraft is approaching from the same direction but executing a 4G turn away from the radar

. An RCS model of the aircraft similar to that

described earlier was used in CounterSim and the trajectories of Figure 5 were reproduced. The

monopulse radar model using the same parameters as the measurement radar was used to track the aircraft and record the in-phase and quadrature components of the returned pulses and the RCS at the tracking range. Modelled and measured RCS data for the 2 cases is shown in Figures 6 and 7. The RCS scale is not absolute but has been normalized to the peak measured RCS of the 4G turn.

Figures 8 and 9 show the relative RCS density with time for the 2 cases. In both instances there is overall good agreement but the modelled data shows more peaks. This is probably due to the number of scatterers used in the model and sub-optimal scatterer configuration. The use of more scatters and/or improved scatterer scaling and placement would probably result in a smoother, closer fit to the measured data.

Figure 5 - Aircraft RCS trial trajectories

Figure 6 - Modelled and measured relative RCS – 30° offset – Run A

Figure 7 - Modelled and measured relative RCS – 4G turn – Run B

Figure 8 - Measured and modelled scintillation – 30° offset - Run A

Figure 9 - Measured and modelled scintillation – 4G turn – Run B

Modelled ScintillationMeasured Scintillation

Modelled ScintillationMeasured Scintillation

3. EXAMPLE AIR SCENARIO The AMX combined RF and IR model described

above is used with a generic monopulse radar model and a generic MANPAD with a rising sun reticle tracker and no counter countermeasures. The decoys used are chaff, ejected in a typical pulsed sequence, and conventional MTV flares.

CounterSim is an object oriented application and the engagement widow is used to compose a scenario with the different components being arranged in a tree of logical collections and hierarchies. The example scenario tree is shown in Figure 10.

Figure 10 - Example scenario tree

The purpose of the scenario is to illustrate some basic aspects of CounterSim and to provide some detail on the results of the RF modelling method.

Because of the unclassified and generic nature of the example, no conclusions should be drawn about the real life outcomes of the scenario that is described.

Figure 11 is a 200m grid plan view and shows the start position of the aircraft (-500, 3000) and the locations of the MANPAD (-1650, 2400) and fire control radar (0, 0).

. Figure 11 - Plan view of the example scenario

Figure 12 - Aircraft trajectory

The aircraft track is defined in CounterSim as a

comma separated variable (csv) file of aircraft x, y, z, azimuth angle and bank angle versus time at 0.2s intervals where x and y are relative to the aircraft start point (-500, 3000). The track file therefore defines the aircraft speed, which in the example, is 100 m/s. The trajectory is arranged so that, at the point coinciding with chaff release, the aircraft radial velocity and Doppler return pass through zero. Figure 12 shows the aircraft position at 1s intervals. Chaff is released at 5.4s when x=0 and the aircraft is heading due east.

As mentioned earlier, the IR engagement is deliberately very basic and leads to a successful outcome. The MANPAD is fired 1.5s after the run start. An MTV flare is fired from the starboard launcher 2.2s after the missile launch and another flare is fired from the port launcher 0.2s after the first one. The missile is decoyed with a miss distance of 26.9m. Figure 13 shows a view of a 3D file generated from the CounterSim generated data. The view shows the 2 decoy tracks in red and the blue missile trajectory relative to the aircraft. The example was deliberately designed to have a small miss distance in order to show the flare and missile tracks close to the aircraft.

Figure 13 - Flare and missile trajectories relative

to the aircraft.

The RF engagement features a well known strategy for achieving break-lock of the fire control radar. The method is to dispense chaff at the point where the aircraft presents a near zero Doppler return to the radar. Gun shells or RF guided missiles are not modelled in this instance. The aim of the RF simulation is to include the RF modelling processes and to demonstrate that the RF definition is sufficient to provide credible RCS data and Doppler results derived from the modelled radar data.

Figure 14 shows the Doppler response of the aircraft derived from the recorded data of the monopulse tracker with no chaff release.

The aircraft is the green / orange / red track. The chart is wrapped so that the track joins from the

bottom to the top of the chart and then top to bottom. Zero Doppler occurs at 5.4s as intended.

When chaff is ejected at 5.4s, the Doppler response of Figure 15 is produced. The data for Figure 15 was generated with the MTI function of the monopulse radar turned on and so the chaff is attenuated. Break lock occurs and for the rest of the run the radar is tracking on the chaff. It is possible to see the higher Doppler RCS in the chaff at the time of release and the decrease of the Doppler as the chaff slows down.

Figure 14 - Aircraft Doppler response

Figure 15 - Aircraft and chaff Doppler response.

4. CONCLUSIONS

Use of a common RF and IR model in the same CounterSim framework offers advantages with the use of common code, reduced run times and fully synchronized IR and RF data for object positions and other properties.

The use of node extensions in Open Inventor provides an efficient means of modelling platforms. For the example aircraft a complete definition in IR and RF is accomplished in 2 text files of 565Kbytes and 5.1Kbytes.

Open Inventor offers other advantages. For example, the Open Inventor Interpolator feature can be used in CounterSim to change engine plumes and hence IR signature during a simulation. This is initiated by using an engine state parameter either in

the CounterSim aircraft model track file or passed from an external aircraft model. Open Inventor offers further scope for dynamically changing other model components during a simulation.

The IR extension has been in use for some time with good results in a variety of air, naval and land studies.

The early work with the RF scatterer method on a limited set of platforms gives good agreement with measured RCS and Doppler response. However, the RCS model validation work to date has been limited because the initial set up and refinement of aircraft scatterer models is very time consuming. An initial estimate of a scatterer set has to be repeatedly tested, refined and tested again against several sets of measurement data.

Work is now beginning on the use of evolutionary algorithms to develop optimum scatterer solutions. This will ease the burden of scatter model development and enable testing of different numbers of scatterers against measurement data to gain insights into optimal solutions.

Future work with the RF aircraft and chaff models will simulate past chaff trials where break lock instances have been recorded. The correlation between real and simulated break lock can then be assessed and used to refine the models or the simulation methods.

References [1] Open Inventor open source licence at

http://oss.sgi.com/projects/inventor/ [2] Macal, C., Li, Z., Nevins, M., Sutton, M.,

“The Implications of Developing an HLA-Compliant Logistics Model - Lessons Learned”, SISO 1998 Fall Simulation Interoperability Workshop

[3] Petty, Dr. Mikel “Composable M&S Workshop” Virginia Modeling, Analysis, and Simulation Center July 9-10, 2002

[4] Hughes, Evan James. “Radar Cross Section Modelling Using Genetic Algorithms” PhD dissertation, Cranfield University 1998.

Acknowledgement The authors thank Dr Evan Hughes of the

Defence Academy, Shrivenham, UK for guidance and information provided for the RCS modelling.