来源:(R)Evolution of the E/E Architectures, ISSN: 1946-4614
随着自动驾驶的发展,软件的虚拟化以及对硬件的进一步抽象,也会成为必然。其具体表现形式比较多样。其中一个场景是,不同硬件集合为栈(stack),这些栈按照延迟和可靠性的不同需求提供服务——比如高性能栈用来支持HAD、ADAS功能,而时间驱动(time-driven)的低延迟栈则用以支持基本的安全(safety)特性。还有个典型的场景,ECU整体虚拟为超级计算机,以实现智能节点计算网络。这些都需要硬件抽象和虚拟化技术的参与。
2. 不同栈的标准化
不同硬件集合而成的栈,产生汽车不同功能的分立。什么意思呢?功能今后会取决于关键需求,而不是按照汽车硬件物理层面的功能域来简单划分(这本质上也是虚拟化的体现)。麦肯锡提出,下面4个栈会成为未来汽车的重要组成概念。
• 时间驱动栈(Time-driven stack)。在这个栈中,ECU直接连接到传感器或执行器上,系统需要支持实时的需求,保证低延迟;资源调度是基于时间的。这个栈涵盖的系统,要达到最高的汽车安全完整性等级(Automotive Safety Integrity Level)级别;
• 事件与时间驱动栈(Event- and time-driven stack)。这个栈涵盖了高性能安全应用,比如说支持ADAS和HAD的。应用和外设被操作系统区隔开,应用基于时间进行调度。应用内部,资源调度可基于时间或者优先级。操作环境要确保安全性要求较高的(safety-critical)应用,跑在独立的容器(container)上,和其他应用是隔离的。目前比较典型的例子是AUTOSAR。
• 事件驱动栈(Event-driven stack)。这个栈主要是车载娱乐系统,它的安全(safety)要求并不高。这些应用也需要与外设隔离开,资源调度基于事件。这个栈包含了一些可视化和使用比较多的功能,应用在用户和汽车的交互方面,比如Android、QNX、Automotive Grade Linux等。
• 基于云的栈(Cloud-based stack)。这个栈是从车外访问车内数据与功能,相关于通讯,,应用安全检测(safety and security),以及建立访问接口等。
实际上已经有部分汽车供应商,或者市场参与者开始针对这些栈做投入。比如说,针对高性能应用的AI和感知,这属于事件驱动栈,有供应商正与汽车制造商一起开发计算平台;时间驱动的例子,如AUTOSAR、JASPAR正在支持这些栈的标准化。
3. 扩展的中间件层(middleware layer)对硬件做抽象
汽车本身正进化为移动计算平台,那么中间件层(middleware layer)可以让汽车的重配置,及相应的软件升级、安装成为可能。当前每个ECU内的中间件,跨单元进行通讯——而未来的中间件能够链接域控制器,来实现功能的访问。
在ECU硬件之上执行操作时,中间件层起到硬件抽象和虚拟化的作用,也就能够实现前文提到的SOA,以及分布式计算。现有的行业参与者事实上正在尝试这种更具灵活性的架构。比如说AUTOSAR的自适应平台,就是一个支持中间件、复杂操作系统和多核处理器的动态系统。
4. 中短期来看,传感器数量会飙升
未来2-3代汽车中,汽车制造商会安装某些具备相似功能的多个传感器,主要是为了确保安全性(safety),并且是以多重保障的形式,比如说毫米波雷达、LIDAR、摄像头。所以传感器的市场需求量在这一时期会发生一次跳跃。尤其针对自动驾驶技术,LIDAR激光雷达用于物体分析与定位,在SAE定义的L4自动驾驶等级中,每辆车需要4-5个LIDAR传感器,实现近360°可视化。
不过就长期来看,情况可能比较复杂。根据不同国家地区的监管政策,解决方案的技术成熟度,传感器单纯从基数上来说,增加或减少都是不一定的。比如说,监管可能强制要求汽车进行司机监控,那么传感器数量自然会进一步飙升,比如动作传感器,以及测心率、疲劳程度的健康监控系统,甚至脸部识别、虹膜追踪。