TRIREME Commander: Managing Simulink Simulations And Large Datasets In Java

Transcription

1 TRIREME Commander: Managing Simulink Simulations And Large Datasets In Java Andrew Newell Electronic Warfare & Radar Division, Defence Science and Technology Organisation Abstract. The Tactical Radar and InfraRed Engagement Modelling Environment (TRIREME) is a flexible framework for simulating military engagement scenarios in Simulink. TRIREME simulations are used to determine the effectiveness of countermeasures through experimentation and analysis. Simulink does not offer an effective environment to analyse complex models in a range of scenarios, as the simulations do not run fast enough. The models also produce large amounts of data that are difficult to manage and view efficiently. The TRIREME Commander (TC) was created using Java to manage the execution of simulations and examine their resulting large datasets. Development of the application overcame issues of manipulating Simulink simulations and limitations of Java s memory model when analysing data. The TC interfaces with Simulink simulations compiled using Real Time Workshop (RTW). Utilising tuneable parameters specified in a MATLAB MAT-File, the application can modify simulations on an individual run basis. The datasets created by an executed simulation are read into application memory for fast access to achieve real-time graphical displays. The large datasets posed problems in Java s memory model during analysis. Data structures using object-orientated design proved too memory intensive. To counter this, a simple array data structure was implemented to reduce overheads and keep access times low. Java Out of Memory exceptions are minimised by reducing precision to acceptable levels and selectively storing data. The TC is a flexible and easy to use application, allowing both the simulation and analysis of TRIREME configurations to be separated from the development environment. TC runs compiled Simulink simulations quickly and implements a slim memory model to view and analyse results in real-time. Importantly, compiled simulations and the TC can be deployed to users and clients with ease and minimal overheads. 1. INTRODUCTION In electronic warfare (EW), engagement simulation and modelling is a valuable tool in the analysis of countermeasures. Simulation to determine the viability and effectiveness of electronic countermeasures and techniques supports and enhances the Australian Defence Force (ADF) [9]. Importantly, the analysis of simulations can support field trials of countermeasures, allowing for pre-planning of limited trial resources. Simulink is an existing modelling and simulation environment from MathWorks Inc. The environment is integrated with MathWorks MATLAB program to provide graphical modelling, simulation and analysis of generic dynamic systems. Simulink, being necessarily broad in application scope, lacks certain features required by Defence Science and Technology Organisation (DSTO) EW simulations. The Tactical Radar and InfraRed Engagement Modelling Environment (TRIREME) was developed in 2004 by the Electronic Warfare and Radar Division in DSTO to tailor Simulink to the specific requirements of EW simulations. The TRIREME framework defines rules and common functionality to the Simulink environment. The framework is designed to provide for development of models in an object oriented manner with high reusability [3]. interface to manipulate simulations and easier portability to other developers and clients than Simulink provides. The TRIREME Commander (TC), a Java application, has been developed to solve these issues, streamlining both the experimentation and analysis phases of simulation development. To meet TRIREME s requirements in experimentation and analysis, both phases are performed in the TC application, external to the Simulink environment and TRIREME framework. To realise the goals in an external application, the Java environment needed to manage, interact with and control TRIREME-based Simulink simulations and overcome issues found in Java s memory model when analysing the resulting large data sets. 2. SIMULINK SIMULATIONS USING TRIREME The fundamental purpose of TRIREME is to create a developer friendly environment in Simulink that promotes ease of use and development. An example TRIREME framework layout is shown in Figure 1. The TRIREME framework s customisation of the Simulink environment greatly enhances the development of simulations. After the development of models, Simulink does not prove as suitable for TRIREME s requirements in the experimentation and analysis phases. As a framework using Simulink, TRIREME is limited in the areas of experimentation and analysis due to the complex and broad nature of Simulink. TRIREME requires faster execution time of simulations, a simpler

2 simulations replayed and outcomes reviewed. Simulations are compared and contrasted, and batch runs of simulations are required to build an overall view of effectiveness. Figure 1: Example TRIREME Simulink framework layout [1] 2.1 The Experimentation Phase In Simulink TRIREME simulations need to be able to be used and run by developers, EW specialists and end users alike. The interfaces, usage and deployment of simulations need to be as undemanding as possible. Simulations require fast execution and the output data to be stored for future analysis. Parameters within the TRIREME models are modifiable to alter the simulation to test countermeasures and strategies. In order to compare and validate simulated measures, multiple runs of varying simulations are required. Simulink provides an environment for experimentation, which only meets some of the TRIREME framework s requirements. Variables within the models can be modified before, or even during, simulation runs [8]. By default, Simulink provides no central or standard means of access to all simulation parameters. The TRIREME framework provides control over variables by utilising a Simulink Graphical User Interface (GUI) to modify variable parameters of a Simulink block, or component. This is known as a mask. Despite employing the GUI masks, parameters can only be accessed and modified by traversing through all masked blocks in the simulation. This requires a level of expertise with Simulink not assumed to be present in all end users of TRIREME models. In order to deploy a TRIREME simulation to clients or other users, MATLAB and Simulink licences are required to take advantage of the full functionality available. The programs are very powerful and provide an excellent experimentation environment that can be very daunting for novice users. Distributing TRIREME models in Simulink also allows access to areas of the model that end users should not be allowed to access or modify. 2.2 The Analysis Phase In Simulink The analysis phase of TRIREME simulations is vital in producing simulations for the ADF. The analysis process validates models, suggests new countermeasures and improves the knowledge of the ADF [9]. In this phase, data from TRIREME simulations is required to be managed and plotted, Simulink provides the ability to analyse simulations during run time. Any part of a simulation can be scoped, monitored or output. Since Simulink simulations may not run in real time, the analysis is limited to the speed of the computer running the simulation. The resource intensive nature of Simulink and its licensing requirements may prevent multiple simulations from running and hence analysis of multiple runs becomes infeasible. The examination of completed simulation run data in MATLAB is a viable alternative to analysing running simulations in Simulink. MATLAB commands can be written to create batch runs to iterate through changing parameters. The resulting data can be placed directly into MATLAB or written to files for storage. The data can be plotted using the powerful plot tools included with MATLAB [6]. The analysis phase in MATLAB thus requires an expert level of knowledge that cannot be expected of all end users of TRIREME models. 2.3 Analysis In A Post Processing Tool A Java Post Processing Tool was developed originally to meet the TRIREME requirements of data analysis. This tool became the basis of the TC application. The TC analysis application requirements for TRIREME were: Ease of use by clients and TRIREME developers. Deployable to clients and TRIREME developers. Ability to compare and contrast simulation results. Ability to view simulation results in real time. The development of the original tool into a complete experimentation and analysis application was driven by the need to meet the TRIREME requirements unfulfilled by Simulink. Java was selected for its ease of portability and development. To effectively use Java to experiment with TRIREMEbased Simulink simulations, investigation had to be undertaken to enable Java to control the simulations. When analysing the resulting data, a solution had to be found to the memory issues arising from problematic storing and manipulating of large amounts of data in the Java environment. 3. MANAGING SIMULINK SIMULATIONS IN TRIREME COMMANDER The TC is designed to be a viable alternative to managing and running TRIREME-based Simulink simulations. This is achieved by the TC meeting and

3 exceeding the functionality of, and providing extra benefits over Simulink execution. The aims of the experimentation phase in the TC are: To modify variable parameters of simulations. To execute simulations utilising default or user defined parameters. To provide an ability to create batch run patterns (i.e. Coverage Diagrams). To run any Simulink simulation created using the TRIREME framework. To organise output of simulations in a meaningful and accessible manner. The application has to be able to interact with Simulink simulations and provide a general interface to manipulate any number of varying parameters. The Real Time Workshop Simulink extension provides a means to meet all our requirements by creating a better execution environment than Simulink. 3.1 Real Time Workshop And Tuneable Parameters Real Time Workshop (RTW) is a Simulink extension that compiles Simulink simulations into standalone executable files [7]. This is performed by converting the Simulink simulation into C-code, to be then compiled and executed. Simulation parameters can be accessed in the compiled C-code via tuneable parameters created with the executable file. A tuneable parameter is a simulation parameter specifically marked in the simulation to be accessed and modified in the compiled executable file. Examples of parameters that are made tuneable for users to modify in the simulation are: Threat Initial Position, Aircraft Initial Velocity, Aircraft Type, etc. MAT-File. The display information added is vital for the creation of the dynamic GUI to modify parameter values in the TC application. The display information is gathered from the GUI masks used to present the parameters to the developers in TRIREME. 3.2 Dynamic Graphical User Interface Creation To enable the user to modify simulation parameters in the TC, an interface to the tuneable parameters stored in the MAT-File is required. To facilitate greater ease of use, the TC creates a GUI to display the tuneable parameters. The GUI is dynamic in the content and controls it displays to the user, based on the tuneable parameters contained in the MAT-File. The first step in creating the dynamic GUI is embedding the required display information into the MAT-File for the application to read. Each tuneable parameter can be displayed as a numerical edit field, combo box list or a check box. Developers of TRIREME simulations select the required type for each tuneable parameter. Depending on the variable type, information such as array size for numerical edit fields or list contents for combo box lists is additionally required. The MAT-File reader in the TC parses the created MAT-File and extracts the required information for each parameter. Each GUI component is recreated in Java using the type and value information stored in the MAT-File. The components are then laid out on screen for the user to access. Figure 2 illustrates a dynamic GUI for parameter modifying, created from tuneable parameters in a MAT-File. When the executable file is created, all tuneable parameter values are defined in an associated MATLAB MAT-File. The executable file reads the associated MAT-File to obtain the current values of the parameters to use during the simulation s execution [7]. Utilising the compiled C executable and the associated tuneable parameters, the TC application can start and manipulate the running of a Simulink simulation. The MAT-File is an open standard defined by MathWorks [5] and can be parsed into the TC application via specifically written code. A standard RTW MAT-File contains information about the parameter and its value. By manipulating the creation of the MAT-File in MATLAB, extra data regarding the parameters can be written. This extra data provides details on input and output files for the simulation, parameter defaults and, importantly, display information. A DSTO developed MATLAB script automates the process of adding the additional information into the Figure 2: Dynamic GUI with edit box values, a combo box value and a check box value displayed Modified values are then written back into the MAT- File at the user s request. When the compiled Simulink simulation is next executed, the new values from the MAT-File are read to initialise the parameters within the simulation. By utilising the RTW compiled Simulink simulations and their associated tuneable parameters, the TC application provides a robust, easy to use and flexible experimentation environment. TRIREME-based

4 Simulink simulations can be executed from within the application either as single runs or batch run patterns, set by modifying tuneable parameters. Utilising Java s threads, multiple simulations can be executed and managed at the same time, meeting the requirements of TRIREME experimentation. 4. DATA ANALYSIS IN TRIREME COMMANDER Data resulting from TRIREME-based Simulink simulations are defined by two categories; description and summary. The description data describes the simulation at each time step. Every item in the simulation, every position, and each informative data signal is recorded. The summary data presents single values that are recorded or calculated at the termination of the simulation and summarise aspects of the run. Summary data files can include multiple runs when performing batch runs. The TC application presents the data in a meaningful manner to the user for analysis. The data is presented in a variety of plots. Plan Plots shows a bird s eye view of the simulation for reference and requires positional data for all items at every time step. Data Plots graph any data on a plot against the simulation time. Coverage Plot displays summary information based on a coverage area manipulated over multiple runs. A large Coverage Plot example is shown in Figure 3. Creation of this plot involved 10,830 simulation runs, which produced 32,492 data files totalling 5.89GBs of data. Real-time viewing and analysis of results is important to obtain a clear picture of the simulation. The Java data structure developed to store in the data in application memory must provide fast access to ensure all plots are able to update in real time. Multiple plots can be synchronised and viewed from multiple simulations at the same time. The data structure implemented must be scaleable to hold multiple large data sets for all displayed plots. The Java platform is designed with portability as a priority. The Java Virtual Machine (JVM) that ensures this portability also limits the amount of system memory a Java application can utilise [4]. It is important, when reading data sets of large sizes, to carefully manage the data, to avoid reaching or exceeding this limit. An Out of Memory Java exception is thrown when this limit is surpassed and unpredictable behaviour of the application follows. The data structure used must minimise the likelihood of the memory limit being reached. 4.2 A Data Structure For Handling Large Data Sets The information used to visualise the simulation lends itself very well to Java s object oriented approach. Each piece of information is encapsulated in a relevant object for every time step of the simulation. The first approach developed to read in TRIREME data sets involved an object oriented data structure. The objects were created encapsulating data for each simulation object at each simulation time step. Access to the data is performed by knowing the desired object and information required. When reading in large files, it became apparent that an object orientated approach did not scale up to the sizes required. A TRIREME simulated EW engagement can run up to and beyond 2000 simulated seconds, depending on the complexity of the scenario. With typical simulation time steps of seconds, each recorded signal and item in the simulation contains at least 10,000 data entries. The memory overheads in creating each object for each item at each time step quickly become infeasible. Figure 3: A large Coverage Plot in the TC All plots require the large data sets of the simulation results to be stored in the Java application s internal memory. The size of the datasets is the cause of memory and speed issues, which can affect the performance and usability of the analysis tool. 4.1 Analysis Requirements To ensure the simulations can be deployed to and analysed by any developer or client, data resulting from TRIREME based Simulink simulations is stored in a flat file database. The files are comma delimited, ensuring the data is platform independent and easy to read in numerous other applications. An approach to storing data in Java s memory was required that did not involve object memory overheads. The data structure has to allow fast access to the stored data, to keep the plots updating in real time. It was determined that a simple array data structure was the best fit for these requirements. Dismissing object orientated design altogether, data is stored in a two dimensional array of Java primitive values. Rows of the array are accessed by the time step of the simulation. Columns are accessed through a known data order. Each item in the simulation has an indexed position in the array. The item s data is then stored in a pre-determined order from the indexed position. Figure 4 shows how an item s index and the required data s offset can be used to obtain any pieces of data in the data array structure.

5 Figure 4: 2D data array access using item index and data offsets Access to arrays using direct indexing is performed in O(1) time [2], maintaining the requirement for fast access time. The size of the data array to allocate can be determined before storing the data by quickly reading the size of the data files. The extra time required for the pre-allocation of the array s size is offset by the improvement in memory. When plotting or visualising the simulation data, not all the recorded data is required. Only the required information is read into Java s memory. If a new plot is requested for an open simulation utilising un-read data, the data needs to be re-read to store the required information. Care is taken to ensure that all plots for a single simulation read from the one data array in memory. Data for a simulation is only stored in the one location and shared between the plots that require it. 4.3 Assumptions And Compromises Storing the information in the array data structure assumes that the time required setting up the structure is offset by the resulting memory efficiency, as the set up of the data array structure requires two reads of the files. Where the time taken to read-in data is notably large, progress bars are used as a visual feedback to users. A compromise in the precision is made to reduce the data storage memory requirements. Data is stored as Java floats, requiring only 4 bytes of storage. Storing the data as Java doubles requires 8 bytes for each value 1. This loss in precision is acceptable because data values are only used in graphical displays. The screen operates in discreet integer whole values for pixel positions. All data positions are converted to the correct integer pixel position for display. Any data items within a small range of each other become mapped to the same pixel on screen. The range of values which are mapped to the same pixel when plotted on screen depends on the plot scale and screen resolution. For the current plot in the TC application, this compromise was deemed satisfactory. This decision may be reviewed in the future, depending on the long term use of the application. The data files are not modified and still retain their original precision. 1 Memory sizes of Java primitives are JVM dependent. These results were calculated on a win32 implementation of Sun s JVM, version 1.6.0_03. If memory problems still persist as data set size increases, the JVM itself can be made more efficient. The size of memory the JVM can obtain from the system can be increased to use more resources [4]. This is currently implemented as a user definable option in the TC. Third party JVM s can also be used to run the TC application. A third party JVM may implement memory allocation with greater efficiency than the standard JVM released by Sun Microsystems Inc. An example of a JVM that has been successfully used with the TC application to increase memory performance is BEA System s JRockit [1]. 5. FUTURE WORK The TC application has proven valuable in the experimentation and analysis of TRIREME-based Simulink simulations. The successful integration of compiled TRIREME Simulink simulations into the TC is opening up to further possibilities for integration with Simulink. The future of the TC is driven largely by the needs of clients when running and analysing simulations. The power of TC comes from the ability to develop extra functionality to meet the exact requirements of users. 5.1 Expanding Simulink Interoperability It is common in the Defence market for simulation models to be shared. Models developed in Simulink that do not conform to the TRIREME framework cannot easily be accessed in the TC. Investigation is required into the possibility of interfacing the TC application more directly with MATLAB. It may be feasible to create dynamic scripts to execute non-trireme simulations from TC with or without RTW compilation. Decoupling the TRIREME framework from the TC would allow for the application to be shared and utilised by more Simulink simulation developers. 6. CONCLUSIONS The TRIREME Commander (TC) is a flexible and easy to use application, allowing both the simulation and analysis of TRIREME-based Simulink simulations to be separated from the development environment. The TC overcomes limitations found in the experimentation and analysis phases when using the Simulink environment. In the experimentation phase, the TC was developed to control Simulink simulations. This was achieved by utilising RTW compiled Simulink simulations. Using the tuneable parameters, the TC Java application is able to modify and control the simulations. All the available parameters are presented in a central and easy to use GUI. This provides all developers and clients with immediate and total control over the simulations. When analysing simulation results in Java, the Java memory model becomes problematic with the large data sets required. A data structure to store and access data was developed to meet the needs of EW simulation

6 analysis. The implemented data structure has proven robust and scalable when viewing large and multiple data sets. Both the compiled Simulink simulations and the TC can be deployed to developers and clients with no licensing or other environmental overheads. Simulink simulations can be accessed, controlled and analysed with ease by any non-technical user through the use of the TC. REFERENCES 1. BEA Systems. (2006) BEA JRockit s/bea_jrockit_entjava_business_wp.pdf. 2. Goodrich, M. T; Tamassia, R. (2001) Data Structures and Algorithms in Java (Second Edition), Data Structures and Algorithms in Java (Second Edition), Wiley College. 3. Hatfield, B; Reynolds, S; Hermans, B. J. (2005) The Tactical Radar and InfraRed Engagement Modelling Environment (TRIREME) SimTecT Simulation Technology and Training Conference. 4. Lindholm, T.; Yellin, F. (1996) The Java Virtual Machine Specification, Addison-Wesley. 5. MathWorks, T. (2007) MAT-File Format, doc/matlab/matfile_format.pdf. 6. MathWorks, T. (2000) MATLAB User's Guide, MATLAB User's Guide. 7. MathWorks, T. (2004) Real-Time Workshop User's Guide, Real-Time Workshop User's Guide. 8. MathWorks, T. (2000) Simulink User's Guide, Simulink User's Guide. 9. Mc Farlane, D; Kruzins, E. (2006) Australian Defence Simulation - Status, ralian_defence_simulation-status.pdf.