Thomas R Kronhamn Ericsson Microwave Systems AB Mölndal, Sweden

Transcription

1 6HQVRU,QWHU1HW:RUNV Thomas R Kronhamn Ericsson Microwave Systems AB Mölndal, Sweden Thomas.Kronhamn@emw.ericsson.se $EVWUDFW It is shown how distributed sensors, networked by Internet techniques, can interact to create not only a common, wide area situation picture but also to support each other in the measurement and tracking process. The paper gives a framework for how the networked system can accommodate sensors of different sophistication and for the system to be developed in an evolutionary way. Specifically, a solution to the truly distributed sensor fusion problem is described. In this solution sensors cooperate directly sensor-to-sensor, in a totally flat architecture. By making the fusion support the primary data sources, the sensors, it is implicated that it also benefits the system as a hole..h\zrugv Sensor networks, Internet communication, sensor data fusion, distributed fusion.,qwurgxfwlrq Networks and data fusion are hot topics in many areas today. Primarily, this paper deals with sensor networks for air surveillance. Traditionally, sensors were connected to centers/hubs designed to create, from the specific sensors used, a common situation picture for the area covered by the sensors. This could be the case for sensors distributed over an area or for multi-sensor platforms, often ships or aircraft. However, new demands on coordinating assets in a flexible and robust way and the advent of Internet communication have made new solutions both wanted and possible. This paper will show how networks can be built from very diverse pieces of equipment, to build "a system of systems". Particularly, it is shown how different levels of sophistication can be accommodated and how the network fusion functionality can be developed in an evolutionary way. Fundamental to such a process is to formulate the fusion objectives and to have a clear strategy in relation to the classical data fusion problems. The paper defines three levels of ambitions for the sensor data fusion and gives corresponding solutions. A specific section is devoted to DISSY, the "ultimate" distributed sensor system solution. Architectures for multiple sensor tracking have been discussed in the literature, e.g. in [1,2,3]. DISSY, first presented in [4,5], shares ideas with the "distributed composite tracking" concept of [3]. The main differences to [3] are in the measures to ensure a truly common air picture. First, in DISSY, it is favored that all measurements in a vicinity of a track are communicated, leaving the association task to the receiving sensor. This prevents that association errors are spread to others. Second, communicating data is not enough to ensure a common picture, because of bandwidth constraints. A "hand shake" procedure is necessary between sensors to establish which one that should be responsible globally for each track. Otherwise, the result would be similar, but not truly identical, air pictures. 7KHQHWZRUNLGHD 2SHUDWLRQDOEHQHILWV The network idea, from an operational point of view, is to create a multi-source, multi-user system with key qualities such as flexibility and robustness. Indirectly this favors a flat, distributed architectural solution. Other operational objectives are to give, all units involved, both a common unified situation picture as well as an increase in the quality of information.

2 1HWZRUNFRPSRQHQWV From a sensor point of view some sensors may be dedicated to the network, others may be sensors belonging to taskoriented platforms or systems of different kinds. These could be units of fighter aircraft, ships, air-defense systems, AEW-systems, etc.. One of the network ideas is to exploit the different qualities of sensors such as radar, ESM, IR, etc. to the benefit of track continuity and target classification. Some sensors may be designed functionally to work together and to be supported by specific high performance data links. Many sensors today may, on the other side, be of local use only. The paper addresses the question of how to make them work together, to be a "system of systems", see Figure 1. Figure 1. A system of systems

3 Figure 2. The Internet world. 2.3 An Inter-Net-Work Logically we think of the sensor system as in Figure 2 that is as sensors connected by way of an Intranet. In this way the physical location or the physical communication links are not an issue from a functional point of view. Functionally, sensors may now cooperate because they observe the same targets and not because they have been connected to specific centers or fusion nodes. 6RPHIXVLRQDVSHFWV 'DWDIXVLRQDPELWLRQV Sensor data fusion may be done in numerous ways. From an engineering point of view, customer needs (expressed as system requirements) should be the leading star. This means that solutions should not be unnecessarily complicated. Here we define/distinguish three levels of ambition, in increasing order of complexity: A1: Creation of a unified situation picture. A2: Performance improvements by use of all data available. A3: Performance improvement by support of local sensor measurement and track. With "a unified situation picture" is here understood that all users shall have the same situation picture. With "use of all data" means that data, from different sensors, concerning the same target should be used to improve the result compared to the single sensor performance. With "by support of local sensor measurement and track" means that the basic measurement and track processes of the sensors themselves should benefit from the data of the other sensors. This may be achieved by feedback from a fusion node or, as advocated in this paper, by direct sensor-tosensor communication.

4 Figure 3. A sensor block diagram showing points of potential benefits for a sensor from external data. In Figure 3, three potential areas of performance improvements from external data are shown for a sensor target track function. These are association, filtering and track load. In the figure, two alternative entry points are shown for external data into the target data processing chain. The preferred alternative is the plot data entry into the association block. For full advantage "high bandwidth" plot data is required. In case track data is received, this still can be beneficial, depending on the status and quality of the own sensor track data. For adaptive sensors, with data arriving at a rate comparable with its own adaptive loop bandwidth, track load savings can be made. Within each level of ambition described above there are still many alternative solutions. In this paper, an engineering design approach is taken that has its focus on the system requirements and tries to find simple ways to avoid or solve the problems encountered. Below, some data fusion issues are discussed. 'DWDIXVLRQLVVXHV &RUUHODWHGGDWD However, even if known, correlated data represents an additional communication and processing load. Three different situations with correlated data can be distinguished: - "common process noise", - shared measurement data, - data feedback. Common process noise is present in track data from different sensors. This means that dynamic track errors are correlated, while the measurement errors are not. Shared measurement data may be present if data can take different routes in a network. This may happen if sensor data, no matter if measurement data or track data, is sent to sensors or fusion nodes without control. Data feedback, here primarily thought of as data from a fusion node that is fed back to sensors, often leads to the sensor s own data coming back to an unknown extent. A general comment on these problems is that they should be avoided if possible. In high performance applications this can be done by direct communication of measurement data sensor-to-sensor. In low performance applications it can be avoided by selection (of track data) rather than fusion. Correlated data is often a problem in data fusion. This is especially the case if the degree of correlation is not known.

5 &RPPXQLFDWLRQEDQGZLGWK Sensor data fusion is always affected by the communication bandwidth. With narrow band, fixed protocol communication links the transmission of track data often is preferred over plot data. With high bandwidth links and flexible protocols the question is open and the answer may be both. In a network, of the kind here considered, the situation may be that bandwidth levels can not be guaranteed and that equipment may be of very different kinds in terms of fusion functionality. Often argued in the past was that track data was more communication efficient than plot data. This was certainly true in the early days, with poor false alarm control. This paper favors plot data for fusion performance reasons (see above). In this solution, however, only a selection of data is communicated and only from selected sensors (those actually observing the target). Another reason is that track data today, to give the full picture, often is of multiple model complexity, far outweighing measurement reports (plot data) in terms of data content. A conclusion must be that solutions must be adapted to the conditions at hand. When high performance solutions are required communication performance must be guaranteed or flexibly controlled. 'DWDIXVLRQVROXWLRQV Given the levels of ambitions (A1-A3) and the different problems presented above, some straightforward solutions (S1-S3) can be found. There are of course numerous possible variants, but solutions are given here with the purpose to match the level of performance ambition, without unnecessary involvement in the problems mentioned. Below the word "selected" is used when one out of two or more pieces of data is chosen, as opposed to "fused" when the data is filtered or otherwise weighted together. Included in the notion "selected" is the possibility to "combine" data from different sensors, which may complement each other in different ways. Such a typical situation is to combine radar or laser range data with IRST angular data when these sensors are co-located on platforms. The three solutions (S1-S3) are as follows: S1: Track data from the best sensor or node is selected. This solution means that no extra fusion is performed for the sake of the net. S2: Plot data should be fused at nodes, where possible. If done at several locations for a particular target, or where there are sensors not connected to these nodes, track data from the best location should then be selected. This solution should be used when sensors and communication links are known and dependable, such as in multisensor platforms and specifically designed local sensor nets. The solution results in that extra track functions are introduced at the nodes. Sensors may have (probably have) track functions of their own. Plot data, not all but selected, potentially belonging to the track in question, should be communicated. S3: Plot data should be shared among sensors or nodes and fused in a way that all data concerning each target is available at the fusion point (sensor). The best node or sensor should then be selected. In this solution fusion nodes should only exist where sensors do not have a tracking capability of their own. Common for all the solutions are the interface to the net and that there are no correlated data problems. 7KH',66<VROXWLRQ In a perfect world where all sensors are built, with the highest ambitions, for the network, a truly distributed Sensor Inter-Net-Works can be obtained in the way shown in this section. Here, a solution is shown that satisfies the highest standards in - performance; all data fused, direct sensor-tosensor support, - robustness; fusion at sensors, no extra fusion nodes introduced. This is done without suffering from the problems mentioned above. 7KH',66<SULQFLSOH The solution of DISSY, DIstributed Sensor SYstem, is depicted in figure 4. Each participating sensor is connected to the network by the three services shown in the figure. Full functional standard is not necessary for participation. The services are: 1. One service finds out, for each specific target, if any other sensor observe the same target. This is based on the location of the own target track. These sensors send data, from an area around the actual track, to each other. 2. Another service adapts the received data to the functionality of the host sensor. The received data can be plots or tracks with different amounts of delay. 3. The third service is negotiating with the other sensors for the global responsibility of the target data. This is based on rules and data quality. The DISSY principle results in a flat architecture, as opposed to a solution with local and global fusion nodes (of which there are many variants). Sensor cooperation is logically the same irrespective of local physical connections.

6 Figure 4. DISSY, DIstributed Sensor SYstem. Each participating sensor, or sensor sub-system, is functionally a part of the distributed sensor system by use of the three services shown in the figure. 0RWLYDWLRQDFDVHVWXG\ Consider a target crossing the area of interest. There is always (almost) one sensor to be the first to detect and start tracking. This sensor learns (service no 1) that no other sensors are tracking this particular target and sets up a global track. When another sensor gets its first detection from this target, it finds out (service no 1) that there is already a global track at this location. These two sensors now start to exchange data. This same thing takes place for each new sensor observing the target. The data exchanged by the sensors may be of many different kinds and not known in advance. One basic idea behind the distributed network is that sensor cooperation FDQ QRW EH SUHSODQQHG in terms of which sensors that observe a particular target at a particular time and that sensor cooperation VKRXOG QRW EH SUHSODQQHG because of requirements on flexibility and mobility of sensors. This means that data may come in many different forms, such as plot or track data and of one, two or three space dimensions. Not only data come in different kinds but so does also the receiving sensor functionality. The purpose of "service no 2" is to flexibly adapt the data to the sensor. This range from doing nothing to taking care of everything. At the low end, this can be a sensor that cannot benefit from external data and only delivers local track data. At the high end, a sensor has the ability to accept and to use, to the advantage possible, data from all kinds of sensors. A requirement for an Intranet of sensors is to accept the plurality of sensor sophistication, as the first goal is to make the net work and then gradually hone its abilities. At each instant of time there is always one sensor that is the "best", in terms of target measurements. By the sensorto-sensor communication, this sensor has the possibility to improve further by means of the received data. It is hard to imagine that, from a performance point of view, anything could be gained from sending data to a third party (such as a fusion node) instead of sensor-to-sensor. A third party would always be worse off than the best sensor in terms of data and can not generally be better positioned in relation to users, in a flexible, distributed multi-user network. The remaining thing, sending data to each other, is to decide bilaterally between the sensors which will produce

7 the best result, "service 3". The best sensor will be responsible to the users for the particular target data. For a target, passing through the area of interest, this responsibility is handed over from sensor to sensor all along the path. Criteria may be based on track quality measures and predetermined relations among sensors. Mostly the criteria are not critical, as data is shared among the sensors. $QHWZRUNHYROXWLRQSURFHVV Building a network is not necessarily only high-tech in terms of fusion. First thing is often to make things work together with existing equipment. Successively equipment may then be modified, or new material added that is adapted from the start. There will certainly always be equipment of different standards in terms of functionality. The challenge will be to manage the network development in an evolutionary way. The process advocated here is that sensors etc delivers track data to the net. A net service correlates and selects the best data; i.e. produces the unified picture for all users. This allows a unified situation picture to be created regardless of the fusion sophistication at various members. A net service, rather than a built-in function at the sensors and nodes, has the advantage of minimizing modifications in existing equipment. To raise the quality of the result, sensors and nodes may share data among themselves, when this is beneficial. This can be done without affecting the previously described process of creating the unified situation picture as shown with solutions 2 and 3 above. To raise the robustness of the net, the number of fusion nodes may be increased, but rather, the fusion functionality, both the data fusion itself and the responsibility negotiation, should be distributed directly at the sensors. The higher performance levels described will certainly come to use in the new generation of microwave sensors based on DGA-techniques (DGA: Digital Group Antennas), where time critical sensor-to-sensor co-operation will be exploited. Another application that will benefit from this solution is networks of passive sensors, where no natural fusion points can be found. 5HIHUHQFHV [1] Chong, C. Y., S. Mori and K. C. Chang, Distributed Multitarget Multisensor Tracking, in Multitarget- Multisensor Tracking: Advanced Applications, Vol. I (Y. Bar-Shalom, ed.), Artech House, 1990, pp [2] Blackman, S. S., and R. Popoli, Design and Analysis of Modern Tracking Systems, Artech House, [3] Moore, J. R. and W. D. Blair, Practical Aspects of Multisensor Tracking, in Multitarget-Multisensor Tracking: Applications and Advances, Vol. III (Y. Bar-Shalom and W. D. Blair, ed.), Artech House 2000, pp [4] Kronhamn, T. R., Sensorsamverkan i Omvandling, Milinf 2000, Enköping, sept (in Swedish). [5] Kronhamn, T. R., Sensor Fusion Revisited, Militärteknisk Tidskrift - Swedish Journal of Military Technology, No. 4, &RQFOXVLRQV The paper has shown a way to build wide area networks of sensors by Internet techniques. A framework has been given that allows system components of different sophistication to be included. This also makes it possible to develop the network in an evolutionary way. The DISSY solution results in a totally flat architecture without many of the problems in hierarchical solutions. This technique is considered especially important for high performance requirements when adaptive and passive sensors are involved.