当谈BEV的时候，我们在BEV的中融合是一个feature级的融合。当把不同传感器的feature投映到BEV空间时，如果空间的calibration不是一个精度（特别是对于这种BEV），它往往会比传统算法对这种calibration的精度要求更高，可能会到一个0.1度的级别。在这个基础上，我们对calibration的要求也会更高，这样我们才能够得到一个准确匹配多维、多空间的feature融合的效果。
解决了时间和空间的问题之后，在这样一个复杂的异步高并发的系统里、在实际的软件开发过程中，我们需要很强的调度能力。在一个异步高并发的系统中，我们如何通过调度把一个不确定性的系统变成一个确定性的系统？这就需要我们有一个确定性的调度能力——全局调度能力。往往开发一个复杂的自动驾驶系统时，我们的系统可能会存在多个进程，单SoC内可能会有多个进程，也会有多SoC，还会有多域、跨域的协同工作。
当谈整个自动驾驶系统时，我们的软件系统往往需要优化的是一个端到端的延迟，可能并不是某一个任务的单点延迟。当去优化整个端到端的延迟时，我们需要有全局的思考。在不同时间、不同时刻、不同任务的体系下，如何把我们的任务调度按照期望的顺序、期望的时间，达成期望的结果。为了完成这样的调度，同时需要我们有很好的任务Profiling机制。多任务调度需要我们在每一个任务中有Profiling的执行时刻，有它编排的顺序，同时需要有对应的工具，能够把这些Profiling的结果通过一些自动化编排或者人工编排的方式达成异步高并发的确定性。
当解决了所有这些数据和调度问题之后，我们才刚刚开始为我们的算法架构准备好基础的数据能力。
在端到端的过程中， BEV feature实际上还有时间融合的过程。时间上的融合其实就是一个多帧的持续关系，从而达到时空融合。如何完成这个时空融合，首先我们需要获得一个高精度、高清的车辆自身的ego-motion。一般我们会评价ego-motion，比如说100米的距离，它的ego-motion误差要小于一米，比如说每秒的一个角度误差小于0.1度，我们如何来完成这件事情呢？
计算ego-motion往往需要车辆原始底盘的信号，而原始底盘的信号需要信号矩阵去解析，不同车型的信号矩阵也是不一样的。我们也可能会需要IMU和GPS的数据。这些数据都是高频、小数据、高并发，而在自动驾驶的域控里，这些数据往往是连接到一个MCU网关，整个数据链路往往也非常的长。从车身信号到高安全等级的MCU，对这些信号打上时间戳，然后通过数据链路、通过SPI或者以太网，到计算核OS里的Kernel，再到Driver 、HEL，最后到应用层的Library，数据链路是非常长的，而往往在自动驾驶的开发过程中，数据链路是遇到问题最多的地方，而我们对这个数据链路延迟的要求非常高。如果数据链路的延迟过高，意味着ego-motion的延迟可能无法正常的让BEV完成一个时空的融合。
