Coupling of TESS with SE-WORKBENCH for EO/IR countermeasure development and effectiveness assessment

Transcription

1 Coupling of TESS with SE-WORKBENCH for EO/IR countermeasure development and effectiveness assessment C.R. Viau a, I. D Agostino a, T. Cathala b a Tactical Technologies Inc., 356 Woodroffe Ave., Ottawa, ON, CAN, K2A3V6 b OKTAL Synthetic Environment, 11 avenue du Lac, Vigoulet-Auzil, FRA, ABSTRACT A research and development collaboration was established between Tactical Technologies Inc. (TTI) and OKTAL-SE with the purpose of coupling OKTAL-SE s simulation suite SE-WORKBENCH-EO and TTI s Tactical Engagement Simulation Software (TESS). TESS simulations are physics-based tools developed in the MATLAB/Simulink framework that enable users to analyze, evaluate, understand and optimize the effectiveness of electronic countermeasures (ECM) against threat weapon systems. The primary motivation for coupling the two simulation software was to create a complete set of powerful research tools capable of generating complex and realistic electrooptical (EO) and infrared (IR) synthetic environments (air, sea and land) in support of IR countermeasure systems development, tactics and effectiveness assessment against the latest generation of imaging IR (IIR) guided threat systems. The paper focuses on the TESS and SE-WORKBENCH-EO interface and its applications to IR countermeasure development and effectiveness assessment. Topics include the motivation for the software coupling, an overview of the Simulink engine, an overview of S-Function structure, a description of the main components of the software interface, description of the data exchange between the two software systems and a demonstrations of the synthetic environment created by SE-WORKBENCH-EO and processed in TESS. The report also presents future post-integration work. Keywords: electronic countermeasures, imaging infrared seeker, TESS, SE-WORKBENCH, modelling, simulation 1. INTRODUCTION The infrared (IR) guided missile has been a lethal threat to civilian and military platforms for many decades. The most recent generation of IR seekers are fitted with focal plane arrays (analogous to visual cameras) and advanced processors capable of detecting, recognizing, and tracking various types of targets in densely cluttered environments. In the terminal phase, some of these advanced systems are capable of identifying and targeting specific areas of a platform in order to maximize the inflicted damage. To minimize such damages, preventive and reactive measures have been developed to reduce a threat s effectiveness and increase a platform s survivability. The survivability of a platform is greatly dependent on its detectability and the type of countermeasures used for selfprotection. The detectability of a platform is driven by signature (thermal, electromagnetic, radar cross section) management and suppression measures implemented to reduce its visibility from approaching threats. Understanding and suppressing a platform s sources of radiation is a preventive and essential step in maximizing survivability. However, reducing detectability and susceptibility of a platform is not sufficient to ensure survivability. Other methods of concealment and deceptive techniques are required to defeat the modern IR-guided threat. To defeat IR-guided threats, platforms may use a combination of countermeasures (see Figure 1) such as obscurant smoke, flares and decoys as well as various types of jammers such as directional IR countermeasures (DIRCM). Obscurant smoke is typically used in land and naval applications to temporarily conceal the precise position of the platform. Flares and decoys can be used pre-emptively to deny a lock-on by an IR-guided system or reactively to lure the threat s tracking cell away from the targeted platform. A jammer, typically used in land and air engagements, uses an intense radiation source to dazzle, saturate and in certain cases inflict permanent damage to the threat s seeker. 1

2 Figure 1 - Obscurant Smoke 1 (top left), Naval Decoys 2 (top right), Flares 3 (bottom left), DIRCM 4 (bottom right) In order to develop these countermeasure systems and tactics, scientists and engineers require an in depth understanding of the physical interactions between the systems, their environment and their overall effectiveness. This knowledge is typically acquired using physics-based simulation tools, hardware-in-the-loop simulators and reverse engineering when available. The system modelling and simulation (M&S) phase is a critical step in the development process where the developer can gain a broad understanding of the algorithm, tactic or system s capabilities and vulnerabilities. The M&S process allows the developer to conduct trade-off studies, performance analyses and virtually an unlimited number of scenarios that cannot be conducted in field trials due to the cost and time restrictions. With the right physics-based M&S tools, developers can optimize and assess their algorithms, tactics and systems effectiveness prior to hardware development and field trials. A physics-based simulation tool called Tactical Engagement Simulation Software (TESS ) was originally developed in mid 1990s to support radar and IR countermeasure analysis work for the international defense community. TESS simulations are physics-based, developed in the MATLAB and Simulink framework and enable users to analyze, evaluate, understand and optimize the effectiveness of countermeasures against threat weapon systems. TESS distinguishes itself from other simulation products with its available source code which allows users to inspect, verify and modify any of the underlying mathematical equations and algorithms of the simulation. In 2006, TESS was extended to simulate IIR threat systems and countermeasures and in 2013 a research and development collaboration was established to couple TESS with OKTAL-SE s SE-WORKBENCH-EO. The primary motivation for coupling the two simulation packages was to create a complete set of powerful research tools capable of generating complex and realistic electro-optical (EO) and IR synthetic environments (air, sea and land) in support of countermeasure systems development, tactics and effectiveness assessment against the latest generation of IIR guided threat systems. The following paper focuses on the Simulink/SE-WORKBENCH-EO interface and its applications to IR countermeasure development and effectiveness assessment. Topics include the motivation for the software coupling, an overview of the Simulink engine, an overview of S-Function structure, a description of the main components of the software interface, description of the data exchange between the two software systems and demonstrations of the IR synthetic environment from the joint TESS/SE-WORKBENCH-EO solution. 2

3 2. REQUIREMENTS FOR IR SYNTHETIC ENVIRONMENTS In 2006, TTI initiated a project to develop the capabilities to model IR imaging systems in TESS. The first application was derived from a naval radar electronic countermeasure model to create a simulation tool for assessing IR countermeasures against anti-ship missiles. In 2008, the initial capability was evolved into a land-based active protection (APS) countermeasure systems which simulated an armoured vehicle using soft-kill (obscurant smoke, IR jammer) and hard-kill (counter munition) to protect itself from anti-tank weapons such as rocket propelled grenades (RPG) and guided missiles (ATGM). In 2012, the IIR capabilities were integrated into a surface-to-air and air-to-air engagement simulation tool where a target platform (fixed or rotary wing) used various types of flares (standard, propelled, distributed) and/or a DIRCM system to defend itself against the latest generation of IIR seekers. One of the main challenges encountered in the development of these simulation tools has been to create realistic and accurate IR synthetic environments representing what the imaging system sees during an engagement. Many of these advanced systems operate simultaneously in multiple wavelengths and a scene representation in each of the bands is required. Figure 2 illustrates generic examples of what an IIR camera might observe in land, naval and air environments. Figure 2 - IR imagery of land 5, naval 6 and air 7 targets in their environment In ground based simulation, multiple scene representations are required from both the perspective of the threat (either the gunner or the seeker) and the perspective of the protection systems on the platform which detects and supports fire control solutions. The scene observed by the threat includes a target platform (armoured vehicle), a terrain (desert, urban), countermeasures (smoke, flares, jammer) and their effects on the threat system (dazzling, saturation, noise, beam spreading). The scene observed by the APS s IR sensors located on the target platform includes the terrain and the approaching threat weapon (RPG, ATGM). In naval simulations, a scene representation is required from the perspective of the threat missile. The scene observed by the seeker includes the ship target platform, naval decoys, a sea and sky background. In air engagements, multiple viewpoints are required from the missile perspective and the DIRCM system s perspective as it tracks the approaching threat. The scene observed by the seeker includes the target aircraft, environment (clouds, sun, moon) and countermeasures (flares, DIRCM). The scene observed by the DIRCM system includes a background (terrain and/or clouds depending on the engagement altitude) and an approaching missile system with signature representation from the aerodynamic heating of the airframe and the plume. TESS IIR simulators currently have the ability to render simple synthetic environment and countermeasure representations using MATLAB s native graphic engine 8. Although MATLAB is very good at plotting graphical representation of complex datasets, it is not intended as a scene graph. The amount of fidelity and realism needed in an IR synthetic environment and the expectations of advanced users had surpassed the current capabilities. An advanced tool for rendering complex IR synthetic environment with the potential capability of real-time imagery for hardware-inthe-loop simulation was required. 3. COUPLING OF TESS AND SE-WORKBENCH-EO In order to address the rapidly evolving requirements for complex IR synthetic environment, a research and development collaboration between TTI and OKTAL-SE was initiated to couple TESS with SE-WORKBENCH-EO. As illustrated in Figure 3, SE-WORKBENCH-EO 9 is a complete suite of tools used by the international research community to perform multi-sensor simulations. It enables the user to create virtual and realistic multispectral 3D scenes that may contain several types of target (and now countermeasures), and then generate the physical signal received by a sensor, typically 3

4 an IR sensor. In the SE-WORKBENCH-EO workshop, SE-FAST-IR is a set of physics-based software and libraries that allows preparing and visualizing 3D databases in real-time for the EO domain. SE-FAST-IR makes an intensive use of OpenGL Shader state-of-the art technology. Most of the physics computations are processed on the graphic board, resulting in a minimal CPU load that thus remains available for other simulation tasks. SE-RAY-IR is a ray-tracing software, which enables the computation of highly realistic images in both the visible and the IR spectrum resulting from complex scenario runs that include 3D terrain, 3D targets, atmospheric conditions, sensors models and associated trajectories. Figure 3 - SE-FAST-IR and SE-RAY-IR inside the SE-WORKBENCH-EO Suite The coupled solution allows TESS users to create dynamic and detailed EO/IR rendering of complex 3D scenes (land, air, naval) with SE-FAST-IR or SE-RAY-IR. Jointly, the tools provide engineers and researchers the ability to model closed-loop engagements and physical interactions between a target platform deploying countermeasures and an IIR guided missile system. The tool models the terminal phase of an engagement with the missile seeker turned-on in either search or track mode and operating autonomously until end-game. At every time-step of the simulation run, TESS computes, using physics-based principles, the motion and behaviour of the various entities (target platform, countermeasures, missiles and launch platform). These updated states are passed from TESS to SE-FAST-IR or SE-RAY-IR via a Simulink and SE-TOOLKIT interface. SE-TOOLKIT is a set of libraries and Application Programming Interfaces (APIs) that provide the user external control of the SE-FAST-IR and SE-RAY-IR products. Once SE-FAST-IR receives all the updates from TESS, a new EO/IR scene is rendered from the perspective of the sensor of interest and returned to TESS for processing and analysis. TESS applies user-defined image processing algorithms to the new IR scene to identify and track potential targets. The result of the target discrimination process is used to generate missile flight path corrections based on the type of navigation scheme used and numerous autopilot feedback loops. This process is repeated every time-step until the missile s point of closest approach to the target occurs. 4

5 Commonly used measures of effectiveness (MoE) such as miss distance, probability of kill and probability of survival are computed at the end of each simulation run. A front-end database allows the user to define and store data libraries of Targets, Countermeasures and Threats. A programmable batch runner allows the configuration and execution of batch runs (Monte Carlo) of simulated tactical engagements. Figure 4 - TESS SAAM(IIR) Block Diagram, Sensor Views, 3D Plots and Signal Viewers In the standard configuration, a set of targets, countermeasures and environmental conditions have been pre-configured using the various SE-WORKBENCH-EO tools (illustrated in Figure 3). Users have the ability to select from the available entities but still have the flexibility to characterize a long list of target, countermeasure and threat system parameters such as maneuvers, number of launchers/dispensers and their position on the platform, number and size of the countermeasure, deployment timing sequences, missile and seeker characteristics including propulsion, guidance, autopilot, aerodynamics and warhead subsystems. In the advanced configuration, users have the ability to use the SE- WORKBENCH-EO suite to customize their IR synthetic environment. The collaboration effort first focused on the integration of SE-WORKBENCH-EO and TESS ASM(IR) which is a naval countermeasure development and evaluation tool. The physics-based simulation tool models a naval vessel, its launchers, distraction and seduction naval IR decoys, environmental elements and atmospheric attenuation, a threat system including the launch platform (surface or air), missile system with an imaging seeker, propulsion, aerodynamics, guidance, autopilot and warhead. The following section describes in further details the custom Simulink interface developed to interact with SE-WORKBENCH-EO. 4.1 MATLAB/Simulink 4. SIMULINK INTERFACE TO SE-WORKBENCH-EO MATLAB/Simulink is a graphical block diagramming tool used to model, simulate and analyze dynamic systems 10. Models are constructed by adding and connecting pre-built function blocks from the Simulink library. Model blocks provide a visual and intuitive means of modelling mathematical functions and signal processing operations. 5

6 The Simulink library contains a range of built-in model blocks to perform a wide array of functions. Custom model blocks may be constructed using MATLAB System-Functions (S-function), a powerful extension to the Simulink environment. S-functions are user-built Simulink blocks, written in one of several computing languages. These custom functions form dynamically linked subroutines that the MATLAB interpreter can read and execute C Mex S-Function Overview To implement a means of communicating between the Simulink engine and SE-WORKBENCH-EO, a C Mex S- function was constructed. This is a custom MATLAB S-function, written in the C programming language. While other less complicated interface options between Simulink and SE-WORKBENCH-EO are possible, none provide the flexibility and advanced range of controls that implementing a C Mex S-function can offer. A C Mex S-function, like all custom S-functions, is written using the S-function API syntax. This API syntax is the interpreter that allows the custom code to communicate with the Simulink Engine 11. Once completed, a C Mex S-function can be compiled using the MATLAB mex utility to create a binary source mex-file. This mex-file is then associated with an S-function block, available from the User-Defined Functions section of the Simulink library. At runtime, this custom S-function block is loaded and executed by the Simulink Engine as any other built-in Simulink block The Simulink Engine The Simulink engine executes simulation by stepping through and repeating a series of integration steps. During each simulation, some of these steps (eg/ initiating the model) are performed only once, while others (eg/ calculating outputs) are repeated as part of a simulation loop. Figure 5 below illustrates how the Simulink engine performs simulations. Figure 5 - How the Simulink Engine Performs Simulation 13 In order to establish communication between the Simulink environment and SE-WORKBENCH-EO, the SE-TOOLKIT functions are structured into the simulation process loop framework shown above in Figure 5. Single run commands responsible for initializing the SE-TOOLKIT connection, loading the scenario, initializing entity positions, and starting the scenario are grouped in the Initialize model stage. Recurring commands like those responsible for repositioning and resizing scene entities, and capturing/outputting sensor data are executed from within the simulation loop. Stopping the scenario and terminating the SE-WORKBENCH-EO connection occurs at simulation end, after the simulation loop has executed for the last time. 6

7 A more detailed process view of the Simulink Engine interaction with an S-function is shown in Figure 6. The order and various types of S-function API callbacks, and the manner in which the SE-TOOLKIT interacts with this API is explored further in the next section. 4.4 Constructing a C Mex S-Function Figure 6 - Simulink Engine Interaction with C S-Functions 14 The MathWorks provides a basic template for constructing C Mex S-functions, which can be written in either C or C Since the tutorials associated with the SE-TOOLKIT were written in C, it was natural to develop the C Mex S- function in the C programming language. The basic template for a C Mex S-function can be divided into the following sections, discussed in further detail below: Definition of Constants Included Header files Static variables S-Function API Methods o Model Initialization mdlinitializesizes mdlinitializesampletimes mdlinitializeconditions (not used) mdlstart o Simulation Loop mdloutputs mdlupdate (not used) mdlderivatives (not used) o End of Simulation mdlterminate S-Function trailer 7

8 4.4.1 Definition of Constants The first section of the C Mex S-function is typically used to specify required and optional defined constants. For example, the S-function name and level must be specified. Optional defined constants include mathematical constants (eg/ Pi), or other values that remain constant but are referenced by the various methods of the S-function. Examples include the number of inputs, the number of outputs, and the number of S-function mask arguments Included Header Files This project requires the inclusion of a variety of header files. Specific to the C mex S-function, the file Simstruc.h must be included for the definition of the SimStruct (the S-function s simulation data structure) and its associated macro definitions 16. Additionally, the mex.h header file is included for callbacks related to interacting with the MATLAB Base workspace from within the S-function. A number of standard C libraries are also included, for math operations, string concatenation, etc. Specific to the SE-TOOLKIT, the header files listed below are included. These header files contain functions related to interacting with the SE-TOOLKIT, particle systems, optronic sensors, and error tracing. #include <setk/setk.h> #include <setkd_scnx/setkparticlesystem.h> #include <setkd_scnx/setkparticlesystemproperty.h> #include <setk/setkoptronicsignal.h> #include <setkmessage/setkmessage.h> Static Variables Next, any variables which remain static throughout the simulation are defined. These variables typically relate to settings in the SE-TOOLKIT. For example, this is how an array of IR context options is made available to the user at runtime S-Function API Methods and SE-TOOLKIT Functions Simulink provides a means of accessing the S-function simulation data structure via a set of defined API functions. This project uses the majority of the MATLAB API functions defined in the basic C Mex S-function template. Additional API functions are also used to support some of the advanced requirements for this project (eg/ dynamically dimensioning the output ports). Calls to the SE-TOOLKIT API functions take place from within the MATLAB API functions. These two sets of API functions, and the manner in which they interact are described below. SE-TOOLKIT API functions are suffixed with an * character to differentiate between the two sets of API commands Model Initialization The Model Initialization phase of the simulation is responsible for initiating single-run commands required to set up the scenario. This includes initializing the connection to the SE-TOOLKIT, loading the scenario, positioning scenario entities, creating decoys, and starting the scenario. First, the SimStruct function mdlinitializesizes is where the input ports, output ports, and persistent variables are defined. Defining the number of each port type determines the number of input and output connections to the Simulink model. The port connections are defined later in the initialization phase. Persistent memory variables are created through the use of DWork vectors. Creating a DWork vector assigns a block of memory specifically reserved for the S-Function, and allows memory allocation and de-allocation to automatically be controlled by the Simulink Engine 17. Similar to a global variable, DWork vectors store data (eg/ counters, launch flags) persistently between time steps and may be accessed as needed throughout the simulation. Next, the input and output ports are dimensioned using the SimStruct functions mdlsetinputportdimensioninfo and mdlsetoutputportdimensioninfo. The inputs port sizes are known and remain unchanged for the simulation, so these are assigned as fixed values. The output port sizes are assigned dynamically, determined by the IIR sensor resolution values entered in to the S-function Parameters mask. The sample time of the S-function is set via the mdlinitializesampletime SimStruct function. Since the Simulink model uses a fixed time step, a discrete S-Function sample time is used. The S-function sample time is regulated by the userdefined sample time set in the IIR sensor input parameters. This value is retrieved using a MEX Library command 8

9 (mexevalstring) to query the parameter directly from the sensor block mask in the Simulink model. The sssetsampletime command is then used to set the sample time, in combination with a zero offset time (sssetoffsettime). Interaction with the SE-TOOLKIT API occurs for the first time in the next S-function SimStruct callback, mdlstart. This function is executed once when a model is run, after the initialization phase has completed. The mdlstart function houses the SE-TOOLKIT API commands to initialize the link to the SE-TOOLKIT API, load a scenario, initialize scene entities, and start the scenario. A complete listing of all SE-TOOLKIT API functions is available from the SE- TOOLKIT SDK documentation provided by OKTAL-SE 18. The first step in this function is retrieving handles to our input ports via the ssgetinputportrealsignalptrs command. These inputs contain user selections determining which scenario to load, the IR context, the simulation clock, and the entity positions. The SE-TOOLKIT API is initialized using the setkinitialize* API function, and then a user-selected scenario is loaded using the setkscenarioload* function. Next, the IR context is selected using the setkscenarioselectcontext* command. This function is used to select the rendering context. Valid choices include SE-FAST-IR-SWIR (short wave band, typically 1-2 µm), SE-FAST- IR-MWIR (mid wave band, typically 3-5 µm), and SE-FAST-IR-LWIR (long wave band, typically 8-12 µm). Scene entities already present in the scenario (ship, threat, optronic sensor) are initialized by first retrieving a handle to the entity, and then repositioning it. This is performed by using the setkscenariogetentity* and setkentitysetlocaltransformation* API commands respectively. Decoys are an exception as they are created at runtime using the setkscenarioaddparticlesystem* function, which is part of the SE-TK-PARTICLES API (an extension of the SE-TOOLKIT) 19. Performing this action at runtime gives us the flexibility of creating a user-defined number of decoys. Lastly, the scenario clock is initialized to 0.0 seconds using the setksimulationsetinitialdate* function, and the scenario is started via the setksimulationstart* command. The scenario is now fully initialized and ready to run Simulation Loop With the Model Initialization phase of the simulation now completed, the main simulation loop begins. During the simulation loop, the scenario clock is advanced, scene entities are updated, the sensor signal image is rendered, and the sensor radiance array is captured and output to the Simulink model. The mdloutputs SimStruct API function is the parent callback structure used to perform these tasks each time step. This function is executed with a frequency determined by the setting chosen in the mdlinitializesampletime function during the model initialization phase. First the handles to the input and output ports are retrieved via the ssgetinputportrealsignalptrs and ssgetoutputportrealsignal commands respectively. The input port parameters are used to advance the scenario clock (sstksimulationgountil*), and provide the parameters necessary to retrieve (setkscenariogetentity*) and update (setkentitysetlocaltransformation*) scenario entities. Output ports are used to return the sensor radiance array and scenario gain values. Once the scenario and entities have been updated, the SE-TOOLKIT API function setkoptronicsensorrendersignal* is used to render the signal generated by the IIR sensor. This function returns a handle to the captured signal. The setkoptronicsignalgetsignalradiancesbuffer* command is issued to return a pointer to the radiance array of the signal handle, and return the array size. Each element in the array corresponds to the radiance of a particular pixel in the scene. The radiance array is then processed and assigned to the first output port. The second output port is assigned the minimum and maximum radiance values from the radiance array, used to determine gain thresholds for the IIR sensor. Lastly, the setksignalfree* command is issued to free the signal for the next iteration of the simulation loop End of Simulation When the simulation has completed, the mdlterminate SimStruct API function is called to instruct the scenario to halt, and terminate the connection to the SE-TOOLKIT. The setksimulationstop* and setkfinalise* SE-TOOLKIT API commands are issued from within this function to accomplish this task. 9

10 4.4.5 S-Function Trailer The S-function trailer is included with the basic C Mex S-function template, and is located at the very end of the file. Its inclusion is required. The trailer contains a reference to a MEX file interface mechanism (Simulink.c) required for the simulation Compiling the C Mex Source File and Building a Binary MEX File With a C Mex source file written, the next step in the process is to compile the code and build a binary MEX file. A MEX file is a MATLAB executable file. A binary MEX file acts as an interface between the MATLAB interpreter and the methods in the source MEX file written in the C Programming language. The result is a dynamically linked subroutine able to be read and executed by the Simulink Engine 12. To build a MEX file, a MATLAB-supported compiler must be installed on the compiling PC, and selected as the default MATLAB compiler. The Microsoft Windows SDK 7.1 compiler was used in this project. Selecting a compiler can be performed using the MATLAB mex function ( mex setup ) from the Base workspace and following the setup instructions. Building the MEX file is performed by using the MATLAB mex function from the MATLAB workspace command line 21. The following components are assigned to the mex command: Includes (-I) o This is the pathname of the directory containing the SE-TOOLKIT includes listed in the first section of the source C Mex file C MEX file o The source C Mex file SE-WORKBENCH-EO library o The path and filename of the SE-WORKBENCH-EO library file Executing the command from the MATLAB workspace command line creates a 32-bit binary MEX file (.mexw32). 4.6 Configuring OKTAL-SE Environment Settings The SE-TOOLKIT requires that a number of execution environment settings be configured prior to launch. This operation defines system paths and the locations of dynamic libraries on the Windows system. The environment settings to be configured include the installation directory of the SE-WORKBENCH-EO, definition of the Microsoft Developer (MSDEV) path, definition of the location of third party applications, and definition of the location of SE- WORKBENCH-EO license and multidomain database files. A full description of this specification may be found in the Dynamic libraries path needed to run SE-TOOLKIT section of the SE-TOOLKIT Programming manual Adding a C Mex S-Function block to a Simulink Model, and Linking to a Binary MEX File With a MEX file constructed and environment settings configured, a custom S-Function block can now be added to the Simulink model. The S-Function block is located in the User-Defined Functions section of the Simulink library 22. Once added, the name of the binary mex-file, and any S-function parameters required by the source file (eg/ IIR sensor resolution) are assigned to the block mask. Clicking the block s Apply button links the block to the binary mex-file and automatically creates input and output ports as defined in the source file. 4.8 Connecting Input and Output Ports Figure 7 below illustrates an S-function block fully integrated into the context of the TESS simulation model environment. The inputs and outputs discussed in the previous sections have all been connected. The details of the various connection types are presented below. 10

11 Figure 7 - Integrated C MEX S-Function Clock - The simulation clock signal from the Simulink model, used to advance the SE-Scenario simulation clock. Scenario - An integer value corresponding to one of several pre-built naval scenarios (.scnx). IR Context - An integer value corresponding to one of three IR Contexts (short-wave, mid-wave, and long-wave) Target Platform 6DoF -Six degrees of freedom data (x, y, z, az, el, roll) used to position and orient the target ship entity each time step in the scenario. Threat Platform 6DoF - Six degrees of freedom data (x, y, z, az, el, roll) used to position and orient the threat system entity each time step in the scenario. Anti-Ship Missile 6DoF - Six degrees of freedom data (x, y, z, az, el, roll) used to position and orient the threat missile and IIR Sensor each time step in the scenario. Decoy 6DoF - Six degrees of freedom data (x, y, z, az, el, roll) used to position and orient decoy countermeasures each time step in the scenario. Decoy Flags - Binary state values used to update the various launch and bloom states of each decoy. Decoy GSD - User-defined decoy growth, sustain, and decay time constants used to specify a growth profile for each decoy. Sample Rate - The sample time used to update the scenario. This user-defined parameter controls the IIR sensor frame rate. 5. RESULTS AND DISCUSSION The integration of SE-WORKBENCH-EO with TESS provides the ability to generate detailed and realistic IR environments which was not previously possible with the MATLAB based IR scene generator 8. Examples of IR scenes in TESS generated by SE-WORKBENCH-EO are illustrated in Figure 8 and Figure 9. There are numerous significant improvements that SE-WORKBENCH-EO provides in comparison to the previous IR scene generator. In the air engagements, the use of SE-PLUME creates detailed aircraft engine signatures and their 11

12 radiative effects on the other parts of the platform which was not previously possible. In the land scenarios, vegetation, natural terrains and buildings can now be used to create battlefield clutter affecting probability of detection of a camouflaged target or an incoming RPG. The effectiveness of an active protection system can be assessed in an urban area where insurgents may be hidden in buildings or behind another vehicle. In the naval environment, SE-3DDB (sea database) provides detailed sea models with various sea states, ship wakes, dynamic representation of sea profiles (3D foam volume), and interaction with floating objects (rear and bow wake, Kelvin wake, buoyancy rules). The inclusion of these physical phenomena produces a realistic naval environment and plays an important role in the missile seeker s ability to discriminate targets from background clutter. Figure 8 - IR Synthetic Environments in TESS and SE-WORKBENCH-EO Figure 9 - Real naval decoy deployment 24 (top row) and simulated deployment in ASM(IR)+ using SE-WORKBENCH-EO. As described in Section 4, a significant amount of resources were devoted to developing the necessary plumbing to establish a communication link between Simulink and SE-WORKBENCH-EO. Another important area is the development of realistic countermeasure models and effects. In the case of ASM(IR)+, naval IR decoys needed to be ported from the MATLAB environment to SE-WORKBENCH-EO. Viau et al. 23 describe in greater details the physical modelling of naval decoys in TESS and SE-WORKBENCH-EO. An example of a real decoy deployment and the simulated deployment in ASM(IR)+ are illustrated in Figure 9. In ASM(IR)+, users have the ability to characterize a deployment sequence and the individual decoys with parameters such as number and maximum size, growth/sustain/decay times, individual deployment timing, orientation and deployment range from the platform. TESS simulators are used in several ways in the countermeasure development process from design, test, optimization, hardware-in-the-loop to operator training. One particular feature of TESS is the programmable batch runner which allows the users (and the TESS engineers) to develop batch run scripts for testing and evaluating various aspects of the system such as deployment sequences and timing, detection and tracking algorithms, fire control algorithms, 12

13 countermeasure effectiveness and optimization. In an optimization application, the batch runner provides access to userdefined simulation outputs which can be used in an adaptive algorithm to setup the input parameters for the next run. The batch run results can be used to create various types of plots for visualization as illustrated in Figure 10. The Miss Distance Polar Plot demonstrates the platform s probability of survival for various miss distances as a function of the threat s direction of arrival. The Target-Centric Electronic Countermeasure (ECM) Effectiveness Plot illustrates the threat weapon s probability of kill as a function of a threat s direction of arrival. The dark red regions indicate the zones where the countermeasure technique did not have any effect on the threat. The countermeasure optimization attempts to minimize the red (kill) zones and maximize blue (survival) zones. The Threat-Centric Weapon Envelop highlights a weapon system s probability of kill envelop as a function of a target aircraft flight path (in this particular plot, a North- South trajectory). This type of plot is useful in understanding a weapon system s effective range and vulnerabilities. The threat-centric plot can be viewed with a top-down perspective as illustrated below or with an altitude/down-range perspective providing an elevation view of the threat s envelope. Figure 10 - Typical TESS Batch Run Plots 6. CONCLUSIONS AND FUTURE WORK The IIR missile has threatened naval, land and air platforms survivability for many years. With the technological advancements in focal plane arrays, detectors and electronic imaging, this threat will continually become more lethal. Platform survivability is built on two fundamental concepts; signature management and effective countermeasures. Developing effective countermeasure starts with an in depth understanding of the physical interactions between the threat, the target, the countermeasures and their environment. A significant amount of this knowledge can be acquired using physics-based modelling and simulation tools such as TESS. One of the essential pieces for modelling engagements between a target and a threat IIR seeker is the capability to render realistic and accurate IR synthetic imagery of the scene observed by the threat seeker. SE-WORKBENCH-EO s ability to generate physically accurate multispectral synthetic environments addresses this need and has been integrated into TESS. The main focus of this report was to provide an overview of the coupling between TESS and SE-WORKBENCH-EO. The collaboration between TTI and OKTAL-SE first focused on the coupling of TESS ASM(IR)+ and SE- WORKBENCH-EO for the development and effectiveness assessment of naval countermeasures. The next part of this ongoing collaboration will be to build on this effort and potentially integrate SE-WORKBENCH-EO with other TESS IIR simulators such as TESS ILAPS (Integrated Land Active Protection System) and TESS SAAM(IIR) (Surface-to-Air and Air-to-Air Missiles). The advanced IR synthetic environment capabilities of SE-WORKBENCH-EO now provide the possibility to integrate other systems in TESS such as imaging DIRCM, missile approach warning systems (MAWS) and airborne/seaborne IR search and track (IRST) systems. The coupling with SE-FAST-IR now opens the possibility to use TESS with SE-FAST-HWIL in a hardware-in-the-loop configuration in support of DIRCM, MAWS, IRST and other EO/IR sensor development. 13

14 REFERENCES [1] rutanksmoke.jpg ( )., < (6 May 2014 ). [2] MASS_firing.jpg ( )., < (6 May 2014 ). [3] AC-130_Training.jpg ( )., < 130_Training.jpg> (6 May 2014 ). [4] DIRCM_big_01.jpg ( )., < (6 May 2014 ). [5] 02infraredtank.jpg ( )., < (6 May 2014 ). [6] Alt_FLIR_Ship1.jpg ( )., < (6 May 2014 ). [7] MWIR_comm.jpg ( )., < (6 May 2014 ). [8] Tremblay, J. P.., Viau, C. R., A MATLAB/Simulink methodology for simulating dynamic imaging IR missile scenarios for use in countermeasure development and evaluation;, 17 September 2009, 74830K 74830K 11. [9] Cathala, T.., Latger, J., Improvements of SE-WORKBENCH-EO for the infrared real time rendering of outdoor scenes, presented at 6th International Symposium on Optronics in Defence and Security, 28 January 2014, Paris, France. [10] Simulink., Wikipedia Free Encycl. (2014). [11] What Is an S-Function? - MATLAB & Simulink., < (16 May 2014 ). [12] Introducing MEX-Files - MATLAB & Simulink., < (16 May 2014 ). [13] How S-Functions Work - MATLAB & Simulink., < (16 May 2014 ). [14] Simulink Engine Interaction with C S-Functions - MATLAB & Simulink., < (16 May 2014 ). [15] Templates for C S-Functions - MATLAB & Simulink., < (16 May 2014 ). [16] S-Function SimStruct Functions - MATLAB & Simulink., < (16 May 2014 ). [17] DWork Vector Basics - MATLAB & Simulink., < (16 May 2014 ). [18] OKTAL-SE., SE-TOOLKIT SDK: Programming Manual. [19] OKTAL-SE., SE-TK-PARTICLES SDK: Programming Manual. [20] C MEX S-Function Examples - MATLAB & Simulink., < (16 May 2014 ). [21] Build MEX-function from C/C++ or Fortran source code - MATLAB mex., < (16 May 2014 ). [22] Include S-function in model - Simulink., < (16 May 2014 ). [23] Viau, C. R., D Agostino, I.., Cathala, T., Physical Modelling of Naval IR Decoys in TESS and SE-Workbench for Ship Self Protection, presented at 10th International IR Target and Background Modelling & Simulation Workshop, 23 June 2014, Ettlingen, Germany. [24] Rheinmetall MASS - IIR / Laser -Screening - YouTube., < (15 May 2014 ). 14