来源：智车Robot 作者：canonical
概要
无论是车载娱乐软件、驾驶辅助软件还是自动驾驶软件，软件的加持为汽车行业和用户带来了巨大的好处和便利。然而，正如机械零件需要清洁、润滑和更换一样，软件也需要维护。
原始设备制造商（OEM）和一级供应商也许十分擅长挑选方便定期保养（如更换发动机的机油或者正时链）的汽车零件，但对于汽车软件，却很可能无从下手。随着软件功能越来越复杂，如果现在选择的软件架构不合适，未来几年可能就需要付出高昂的软件维护费。因此，原始设备制造商和一级供应商必须重视车载软件系统及软件架构，并将软件所需的定期维护（如软件安全漏洞补丁或软件升级）纳入考虑范围。
在本文中介绍如何确保软件定义汽车配备最先进的安全和安保解决方案，同时阐述使用开源软件的重要性——不仅能让原始设备制造商专注于开发下一代应用、满足消费者需求，还能控制成本。
引言
软件定义汽车行业的U形赛道
过去的几年里，汽车电气化和自动驾驶领域取得了飞速发展，汽车行业所面临的主要挑战由机械零件转为电子系统和车载软件。
以前，汽车设计阶段出现的问题往往与机械零件相关。为了保证机械零件的充足供应，原始设备制造商通常会与一级供应商和二级供应商签订长期协议，保证在某款汽车停产后的至少十年内市面上仍有相应零件可供替换。当汽车需要维修保养时，处在价值链末端的最终消费者将间接向一级和二级供应商支付零件的费用，直至车辆使用寿命结束。
随着“软件定义汽车”逐渐成为汽车产业的主要发展趋势，汽车设计过程中需要解决的问题也多与软件相关，也与最终消费者更密切相关。每一位车主都希望在汽车安全得到保障的同时，享受最新推出的功能，但很少有车主愿意频繁为安全功能更新付费。
日新月异的市场变化迫使汽车行业奋起直追，紧跟发展趋势。这一点，从雷诺或大众等公司软件工程部门惊人的部门扩张中可见一斑。
“在2011年时，雷诺和大众公司甚至找不出一个内部软件工程师”，而如今，这两家知名车企都各自拥有一支庞大的软件工程师团队。
与此同时，供应商也争相组建自己的软件工程部门。以生产出全球首款沟纹汽车轮胎的德国大陆集团为例，该公司仅2021年一年就投入3100万欧元用于公司内部开发软件 。大陆汽车技术核心业务部门（分为车辆网联技术（VNI）、自动驾驶及安全技术（AMS）业务单元）拥有约89,000名员工，而轮胎业务部门现在只有约57,000名员工。大陆集团并非特例，知名的雨刷系统和灯光照明系统供应商法雷奥集团以及知名排气系统供应商马瑞利公司都采取了相似的措施，扩大其在电子解决方案和软件领域的专业优势。
尽管各个公司都纷纷组建自己的软件部门，但不得不承认的是，市场期待和随着技术难度增加而飙升的成本之间存在着不小的差距。
基于上述考虑，原始设备制造商面临的挑战将是如何部署日益复杂系统，并且控制好因维护系统而支出的年度经常性费用。
起步阶段
重新定义数据时代的汽车架构
从汽车行业的发展现状可以明显看出，在未来，汽车每天需要处理的数据量将达到十兆字节。车内的长程传感器和短程传感器（如LiDAR和摄像头）将收集各类数据，并且，传感器的数量将呈现递增趋势。
除需要数据处理和计算的自动驾驶外，汽车内部还有车载娱乐系统和扩展的车辆故障诊断系统（进一步增强车载自动诊断系统OBD-II进行的故障诊断）。这三大车载系统都需要稳定的数据处理。
那么，是否可以将这些数据都上传到云服务器呢？这种可能性微乎其微。事实是，车载系统将先对部分数据进行本地处理，随后再将主要数据或者整合数据上传到云端。
"为了保证每天数千万字节的数处理量，汽车系统中必须嵌入计算引擎。"
这样一来，需要上传的数据量大大增加。此前，车辆的电子控制单元（ECU）位置通常靠近与其相连的传感器和执行器，因此分散在汽车内部的不同位置。如今，原始设备制造商（OEM）纷纷转而使用“汽车电子电气架构”（EEA），实现电子控制单元的合并与整合，并使用以太网将将各个电子控制单元互联起来。这种全新架构中也会包含1至5台内置高性能计算机（HPC）。
下面，我们将介绍从传统架构转向全新EEA架构产生的诸多影响，特别是在硬件和软件维护方面的影响。
来源：雷诺--日产联盟
复杂性与日俱增
硬件复杂性
在汽车领域，电子硬件的设计并不像电脑那样基于安装在主板上的中央处理单元（CPU）和PCIe扩展卡，而是基于“片上系统”（SoC）。片上系统是一种集成电路，其上包括所有或者绝大多数计算组件。实际上，汽车的片上系统通常包括几个CPU，用于保证计算性能和行车安全。这几个CPU包括数字信号处理（DSP）单元、图形处理单元（GPU）、视频加速器、图像处理单元（IPU）以及CAN总线接口等。换言之，片上系统是一个非常复杂的系统。
来源：德州仪器公司TDA片上系统
"硬件已经如此复杂了，汽车生产商需要更强大的软件实力才能征服前行道路上的挑战，因为软件比硬件更为复杂。"
纵观汽车硬件的发展，不难发现，片上系统的复杂性仍在攀升，尚未到达发展巅峰。实际上，即使目前车载硬件的性能尚未达到Teraflop区间，但市面上已经出现了一些包含16个CPU内核的芯片组 。可以预见，汽车将很快迎来80核CPU甚至计算性能更卓越的多核CPU。
软件复杂性以及微服务
汽车行业逐渐由“机械定义汽车”转变为“软件定义汽车”。在这个趋势的推动下，汽车开发周期被重塑，汽车开发工作方式和所需技能也迎来全面转折。这些变革为行业带来了额外的重重挑战。为了应对挑战，汽车生产商纷纷扩大专业团队，不惜重金聘用并培训专业人才。就目前来看，人才成本仍处于上升趋势。在大范围聘用专业人才的同时，企业又面临另外一个挑战：如何吸引能够为公司打下坚实软件战略基础的得力人才。还有一种办法是培训原始设备制造商及其供应商的现有人员，教会他们追赶变革潮流所需的新技能。然而，技能学习十分简单，重塑员工的固有思维方式却非常困难，尤其是该领域的发展已经高度成熟时，难度尤为突出。
与此同时，终端消费者对更多、更复杂的功能的需求也在逐渐增加。麦肯锡公布的数据表明，“在过去十年中，汽车行业单个软件项目的平均复杂度增长了300%。”如今，每一辆汽车之上，都有大约1亿行代码在运行——比军用飞机F-35或波音787梦想客机的代码条数还多 。预计到2025年，汽车上运行的代码行数将达到2亿，而对于L5(完全自动)自动驾驶系统而言，代码行数甚至有可能达到10亿行。
以下为美国汽车工程师学会（SAE）定义的驾驶自动化级别：
美国汽车工程师学会（SAE）对驾驶自动化等级的划分
除此之外，人工智能（AI）或机器学习（ML）算法也在很大程度上增加了车载软件的复杂性。
来源：麦肯锡
网络安全威胁
据报道，1983年，软件和互联网领域最早的“黑客”凯文·鲍尔森（Kevin Poulsen）黑入了互联网的前身——Arpanet阿帕网。那时，偷车贼需要打破车窗，连接方向盘下的电线才能成功偷走汽车。而如今，随着车载软件数量的激增，汽车行业更加容易受到网络犯罪的攻击。
1983年，德国BOSCH公司发明了CAN总线，其诞生比万维网和互联网还早。由于CAN总线本质上不能抵御黑客的攻击，当将其嵌入现代汽车后，CAN总线就给了黑客可乘之机。正如凯文·鲍尔森黑客事件暴露出了互联网的漏洞，“黑客远程劫持吉普车事件” 则暴露了汽车导航系统的许多安全隐患。
2021年发布的一份关于全球汽车安全的报告指出，“汽车行业的常见安全漏洞和安全暴露（CVE）已经有110个，仅在2020年就有33个，而2019年有24个。” 然而，并非所有安全威胁都纳入了CVE。上述报道中还指出，在2020年8月，在10家不同公司开发的40个ECU软件中发现了300多个漏洞。有关当局正在审慎研究安全漏洞对经济造成的影响，并出台了一些规章制度来抵御安全威胁。
ISO/SAE 21434标准“规定了有关道路车辆电气和电子（E/E）系统（包括其部件和接口）的概念、产品开发、生产、运营、维护和退役等各阶段网络安全风险管理的工程要求”。此外，联合国还通过了第155号条例《关于批准车辆的网络安全和网络安全管理体系的统一规定》。该条例概述了“有关车辆网络安全和网络安全管理系统审批的统一规定”。
由于联合国第155号条例的出台，原始设备制造商及其供应商必须合作开发软件安全补丁或修复程序，以防止并限制车辆使用期间出现网络犯罪行为。每一次软件交付，无论其目的是引入增强功能、修复错误还是解决安全问题，都需要在经过网络安全评估和正式的审批程序后才能推送给车辆端。
为了满足这一强制性要求以及客户的期望，原始设备制造商和一级供应商应该了解车载软件的复杂性。在软件领域，仅通过一种方法来实现一项功能或服务的情况非常少见。软件架构师必须做出明智的决定，因为减少管理软件的复杂性是削减长期软件维护成本的唯一途径。
"我们所面临的挑战不仅仅是交付一个软件系统，还包含如何对其进行长期维护。汽车生产商是否为此做好充分准备？"
但网络安全风险并不局限于软件，有时硬件也会暴露出安全漏洞——众多产品中发现的“崩溃(Meltdown)”和“幽灵(Spectre)”两种安全漏洞就是一个有力的证明 。显然，这样的安全漏洞会增加系统设计的复杂性，因为软件架构师需要在考虑软件风险的基础上，预测潜在的硬件漏洞。
安全考虑因素
系统复杂性并非汽车行业面临的唯一挑战。我们刚才谈到了网络安全问题。实际上，车辆的网络安全和安全保障是两个独立的话题，因为车载系统的安全并不能确保乘客的安全。汽车是一个移动设备，其重量往往超过一公吨：汽车不仅需要保障乘客的人身安全，还要保护行车环境的安全。
假如乘客不系安全带，即使安全系数最高的汽车也不能完全保障乘客的生命安全。尽管二者概念截然不同，但它们的关系却是密不可分的。
上文提到的“黑客远程劫持吉普车事件”就证明了这一点，黑客破坏汽车网络安全后也对乘客的人身安全构成了威胁。随着汽车上安装越来越多起到预先防撞作用的主动安全系统，这一点尤其需要考虑。由于主动安全系统依赖于软件的正常运行，因而十分容易受到网络安全攻击。为此，汽车行业引入了功能安全（FuSa）概念，旨在为原始设备制造商及其供应商提供一个框架，让安全理念渗透到各个流程中，并成为概念、生产、交付、保养等流程的重心。
ISO 26262《道路车辆功能安全》是一个国际安全标准，对安装在量产道路车辆上的电气和/或电子系统的功能安全进行了约束和规定。ISO 26262标准将汽车“功能安全（FuSa）”定义为“不存在因电气和电子系统故障所导致的不合理风险”。
功能安全问题不是单纯的硬件系统问题，也不是单纯的软件系统问题，它是一个系统性问题，涉及硬件系统和软件系统两方面的具体操作和流程。
硬件安全
对于硬件系统而言，其只有在满足严格安全要求的片上系统（SoC）和电子控制单元（ECU）之后才能安装到汽车中。ISO 26262标准对汽车安全完整性等级（ASIL）进行了定义，并根据目前正在开发的系统的重要性，梳理了各个等级适用的要求和流程。例如，如果要达到ASIL-B等级，则汽车系统的单点失效覆盖率需要达到90%以上，而ASIL-D等级则要求单点失效覆盖率达到99%以上。同时，ISO 26262标准也给出了“单点失效”的定义，并规定了“预测失效率”的计算方法。该标准中还定义了所需关键术语，并提供了相应评估方法，以帮助读者全面理解汽车的系统安全。
预测硬件失效率
ISO 26262标准介绍了几种评估半导体元件失效率的技术，可以评估电应力、晶体管失效或封装失效的发生率。这些失效类型和各自的发生率主要取决于电路类型、实施技术和环境因素，如湿度、温度、压力、电磁干扰等。ISO 26262标准还区分了元件的预计失效率和预计可靠性。此外，该标准指出，特殊情况下，某个单点失效可能会引起几个单独元件的安全风险。该标准进一步明确可通过相关失效分析（DFA）并识别相关失效发起点（DFI）解决这些风险场景。
数据传输故障检测
为了满足上述安全要求，半导体公司提出了大量的硬件检测机制和解决方案。其中最为常见的包括：
• 奇偶校验码。通过在片上通信流量中添加一个“校验比特”以达到检测数据传输性的目的。奇偶校验位是最简单的错误检测码，检测方法直截了当：若设置校验比特位为0，则传输编码个数为偶数个；若设置校验比特位为1，则传输编码个数为奇数个。若接收端接收到偶数个编码，并且知道校验比特的位置，就可以把它去掉，找到传输的数字。这样一来，如果接收端得到奇数个编码，就意味着在传输过程中出现了数据损坏。虽然奇偶校验码可以检测到传输错误，但不能检索到正确的信息，因此需要重新发送信息。
• 循环冗余校验（CRC）是另一种用于检测数据传输故障的工具。循环冗余校验利用除法及余数的原理来做错误侦测。将特定大小的余数附加到数据后面，然后在接收端进行检验确定数据是否发生变化。在收到信息后，接收端对包含CRC的部分进行多项式除法：与信息一起收到的CRC应该与接收信息上计算的CRC一致，否则意味着有一个传输错误。
• 纠错码（ECC）是奇偶校验法的增强版解决方案，因为这种办法包括了一种即使硬件损坏下也能检索到初始信息的方法。纠错码有很多种类，甚至无线5G标准也包含了新的纠错码机制。
虽然目标是检测传输问题和检索传输的初始信息，但这些检验技术需要与信息一起传输额外的编码。这对实际的网络带宽有直接的影响，此等影响会逐渐减少：如果每个字节中有1比特用于错误检测，7比特为实际数据，那么带宽会减少1/8，即12.5%。
然而，有时会出现传输中断。传输中断可能是因为物理通信中断，更多的时候是因为某个进程挂起时间太久。因此，我们使用“通信超时”来检测通信损失量。
检测运行时错误
如前所述，ISO 26262标准涵盖了可能发生在晶体管层面的问题。半导体公司如今往往使用硬件检查工具来验证操作的正确性。但半导体公司同时也利用安全控制器收集整个系统中的故障信息，对其进行分析，并将故障信息传递到软件系统的高层架构。
最近兴起的另外一种低成本提高安全合规性的方法是“内置自检”（BIST）。此方法诞生的契机是因为半导体制造商早前需要一种方法来识别产品的制造缺陷，完善质检流程。通过充分利用这些增强的系统内置测试功能，同时在处理器正常运行时使用这些功能，能达到有效识别运行时故障的目的。
冗余检测机制
为了达到安全要求，生产商通常会采用复制系统的办法。在相同安全要求下，如果两个系统是分别实施的，安全性甚至还会增高。双重模块冗余（DMR）以及三重模块冗余（TMR）是指将一个系统或系统中的某个元素增加一倍或两倍，并向此等系统或者模块提供相同的输入信号，比较输出信号的一般方法。三重模块冗余的原则是多数表决，取多数输出结果为最后的输出：若三个系统中有二个系统输出结果相同，则这个结果为正确的输出结果。就双重模块而言，如果输出结果不一致，则说明系统存在错误。双模块冗余（DMR）以及三重模块冗余（TMR）用于不同的硬件层次，包括模块层次、芯片层次，甚至在某些情况下也可能是系统层次。
一些片上系统支持双核锁步功能。安全硬件机制通过双重模块冗余（DMR）来实现，为两个完全相同的CPU内核提供完全相同的软件，并共享同一个时钟周期。在每个时钟周期，会有一个逻辑比较器检查两个内核的输出结果是否一致，如果不一致，就会报错。
但高性能CPU通常结构更复杂，确定性更弱，所以，双核锁步法实际效果可能会不尽如人意。因此，一些比双核锁步法更复杂的替代法应运而生，比如使用“安全岛”在保持高度安全完整性的CPU内核中执行检查任务。除此之外，双核锁步法的另一个优化方法是“CPU分核-锁步”。
就像前面提到的失效检测技术对减少通信实际带宽一样，CPU冗余技术也会占用其本身的可用处理能力。双核锁步法或其引申办法会使片上系统的有效计算能力减少50%（使用Split-Lock办法时计算力减少幅度略少）。此外，这项技术还会导致开发成本和硬件成本增高，因为必须要增加冗余。
软件安全性
半导体公司通常需要使用专用软件来确保硬件安全合规性 。换言之，一些云上系统需要软件执行特定以充分发挥其安全潜力，例如在硬件安全章节提到的“内置自检(BIST)”。恩智浦半导体公司推出的S32车用处理平台是当下最热门的汽车SoC系列之一。该公司认为：“S32安全软件架构组建参与了启动、运行和故障恢复期间的工作。”
来源：恩智浦S32安全软件架构
并非所有的软件都是安全合规软件，也并非所有软件都能满足安全要求。此外，软件认证费也是一笔不菲的花销。因此，伴随着电子控制单元的逐步整合，在同一个片上系统或电子控制单元中包含不同的安全临界等级逐渐成为行业趋势。这种趋势能够优化成本控制和性能。车载信息娱乐系统电子控制单元就是一个有趣的例子。
现在，行业普遍将中控台、仪表盘、平视显示器和乘客监控功能融合在同一个电子控制单元中。融合后，某些显示元素和声音元素的安全要求就比其他元素更高。下图介绍了实现电子控制单元整合的主要软件。
不同选项之间的主要区别在于处理安全合规功能的地方有所不同。
• 在选项a中，硬件分离由符合ASIL/安全合规的管理程序管理。
• 在选项b中，硬件分离是通过在片上系统中使用2种类型的内核来实现的。例如，用一个或几个ARM Cortex-M内核来满足车辆通信和安全需求，另外一组通用内核来实现高端计算功能。
• 在选项c中，硬件分离不在片上系统进行，而是在硬件层面——使用两个不同的专用片上系统（一个用于安全，一个用于一般用途）来实现硬件分离。
这样的架构不仅会增加软件开发难度，而且会带来复杂的集成和调试挑战。
可以使用类似办法或者其他新办法，比如在系统中引入AUTOSAR自适应平台。这些是通常基于特定片上系统的优化选项，而特定能力通常带来会增加复杂性。
硬件复杂性将会持续增长，以此扩增片上系统的计算能力。在此之上，安全要求还会增加系统复杂性。将计算能力和安全性整合到单个片上系统会变得越来越复杂。半导体公司将不得不提高片上系统的成本，以便达成相应安全要求。
同样地，系统复杂性越高，认证就越困难，花费的成本也就越高。价格的增长曲线不太可能是线性的，更有可能是呈指数级增长。
但要确保安全合规，还需要在软件方面多加投入。ISO 26262标准要求系统开发过程遵照V型生命周期模型。这意味着，软件开发商首先要捕捉客户需求，然后根据这些需求定义功能。软件开发商需要将功能分解到硬件系统和软件系统；软件系统再细分为功能。此外还需要定义、创建或重新启用具体的测试流程，然后依次进行功能层面、软件层面、硬件层面，系统层面的测试。这种系统开发方法伴随着一套流程来运行软件，包括代码审查、捕捉需求偏差、运行测试、测量测试覆盖率等等。
"汽车公司必须做好承担高额软件维护成本的准备。"
现在，我们假设，现有的1亿行嵌入在当前汽车中的代码都是符合安全标准的（事实可能并非如此），按照ISO 26262标准定义的V型生命周期模型，我们还需要多久才能写出新的1亿行代码，以便到2025年前使总代码数达到2亿行？我们需要多少名软件工程师的通力合作？
参照现在已有的1亿行代码，原始设备制造商和一级供应商应该能够粗略估算出按照COCOMO或任何其他方法，新增1亿行代码所需的成本但这也仅仅是预计成本，任何的变更都会导致成本的变更。
那么对于拥有5级自动驾驶系统的汽车来说，10亿行代码的预估工作量是什么样的概念呢？同样，如果大部分内容都不能重复使用，那么编写规范、执行和测试如此大规模的软件需要多长时间呢？
使用开源是唯一的可持续发展方式，在“建议”节详细阐述。
隔绝干扰
如前所述，硬件电子控制单元整合是一大趋势。在大多数情况下，这意味着将安全关键组件和普通处理组件整合到同一个电子控制单元中。但安全系统必须具备“免干扰”功能。换言之，如果一个系统结合了安全关键组件和非安全关键组件（如在同一个电子控制单元内），则应证明非安全关键环境不会对系统中的安全部分造成干扰，进而引发安全问题。
例如，应确保调度器不会被破坏，某个进程不会终止系统，且内存堆可应对缓冲区溢出的情况。
在查看了CVE事件之后，我们发现，大多数CVE事件都是基于后门、内存溢出或软件（或硬件）组件的意外/无意行为：因此CVE的重点在于强调安全威胁。我们每天都会发现新的CVE漏洞。即便按照ISO 26262（《道路车辆功能安全》标准）设计，且严格遵循Automotive Spice（软件流程改进和能力测定标准）流程，具备ASIL D等级的实时操作系统（RTOS）也会存在安全漏洞。
但不管怎么说，没有保护措施就意味着缺乏安全性，这是大家一致公认的事实。
ISO 26262标准并不足以确保汽车的安全性。根据现有先进技术要求，我们应按照ISO/PAS 21448（《道路车辆预期功能安全》标准），将预期功能安全（SOTIF）纳入对系统的分析之中。这是另一个亟需解决的难题。
"系统越复杂，就越难评估和证明其安全合规性。"
建议
寻找解决难题及安全性问题的有效方法
现阶段，我们可解决以下问题：
• 处理更多车辆数据，速度更快
• 不断攀升的硬件复杂性所带来的挑战
• 软件泛滥问题
• 网络威胁带来的其他难题
• 软件的长期维护需求
• 软硬件各自或共同的安全要求
接下来，我们将探索航电、开源软件开发等行业应对这些挑战的最佳实践案例。
限制安全污染
我们已经证明，使用开源是唯一的可持续发展方式。但这并不代表我们应该寄希望于修改开源软件来满足对汽车的需求。例如，安全污染是指系统中越来越多的部分开始需要安全保护。如果我们一味地追求缩短上市时间，而非提升最终用户的安全性，最终会导致忽略相应的架构研究。安全污染极大地限制了开源软件的使用性，
因为绝大多数开源软件都不符合、也不可能符合安全要求。对OEM而言，对系统各部分实行高安全合规性要求，例如要求每个组件都是ASIL D等级，似乎比将ASIL B等级系统升至ASIL D等级更为容易。然而，这样做会导致复杂性和成本增加，同时还降低了功能。例如，与更通用的操作系统相比，符合安全标准的操作系统支持的功能更少。此外，每做一次更改（如CVE补丁），都需要进行一次安全评估，因此同时兼顾安全性和保护措施的合规性会导致复杂程度再次升级。
因此，一旦在车辆上配置此类系统，运行成本会迅速增加。而且配置完成后，系统架构可能很难更改。对原始设备制造商而言，避免成本激增的唯一方法是理性控制系统的安全边界。
最近，随着自动驾驶和电子控制单元的整合，安全要求已经对车载信息娱乐系统等许多车辆组件造成了影响。
在避免安全污染方面，汽车公司可以借鉴其他行业的经验。例如，航电系统架构就明确规定了系统安全与非安全相关组件之间的区别。比方说机载信息娱乐系统不会干扰飞机的安全组件。某些安全组件还可以控制非安全组件，比如机长广播可以控制机载信息娱乐系统。
我们针对未来电子电气架构的建议是考虑支持两种类型的通信通道（在电子控制单元硬件层面）：安全通道和通用通道。系统中的通用组件可与符合安全标准的组件交互（访问传感器或执行器并从中读取状态），在可用时，使用云原生类型的消息传递系统（安全组件）进行回复：安全第一。应禁止通用组件设置参数或控制安全组件。
不建议重建电子控制单元安全和非安全组件。建议由两种不同类型的片上系统（SoC）/中央处理器（CPU）负责同一电子控制单元中的安全性和通用特性，（如前述选项c）硬件分离所示）。这样，就无需将所有的高性能计算或边缘计算SoC/CPU连接到安全通信通道上，从而降低软硬件设计的复杂性。
麦肯锡预计，硬件和软件将实行分开采购，使“采购更具竞争力，扩展更简单，并允许使用应用软件标准化平台，同时保持硬件方面的竞争”。
出于这一原因，原始设备制造商和一级供应商下一步将分别采购软硬件安全和通用组件。
硬件安全要求催生了进入壁垒，从而阻止了更大规模的竞争。而取消系统架构中部分硬件模块（如HPC）的安全要求，将导致竞争局面重演，并降低物料清单（BOM）成本。
例如，半导体公司可能会借此机会，为汽车行业提供符合AEC-Q100标准的CPU，且无需经过ASIL标准认证。我们可以期待看到功能更加强大、具备多个内核的CPU，同时相比个人电脑/服务器，它们的价格也不会出现大幅上涨的情况。
如今，有多少在Linux操作系统上创建的原型，为了最后能够在“安全实时操作系统”上运行，不得不进行重新设计、移植和调整？试想一下，如果开发出能够立即在目标硬件上运行的概念验证（POC），把符合安全标准的组件与通用组件区分开来，这样将大大减少对符合安全标准的虚拟化解决方案的需求，并增加符合安全标准的定制化操作系统的使用（无论是否基于Linux操作系统）。届时，原始设备制造商将能够使用Linux操作系统和开源软件。与安全操作系统的使用情况相同，获得有限领域内的安全要求也将改善资源的使用情况：降低所需的具备安全知识的工程师数量。招聘压力会更小。
采用开源和Linux操作系统
Facebook/Meta、Airbnb、Netflix（以及许多其他公司）之所以成功，是因为他们试图用自己的操作系统取代微软的Windows或Linux，还是因为他们使用了开源并专注于客户服务呢？他们肯定非常熟悉自己的软件栈，但不会浪费精力去重新发明开源社区中已经存在的东西。如果他们发现了一个漏洞，或者开发了一个增强版开源模块，他们就会将其发布到社区，从而让模块功能进入上游，获益更多人，并促使整个社区共同参与维护过程。这就是开源的改进和发展方式。
我们建议原始设备制造商和一级供应商与Linux的商业供应商合作，以此对Linux内核及扩展开源软件包进行长期支持和安全维护。这样，他们就得以专注于自身的软件解决方案，并通过客户应用程序开发和服务推动差异化竞争。
同时，由于车辆与云端连接，原始设备制造商应考虑与Linux发行商合作，为云服务器、工程师桌面及车载Linux软件提供支持。这样，原始设备制造商就能以较低的费用获得更高级的支持，同时减轻管理多家供应商、多份合同及多个开发环境的负担。
开发下一代汽车应用程序
软件代码库的扩展并非汽车行业所特有。为维持软件复杂性和日益多样的功能之间的平衡，整个IT行业不再固守静态和单一方法，而是开始采用微服务和高可用性软件设计。
微服务案例
基于微服务的应用程序架构实现了将单个应用程序开发为一套小型的、狭义的且可独立部署的服务。每个微服务都在各自独立的进程中运行，并与轻量级机制（通常是超文本传输协议应用程序编程接口）通信。这些服务将聚焦特定的业务功能，并使用完全自动化的机制独立部署。
打个比方，我们可以用一座老旧的房屋来理解向微服务的过渡。这种过渡就好比打通这座房屋内厨房和客厅之间的墙，拆除手工制作的橱柜，然后以大品牌的模块化系统取而代之，并添设可通过家庭局域网和互联网通信的厨房电器和电视机。这座房屋的外墙没有任何改变，内部也仍设有一个厨房和一个客厅，但这些设施都更加现代化，舒适度更高，且具备一系列全新功能。
在这个重构遗留应用程序的过程中，部分遗留代码是由其他人（即社区）维护的，因此通常会被开源代码所取代，也就是说使用这些代码的人无需承担所有维护成本。此外，与取代的遗留代码相比，开源代码的用户使用量更高，覆盖更多案例：换言之，这种开源代码的可靠性也更高。
向微服务架构模型的过渡应旨在以等价开源软件取代70%（或以上）的遗留软件。这样，就可以将精力集中在剩下30%（或以下）可带来关键差异的软件上，从而为公司创造附加值。
如何处理单点故障
高可用性软件设计的目的是识别单点故障（SPOF）。SPOF是系统的一部分，如果它停止运转，将导致整个系统停止工作。例如，如果一架单引擎飞机的引擎发生故障，那么飞机就无法起飞，而相比之下，搭载双引擎的商用飞机在起飞过程中即使其中一个引擎发生故障，飞机也能顺利起飞。使用具备微服务设计的应用程序，能更轻松识别SPOF，并尝试消除它们。消除SPOF的方法有以下几种：镜像、负载平衡、复制、自我修复等等。
本文的目的并非深究细节，其关键在于，IT行业使用高可用性设计来确保服务器的容错性和99.9%的正常运行时间。此外，其还能在不关机的情况下，立刻进行服务器维护、升级和实验。车辆不就是应该具有容错性，并在大部分时间内保持正常功能和较长的正常运行时间吗？我们不就是应该能在不用停车的情况下进行升级吗？当IT行业工作者设定下这些目标时，他们充满了斗志。但这些目标的实现是十分有益的，应该应用于汽车行业。
事实证明，互联网具备稳定性，并且能够全天候运行。高可用性软件和基于微服务的应用架构是实现这一目标的关键支柱。数据中心运行的软件在很大程度上是与硬件无关的。它可以轻松部署在世界上的许多地方，也可以由Amazon Web Services，谷歌云平台，微软Azure等公共云托管，甚至可以在企业内部托管，切换主机时无需重写应用程序/服务。这只是其优势之一。
微服务应用程序是容器化的软件：也就是说它们在一个“盒子”（即容器）中运行，这个盒子中包含了它们需要执行的内容。容器化的软件有几大优点：
• 如果微服务出现故障，受影响的只是它所运行环境或容器中的部分，并不会导致整个系统瘫痪。
• 为支持微服务运行，容器中配置了一个虚拟硬件和操作系统环境。
由此产生了硬件抽象，使得微服务与实际的物理硬件无关。
网站、网页游戏或网页应用与硬件无关：它们可以在许多具有硬件特性（如屏幕尺寸、方向、图形处理器、网络摄像头）的设备上运行。
我们认为在嵌入式关键任务软件中，Snap软件包能够实现所需的硬件抽象（让应用程序与硬件无关），同时提高整个系统的稳定性（应用程序中的某个功能故障不会危及整个系统）。
Snap是一项应用程序及其所有依赖项的捆绑集成包，无需修改即可在所有主要的Linux发行版，甚至集成Snap支持的定制发行版上运行。已经有数以百万计的人使用了41个Linux发行版中的上千个Snap。其中包含了教程、支持材料、创建和部署新应用程序或补丁的工具。原始设备制造商和一级供应商也有可能创建Snap，并将其部署到运行Linux的新旧电子控制单元中。每个人都可以在Linux电脑（和物联网设备）上免费使用这些Snap，无需付费或解锁。
Snap的一大优点体现在操作和应用管理上。实际上，它们不仅能保证开箱即用的安全性，还能在不损害系统的完整性和可靠性的前提下，充分利用硬件的可移植性。任何原始设备制造商都可轻松部署Snap，无需在任何设备上移植即可运行。
Ubuntu Core ，一种完全基于snap的容器化版本。Ubuntu Core的设计具备安全性：通过AppArmor和安全计算模式提供安全性隔离。其还提供TPM支持，安全启动和全磁盘加密。
利用Snap的整体安全方法，嵌入式系统具备了安全性、不变性、模块性和可组合性等优点。软件可通过delta进行无线更新，delta在出现问题时会（从Linux操作系统到任何单个应用程序）自动回滚。
汽车工业从CAN总线到以太网的过渡用了30多年的时间（而且只是部分过渡）。构建故障抵御系统是汽车行业的必备条件，有许多方法可以实现这一目标。此外，系统的网络安全维护设计需具备成本效益。随着ISO/SAE 21434（《道路车辆网络安全工程》）网络安全法规的实施，当前正是从安全性、保护措施和可扩展性三大角度重新考量汽车软硬件架构的合适时机。
以客户为中心
与手机的设计和功能相比，车载信息娱乐系统已经过时了长达4年多。
实现与手机相同的功能只是一个里程碑，并非我们的目标。车辆可开发的功能远超手机（比如自动驾驶）。
固件或软件在线升级（FOTA/SOTA）是第一步，但它并不具有突破性：人们在相关领域已对手机和电脑展开了探索。问题在于，更新能为最终用户创造哪些好处。如果还保留2年前的功能或外观，很可能会让客户大失所望。
原始设备制造商和一级供应商需要提升软件开发与交付的速度，以便与其他行业（如手机）保持同步创新。再者，汽车是最先进的消费品。它们具备实现更高期望的潜力，而不应只达到其他行业的同等水平。
对于原始设备制造商来说，软件开发成本应更低，且上市时间应更快。如果软件的主要部分（将取悦最终客户的部分和承载第三方服务的部分）能够在非安全环境中运行，这一切将成为可能。同时，硬件的采购也需更容易（至少是在非安全环境下运行的硬件），并减少使用汽车专用片上系统。
这样，原始设备制造商就可为其客户和第三方生态系统提供新的服务。智能手机的成功很大程度上归因于平台（即智能手机及其应用程序商店）提供的第三方应用程序和服务生态系统。
集成软件公司的思维方式
虽然汽车行业正在探索从硬件定义汽车向软件定义汽车的过渡，但我们有必要了解这两者之间的区别：
• 硬件设计通常以节约成本为主：如何在硬件上做出改变，使成本降低1美元？每台设备节省1美元，那么100万台设备就能节省100万美元。
• 软件通常要考虑可扩展性因素：我们怎样才能使软件解决方案适用于上百万的用户呢？每月向每个用户收取1美元费用，就能产生100万美元的收益。
这两者之间有着本质区别。
传统汽车制造商曾钻研过硬件设备的物料清单。汽车在开发过程中需要明确和详细的规范。为满足规范要求，制造商选择了最具成本效益的硬件。最终，车辆在一定程度上受到了这些硬件的限制，且这种影响会持续整个生命周期。
特斯拉等公司则倾向于选择功能更加强大的硬件方案。但这并不意味着他们不注重物料清单成本。他们在考虑竞争优势因素时，有更大的自由度。特斯拉甚至在车机系统内引进了游戏。这些游戏指的并非机载娱乐设备上的游戏，而是需要在家里用游戏本玩的游戏。提供车载游戏这个功能可以奏效吗？也许没有，但这不是问题的关键。问题是，如果客户在知晓这一功能之后，是否会感到满意？因为不管怎么说，客户满意度都比功能本身更重要。
这样的硬件和片上系统更加昂贵，但每年部署的新功能，也为吸引客户提供了更多优势。同样，客户满意度是关键驱动因素。而且可以肯定的是，大多数客户更倾向于功能不断完善的汽车：这会让他们拥有一种定期获得新车似的新奇感受。的确，与较低端的片上系统方案相比，这样的选择会导致物料清单成本增加。但每家原始设备制造商都做出了战略选择，比如弯曲复杂的车门形状、添加可伸缩的后扰流板、使用特定的轮辋……这些选择有助于将他们的产品做出区分，以及建立各自的品牌认知。一些原始设备制造商认为，车载硬件和软件的计算能力能有效提升客户满意度。
但还有另一个有趣的影响因素：30年前，制造商在生产消费电子设备、手机或车辆时，在产品生命周期内花费的电子硬件成本为零。但现在的情况已截然不同，因为软件在这些设备中发挥着重要作用。如今，客户希望看到不断推出新的产品功能，此外，系统安全也需要维护，这样一来，每年都会产生与软件相关的费用。因此，除了硬件的物料清单成本外，还需要评估和优化电子电气架构的总体拥有成本（TCO）。减少系统复杂性将成为降低维护成本的关键。
最后，选择主要基于现成组件架构，且对汽车的适应性要求最低的原始设备制造商（例如，在CPU方面仅要求AEC-Q100认证和扩展产品可用性），将更能适应采购短缺问题：这一点不仅体现在芯片方面，也包括工程和招聘方面。
为未来发展做足准备
几十年来，原始设备制造商一直致力于打造卓越的内燃机产品，以及各自的品牌定位和识别，但最近，他们发现局势已截然不同：新的品牌诞生，市场上出现了更快、更动感的电动汽车，而且能创造丰厚的利润（就特斯拉的市值和利润而言）。为了迎合这些市场变化，他们推出了多个方面的举措。但只有未来需要维护部署在某领域的车辆时，他们才能真正履行如今的决议。我们的建议旨在帮助原始设备制造商及其供应商做出正确的决定，以实现可持续发展的未来。
