IoT的核心发展思路是将世间万物电子化、数字化，汽车也不例外。慕尼黑工业大学信息学教授Manfred Broy说过，如果你现在买辆高端汽车的话，“它很可能包含了1亿行软件代码”。这些软件代码又运行在70-100个ECU（电子控制单元）上，这些ECU就在车内形成连接网络。实际上，汽车中的软件在规模和复杂度上还在迅速成长，商业研究公司Frost&Sullivan预计，很快汽车内的软件代码就要达到2-3亿行的程度了。
来源：(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°可视化。
不过就长期来看，情况可能比较复杂。根据不同国家地区的监管政策，解决方案的技术成熟度，传感器单纯从基数上来说，增加或减少都是不一定的。比如说，监管可能强制要求汽车进行司机监控，那么传感器数量自然会进一步飙升，比如动作传感器，以及测心率、疲劳程度的健康监控系统，甚至脸部识别、虹膜追踪。
您可能感兴趣
