785
在卷硬件、卷算法卷到一定水平后，智能汽车产业开始卷中间件等“很不性感”的基础软件了。
中间件会影响到通信效率，因而，中间件的性能及可靠性，对自动驾驶功能及体验有很明显影响。比如，行车功能与泊车功能之间的切换所需的时间，在中间件比较差的情况下，需要10秒钟；而在中间件比较好的情况下，切换仅需2秒就可以完成。
除这些基础功能外，掌握中间件更是被一些车企认为是实现“灵魂自由”必不可少的一环。因此，几乎每家“不甘平庸”的车企都在自研中间件。
那么，究竟是哪些因素使得车企将自研中间件跟实现“灵魂自由”强捆绑了呢？为实现这一目标，车企自研的中间件需要达到怎样的标准？自研中间件会遇到哪些困难？如果自研失败了又怎么办？ 专业的中间件供应商可以为终止自研或一开始就没打算自研的车企提供什么帮助呢？
一．车企为什么要自研自动驾驶中间件？
“我最近反复思考一个问题：为什么当前很多车企的关注点都在中间件上？因为，中间件是一个开发平台，在车企看来，一旦中间件能自己掌握了，他们就可以在供应商的方案跟自研方案之间无缝切换，那自由度就可以完全掌握在自己手里上了。 ”
在去年年底的一场沙龙上，某自动驾驶方案公司的战略负责人抛出了这么一则观点。
在供应商的方案跟自研方案之间切换需要中间件没错，但是，中间件一定就得自研吗？难道向供应商买的中间不能实现这一目标？
九章智驾在之前的行业交流中了解到，主机厂对自研自动驾驶中间件有“执念”的理由主要有如下几点——
1.AUTOSAR AP在设计之初对SOA的考虑并不充分，因而对SOA开发并不友好。存在的问题主要有：1）工具链不完善，使用复杂度高；2）资源消耗大，易占用实时域资源，影响安全；3）缺少灵活的API接口，应用开发难度大。
2.许多供应商为了追求产品的通用性，将AUTOSAR AP做得大而全，但大而全的结果往往是，AUTOSAR AP中的许多功能模块是主机厂在开发的过程中所用不到的；并且，大而全的产品往往是充其量将每个功能都做到了80分，却没有几个真正能做到90分的。“不仅贵，而且还不好用”。
比如，AUTOSAR AP里会有大量端到端的信息安全模块，但实际上，信息安全模块是跟主机厂内部自研的PKI或安全体密切挂钩的，而供应商由于对每个主机厂内部的PKI或安全体系不够了解，因此，他们所提供的相应模块都不能正常使用。
这些多余、不能正常使用的模块，将会对整个系统的稳定性、安全性和性能产生负面影响：
增加系统的资源占用，包括内存、处理器和带宽等，导致系统性能下降，响应速度变慢，甚至出现系统崩溃或死锁等问题；
可能存在安全漏洞或后门，这些漏洞可能被攻击者利用来进行恶意攻击、信息窃取或破坏系统的行为，从而增加系统的安全风险；
增加系统的复杂度，导致系统的维护和管理变得更加困难，成本也会更高。
因此，主机厂需要对供应商提供的功能模块进行审查和裁剪，只保留系统所需的核心功能，以确保系统的稳定性、安全性和性能，但这个过程费时费力。
3.AUTOSAR AP的开发标准较多，开发过程又主要依赖供应商，而供应商的配合度又不可控。
4.使用供应商的中间件，在遇到问题后需要提供证据证明是“中间件的问题”，很容易扯皮，进而会影响到项目进度。
5.供应商提供的中间件，往往带有该供应商内部开发模式、组织架构的“印迹”，若主机厂的开发模式、组织架构跟该供应商的开发模式、组织架构不一致，则供应商的中间件用起来比较麻烦，可能会使新车型的量产进度受到影响。
6.很少有中间件供应商能提供一套完整的中间件，而来自不同供应商的中间件又没有统一的标准，如果在同一个项目中使用来自不同供应商的中间件及工具链，彼此之间的适配成本会非常高。
7.供应商开发的中间件是否达到了其在PR中所宣传的功能安全&信息安全标准，虚假难辨。在实践中，主机厂花在验证上的工作量特别大。
8.担心中间件供应商破产，危及自身新车型的量产。
9.过去为AUTOSAR CP所支付的高昂成本，已经让主机厂有心理阴影了。主机厂认为，只有必需的组件从供应商处采购，其他的自研则可以减少被供应商盘剥。
10.未来需要将自动驾驶域、座舱域、底盘域进行融合，不同域之间必须进行交互，自动驾驶方案商或自动驾驶中间件厂商开发的中间件，存在无法识别车内其他域的通信协议的问题。
二．车企自研的中间件应该满足哪些标准？
根据九章之前做的采访交流，车企自研的中间件，至少要满足如下标准——
（一）基础指标
1.传输实时性：传输时延小于20毫秒。
上层软件并不直接访问硬件，而是需通过中间件实现，因此，若中间件无法满足实时性要求，则无法保证应用层实现其所要达到的功能。比如，通过中间件访问毫米波雷达数据慢两拍，就会导致模型运算结果出现较大误差，对驾驶安全性存在较大影响。
2.传输正确性：中间件在传输、解包的过程中需维持信号一致，实现精准发送；若无保护机制，则容错允许偏差值应该小于1%。
3.稳定性：不存在数据发送频率不一致、抖动、丢帧的情况。
4.功能安全：不同的OEM对于安全重视程度不同，导致对功能安全、网络安全要求存在差异化。总体来说，传统车企对功能安全的重视程度高，而新势力对功能安全的重视程度低（对功能安全不做强制要求）；但随着智驾等级越来越高，功能安全需要满足ASIL-D标准，至少是那些影响到运行过程和数据有效性、安全性的关键中间件模块需达到ASIL-D。
5.信息安全：需将加密算法库移植进信息安全模块，同时要保证硬件能够实现信息安全的加解密处理。
6.有冗余机制：若中间件停止工作，会有备份发包机制将已处理好的数据再发出去，并且上报。
7.自动故障检测功能:能检测到自身存在的故障，并上报。
8.CPU占用：对CPU或BPU占用不能过多。
（二）高阶标准
1.工具链适配性：工具链适配性虽不是硬性指标，但非常影响开发效率。
2.能对数据刷写过程做诊断：以往，MCU上的数据量较小，仅通过CAN总线的刷写即可满足需求，而当前，SoC芯片上的数据量很大，仅通过CAN总线做刷写已无法满足需求，因此，需要中间件承担一部分刷写的任务，并且，中间件还需要能对刷写的过程做诊断。
3.具备分布式通信框架：高阶自动驾驶功能部署的节点、通信数量较多，要求中间件的调度管理模块具备分布式通信框架。
4.与硬件平台的兼容性：中间件模块需包含hardware硬件抽象层，兼容不同硬件的物理特性、功能特点，形成抽象隔离，可跨SoC平台使用。
5.对底层软件具备较高兼容性：需兼容多款操作系统，包括微内核、宏内核系统等。
6.对特定设备开放接口：比如，超级T-Box接收的V2X数据在传输的过程中需要通过无线通信的方式进行数据交互。这就需要中间件对T-Box开放接口。
7.具备不同应用和服务信息的订阅与发布功能：目前，中间件尚不能在不同的硬件平台上“游刃有余”，但调用大量的API实现异构通信又是有必要的，因此，在不同的环境中，中间件需要不同的订阅与发布机制。
8.与SOA架构的适配性：中间件应能适配主机厂的SOA框架，功能应具有可扩展性、未来可OTA，还可以根据用户需求做裁剪。
9.支持跨域协同：即把传统IT行业里用于云计算的那一套技术栈和解决方案都搬到车里面，用一套通用的计算框架在底盘域、自动驾驶域、座舱域之间做一些跨域的数据采集与调动，以及通用计算，以方便跨域协同。
中国车企推出新车型的速度很快，且车型的迭代速度也很快，而每个车型的车内通信矩阵和元器件、执行应用能力都不一样，由于缺乏一套通用的规范和工具，这就导致，每开发一个车型，大量的工作就需要充分做一遍。
这个过程中，不仅工程量超大，而且，工程复杂度也难以控制。在涉及舱驾融合（不局限于one-chip方案，还包括one-box方案）等跨域融合的情况下，尤其如此。
为减少工程量，并将工程复杂度控制在合理水平，目前，大家都在探索一种跨域中间件，或者称之为全域中间件/整车中间件——主要负责对整车的硬件抽象层进行调度，把整车的各个零部件通过API的形式提供给算法。
三．车企自研中间件的难点
当然，车企要自研中间件，并不容易。
比如，在技术层面，难以同时兼顾性能与功能安全——若需一味保障功能安全，则性能提升将面临很大瓶颈，且存在较大未知性。鉴于此，有一些主机厂的做法是为了保全性能而牺牲功能安全。
当然了，比技术难题更突出的，是人才和组织方面的难题。
1.人才匮乏
中间件这种基础软件，如果要做成生命周期比较长的产品，需要行业里最顶尖的团队。但行业里最牛逼的人就那么多，僧多粥少，想要自研中间件的公司越多，平均下来每一家能招聘到的人才就越少。
事实上，基本上每家要主机厂的自研团队都面临人才不足的问题。
笔者想起，几年前，缺芯问题严重的时候，网上流传过一篇很有意思的文章《为什么芯片公司越多，大家越造不出芯片》，这篇文章的主要观点是：造芯片需要一个成建制完整的团队，结果呢，芯片公司越来越多，而人才在短期内并不会有大幅度增长，那新成立的公司就只能从存量的公司里面挖人，挖来挖去，每家公司都缺乏一个成建制的完整的团队。
上述逻辑，同样适用于中间件的自研。
2.管理困难
部分传统车企的管理层缺乏软件思维，难以协调管理好众多的软件人才。
尤其是，主机厂的部门墙普遍比较严重，那么，在做跨域中间件时，你如何保证底盘团队、智驾团队跟座舱团队能精诚协作？
即便是费了九牛二虎之力研发出来了，车企也很难轻而易举地享受“胜利成果”。
1.上下层软硬件供应商的配合度低
车企自研的中间件若出现问题，将会涉及到上层应用以及下层硬件平台的修正，若该中间件已量产上车，上下层软硬件供应商通常不会配合处理因车企自研引发的问题。
2.后期维护成本很高
有一个德国主机厂，本来在中间件自研上面已经走得很深入了，结果发现很难再走下去了——该车企在前期的确招了很多优秀的工程师，但后来发现，这些最优秀的工程师，精力都被绑定在对现有系统的维护上面了。
很多纯硬件思维的老板对自研有一个深刻的误解，好像只要把东西“做出来”就可以“一劳永逸”了，殊不知，软件系统的维护成本要比硬件高得多。尤其是，一款基础软件如果做得比较好，那它的生命周期一定要长，而生命周期越长，维护成本就越高。
很多人会想当然地认为，把自研工作交给一流的软件人才做，后期的维护工作交给二三流人才，但这显然行不通。二三流的人才，如果对软件的理解达不到一流人才的水平，那他如何能做好维护工作呢？
可如果最优秀的工程师都被绑定在一个特定的自研系统的维护上，那你还要不要干别的事情了？
现在，这家国际车企终于想通了，决定将中间件及工具链交给专业的供应商。果然，“真正教人学会成长的，不是大道理，而是南墙”。
实际上，去年下半年以来，许多在前几年一本正经地自研的主机厂都开始认清了形势，逐渐回归到了行业协作的模式上。
四．放弃中间件自研的主机厂，能从供应商得到怎样的支持？
在行业协作模式中，专业的中间件供应商是一股非常重要的力量。主机厂的短板，得由他们来补上。那么，专业的中间件供应商能为主机厂解决哪些主机厂自己很难解决的痛点？为解决这些痛点，他们又推出了怎样的技术与产品呢？
带着这些疑问，笔者前段时间跟博世旗下软件定义汽车中间件、开发工具链子公司易特驰中国CTO郑心航做了深入交流，有不少收获。为更方便大家了解专业供应商在这块的差异化能力，在此，我们将易特驰的做法简单列举几项——
1.对大而全的AUTOSAR AP进行裁剪，只保留主机厂需要的部分
我们在文本的第一章提到，许多供应商为了追求产品的通用性，将AUTOSAR AP做得大而全，但大而全的结果往往是，AUTOSAR AP中的许多功能模块是主机厂在开发的过程中所用不到的；并且，大而全的产品往往是充其量将每个功能都做到了80分，却没有几个真正能做到90分的。“不仅贵，而且还不好用”。
这些多余、不能正常使用的模块，将会对整个系统的稳定性、安全性和性能产生负面影响。因此，针对主机厂的实际需求，易特驰可以将AUTOSAR Adaptive进行模块化的独立销售与部署。
2.解决corner case在仿真平台上“难以复现”的问题
在corner case出现之后，如何在仿真平台上对该corner case进行复现呢？这是自动驾驶系统开发过程中的一大痛点。
对corner case进行复现，需要中间件平台能支持确定性的输入输出。所谓“确定性的输入输出”，即传感器在输入一组数据后，控制算法输出的控制指令应该也是确定的、可预测的（无论何时何地，只要输入条件相同，系统的反应和行为就应该保持一致）。但实际上，现在很多中间件平台（如AUTOSAR AP）并不支持确定性的输入输出，这就会给开发者们带来很大的困扰。
比如，在自动驾驶系统在真实路测中未能对某个玩滑板车的小孩做出“反应”，而在仿真平台上，系统对这个小孩却是“有反应”的。但由于中间件不支持确定性的输出输入，那即便是这次在仿真平台上“顺利应对”了那个玩滑板车的小孩，开发者也不能断定，问题是否真的已经被修复了。
场景复现的问题解决不了，自动驾驶算法的开发效率就上不去。
那么，为什么许多中间件都无法支持数据的确定性输入与输出呢？笔者了解到的原因主要有如下几点——
通信效率问题：自动驾驶系统需要处理的数据量很大、进程又多，并且还需要在毫秒级的时间内做出决策，这对中间件的通信效率提出了很高的要求。
标准化问题：自动驾驶领域的标准和协议仍在发展中，这可能导致中间件在不同系统和组件之间的兼容性和互操作性问题。
时序保证不足： 各个不同传感器所收集到的数据传至处理器上的时间是不一致的，而AUTOSAR AP可能无法提供足够的时序保证，导致系统在不同情况下的响应时间不一致或无法满足实时要求。
对异构性的支持不足： 自动驾驶系统通常需要集成多个不同类型的传感器和执行器，并与其他子系统进行通信和协作。如果AUTOSAR AP不支持对这些异构组件的有效管理和协调，可能就会导致系统的行为不可预测。
针对上述痛点，易特驰跟博世集团的智能驾驶与控制系统事业部联合开发了一款“能实现数据确定性调度和确定性回放”的中间件EDMS，并提供完整的自动驾驶系统从架构设计、算法开发、数据录制，仿真回放等一整套工具链。
EDMS的推出，显然会帮自动驾驶系统的开发者们降低在仿真平台上对corner case做复现的难度，进而提高开发效率。
3.解决“AUTOSAR AP对SOA开发不友好”的问题
虽然不少OEM基于AUTOSAR AP 进行开发，但AUTOSAR AP在设计之初对SOA的考虑并不充分，因而对SOA开发并不友好，存在的问题主要有：1）缺少灵活的API接口，应用开发难度大；2）工具链不完善，使用复杂度高。
ETAS在与主机厂的项目合作中发现，API本身的设计并不是难点，真正的难点在于：随着车型的迭代加速，不同车型的可编程能力也快速变化着的，如何能便捷高效地解决跨车型的API发布和变更管理？
ETAS提供了基于行业标准VSS的一系列开源开发工具链，能够让主机厂的自主、自动高效的将车内API与中间件的开发设计，与底层控制器与控制信号自动整合。
4.通过“全域中间件/整车中间件”来提升技术的复用度
当前，自动驾驶方案的通用程度有多高？
对笔者抛出的这个问题，易特驰中国CTO郑心航的回答是：这就看你怎么定义“通用”了——
如果要求跨主机厂“通用”，显然不现实；
在同一家车企的不同车型上通用，也很难；
即便在同一个车型上，跨域中间件能否通用，也要看该车型的平台及EE架构是否发生了变化——如果融合的架构做得不够好的话，自动驾驶方案在应用到同一车型的不同款式上时还是需要做大量的手工调试工作。
国内车企跟国际车企有一个很大的差距就是，平台化的成熟度比较低，因而，技术的复用度很低。
国际车企，往往是一个大的平台开发完之后，至少在未来的十年内，好多不同的车型都可共享这一个平台；但国内车企在这些年由于迭代节奏比较快，在平台化建设上花的精力并不是很多——很多时候，都是为了赶项目进度，顾不上做平台化建设，在遇到问题后再通过“一事一议”的方式来解决，而这种权宜之计，尽管在当时看来是效率很高，但在从长期看，并不利于公司能力的积累。
可以料想，今后，随着国内车企不断推出新的车型，因技术复用度低而来的工程复杂度会加剧。
当前，易特驰正在探索通过集成度更高、性能更强大、工具链更好的全域中间件（又称为“整车中间件”）来解决自动驾驶方案的通用性及跨车型共享的问题，从而大幅度提高自动驾驶方案在跟不同车型适配时的效率。
5.从“人的效率”与“机器的效率”两个角度来提升中间件的效率
有算法公司的人反映，自动驾驶中间件产品存在的最大问题就是效率问题，主要体现在上层应用开发效率、数据回传效率、传输效率、任务抢占等。
易特驰中国CTO郑心航的解读是，这里的效率，应该包括“人的效率”（在开发的过程中，工程师解决一个问题需要耗费多少时间）与“机器的效率”（最终装车以后，系统在运行过程中需要耗费多少 CPU、 多少内存）两类。
为提高“人的效率”，易特驰引进了DevOps，通过DevOps将汽车软件在开发、编译、测试、验证当中的大量工作自动化。比如，一行代码上传上去后，DevOps可以自动生成质量报告，告诉上传者，他的哪一段代码是有问题的。
其实，DevOps并不是什么新鲜概念，它在十几年前就在IT行业内应用了。DevOps的提出主要是为了解决软件开发团队和运维团队之间的协作问题，确保在开发者修改并提交代码、完成测试验证之后，这个代码能快速地部署到客户的生产系统里面去。
智能汽车做好OTA，就离不开DevOps。
为提高机器效率，易特驰的对策是，在跨域协作中，将对功能安全和实时性要求高的模块跟对功能安全和实时性要求低的模块解耦，这样，在将来软件变化的过程当中，尽可能只去改那些对功能安全要求不高的模块，而对功能安全要求高的模块则尽可能保持稳定。
此外，易特驰还用深嵌入式 AUTOSAR 强实时控制每一个控制器上的进程、资源消耗、循环的复杂度，以此确保系统能在强功能安全下运行，并且性能不会受到其他系统的影响。
6.加入硬件加速模块，为“大模型上车”做好准备
后续，大模型上车会对自动驾驶基础软件的能力提出哪些要求？ 博世集团是否有相关的技术储备？
笔者从博世智能驾驶与控制系统事业部得到的答案是：中间件有硬件加速模块，可帮助算法代码更方便地使用芯片底层提供的各种功能，大模型上车后，中间件也会同算法团队协同，保证基于深度学习的模块在系统中高效运行。
中间件的硬件加速模块是一种专用硬件设备或组件（包括网络加速器、加密解密加速器、压缩加速器、数据库加速器等形式），旨在通过专用硬件设备或组件来加速特定的任务或操作，从而提高中间件系统的性能和效率。
相对于纯软件实现来说，这些硬件加速模块可以减轻主处理器的负载，因而，通常能够实现更高的性能和吞吐量，从而满足对性能要求较高的中间件应用场景。
当然，并非所有的中间件都具有硬加速模块。只有在中间件需要处理大量的数据流或执行复杂的计算任务时，硬件加速模块才是必要的。
7.提升中间件工具链的“易用性”
目前，中间件还存在一些问题，主要是工具链的易用性不够，客户公司工程师的学习曲线比较陡峭、学习周期比较长。比如，AUTOSAR AP本身不具备订阅和发布的机制，这就需要嵌入另一种中间件如DDS进去，而域控与域控之间的相互通讯又要考虑加入SOME/IP进去，这会存在各模块之间的耦合性不够的问题。
如何缩短工程师的学习周期呢？易特驰的做法：
1）.就是前面说过的，将对功能安全和实时性要求高的模块跟对功能安全和实时性要求低的模块解耦，通过这种架构上的分割，给开发者们提供一个简单易用的开发环境（开发者们基本上不用去碰、甚至也不需要特别懂那些对功能安全和实时性要求高的模块了）。
2）.跨业务部门将工具链打通，提升工具链的集成度。
整车软件开发的生命周期，涵盖了电子电控架构设计、信号矩阵编排、控制算法建模、代码生成、仿真测试、整车标定测试验证等等过程，其中每个细分领域的工作都可能会涉及到十几个不同部门、几十个不同供应商的软硬件工具。针对这一点，ETAS推出了软件工厂的概念，除了对自身传统的软件开发工具链加强了全过程自动化整合，也能对第三方甚至竞争对手的产品进行自动化过程打通。
五．九章与易特驰中国CTO对话实录
下文为九章智驾与易特驰中国CTO郑心航的对话实录——
九章智驾：您去年在接受《中国汽车报》采访时说：“今后，对于汽车软件新功能的开发，我们会尽可能避免变更控制器软件本身，而是将其作为底层驱动来看待，这将是开发范式的一个显著变化。” 这段话该怎么理解？
郑心航：我举一个例子：假如你要开发一个在手机上用的社交软件，那你需要去改摄像头的驱动、去改存储SD卡的驱动、去改通信基带吗？不仅不需要改，你甚至都不需要懂这些吧？同样的道理，车上的各类控制器，就类似于上面的这些驱动，其功能已经历过时间的检验，是非常稳定的系统了，就算你要开发新的应用层功能，也别碰这些东西。
其实，大部软件的功能定义，都可以从整车层面考虑，而不只是应用层。这也是SOA理念的一部分。
九章智驾：总结句下来，SOA理念的核心就是：底层的改动越少越好，将上层模块化、使其可自由拆解——不光是软硬件解耦，还有硬件跟硬件解耦、软件跟软件解耦。 可以这样理解吗？
郑心航：对的。就是把整个系统的整体功能打散，拆成很多颗粒度更细分的、可以复用的，或者可以重新编排的模块，然后，通过重新编排就可以实现系统。
九章智驾：看起来，SOA的理念，其实更有助于车企去做正向开发？之前还没有SOA的时候，采用怎样的技术架构就决定了我能实现的哪些功能，一旦技术架构定下来了，功能就很难扩展了；而在SOA理念下，技术架构可以根据功能来调整的。可以这么理解吗？
郑心航：是的。
按照传统的开发模式，如果你希望能自动调整车舱内的座椅位置、空调温度，那你首先得重新定义车内的通信矩阵，然后再让座椅供应商改座椅控制器的指令、让空调供应商调试空调热管理系统的总线。
但在SOA的架构下，你只需一次性把所有的 API 都挂到平台上，后续的新功能，就在这个 SOA 之上开发就行了，下面的控制器就不用变了。
九章智驾：总结下来，之前是“牵一发而动全身”，现在则是“牵一发就是牵一发“而已。
您之前还提到，SOA理念的落地，在很大程度上要通过跨域中间件来实现，而在此过程中，行业里习以为常的组织架构也将发生变化。 这个该如何理解？
郑心航：目前，还没有任何一个主机厂有一个专门的中央部门来定义跨域中间件，至少是从组织层面还没有。当然，主机厂也希望我们能把这个跨域中间件做出来，这样就免得他们内部的部门之间老是打架了。
九章智驾：易特驰的官方公众号此前提到：易特驰提供一个安全守护模块，从整车的角度出发，将各类功能安全的核心控制和维护收归保作系统层面，智能汽车软件的开发者无需对整车功能安全有太强的了解，只要关心自己面向消费者的业务逻辑即可。
这个该怎么理解呢？
郑心航：这是易特驰在行业里率先提出的一个新的开发范式，其实也是SOA理念的一部分。
在传统汽车时代，所有的功能安全都是在控制器内实现，即每个控制器都有自己的功能安全等级、有不同的功能安全场景，那每个模块的开发团队都需要掌握功能安全相关知识。
但在“将各类功能安全的核心控制和维护收归操作系统层面”的理念下，大部分新类型的软硬件功能都会在SOA平台或跨域工作平台上做开发，而功能安全模块等底层模块则会交给整车操作系统层面统一去控制；相应地，各控制器的开发者也就不需要自己再去操心功能的安全了。
在这一理念下，如果当前处于整车安全模式，则各上层应用就可以调用各控制器；如果当前不处于整车安全模块，则上层应用就没法调用各控制器。比如，根据驾驶员的身高调整座椅位置这个功能，在正常情况下是可以被调用的；但在车速达到30公里/小时以上时，这个功能就没法调用了。
诚然，不大可能把所有控制器的所有安全模块都做一个排列组合（这样很容易失控）；但至少在一开始，我们可以设置2-3个不同的安全模式，在不同的安全模式下，上层应用可以去访问不同的控制器。
九章智驾：“将各类功能安全的核心控制和维护收归操作系统层面”这种理念应该可以提高自动驾驶系统的开发效率，那它有没有提升安全性呢？
郑心航：我们的目标是不降低整车的安全性——在确保安全性的基础上提高开发效率。
九章智驾：很多公司都在自研中间件，但功能安全模块并不是他们擅长的。那么，易特驰会考虑将功能安全模块单独出售给主机厂或算法公司吗？还是说，这块是作为核心竞争力，不会单卖？
郑心航：功能安全模块是易特驰提供的整体解决方案的一部分，不会单独卖。因为，别人只买这一块的话，也不能很好地发挥出它的效益。
九章智驾：自动驾驶行业在过去几年的实践已经证明，由于芯片平台和算法都还没收敛、中间件还不能真正满足SOA框架的需求，软硬件解耦一时半会儿还无法成立。在实践中，中间件先得跟一款芯片平台深度绑定才行。
这是因为中间件的硬件抽象层很难做，因而难以跨SoC平台使用吗？易特驰提供的基础软件方案是否能成为“特例”？
郑心航：这个话题之所以能引起很大的争议，是因为行业内不同的人对软硬件解耦的定义不同、期望值也不同。
其实，当年在AUTOSAR CP 平台出来的时候，就有人在讲“软硬件解耦”，说自己开发出来的控制器软件可以部署在不同硬件上面。
九章智驾：可现在，AUTOSAR CP是“软件依附于硬件”的典型啊。
郑心航：你去看它的初始愿景，确实就是软硬件解耦，只是在这个目标上它没有成功而已。
九章智驾：那它没有成功的原因在技术方面还是商业方面？
郑心航：两方面的原因都有吧。
从商业层面来说，主机厂并没有期望控制器的盒子向供应商A买，然后对应的软件向供应商B买。那时，主机厂的采购习惯就是，我找一家供应商，你帮我包了整个系统。
从技术层面来说，在AUTOSAR CP时期，怎么保证供应商B的软件能跟供应商A的硬件完全兼容呢？即便能兼容，在交给两家供应商做的情况下，测试验证的工作量显然会更大，而这块工作应该由谁来承担呢？
九章智驾：现阶段，主控芯片变成SoC了，中间件是类似AUTOSAR AP这种，所以，大家在谈软硬件解耦的时候，有一个基本的共识应该是说“中间件相对稳定，然后，下面的SoC芯片跟上面的算法‘任意切换’”。
但这个看似“比较基础”的目标仍然未能实现，原因在于中间件的硬件抽象层没做好，因而难以跨SoC平台使用吗？
郑心航：自动驾驶车辆上的摄像头和激光雷达采集到的数据都是精度很高的数据，为了降低数据传输的时延，就得通过硬线零拷贝这种非标准的硬件框架来传，这意味着，数据是一定要跟特定SoC的硬件架构绑定在一起的。（零拷贝等技术手段，目前高度依赖于特定厂商的硬件平台的实现方式，无法与硬件平台解耦。）
此外，即便是算法跟SoC可以解耦，但数据来源于传感器，而数据质量不一样，算法的表现就不一样，因而，传感器型号的变化就会对算法产生很大的影响。那你怎么可能真正实现软硬件解耦呢？
最理想的软硬件解耦，应该达到PC行业这种解耦程度，但毕竟，智能汽车的物理架构要比PC复杂得多，并且还没有统一的行业规范，因此，智能汽车的软硬件解耦最终能实现的程度应该会跟PC行业有很大的差距。
九章智驾：所以，听下来，软硬件解耦没有达到预期，它不全是个技术问题？
郑心航：有技术问题，也有组织问题，但当前来说，更多还是技术问题。
九章智驾：但不管怎么说，中间件最初的“使命”就是帮助实现软硬件解耦。那易特驰作为中间件厂商，如果产品能帮助下游客户更好地实现软硬件解耦的目标，你们的市场占有率会不会大幅度提升？从这个角度来说，易特驰会不会把更好地服务于软硬件解耦当成一个很重要的目标？
郑心航：中间件能不能帮助实现软硬件解耦，这并不是一个非黑即白的问题。
一方面，达到PC行业那种软硬件解耦水平，确实不是我们要追求的目标；另一方面，我们也确实相信，在SOA架构下，可以实现上层的应用软件跟ESP等底层的控制器在逻辑上的解耦。
九章智驾：易特驰的部分基础软件和工具链是开源的，目前，开源的主要是哪些模块？这块的商业模式是怎样的？开源生态的实际进展是怎样的？开源面临的最主要的挑战是什么？
郑心航：开源的主要是跟云原生相关部分。 所谓云原生，即把传统IT行业内原来用于云计算那一套技术栈和解决方案搬到车里面，将其变成一个通用的计算平台，在底盘域、自动驾驶域、信息娱乐域之间进行一些跨域的数据采集、调度及计算；将对功能安全和实时性要求高的模块跟对功能安全和实时性要求低的模块解耦。
我们既向那些打算自研的主机厂提供开源的社区版产品，也向那些更倾向于跟供应商合作的主机厂提供企业版产品——企业版的功能安全等级更高，我们也可以根据客户的特定车型做大量的适配及验证、认证工作。
对不开源的部分，我们还可以跟客户共享IP，但这个是要 case by case去谈的。
九章智驾：博世对做标准化、平台化的产品是有“执念”的，但现阶段，主机厂对自动驾驶相关技术的需求都是高度定制化的，甚至会“为了差异化而差异化”，那易特驰是如何平衡平台化跟定制化开发的关系呢？
如果重心是提高产品的通用化水平，那如何解决适配性和兼容性问题（跟不同芯片、算法及其他公司做的中间件的兼容）？
郑心航：这是一个关于公司如何定位的问题。
从中长期来说，易特驰是一个产品化的公司，但当前，智能汽车产业正处于快速变动中，这意味着，在中短期，一定会有大量的市场需求是我们的标准化产品所无法满足的，因此，我们也愿意为主机厂提供定制化的解决方案。
与此同时，我们也会逐渐地将每家主机厂的特定需求进行提炼，提升它的复用性，然后形成标准化程度比较高的方案。
也就是说，在这个需求还不明确的领域里，我们不能一下子就推出一个庞大的全新的产品，而是在做一个个定制化的项目的过程中来形成未来可复用的能力，并最终形成新的产品。
九章智驾：我们在此前的沙龙上也听到类似的观点，就是说，标准化的东西，还是得在定制化内容的基础上去抽象。
郑心航：对对对。这也是博世长期以来的成功经验的总结。
九章智驾：我们之前听一些主机厂的人反映，工具链和中间件需要跟主机厂的研发流程高度匹配，因而只能以服务的形式提供，很难做成标准化的产品。那易特驰是如何看这一观点呢？
郑心航：每家主机厂的工作流程都不一样，为了让客户的工作流程跟我们提供的工具链和中间件相匹配，我们可能得提供一些工程咨询服务。
这个工程咨询服务，就是首先理解客户的痛点、梳理它的现状（至少包括技术和组织架构两个方面），然后再以咨询方式给它定制一整套的解决方案。当然，这些定制化方案中肯定也包括了大量已经很成熟的通用化解决方案。
下载ECAD模型
