新闻资讯
汽车和物联网IoT构建一个时代：汽车电子与软件架构的10大趋势预测
物联网IoT的核心发展思路是将世间万物电子化、数字化，汽车也不例外。慕尼黑工业大学信息学教授Manfred Broy说过，如果你现在买辆高端汽车的话，“它很可能包含了1亿行软件代码”。这些软件代码又运行在70-100个ECU(电子控制单元)上，这些ECU就在车内形成连接网络。实际上，汽车中的软件在规模和复杂度上还在迅速成长，商业研究公司Frost&Sullivan预计，很快汽车内的软件代码就要达到2-3亿行的程度了。
换句话说，汽车已经从硬件驱动的机械设备，转变为软件驱动的电子设备，汽车本身已经成为另一种形态的计算机。如今D级或大型车，软件占据“整车含量”的10%，这个比例预计到2030年可达30%。行业的各层级参与者自然期望通过电子设备与软件相关部分来获取营收。这也是即将于11月19日在上海举办的Aspencore汽车电子论坛的时代背景。
原本提供软件和数字技术的市场参与者属于Tier 2、Tier 3级别，但在此役之后会跃居至Tier 1供应商的位置。它们会走出仅提供功能、应用的圈子，变得越来越重要。汽车制造商本身则将下潜到操作系统、硬件抽象、信号处理之类的领域，以增强其竞争力和差异化特性。而且，那些原本没有从事过汽车相关业务的电子、电气科技企业，也开始涉足这一领域，并期望分得一杯羹。这些趋势现在正在发生。
原本传统的汽车产业链，包括了整车厂及各级供应商，结构就像是个纵向一体化的金字塔。但随着上述趋势的到来，汽车产业格局正在向横向分工化、平面化转变——纵向的高度显著降低，不同企业分别制造自己擅长的产品：软件与数字技术提供商跃居Tier 1就是这种趋势的特别写照。这个时候，我们大概有必要重新思考汽车的架构，以及行业的趋势。
来源：McKinsey&Company
总体来说，随这种趋势变化，汽车架构会变成基于通用计算平台的、面向服务的架构(service-oriented architecture，SOA)。更多的市场参与者并不主要通过汽车或汽车硬件来赚钱，而通过提供服务及汽车产业本身来赚钱。
汽车市场的差异化主要将不再是传统的机械硬件，而在软件及电子技术驱动的用户界面、体验方式等层面。开发者还会提供新的连接解决方案、高级分析和操作系统。麦肯锡在去年的一份报告中，总结了未来的多层级车载及后端结构，如上图所示。其中包含了娱乐系统的革新、自动驾驶能力、基于“故障仍保持工作(fail-operational)”系统的智能安全(safety)功能等。上层数字栈(stack)会下潜，和智能传感器之类的硬件做融合;这些栈也会发生横向融合，产生新的层级以后，持续将新的结构融入到SOA中去。
架构变化衍生了很多新的技术趋势与热点。比如说，网络安全(Cyber Security)方面的需求，会从以往单纯的访问控制策略，转变为“融合型安全”——针对网络攻击进行防护、检测、响应甚至预测，这已经是传统信息技术架构中完整的网络安全环了。我们前不久拜访是德科技时，就已经看到在汽车电子相关测试中，网络安全测试单独列项，毕竟汽车的网络安全已经与人身安全直接挂钩——这一点甚至可能对信息安全行业布局产生革命。
再比如模块化的SOA与OTA(over-the-air)更新会成为维护复杂软件的刚需，并且催生基于需求的新功能(function-on-demand)这种业务模式;娱乐系统，以及ADAS的某些组成部分，会变得“应用化(appified)”，因为第三方应用开发者开始提供车载内容了;新型智能传感器和应用产生海量数据，市场参与者需要找到高效处理这些数据的方案;高度自动驾驶(HAD)技术则要求功能聚合、更高算力，以及高度整合……
这里我们只是不成系统地点出了汽车电子化、网联化、智能化带来的其中一部分市场及技术趋势转变。麦肯锡在去年的《重新思考汽车软件与电子设备架构》报告中，针对未来的架构变化做出了一些预测，可供更为系统的参考，摘录如下：
1. ECU电子控制单元加速集成融合(consolidation)
这个趋势我们在以往的汽车行业相关报道中曾不止一次地提到过。增加特定功能不再需要特定ECU，行业整体转向汽车ECU架构的合并集成。首先大部分功能会集中在一个统一的域控制器中，部分地取代现如今的分布式ECU格局。尤其对于ADAS、HAD功能相关的栈而言，这种集成会成为重要趋势。
来源：(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°可视化。
不过就长期来看，情况可能比较复杂。根据不同国家地区的监管政策，解决方案的技术成熟度，传感器单纯从基数上来说，增加或减少都是不一定的。比如说，监管可能强制要求汽车进行司机监控，那么传感器数量自然会进一步飙升，比如动作传感器，以及测心率、疲劳程度的健康监控系统，甚至脸部识别、虹膜追踪。
但传感器数量增加会导致物料成本增加，通过改进技术降低成本会成为一个长期趋势。比如说类似摄像头+雷达的融合式解决方案预计会统治市场，集成方案是有助于减少传感器数量的;更高级的算法、机器学习都能够加强传感器性能和可靠性，那么具备相似功能的多传感器方案会逐渐消失;更高级的单个传感器也会替代过往的组合传感器解决方案。所以长期来看，车载传感器数量减少也是有可能的。
5. 传感器变得更智能
未来的系统架构会要求智能和集成传感器，去管理用于自动驾驶的海量数据。一些比较高级的功能，比如说传感器融合、3D定位当然还是需要在中央计算平台进行的。但更多传感器数据的预处理、过滤和快速响应，还是会在更偏边缘的位置进行，甚至是在传感器内部直接完成。
由于传感器生成数据的海量性，智能会从ECU分担出一部分给传感器，传感器自己去执行那些要求极低延迟，同时计算性能要求不高的预处理。与此同时，智能传感器可以对它们自己进行状态监测，为确保传感器在任何情况下都能正确工作，会有新型的传感器清理应用，比如除尘、除冰之类的能力;多传感器的冗余设计，则能够增加传感器网络的可靠性、安全性(safety)。
6. 供电与数据网络的冗余设计
对安全(safety)要求比较高，以及其他一些关键型应用，对可靠性要求是很高的。他们需要完整的冗余设计，包括数据传输和电力供应。电动车技术、中央计算机，以及对电力需求很大的分布式计算网络，都必须有相应的冗余电源管理网络方案。比如支持线控转向的“故障仍保持工作(fail-operational)”系统，各种HAD功能都需要冗余系统设计，这对于现在的fail-safe monitoring故障安全监控实施方案而言，在架构层面上会有更高的要求。
7. 车载以太网会成为汽车骨干网络
作为业界共识，而且是已经在开展工作的一个趋势，这一点几乎已经无需赘言。至少现在的车载网络是无法满足高带宽数据传输需求的。HAD的数据速率和冗余设计要求，连接环境的安全性(safety and security)，以及跨行业的标准协议间的传输需求，都让车载以太网成为必选项——尤其对冗余中央数据总线。
采用以太网解决方案，可以确保跨域通讯可靠，增加包括AVB(audio-video bridging)、TSN(time-sensitive networks)等扩展，满足实时性要求。LIN、CAN之类的传统网络依然会存在，不过仅针对闭合的更低层级的网络。FlexRay、MOST之类的技术很可能被车载以太网及其扩展AVB、TSN所取代。
8. 为功能安全与HAD考虑，OEM厂商会严格控制数据连接，但针对第三方数据访问仍会开放接口
OEM厂商的后端，必定是车载网关传输安全关键型(safety-critical)数据的唯一出路。针对第三方数据访问，也需要提供接口，除非监管政策不允许这么做。车载娱乐系统前面就已经提到可能会“应用化”，这个过程会浮现出新的接口，让内容和应用供应商部署内容——这个过程OEM厂商一定还是会有各种限制标准。
现如今的板载诊断端口，一定程度会被远程通讯解决方案替代。这种物理维护访问端口已经不再必须。OEM厂商针对某些特定的场景，比如汽车丢失追踪，在后端提供数据端口。
9. 本地信息上云，具备大数据价值
非敏感数据(非隐私与安全相关数据)未来会更多地在云上处理。随着数据量的增加，数据分析会变得很重要，这些数据毕竟能够给出很大的价值。无论是自动驾驶还是其他的数字化创新，这主要取决于市场参与者之间如何做数据共享与分析。
不过目前尚不清楚，这件事该如何执行，以及究竟由谁来做。有传统供应商和市场参与者已经开始构建融合型的汽车平台，能够对大量数据做处理。
10.汽车也像手机一样，可定期升级系统
本地的板载测试系统，能够自动检查功能与集成更新。这种更新能够实现生命周期管理，以及汽车现有功能特性的加强或者解锁。所有的ECU都和传感器、执行器收发数据，获取数据之后能够支持一些创新型的应用场景，比如基于汽车参数的路径计算。
OTA更新对于HAD而言也是基本能力。OTA更新可以带来新功能、加固网络安全性，汽车制造商要部署功能和软件也更快。实际前面提到的汽车架构重大变化——OTA都是其驱动力。与此同时，OTA更新也要求具备端到端的网络安全特性，从车外的云到车里的ECU的整个通路。这套安全解决方案仍待设计完善，未来究竟由谁来做，怎么做都是值得观察的。技术层面，OEM厂目前正与相应技术供应商紧密合作。连接和OTA平台都是需要解决的问题。
另外，要让汽车得到像智能手机一样的可升级特性，中间需要解决成交合同、监管需求，以及网络安全与隐私方面担忧的诸多问题。未来监管机构很可能强迫软件维护确保汽车设计的安全性完整性。
虽然汽车行业目前整体处在过渡期，所以市场环境充满不确定性，但在软件和电子设备架构方面的发展，依旧是无可质疑的。这样的变迁未来还会有更多的动作和事件发生，比如汽车制造商理应创立行业联盟，对汽车架构做标准化;数字技术供应商会带来云平台;还有原本的市场参与者可能会开发开源的汽车栈和软件功能;汽车制造商则推出连接更为复杂的自动驾驶汽车。
汽车行业的各层级参与者总结策略性转变可能会有下面这些：
汽车开发周期，与汽车功能开发周期，会切分开。因为无论从技术还是从组织的角度来看，未来部署汽车功能都会是件难度大得多的事情，毕竟软件即将成为汽车主宰。
定义好软件和电子设备开发的目标附加价值。OEM厂商必须真正理解自家的差异化特性在哪里，以及针对该差异化特性如何做全盘控制。另外就是明确定义自家软件和电子设备开发的附加价值边界在哪里，这样才能真正搞清楚哪些商品或内容并非核心竞争力，而仅能与合作伙伴或供应商共同交付。
给软件定价，寻找新的业务模型。软件在汽车中成为重要的独立个体后，OEM厂需要思考用户单独购买软件的流程和机制问题。各层级供应商在此也扮演重要角色，他们也需要针对其软件和系统标定清晰的业务价值，这也是未来利润增长点的一部分。另外，尤其对于供应商而言，分析在新架构中，哪些汽车新特性是具备真正价值的，就能对其进行货币化操作——那么针对软件和电子系统的销售，需要采用新的业务模型，不管是产品、服务还是某种全新的方案。
围绕新的电子设备架构，做专门的机构设置变更。包括OEM厂和供应商，都应该针对汽车相关电子话题做不同的机构设置。因为未来新的层级架构，要求打破现有的“垂直”组织结构，转而采用“横向”组织机构单元。总的目标，是为其自家软件和电子开发团队提供专门的能力和技术。
上述趋势的更细致探讨，可以在11月19日于上海长荣桂冠酒店举办的汽车电子论坛上获得。点击本文文末的阅读原文链接，即刻参与。重新思考汽车软件与电子设备结构，这又是个扩展到原汽车行业之外的话题，并且将持续在未来至少十年时间里发挥作用。
‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧ END ‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧