押注单芯片市场趋势 智能汽车架构的演进之路

每一个人、每一个组织乃至每一个社会，在达到某一点时，都应“点击刷新（Hit Refresh）”——重新注入活力、重新激发生命力、重新组织并重新思考自己存在的意义。

——微软 CEO萨提亚·纳德拉《刷新》

OpenAI正让微软重新成为全球最领先的科技公司，放在10年前这完全不可想象，而随着新四化颠覆了整个汽车产业，汽车的定义也在悄然的发生着改变。

过去硬件决定汽车高度，现在软件重新定义汽车，其中，整车架构、智能座舱、智能驾驶成为了未来汽车新的发力点，而身处汽车智能化的时代，随着苹果、华为、英伟达、高通以及亚马逊等巨头全部入局智能汽车，供应商格局面对着更大范围更深度的重塑。

打造一个智能汽车驾驶的技术生态闭环，成为这个赛道的最大公约数，是这些玩家的终极目标。

做最大公约数的条件有二，其一是构筑自身技术护城河，解决行业难题；其二是能够链接创新资源，衍生强大生态。

这背后，离不开一个强大的架构作支撑。比如地平线的Together OS 模式把BPU跟SoC开发完后，中间的底层软件通过开源OS开放的模式跟整车一起系统开发；毫末的DriveGPT大模型的应用,在自动驾驶系统开发过程中带来了巨大技术提升,使得毫末的自动驾驶系统开发彻底进入了全新模式。

东软睿驰提出的框架则更“厚”，其提出的openVOC(Vehicle on Chip)，其是在单芯片的行业趋势下将绝大部分智能化应用尽可能放在一颗芯片上去实现，基于服务化接口访问车上的全部硬件功能的开放，将为智能汽车的发展带来极大的想像空间。

而无论是什么方案，产品一定要是对的形态，能完成对用户心智的转变，并且方案小于它给整车带来的产品溢价，如此一个闭环的商业逻辑才能成立。

这也成为整个产业“刷新”的重要意义。

创新者的“窘境”

哈佛商学院教授克莱顿·克里斯坦森提出了“颠覆性创新”理论，颠覆性创新带来了巨大能量，但同时创新在推广过程中势必面临复杂的系统性困难。

类比汽车产业，电子电气架构也正在从“诸侯割据”走向“天下归一”的时代。随着大算力芯片的发展与车企需求多样性激增,行业进入到跨域融合的新阶段。例如岚图的中央集中式 SOA 电子电气架构以中央控制器 OIB、区域控制器 VIU、车联网终端 T-BOX 为核心，将车上 14 个控制器结合到一个 OIB 中央控制器之中，通过总线带宽、电子控制器算力、集成度、服务化等技术提升终端用户体验，快速响应市场新需求。

但面对创新时，行业往往也会进入到创新者的“窘境”。

比如罗伯特C.马丁在《架构整洁之道》曾指出：软件开发并不是增加人、增加投入就可以解决的。当前，伴随汽车智能化创新落地进程的加速，汽车软件极高的复杂度、庞大的规模前所未有，软件工程师的人数、成本会随着软件版本的升级呈指数级上升，但软件的生产效率却是停滞的，工程师的生产力随着版本的升级迭代呈明显下降趋势。整个汽车行业都在新E/E架构、软硬件调试以及开发方法等方面做大量的投入，但进步的轨道和速度仍然不能按照期待的时间去完成。

最明显的窠臼如下：

一是时间的消耗。当智能汽车引入新的软件、新的芯片、新的技术，传统V字形或瀑布式开发方法的工程落地难度非常高，比如目前自动驾驶、智能座舱、车身等各个域之间实现跨域联动，各领域的软件开发人员在一起开发、修改代码时间成本过高，一旦发现Bug需要重新编译、调试，开发人员之间的协作成本面临巨大浪费，这种开发方式已无法应对百万量级的代码数量，甚至经常面临全新开发一款车型，代码就要全部重新做一遍的情况，而且主机厂在涉及组合功能的开发过程中主要是通过需求文档的形式下发给各个供应商，但各个供应商对需求的理解可能会出现偏差，从而在调试期间花费大量的精力。

二是成本的摊销。智能汽车的主要成本可分为两类，一类是创新成本，一类是将创新特性搭载上车的成本，即工程成本。有非常多的工程师进行调试适配和标定等，特别在软件方面的投入，包括整车改Bug、软件重构的成本是否能在单车型中去摊销？尤其在当下新车型的开发周期越来越短、数量越来越多、市场越来越细分的背景下，单台车的销售收入是否能够负担巨大的软件成本？粗略估算，目前工程成本远高于创新成本，比例是50:1。

两个因素的叠加，导致目前的车企虽然“卷”得凶猛，整个汽车产业都在忙于创新，导致没有时间和精力在一个确定性的方向上持续打磨、提升，其实并没有建立起品牌独特性。

解题“局中局”：要“以终为始”也要“软件先行”

既然面临明显的痛点，行业则需要在颠覆传统的V字研发模式的拐点中，就要构建一种全新方法学和开发框架，从而实现软件充分的复用、高效的迭代。

这是一种方法论、进化逻辑的一脉相承与交替互补。

开发框架的更新，需要依托整车E/E架构的进化。从博世对 E/E 架构定义来看, 汽车 E/E 架构的升级路径表现为分布式(模块化→集成化)、 域集中(域控制集中→跨域融合)、 中央集中式(车云计算)。

但目前，每一代架构的演进、迭代所投入的工程开发成本都十分巨大。比如在分布式的E/E架构中，汽车内的硬件既需要传统的MCU，用于保证高安全性高稳定性，又需要集成SoC、各类硬件加速器的域控制器，MCU的成本与SoC的成本有着10倍不止的巨大差距，以特斯拉AP 3.0方案为例，SoC芯片约占智能驾驶域控制器成本的40%。

面对汽车行业在E/E架构、软硬件调试以及开发方法等方面做大量的投入，全新开放框架的使命就是破解成本与时间鸿沟的死循环。

如何破解？东软睿驰总经理曹斌提出了一个“反常识”的逻辑。

如果按照E/E架构的演进思路，未来只有迁移到中央计算+车云一体的架构中，实现跨平台、跨车型可复用的开发模式，软件的开发成本和运行成本才会同步降低，那以终为始，全新的技术开发框架就应该按照最终架构的形态去构想。

例如openVOC开放技术框架，成为东软睿驰在不断赋能车企量产实践过程中为汽车产业破解成本与创新问题提出的一种解码方式。

openVOC即将绝大部分智能化应用尽可能放在一颗芯片上去实现，其软件架构应更加开放，任何一个应用，可以通过软件的服务化接口，访问车上的全部硬件功能。这些服务化接口以及基于这些服务化接口的开发方法能够被第三方软件开发者很容易地获得，软件具备与平台和整车的“兼容性”，能够单独的迭代，被无数次的集成，最终能够让更多的创新思想、特性能够更容易、快速地去导入到车辆平台中。

与实现框架落地相呼应的，是软件开发的前瞻。

东软睿驰提出的“软件先行”开发方法学，是通过提供工程问题与应用开发彻底解耦、并行展开的一套方法学，优先把开放框架中功能上可能会产生的一些课题先解决掉，基于一体化的开发框架，上层应用软件的开发独立于硬件，并可根据量产需求对硬件灵活升级或替代，到量产阶段将软件模块迅速迁移。

由于真正实现的软硬解耦、甚至是软软解耦，落地到具体开发场景中，开发A应用模块与B应用模块的人员甚至都无须见面，就可将不同应用组件在标准的、统一的平台进行组装式、集成式的模块化开发。

这就类似计算机就是从分布式到集中式，显示核心、存储控制器、PCIe控制器早期都集合在主板的北桥芯片，如今全部被封装进CPU，不仅有数据处理单元，还有图像处理单元，处理效率肯定更快，将具有策略性和复杂性的逻辑软件，部署在中央计算平台，使软件复用和快速迭代成为可能更易于管理。

由此产生的成本与效率优势，将会是肉眼可见的提升。

“承上启下”才能支撑开放框架

E/E架构的演进需要开放框架的支撑，开放框架的量产落地，也同样离不开其中的关键组件和模块。

尤其在未来的单芯片方案时代，芯片内各个组件之间资源混合的使用，通讯的协同，处理器应用的部署等等这些问题，这些问题都需要在早期阶段去解决，所以类似于openVOC这样的开放技术框架在构建过程中，对于中间件、通讯基础设施以及相应的一些功能组件提出非常高的要求。

标准化的服务接口，是构建人车交互应用与整车控制应用中重要的一环，这将助力开发者打通服务之间互相的访问和互动，而且打通车内所有的控制系统，开发应用只需要针对消息总线就可以跟整车实现互动和集成，集成的成本应该是呈指数降低。

这也就是曹斌之前提及的形象的作用比喻——承上启下。向上能够提供标准、可复用、稳定的中间层框架，为应用迭代开发提供基础；向下提供标准设备驱动模型，与硬件相互促进，形成“摩尔定律”。

践行承上启下最经典的架构就是AUTOSAR，其为业务应用程序和基础设施提供各种功能，如消息传递、事务处理、安全、数据管理和缓存等，增强应用程序之间的互操作性、可靠性和可扩展性，企业能够提高开发系统的效率和降低对系统的维护成本。

东软睿驰为openVOC开放技术框架的量产落地搭的一整套软件开发平台——NeuSAR，作用也是使得服务界面、通讯界面能够很好地被定义，第三方开发者更便捷高效地进行软件开发。

东软睿驰NeuSAR aCore 、cCore构成了符合AUTOSAR标准的基础软件开发平台，NeuSAR 消息总线构成了实现openVOC软件架构中多个异构核之间统一的通信平台。据了解，应用开发框架NeuSAR SF（Service Framework）中最新补充Python开发框架，提供针对NeuSAR基础模块的Python语言开发接口。

对于程序员而言，Python是最适合零基础学习的编程语言， Python具有简单的语法，高代码可读性和易于输入的特性。开发者可以使用Python语言调用NeuSAR的基础功能，从而降低开发难度，并通过提供Web Service调用方式，与云端更好地兼容。

同时，整车开发中涉及到的模块适配周期也将会大幅缩短至一至两周，如果主机厂需要在这上面开发的应用的话，这个适配的过程通常是两三个月的时间，那也就是说可能不到四个月一辆整车的软件功能基本已经具备，如果车企的自己的硬件也如此开发的，可能半年的时间基本上就可以进入到一个准量产的状态，就可以进入到整车测试，这个周期的缩短是非常的大，并且开发成本都非常低。据了解，目前东软睿驰已经有经过此番时间验证的合作开发流程车型，即将量产落地。

未来的生态“无限游戏”

在汽车软件开发架构的演进中，无疑将会有更多的优秀、独立软件开发者参与到汽车智能化的发展之中，产业资源得到扩展，软件创新更加繁荣。

詹姆斯·卡斯在《有限和无限的游戏里》说道：有限的游戏，目的在于赢得胜利；无限的游戏，旨在让游戏永远进行下去。有限的游戏在边界内玩，无限的游戏玩的就是边界，它的目的在于将更多的人带入到游戏中来，从而延续游戏。

把供应商卷死，把友商卷死，最终的结局就是把自己卷死的结局，在汽车行业，技术的突破是一方面，商业的突破其实更难，因为它还有很高的信任门槛，车厂对于供应商的选择都是风险厌恶型的。

新的架构，新的开发理念、新的方法，才会产生新的生态。

在曹斌看来，行业生态的打造应优先于个别企业的做大做强。因为生态的健壮性、抗打击能力、存活能力比大型企业要重要许多。各个企业要围绕生态去构建更有活力、更有存活能力的产业基础。

这也正是本土供应商纷纷构建生态的出发点。一般认为，东软睿驰只是一个汽车软件公司，其实公司在域控制器方面也有着深厚的积累，自2015年成立至今，东软睿驰构建了以NeuSAR为核心的基础软件、中间件、工具链产品阵列、自动驾驶领域形成智能前视摄像头、行泊一体域控制器集中式中央计算单元等系列化家族产品，并构建了智能化车云协同的数字底座，在积累了成一定规模的量产案例的同时，也为其筑起极深的生态和技术护城河。

生态的构建，还有技术规范的引领。2020 年，在工信部指导下，东软睿驰牵头联合20余家车企与产业链上下游企业共同成立AUTOSEMO，代表行业首发了《中国汽车基础软件发展白皮书1.0》与2.0版本，并积极参与筹建AUTOSEMO基础软件信息安全工作组、操作系统技术生态工作组等工作。与上汽零束、广汽研究院、一汽集团等国内主流车企以及零部件供应商单位进行ASF（AUTOSEMO Service Framework）、车云一体技术等技术规范的立项、调研、组织修订和编制等工作，这些技术规范已经在广汽、上汽相关车型中量产落地。

双向奔赴才是这个“快鱼吃慢鱼”时代的生存法则，“风物长宜放眼量”，共创共赢的开发生态才是这个时代行稳致远的真理。而随着openVOC等开放技术框架的落地，智能汽车行业的开发方式或将被重塑，更重要的是，将为消费者的驾驶乃至生活方式带来更大的想象空间。