Jesus Garcia. Departamento de Informática Universidad Carlos III de Madrid Madrid, Spain

Transcription

1 *HQHULF6RIWZDUH$UFKLWHFWXUHIRU'HYHORSPHQWRI'DWD )XVLRQ6\VWHPV Juan A. Besada, Javier de Diego, Gonzalo de Miguel, Jose R. Casar Departamento de Señales, Sistemas y Radiocomunicaciones. Universidad Politécnica de Madrid. Madrid, Spain besada@grpss.ssr.upm.es $EVWUDFW This paper describes a generic software platform which can be used for simulation, prototyping and implementation of real time data fusion systems and for training of data fusion engineers. This platform is based on the definition of a set of asynchronous "data processing nodes" cooperating by interchange "lists of data". Those data processing nodes and the data they process are generic, being the data fusion engineer the responsible for implementing the actual data fusion algorithms and defining the interest pieces of data to be interchanged. This architecture has been successfully used for several real projects, such as a simulator of multiradar multitarget tracking systems, the optimization of monoradar filters, an image based tracking system, and a generic real time data fusion system for Airport surface surveillance. In the paper both the overall architecture and some of these examples are described..h\zrugv Fusion architecture, Distributed fusion, Real time fusion.,qwurgxfwlrq Much effort has been dedicated recently to the architecture of the data-fusion process. Specially useful, as a method for conceptualizing this process and due specially to the common language it imposes, is the Joint Directors of Laboratories (JDL) model[1]. This paper, on the other hand, recognizes this model is not too appropriate for an actual design of a data fusion system, as far as it imposes artificial boundaries among different data fusion levels which in real systems are done in a much more cooperative and integrated way. In [2] there is a description of the data-fusion process in terms of an architecture formed by several cooperating nodes in charge of different parts of the processing, as recommended in JDL guidelines. Although in that paper the data-fusion process is modeled as a data-fusion tree, in which the data are successively refined, the process in real systems is more similar to an oriented graph, in which potential feedbacks may arise, and with high level Jesus Garcia Departamento de Informática Universidad Carlos III de Madrid Madrid, Spain functions (like those in Level 4 Process refinement) may be extracting data and controlling many nodes of other levels, managing available resources,. Even within a same level it is not unusual to have feedback loops (e.g. bias estimation and cancellation in level 1), or parallel processing system sharing some data to enhance their functioning. So, from our point of view, a generic data processing system is composed of a set of cooperating nodes interchanging pieces of data following an oriented graph. Different nodes play different roles within the processing system, in order to accomplish the overall data fusion objectives. Therefore, a potential approach to data fusion system design could be defining a set of canonical nodes interchanging standard pieces of data. The problem of this approach is each data fusion problem usually needs different solutions in several stages (e.g. different ad-hoc nodes should potentially be defined for each system), and the pieces of data to be interchanged depend both on the data fusion problem, the available data sources (e.g. sensors, operator inputs, ), and additionally on the defined design (e.g. different data interchange may appear in distributed or centralized system). In other words, having a generic standard nodes and standard pieces of data could be interesting from an architectural point of view, but has problems to be applied to actual problems, related with different fusion levels, To solve this problem, in our software design we have extracted the common behavior of data processing nodes, which is: receive pieces of data from its sources; process these data, changing its internal state; synthesize pieces of data to be sent to its destination; and send these results to its destination. Additionally, we have extracted the common information in the pieces of data we are interested. The data fusion engineer, inheriting from this generic node and datum classes, would be able to define ad-hoc data fusion architectures, so that he could assume all data interchange problems are solved. He therefore may concentrate on the algorithms. Two different ways to 1 This work has been financed by CICYT under contract TIC

2 define a data fusion architecture are available: Use standard ( canonical ) nodes with predefined algorithms, selecting the potential competitive implementations of the same functional block (e.g. Kalman or IMM filters) through a Graphic User Interface, or define and implement new specific nodes using the available data fusion libraries as building blocks. The first method is useful for rapid prototyping and analysis of data fusion systems, while the second may allow for fine tuning of the data fusion architectures. We would concentrate on real time data fusion systems, in which data are referred to a timestamp set in accordance with a common time reference. Surely, the proposed platform may be extended for other problems, such as image fusion, but this has not been our objective. In the design and optimization of real time data fusion systems, and specially in systems concentrated in level 1, it is often important to perform both real time demonstrations with synthetic (simulated) data and also Monte Carlo simulations. Our platform tries to allow the data fusion engineer performing these demonstrations and simulations and being able to use the resulting designs in a real time system, using exactly the same code basis for the processing nodes. It also allows to distribute these nodes in several computers communicating through a local area network (or through the internet), or in several processes running in the same computer. In section 2 the overall system design goals are summarized. Section 3 concentrates on the description of the overall software platform and the definition of the basic architectural blocks. In section 4 some canonical nodes are described at a very high level. Finally, section 5 summarizes several systems currently implemented using this platform or in process to be implemented. It should be said this platform is not yet finished (and the idea is it will never be), but it is reaching a point in which it is proving to be useful for the rapid prototyping and simulation of multiple target multiple sensor fusion systems with different kinds of sensors. Higher fusion levels are not yet much explored. 'HVLJQJRDOV The design goal of our system are summarized in the following list: - Define a generic expansible architecture which may be used for very different real time data fusion systems employing different sensors and information sources, working at different levels of abstraction, This architecture must not impose artificial bounds in the data fusion process, allowing for both classical structures (distributed or centralized fusion, ) or adhoc designs. - Provide the data fusion engineer with software libraries to be able to easily build the desired nodes comprising standard functionalities of data fusion systems (e.g. tracking filters, coordinate conversions, associations/track initiation systems, reasoning systems, display presentation modules, ). The data fusion engineer will be able to build the desired system by first dividing the problem in a set of subproblems to be addressed, in a cooperative way, by the different nodes, and will build each of those nodes using the available data fusion libraries. - Define kinds of nodes through a canonical node comprising high level functionalities. This, together with the potential availability of several different implementations of a same functional block (e.g. Kalman or IMM filters may be tracking filters potentially usable for the same problem, CFAR or Bayesian detectors may compete in other problem, ) allows for the rapid redefinition processing in the nodes, through a Graphic User Interface (GUI). - Implementations of data fusion systems are tuned for a particular problem. The previous (GUI based) method for definition of the data-fusion system could be interesting for fast analysis of the problem, but very often non canonical solutions (i.e. non purely distributed or centralized fusion) should be explored to obtain all the benefits from the data-fusion process. This could be done both by trying to inherit the more abstract behavior of the data fusion node and coding an specific ad-hoc processing, or reusing parts of the available code from other systems (filtering libraries, association methods, ). - The interfaces among the nodes and the use of the libraries should be as simple and general as possible. Very high level abstraction is demanded, although the actual algorithms or models should detail the low level. The reason is we want several people (some of them under-graduate students) to use the platform as a means to learn about the overall data-fusion process, and also to be able to concentrate on one of the key problems, not needing to pay too much attention about nodes not under their responsibility. - The code must be, as far as possible, platform independent. Most of our background is in C programming under Unix systems, but in order to use some lower cost image processing libraries we have had to use Windows systems in some projects. We wanted to be able to have a same code basis for at least Windows, Unix (Solaris) and Linux systems. In order to do that, we are using standard C++, avoiding as much as possible using platform dependant libraries, or at least defining a high level common interaction layer masking actual platform 433

3 implementation details. Most of the coding is being done under Linux. C o r e o f d a t a - f u s i o n s y s t e m - The platform should allow three main modes of functioning: G U I C o n f i g u r a t i o n D B 1. Monte Carlo simulation: for numerical evaluation and validation of the overall system. D a t a - F u s i o n p r o c e s s R e s u l t s R e s u l t s a n a l y s i s 2. Real-Time simulation: should show the results of the data-fusion system in real time injecting synthetic or prerecorded data. 3. Real-Time operation: should be able to work in a networked workstation (or set of workstations) receiving real data. This requirement is somehow contradictory with the employment of non real time operating systems, but we think the code basis should not be difficult to be used under a real time operating system if necessary and additionally, in many cases, real time constraints are not so difficult to attain with general purpose operating systems. - In real-time operation, it should be able to split the overall data-fusion system into several cooperating processes, running either in the same computer or in several workstations. This allows the system to be scalable (to a certain extent). Normalized protocols and data formats should be used for this communication, which should be respected independently of the operating systems in the computers. 2YHUDOOVRIWZDUHSODWIRUPGHVFULSWLRQ The software we are describing is made out of four different functions: - The data-fusion system. - The graphic user interface. - Results Evaluation/assessment functions. - Real time displaying of results. They, and their interactions, are depicted in figure 1. D i s p l a y Figure 1. Overall platform description. The displaying and result analysis/assessment are completely dependent on the actual problem being addressed, and we have decided to perform them using appropriate tools, maybe platform specific. Currently, for results analysis/assessment we are using Matlab. Other tools such as SPSS or PV-Wave could also be used, as far as the approach used has been saving the results needed in a results database. Real time displaying function is not yet implemented in the system. To do something similar, we currently save the results to be displayed and replay them using Matlab. The GUI fills a database with parameters to define the actual data-fusion system mode of operation (real time, simulation, ), structure (nodes and its type), functional blocks of each node (types of filters, ) and parameters of each functional block (for instance, α and β values in an α-β filter or measurement noise covariance in a Kalman filter). Additionally, it may be used to define a simulated environment, composed of targets and other artifacts (clutter zones, ). The interface has been programmed using Motif library, it has a menu-based philosophy and some color codes allowing users the quick recognition of areas not yet defined in the system configuration. It may be run in any platform compatible with Motif. In our case, we have used it both under Solaris and Linux. There are two main components in the interface: menus and parameter forms. Both are defined using text files so any user can adjust them without any change in interface code. Menus are used to navigate in simulated environment (e.g. simulated targets) and nodes definition trees, deciding the functional blocks in effect. Parameter forms are used to pick up the parameters of these functional blocks. 434

4 Figure 3: Another example capture of the interface. Figure 2. Image capture of the interface. Figure 2 shows an example of the configuration of a simulated target whose trajectory is modeled according to flat earth trajectory model (spherical earth models are also available in other branch of the menu). When we select the flat earth branch, the spherical earth model branch is disabled (color coded in yellow). Before this selection, as far as the trajectory model had not been selected, this branch is coded in red (meaning incomplete). To configure some of the parameters of the flat earth trajectory model we press FE_Initial button in the menu, and the bottom parameter form is displayed, asking for trajectory initial time, 3D position and 3D velocity. After filling all parameters, the leaf in the menu changes its color code to blue (completed). Higher level in the menu (ideal trajectory in the example) change their color code to complete (blue) whenever all its branches change from incomplete (red) to completed (blue) or disabled (yellow). The target name ( blanco1 in the example) also changes from red to blue when all the target definition tree just contains completed (blue) or disabled (yellow) branches. (In this draft, the captures contain Spanish words, while the final ones will contain its English equivalents). The data introduced into each parameter form, the selections along the menu, and data such us the names of nodes and targets are stored in a database, enabling for the configuration of the datafusion system. This database is independent of Motif, and may be moved for parameterization of data fusion systems in operating systems not compatible with Motif, such as Windows. In figure 3 you can see some of the nodes available, those related with simulated sensors. The main part of the software platform is the data-fusion system. Functionally, it is composed of one process or a set of cooperating processes interchanging data. We will first describe the case with an only process in charge of the whole data-fusion process, and then we will extend this case to cooperating processes. From our point of view the data-fusion system is composed of a set of data-processing nodes interconnected (some are data providers of some others, which in turn may have data consumers). Structurally, therefore, a datafusion systems is a oriented graph of nodes interchanging lists of data. The interchanged data may be of any type required by the data-fusion system (i.e. measures, local tracks, sensor bias estimations, central tracks, sensor management orders, monitoring alarms, ), and have associated a time stamp and a payload including the desired information in the desired data format. In figure 4 the structural definition of an example data-fusion system may be seen. Radar A simulator Radar B simulator MF Radar simulator Radar control orders plots plots plots Radar Management tracker tracker tracker tracks tracks tracks tracks Track fusion Central tracks Data recorder Figure 4: Example of simulation of data-fusion system The kind of structure we are talking of is similar to that in ROOM, although here we have tried to design a much more simple environment, enabling the modes of operation and methodologies mostly used in data-fusion systems. 435

5 This structure may not be changed once the process starts running, it is static, although pseudo-dynamic structures might be defined by making some nodes behave as switches, letting data pass or not, enabling then for immediate change of the data flow, and therefore of system apparent structure. In this example you may see the potential appearance of feedback loops (sensor management in this case, in general part of process refinement). In our system the nodes are activated asynchronously, whenever time reaches a waking time of his node. Then, the node extracts all the available data from its sources (note certain nodes may not have sources attached), process these data, changing its internal state, and finally makes the necessary results available for its destination. It does not mean it sends the data after the processing to the consumers, but instead it saves it in an internal queue of data which will be collected by consumers when they are activated, at their respective waking time. The communication process is performed in a way ensuring all data are received once and only once by each of the consumers. s processing may not be pre-empted by others (this simplifies inter-nodes communications), which may result in a node not being executed at its waking time, but slightly later (provided the data-fusion engineer design may be performed in real time, otherwise overload of the whole data-fusion process may be induced). It should be noted that this kind of functioning, for the case of Monte Carlo simulation, could lead to idle processing times (those in which the processor is waiting until time reaches the waking time of one node). This will make simulations too slow. To solve this problem, the clock used in this mode is synthetic, and the system does not wait until it reaches the lowest waking time, but instead moves the time to this waking time. In fact, several clock types should be defined, one for real time operation, another one for deferred operation, and a final one for Monte Carlo simulation, as described. Regarding Monte Carlo simulation, a key point in it is the number of iterations (repetitions) in the Monte Carlo loop, which is also taken from the system configuration. In figure 5 a high level data-fusion pseudocode, mostly resuming previous description, is included.!" # $ % & ' ( ) * '+," - % & ' ( ) * '&. / % 0( " 7 " 8 "91 :;.&<= (. 3 - ( >3 >?6 <=.@0( AB CD 8 "E > B '4 " F &> B ' " 8 "G :H +<I ( J K >$ 4L '. M@( N>K$ = '.. >O9P QD D RS.. T0- UP * $ D '. V70. ( Ä 10 W6 V70. ( )"7,0 V70. ( )"D / 0 > ' > "S * 0G X 0 7. ' Y 4 [ZB A "\' >]0 ^4 R_ ` a R [ /0. (.'C\.(+"(. A;4 4R b( Z& X ZB A "_ ; 'c (( Z@ A4d(. ZB ezb A "f Xg h$w ikj4 "l. 45 Wj44 16&X" R kcl & R D 7 ZB A "G > Z@R.( m"-^ X\ n( ZBa R h 8 "o b p R.W ]. kc Figure 5: Data-fusion subsystem higher level pseudocode. The first static initialization steps have to do with structural definition of the system (synthetic environment and data-fusion subsystems). Regarding data-fusion subsystem, this means we will load the parameters in the configuration database and, depending on them, build node objects whose parameters are also taken from the database. Additionally, the connections among nodes are also set up during this initialization. In each iteration the internal state of the nodes should be erased. A final detail regarding the data interchange. Each node keeps an internal state, and the data it provides is just a projection of this state which is interesting for a consumer node. In order to avoid the interchange of great amounts of variable, and taking into account there could be several consumer nodes interested on the same specific data, the list of data to be provided to consumers is compiled once, and consumer nodes get a reference to this data. The results belong to the source node, so the destination cannot change the received data objects (this could break nodes encapsulation, altering source node internal state). The destination nodes can only read the sent data. This kind of pass by reference may be performed within a process, but not in a distributed (in terms of CPU s, not of data processing) data-fusion system. We are currently implementing the means for distribution, according to the following guideline: - We will have several data-fusion processes, each of them following the functional description in figure 5. - Clock synchronization among different clocks of the different data-fusion processes must be guaranteed. 436

6 - Special nodes for inter-process communications should be defined. They will be called interfaces, and there would be both output interfaces (we will call them s) and input interfaces (to be called s). - pairs are the key for inter-process communication, which is performed using TCP/IP sockets. In figure 6 the distributed processing architecture is exemplified. Process A this kind of node, but the actual models for each sensor need to need to be programmed. Random number generator libraries are included in the platform to enable the rapid development of those sensors simulators. In this case, the internal state does not only reacts to input data, but also to the simulated environment. 6ZLWFK1RGH This very simple node just lets the data pass it or not. It may be used to define changing data-fusion architectures enabling for instance the discarding of all data from a malfunctioning sensor or processor. A1 A3 Synchr. Clock A2 EA1 Process B RB1 B1 Figure 6: Distributed processing architecture. B2 5HFHLYHU1RGH It is designed to receive data from an external source, through a socket connection. Is one of the key elements for the distribution of real time data-fusion systems. Figure 8 represents its characteristics: Communication threads buffers Data processing thread nodes 1RGH'HVFULSWLRQDQG([DPSOHV In the presented system, the key element is the data processing (or data-fusion) node. Its basic behavior (method node.execute()) is summarized in figure 7. Incomming sockets ([WUDFWDOODYDLODEOHGDWDIURPQRGHVRXUFHV 3URFHVVWKLVGDWDFKDQJLQJLQWHUQDOVWDWH 3URMHFWLQWHUQDOVWDWHWRJHQHUDWHOLVWRIRXWSXWGDWD Figure 7: internal processing. In this section we will describe in more detail some canonical nodes. It should be noted they will mostly serve as skeletons for the implementation of actual nodes. 6HQVRU6LPXODWRU1RGH This kind of node, from the simulated environment (simulated targets, ), generates synthetic measures (plots, images, ) according to the simulation models. It may or not have sources, depending on the kind of sensor simulated (if it is controllable or not, mainly). The format of the data provided should be compatible with that expected in the actual data-fusion system, if we want to validate the system through simulation (Monte Carlo or demo). Each kind of sensor simulator will be derived from Figure 8: node and associated objects The receiver (two are represented as a gray circles in the figure) is implemented using auxiliary threads. In the figure, threads are represented as ellipses. The complete data fusion process is decomposed in a main thread (big ellipse) in charge of data-processing (including the calls to all nodes, including the receiver node) and another thread in charge of incoming communications from each data source. Each thread reads data from a socket, storing it into a buffer. The receiver node within the main thread reads the corresponding buffer, parses it and generate the incoming lists of data to be processed by other nodes. An important feature of the receptor design is that every access writing or reading into buffers is controlled to assure data integrity. 2XWHU6\VWHP,QSXW,QWHUIDFH It is very similar to the receiver node. The only difference is it does not necessarily follow the communication 437

7 protocols internal to our system. Different protocols, with different outer systems, have to be defined, although the coupling with the rest of the system may be performed in the same way. 6HQGHU1RGH This node is the communications counterpart of the receiver node. It is included in the data-processing thread, and is in charge of formatting the data it receives so that the receiver may understand it, and sending it through the established socket. 6LQJOH7DUJHW7UDFNHU It is used for simple sensor fusion applications in which only one target is present. No association is present, just coordinate conversion and measurements filtering. 0XOWLSOH7DUJHW7UDFNHU This node additionally includes steps related with measurement to track association, track initiation,. The pseudocode in figure 9 summarizes its processing. 6LPSOH7UDFN)XVLRQ1RGH This is a node just comprising track coordinates conversion and track fusion/combination. Different track combination procedures may be selected from the available processing libraries. No track correlation phase is present, this node is only to be used for simple systems with an only target or magnitude to be estimated. 7UDFN)XVLRQ1RGH It is a node equivalent to the previous one, but including association and initiation steps. It is useful for the definition of distributed (from processing point of view) data-fusion systems. (VWLPDWLRQHUURUDVVHVVPHQWQRGH This kind of node is interesting for Monte Carlo evaluation of tracking quality. It compares the simulated truth (simulated environment) with the results from the desired node (fusion process results, measurement results, ). Similar nodes could be used for real time assessments of fusion process, but in this case the truth will be not a- priori known. 7UDQVIRUP PHDVXUHPHQWV DQG WUDFNV WR FRPPRQ FRRUGLQDWHUHIHUHQFH 2WKHU6LPSOH1RGHV *HQHUDWHSDLUVWUDFNPHDVXUH 7UDQVIRUP PHDVXUH WR WUDFN PHDVXUHPHQW FRRUGLQDWH UHIHUHQFH 8SGDWHWUDFNZLWKDVVRFLDWHGPHDVXUH,QLWLDWHQHZWUDFNVZLWKPHDVXUHV 'HOHWHROGRUQRWLQWHUHVWLQJWUDFNV 6HOHFWWUDFNVWREHSUHVHQWHGWRRXWSXW *HQHUDWHRXWSXWGDWDIURPWKLVWUDFNV Figure 9: Multiple Target Trackers (MTT) pseudocode. This kind of node may be used for GNN, JPDA and MHT Multiple target trackers, among others, changing the meaning of some of the steps. For instance, a JPDA pair track-measurement contains a measure combination of real measurements, in an MHT association there could be many potential tracks (related with different hypotheses), and only some of them (those regarding the maximum likelihood hypothesis) should be selected to be presented to output, It should be noted we are not saying all MTT systems have to fit exactly this function. It is perfectly possible to define processing nodes with a completely different processing. These node is just provided as a means for rapid prototyping of different MTT systems. Other nodes have been defined, which may be used as building blocks of a complete data fusion system. Among others, we have defined the following nodes : - Bias Estimator : From a pair of sensors, using ideas such as the ones in [3], it estimates sensor biases. - Bias canceller : Using previous bias estimations, it removes (at least partially) sensor biases. - Data saver : It saves into files results of other nodes processing, so that they may be inspected or analyzed. - Data Loader : It reads previous recordings of data, potentially replaying them. It could be used for offline demonstration of data processing with real data. - Database access: some external data may be stored in external databases, which should be accessed from our system. - Human Input interface : This node interfaces with a Graphic User Interface enabling an operator to interact in real time with the system (for instance changing its structure, or providing additional information useful for the data fusion process). - Results Display : This node displays in a graphic manner the results form other nodes. 438

8 $SSOLFDWLRQH[DPSOHV Here we will describe briefly some applications which have been built using this software platform or are going to be translated to it in the near future. $60*&6VLPXODWRUSURWRW\SH During past years our group has been very active in the design of data-fusion systems for airport surveillance, monitoring and control. We were part of DAFUSA and VISION European Commission projects, the first devoted to design and simulation of ASMGCS systems and the second one aiming to develop a prototype of such a system. Currently we are trying to implement a simulator/real time system prototype, integrating both functionalities, and potentially useful as a design platform for ASMGCS. This example application requires the implementation, among others, of the following nodes (in addition to specific extensions of the canonical nodes for data processing and for data display and human interaction with the system): - Sensor simulation nodes for Surface Movement Radars, ADS-B, Multilateration sensors, miniradar networks. - Monitoring of aircraft paths within the airport and potential conflicts detection. 0$5,$V\VWHP This system, presented in Fusion 2001 [4], is an airport surveillance function based on a distributed network of video cameras. Some of this cameras are deployed next to the runways and taxiways, in order to obtain aircraft identification through tail number recognition, and some others are placed on airport building roofs to obtain a good perspective enabling image-based aircraft tracking. In figure 10 you may see the structure of such a system, in terms of necessary nodes. It is a distributed system with one computer dedicated to the low level processing of an only camera, and a central computer in charge of mixing all the results. We had a software compatibility problem with this system. The low level image processing algorithms were implemented using a image processing library for Windows NT/2000 (the Matrox Imaging Library, from Matrox ). Therefore, the camera dedicated computers are tied to this particular operating system, and the nodes related with this low level image processing are not directly usable in other software platforms. In order to potentially avoid this dependence in the future, we have encapsulated as much as possible the use of these libraries. Tracking dedicated computer Image Capture Image-based tracker Identification dedicated computer Airport database access Image Capture Tail number recognizer Figure 10: MARIA software architecture. Central Fusion computer Display Track and identification fusion system Capture trigger In figure 10 only three fusion processes, one of each of the kinds available, are depicted. The tracking dedicated computer includes an image based tracker which based on the captured image performs local tracking. This tracker is derived from the Multiple Target Tracker node described in section 4.7, and uses an extension of the algorithms in [4]. The tail number recognition system accesses the tail numbers in the airport using an airport database. All this information is provided to the track and identification fusion system which compiles a unique track with identification for each interest target. This information is used both to enhance image based tracking association and to trigger the capture of an image when the aircraft is in from of an identification dedicated camera. 5HIHUHQFHV [1] Multisensor Data Fusion. E. Waltz, J. Llinas. Artech House [2] Modeling and simulation in support of the design of a data fusion system. Éloi Bossé, Jean Roy, Stéphane Paradis. Information Fusion I [3] Removal of Alignment Errors in an Integrated System of Two 3-D Sensors. R. E. Helmick, T. R. Rice. IEEE Transactions on Aerospace and Electronic Systems. Vol 29, No. 4. October [4] Image-Based Automatic Surveillance for Airport Surface. Juan A. Besada, Javier Portillo, Jesús García, José M. Molina, Ángeles Varona, Germán Gonzalez. Fusion Montreal, August