Sensor fusion system partitioning
Instead of each system independently performing its own warning or control function in the car, in a fused-system the final decision on what action to take is made centrally by a single entity. A key question now becomes where the data processing is done and how to get the data from the sensors to the central ECU.
When fusing multiple sensors, not co-located but distributed all over the car, the connections and cables between sensors and centralized fusion ECU are worth some special consideration. The same is true for the location of the data processing as it will also impact implementation of the whole system. Let us look at the two extreme ends of a possible system partitioning.
On the centralized end of the spectrum all data processing and decision making is done in a single location, data comes from the various sensors “raw” – see figure 3.
Sensor module – Sensor modules are small, low cost and low power as only sensing and data transmission is required. Sensors have a flexible choice of mounting locations and require little mounting space. The replacement cost is low. Typically sensor modules have lower functional safety requirements because no processing or decision- making is done.
Processing ECU – A central processing ECU has all data available as no data is lost due to pre-processing or compression in the sensor module. More sensors can be deployed because they are low cost with a small form factor.
Sensor module – Wide-bandwidth communication is needed to handle the amount of sensor data in real time (up to multiple Gbit/s), and due to that the possibility of higher electromagnetic interference (EMI).
Processing ECU – The central ECU needs high-processing power and speed to handle all incoming data. This means higher power requirements and heat generation, with many high bandwidth I/O and high-end application processors. Adding sensors will significantly increase the performance needs on the central ECU. Some drawbacks can be overcome by using interfaces (such as FPD-Link III) that allow sending sensor data as well as power, control and configuration data (bi-directional back-channel) over a single coaxial cable. This can significantly reduce the system’s wiring requirements.
On the other end of the spectrum is the fully-distributed system. It does a high level of data processing and, to a certain extent, decision-making locally in the sensor modules. A fully-distributed system only sends object data or meta-data (describes object characteristics and/or identifies objects) back to a central fusion ECU. Here data is combined and the final decision on how to act or react is made – see figure 4.
A fully-distributed system has both benefits and drawbacks.
Sensor module – A lower bandwidth, simpler and cheaper interface between the sensor modules and central ECU can be used. In many cases less than 1Mbit/s CAN is sufficient.
Processing ECU – The central ECU only fuses object data, so it requires lower processing power. An advanced safety microcontroller can be sufficient for some systems. Being a smaller module it requires less power. Adding sensors does not drastically increase the performance needs of the central ECU as much of the processing is done in the sensor itself.
Sensor module – Sensor modules require an application processor, become larger, pricier and require more power. Functional safety requirements are higher in the sensor module due to local processing and decision making. Of course, adding more sensors can add significant cost.
Processing ECU – A central decision-making ECU only has object data available with no access to the actual sensor data. “Zooming” into areas of interest is difficult to realize.