Restricción para el disfrute del espacio público

The first and most central functional element in Figure 3.1 is the MLE database manager and its associated central database, denoted in the figure by (a) and (b), respectively. This database is a storage and retrieval mechanism housing a large collection of data, and it also serves as the communication hub of the system from where data are continually transmitted between the functional elements of the system — all functional elements therefore communicate with one another via this database. The associated database manager is responsible for managing updates to or facilitating queries for MLE operations-related data as well as processing and converting output data from one functional element to the correct input data format for another.

The HMI in Figure 3.1(c) is the link between man and machine; it enables a human operator to communicate with the functional elements of the system by providing him with an interactive graphic user interface which displays the situation at sea in real time together with the results generated by the other functional elements on a series of computer screens. It is advocated that this transfer of information should be implemented in the form of so-called data streams, which are strings of bits associated with identifiers that allow an operator to request specific data in real time. These streams may be fed live to the HMI and, depending on whether or not they are activated by the operator, may be visualised on a display screen. For instance,

[VesselIdentifier; (Long,Lat); Course; Speed] = [0020; (−35.83, 18.90); 120.3; 18]

is an example of a snapshot from a data stream which may be visualised in a user-friendly fashion via the HMI for the benefit of a threat detection operator, while

[VesselIdentifier; Status; FlagCode]= [0113; F lagged; ZoneInf raction]

is an example of a data stream snapshot which may be displayed similarly via the HMI for the benefit of a threat evaluation operator. Here, the “VesselIdentifier” data field is used as a unique identifier for attaching information to a particular VOI.

In this system architecture, it is proposed that, as the MLE threat detection and threat eval- uation processes tend naturally to function closely together, so too should the MLE resource assignment operators in Figure 3.1(d) work closely together with the MLE threat detection and threat evaluation operators. In certain cases, however, where there are a very limited number of MLE human resource operators, or if a certain human operator has considerable expertise in all three MLE areas, one or a small number of operators may very well be responsible for decision making in all aspects of MLE.

The external threat detection infrastructure functional elements in Figure 3.1(f) comprise all devices used, directly or indirectly, for detecting and tracking maritime objects in specified areas of the ocean as well as for gathering kinematic information associated with these objects, such as their sizes, locations and velocities. Examples of such threat detection devices are land-based, aerial or vessel-based radars, infrared cameras, video surveillance cameras and observations reported from active naval, aerial or reconnaissance MLE resources.

These measured attributes of VOIs, obtained from the sensor systems, are fused together by the attribute management system in Figure 3.1(e) to create so-called system tracks and derived attributes associated with each of the VOIs within the jurisdiction area of the coastal nation [49].

A system track is a record of the historical displacement of a VOI in space from its detection to the present time, while a derived attribute of a VOI is a parameter value that is computed from the measured attributes of the VOI, such as its acceleration or rate of changing course. Based on these attributes, the system also provides future VOI trajectory estimates to the DSSs. Track stitching methods and Markov models are examples of techniques that may be employed to assemble system tracks [49].

This fusion process is conducted by employing all data and knowledge associated with a VOI and results in a combination of these elements into a single consistent, accurate, and useful data representation for that VOI. Successfully implementing the fusion process is critical in cases where VOI input data are obtained from multiple threat detection infrastructure sources which may individually yield slightly or significantly different perspectives on information. The JDL data fusion model, for example, is perhaps the most widely-used method for categorizing data fusion-related functions [2]. This model has been shown to be useful across multiple application areas and is typically intended to identify the processes, functions, categories of techniques, and specific techniques applicable to data fusion.

In order to filter VOIs from the multitude of maritime objects tracked at sea within the jurisdic- tion area of a coastal nation, threat detection operators are tasked with analysing these objects in respect of the physical and kinematic information attached to them, and assessing whether their behaviour is deemed unexplained, suspicious or threatening (to some extent). Following this analysis, the status of a maritime object may be designated as either a VOI or a maritime object of no interest. This procedure must be carried out on a continual basis as the situation at sea unfolds, typically involves a large number of maritime objects and may therefore easily overwhelm a human operator. The aim of the VOI flagging functional element in Figure 3.1(j) is to assist human operators in their threat detection decisions by providing automated decision support for identifying and tracking suspicious maritime activities.

An adaptive early-warning maritime surveillance DSS capable of supporting a maritime oper- ator in his decision making process with regard to various threats and scenarios was proposed by du Toit [49]. Here, so-called fusion, rule-based system, activity classifier and data mining components are incorporated into the proposed DSS. Moreover, the HMI component in this DSS provides the operator with relevant information as well as a mechanism by which the operator may provide feedback to the system. The fusion component, for instance, processes the infor- mation received from threat detection devices, such as radars or infrared cameras, in the form of vessel track updates, which are stored in an operational database. This operational database is directly utilised by the rule-based system component which processes the data as they become available and aims to identify potentially threatening activities amongst the observed vessel tracks according to certain pre-configured sets of rules, such as rules pertaining to zone infrac- tions, proximity of vessels or anomalous activities. Data from the operational database are migrated to a central database after being cleaned and transformed into the necessary format. As tracks become available in the central database, they are processed by the activity classifier component. The work in [49] is strictly limited to the maritime domain and the primary source of data is spatio-temporal AIS data.

The input data provided by the external threat detection infrastructure functional elements may not always provide all the information necessary to facilitate good inferences with respect to the potentially threatening nature of a VOI. The external MLE threat evaluation infrastructure functional elements in Figure 3.1(g) comprise a collection of physical devices which may be used, when requested by an operator, to collect more detailed and/or accurate information related to a particular VOI. Scouting resources (such as unmanned airplanes) dispatched to specific maritime zones in order to establish line-of-sight contact with respect to targeted VOIs,

3.1. Functional elements in an MLE environment 59

and advanced radar systems whose primary function is effectively to zoom in on particular VOI locations, are examples of such devices.

The purpose of the VOI threat analysis DSS in Figure 3.1(i) is to assist a threat evaluation operator in classifying and quantifying the potentially threatening nature of VOIs, by providing automated decision support for analysing the behaviour of VOIs based on the information col- lected during the threat detection process and making automated inferences with respect to the nature and level of threat posed by VOIs. This process therefore only involves system tracks of VOIs and not the tracks of maritime objects deemed of little or no interest. Ultimately, the output of such a DSS consists of a vector associated with each VOI containing entries which correspond to estimated probabilities with which the VOI in question belongs to a finite number of pre-determined threat classes, an unknown threat class and a false alarm class. Various math- ematical models may underlie this process of quantifying these probabilities. Bayes’ theorem may, for example, be used as a framework for introducing newly observed information [9, 36]. The MLE resource assignment subsystem in Figure 3.1(l) is responsible for assisting human operators with decisions related to the utilisation of MLE resources in both time and space. These MLE resources are generally either allocated for the purpose of intercepting VOIs at sea (such resources are said to be in an active state) or are otherwise strategically allocated to certain patrol areas at sea or moved to bases until needed for future law enforcement purposes (such resources are said to be in an idle state). Whereas the MLE response selection DSS in Figure 3.1(m) deals with the allocation of active MLE resources, the idle MLE resources management in DSS Figure 3.1(n) deals with the allocation of idle MLE resources. These two functional elements should operate in perfect real-time synchronisation with one another. Tasks performed within the idle MLE resources management DSS involve, inter alia, the config- uration of patrol schedules, the planning of repair and maintenance of resources and the design of effective scouting strategies. This DSS should combine the expertise and experience of human operators with large amounts of historical data (e.g. probability distributions of specific threat- ening activities occurring in specific zones of the jurisdiction area over specific time intervals) and various mathematical models for scheduling idle MLE resources in both time and space. Because occurrences of newly detected VOIs are stochastically distributed in space and time, it is crucial to manage idle MLE resources in such a way that leaves them, a posteriori, in central positions of relative readiness so that they may be dispatched rapidly when shifted into an active state.