This section provides the reader with a high-level overview of the information flow of the TEWA simulation model developed in Matlab. After reading this section, the reader should be better equipped to understand the simulation source-code in Appendix C as well as the detailed ex- planations of the TE and WA subsystems which follow in the next chapters. The source-code is included in this thesis with the main goal of assisting future work. As such, the source-code may be ignored by the reader with no break in continuity or lack of understanding.
The simulation developed in this thesis may be classified mainly as a discrete-event Monte-Carlo simulation. The discrete-event simulation is selected, not necessarily because the system cannot
End Start 1. Initialise Scenario 2. Generate and Discretize Threat Tracks 3. Evaluate Threats
(More detail provided in Chapter 5)
4. Assign Weapon Systems
(More detail provided in Chapter 6)
5. Publish Results
• Create data structures for threats, DAs and WSs • Place WSs
• Place DAs
• Visualise the scenario setup
• Use threat waypoints to generate realistic flight path • Determine speed at each point threat will be conducted • Discretise the continuous target track into intervals representing the TEWA cycle time
• Determine if threat is hostile or unknown • Calculate derived attributes
• Execute the selected TE process
• Calculate threat model value for each threat • Fuse separate threat values
• Generate SSHP volume equation for each WS • Utilise flight path prediction module
• Execute the selected WAM(s)
• Solve (optimise) the assignment of WSs
• Determine outcome of scenario • Calculate performance metrics • Send results to the HMI
4.4. Simulation Model Architecture 65
be modelled as a complex continuous process, but rather by virtue of the fact that the technolo- gies employed (update rate of sensors) limit the observation of the Area of Responsibility (AOR) to a number of time-indexed, discrete events.
The architecture of the main programme has an open-loop structure (i.e. feedback is not appar- ent) as may be seen in Figure 4.7. It is important to note, however, that this is only possible within a simulation environment, mainly because the threats are not reactive in the sense that they will react (execute evasive manoeuvres) if a WS fires upon them. The threat tracks are therefore fixed from the beginning of the simulation. Consequently, the threat values are calcu- lated for an entire scenario and the resulting threat value matrix is fixed for the whole scenario timeframe, thereby eliminating the need for feedback which would overcomplicate the software development.
A high-level layout of the logic flow in the simulation is depicted in Figure 4.7. More details re- garding the implementation of these sub-routines are provided below, using the same numbering as in the figure:
1. Initialise Scenario. The initial stages of the programme includes creating data structures for all the threats which contain their attributes and kinematic data. Each threat track is defined by a set of input coordinates12 as provided by the user; the velocity at each of these coordinates and, lastly, the most probable WRL, which is defined by a FTTF and LTTF. If the WDP is known, this is also included, but only for evaluation and traceability purposes — it has no logic role in the programme.
The parameters of the WSs and DAs are also initialised during this stage in order to construct a simulation scenario. The location of each WS and DA is defined by x and y coordinates. The z coordinate is assumed to be zero. The DAs also have priority values assigned to them, as defined in Table 4.2. The WSs, on the other hand, have a maximum range, minimum range, setup time, ammunition count and cost associated with them. These initial data structures contain the sole inputs for the rest of the simulation.
A scenario generation algorithm was suggested by Van der Merwe [215], in which a deter- ministic approach is followed to place DAs and a heuristic is used to place WSs in order to sufficiently protect the DAs. In reality, however, the placement of DAs and WSs are typically characterised by various constraints (e.g. terrain conditions, building and safety regulations and even commander intent), though it is rarely possible to quantify these ex- actly. The placement of airfields have different requirements than, for instance, a command centre, and the evaluation of scenarios that are not realistic will not result in meaningful results. This simulation therefore requires manual input to define the positions of WSs and DAs, thereby allowing for the testing of certain specific scenario set-ups only.
Furthermore, as explained in §4.2.4, stochastic noise is added to the input waypoint co- ordinates of aerial threats in order to simulate pilot behaviour and sensor measurement inaccuracies. This random noise is added to the set of input coordinates before the tracks are generated using B-splines. These input values are finally visualised using Matlab’s visualisation toolbox.
2. Generate and Convert Track to Discrete Time. By utilising the input coordinates, B- splines are generated to serve as tracks for the threats. The default functions used for spline generation, as provided by Matlab, proved inadequate since the input coordinates of a specific threat are not necessarily unique or monotonic. An alternative toolbox was
12Each input coordinate is specified by a x, y and z coordinate, but may be interpreted, respectively, as latitude, longitude and altitude, without loss in meaning.
therefore implemented as may be seen in Appendix C. These splines are subsequently discretized according to the number of TEWA cycles as specified by the user — using the piece-wise polynomials of the splines in order to determine function values (threat positions) for specific points in time.
3. Evaluate Threats. All results of the previous two stages are directly sent to the TE sub- routine for further evaluation. Feedback to the track generation module is therefore not required in the simulation environment, as will typically be the case in practice. This stage is further clarified in the following chapter.
4. Assign Weapon Systems. This stage is essentially where the reactive WA process is exe- cuted. More detail on this stage is provided in Chapter 6.
5. Publish Results. The final stage of the simulation involves saving the results by printing them to files and calculating the relevant performance metrics. The saved information may then be used for further analysis in order to evaluate the performance of the various algorithms and models. Finally, the information for the specific scenario is sent to the HMI environment to be used for visualisation and for validation purposes in conjunction with domain experts.