汽车软件开发是很复杂的系统工程。
这种复杂经常让来自不同知识背景的我们，在观点交锋时出现鸡同鸭讲的滑稽。
解决复杂性和对齐讨论基准的一个方式是粗暴地具象化，比如，卡通画人像，寥寥几笔勾勒最关键的特征，很不全面，但足够典型。
本文期望，通过7个典型特点的抽取，来勾勒出汽车软件开发模式的特殊性和变迁性。
1
车载与非车载软件的分类及差异
既然汽车软件是非常复杂的，种类繁多自是预料之内，我们先来解决这个最基本的问题。
1.1 带物理盒子的车载软件
最正宗的汽车软件当属ECU里的软件，也就是车载软件。直观来看，就是固定在车上，并通过线束与电气系统或其他ECU连接起来的物理盒子。
ECU已经在汽车行业存在了近60年，但直到现在，ECU仍然是谈论汽车软件时的主要对象。
只不过，随着汽车电子电气架构的演变，ECU的功能越来越集中化，也即现在炒得热火朝天的域控或中央计算。
无论如何，形式上来看，ECU或DCU都是嵌入在物理盒子里的车载软件产品。
对于汽车软件而言，这个特点就如同爱因斯坦的鼻子一样突出。
1.2 车载软件的内涵
除了形式，再看功能内涵。
首先，基于这两年广泛流传的博世五域划分，可以将车上的电子软件功能进行分区，即动力域（车辆运动）、底盘域（安全）、车身域（车身电子）、座舱域（娱乐信息）和自动驾驶域（驾驶辅助）。
这五域划分可以给我们一个大框架的参考，但对于我们区分开发模式来说，并不够友好。
进一步地，车载软件可以划分为四类：
第一类：与整车高度耦合或安全等级较高的模块，如发动机控制、电机控制、刹车控制、电子助力转向控制、车身稳定控制系统ESP、混动系统控制、安全气囊控制、电池热管理等。
第二类：功能独立且安全等级较低的车身控制模块，如网关、照明控制、雨刮控制、车门车窗控制、无钥匙启动、天窗控制、座椅记忆控制、后视镜控制、功放控制等。
第三类：智能驾驶，ADAS、AD及附属的雷达或摄像头传感器等。
第四类：智能座舱或说车机，主要是以各类大屏为承载的软件。
1.3 非车载软件
除了车载软件，还有一部分是非车载类软件，他们也广泛地存在于汽车行业的各个领域。
包括云平台（如数据埋点后台、电池状态远程监控、OTA运营平台）、工具链软件（详见《拆解一下汽车电子软件开发工具链》）、生产用下线电检软件（EOL，End Of Line）以及手机车联app和车机上的第三方app。
其中，云平台与app和互联网软件比较接近，车载软件和互联网软件则是完全不同类别的东西，谈论主体的不一致经常是两个行业背景的人进行鸡同鸭讲的原因之一。
当然呢，现在这些非车载软件还没有形成稳定及具规模的生态，所以本文后面部分仍然主要基于车载软件展开。
但是，V2X总是趋势，值得我们不断加强关注。
以上软件种类的划分会直接影响到后面6个特点的分布与侧重，阅读时可做关注。
2
从代码到整车的5层集成
汽车软件种类繁多、模块众多，而且需要装在整车上跨模块、跨域体现功能。
所以，只要电子电气架构的集中化没有走到中央计算和云计算，只要供应链各方的软硬件自主权没有被收归一统，多层集成就不可避免。
按照当下的架构发展阶段，我们可以把汽车软件的集成分为5个层次：
将软件单元集成到一起
将软件集成到硬件上
将硬件集成到机械壳体上
将ECU 集成到子系统中
将子系统集成到整车上
有关这部分内容，详见《汽车软件集成的5个层次》。
3
联调与整车级评价
汽车软件开发是个各模块或功能域协作的过程。
一直以来，大家习惯于在各自的电脑上、台架上完成开发与验证，然后在集成点处进行确认。
“各人自扫门前雪”的协作惯例能让分工清晰，也会让几乎不可避免的问题延后暴露。
因此，部分与整车环境依赖关系比较紧密的模块（第一类）会提前进行联调。
很典型的是安全气囊控制器。
整车碰撞试验会花费高额的成本，一旦试验失效，时间和金钱都是巨大浪费，前期的联调非常必要。
比如，安装方向、传感器位置、线束连接、电阻范围、DTC状态、软件版本及对手件响应等的联调确认。
当然呢，安全气囊太成熟、太传统、软硬耦合程度太深了。
与其他模块或整车耦合程度没那么高的模块（第二类），联调必要性就会减弱。比如，简单的天窗控制模块和方向盘加热模块，可能台架上连接一个电机和加热垫就绰绰有余。
智驾和座舱逐渐脱离了传统汽车软件开发模式，而二者之间也有些不同。
智驾的开发验证可以依赖一部分仿真模拟，但终归需要整车的调试标定，尤其需要运动控制部分的功能完善。
智舱集成了大量的人机交互内容，无论是控制指令的发出，还是反馈信息的投屏，大屏正在变成人与车的I/O口，这让座舱的开发颇为困难，所谓联调或者协同验证的意义和必要性也十分显著。
总之，我们已经看到了这样的趋势，联调正伴随着架构的集成化逐渐演变为对整车整体的评价。
4
开发验证受制于实车环境
仿真也是个非常古老的东西，但它的发展看起来始终有些缓慢，汽车开发的各层级开发验证，都难以离开真实的物理环境，也就是车。
车很贵，工程车尤其贵，退而求其次，大家用模拟信号与负载、用简易台架加ECU、用白车身、用拼凑的实车......
而求其次自然会求来软件版本不对齐、验证负载不充分、暴露问题不及时等等各类次的问题。
受制于样件和实车的环境是汽车开发的特点，特别地，在架构融合的过渡阶段，更耦合的功能、更多的交互，会让现在这种单一仿真环境凸显出更大的问题。
5
要考虑生产
一切的软件都需要进入整车，从整车层面解决客户需求，而进入的第一步和主要步骤还是通过生产装配，特别是对于第一类软件。
所以呢，我们做汽车软件要关注制造、关注生产。
原因有二：
OTA技术、流程和监管还不足够成熟，我们还不能自由OTA。
现有的标准化生产方式仍然足够安全可靠。
6
ASPICE
ASPICE也曾被人捧上神坛，最近一两年，大约是因为全行业灰头土脸，精致昂贵的ASPICE逐渐被人报以微笑
。
反复思考、反复调研，我认为ASPICE还会一定程度地回归，会随着行业生态的恢复和产品方案的成熟逐渐体现出其必要的规范性意义。
但是还有一点要说明，ASPICE的分层意义可能会随着架构集中的进一步发展而减弱，比如，软硬解耦后，软件开发中一直关注的系统（软+硬+...）就没太大存在必要了。
有关ASPICE的解读，详见以下三篇文章：
《汽车软件过程“阅卷准则”之ASPICE 3.1品读（上）》
《汽车软件过程“作文提纲或模板“之ASPICE 3.1品读（中）》
《汽车软件过程“满分作文“之ASPICE 3.1品读（下）》
7
功能安全
功能安全正在像ASPICE一样，面临一个相对尴尬的境地。
原本呢，这部分算是传统汽车暨三大件被绕过后还剩余的技术门槛，但是，新势力进来后，先是一波高薪，两三年就培养出一大批功能安全工程师，人才多少是有点饱和了。
年初，特斯拉又掀起一波价格战，多米诺骨牌，各大车企还陆续开启裁员。一阵寒意后，功能安全？饭都吃不饱了，自己都不安全了，还管功能安全不安全。
很显然，特别是对于第一类（与整车高度耦合或安全等级较高的模块）和第三类（智能驾驶）软件，功能安全非常重要，只是这个魔幻的阶段暂时让它无所适从。
8
全文小结
汽车软件是有些行业与产品特殊性的，本文总结了7个相互有关联的特点：
讨论总是需要在同一概念基础上的，所以首先区分了汽车软件的分类，最典型的当属车载软件，我们按照开发模式的差异性分成了4类，而行业的方向正在向非车载软件延展。
对于分布式架构和协同供应链下的车载软件，多层集成是其非常直接的特点，大体来看，从代码到整车可分为5层。
每个集成点都是一个接口，接口之间是需要联调的，尤其对于跨模块、多接口的复杂系统。而随着架构的集中化，这种趋向整车级的评价会是越来越突出的趋势。
在仿真足够真实之前，出于成本的考虑，开发始终会受制于实车环境。
同样地，在OTA足够可靠之前，汽车软件不得不考虑其对生产的影响和生产对其的影响。
ASPICE和功能安全是不同性质的要求，但都是期望将行业的躁动按住一点，将开发的混乱规范一点，将安全的地位拔高一点，但是现在的环境暂时让二者难以生存。
9
写在最后
汽车软件的特点与两个老生常谈的概念密切相关：软件架构的软硬耦合和整车电子电气架构的分布式。
而伴随着软硬解耦和架构集中化，汽车软件的特异性会逐渐地演变，乃至消亡。
完
原文标题 : 汽车软件开发模式的7个特点
相关推荐
-
解读汽车软件测试之“软件需求测试”
《解读汽车软件测试之“软件单元与集成测试”》 接上文。 第二篇针对软件需求测试。软件需求测试有时也被称为软件功能测试或者直接简称为软件测试。 1、概述 软件需求测试是汽车软件测试的第四级别
-
汽车软件开发V模型的本质
太多人在讲V模型了，但越是司空见惯的概念，似乎越让人难以达成共识。这篇文章给出我的观点。开发模型其实有很多，比如，增量式、原型式、螺旋式、喷泉式、W模型等。限于篇幅且必要性不大，我们不讲那么多。其实，
-
自动驾驶革命：解密端到端背后的数据、算力和AI奇迹
作者 |毫末智行数据智能科学家 贺翔编辑 |祥威最近，特斯拉FSD V12的发布引发了业界对端到端自动驾驶的热议，业界纷纷猜测FSD V12的强大能力是如何训练出来的。从马斯克的测试视频可以大致归纳一
-
汽车软件质量这个活儿到底该怎么干？
熟悉的朋友都知道，我的聚焦点在于汽车软件研发管理上，而企业专职研发管理的职能经常落在质量的角色上，但我很少专门写这个角色的文章。原因是，我始终觉得软件质量的“工夫在诗外”。不过，出于对这个职能的尊重，
-
一名汽车软件项目经理的34个能力点和对应的5个级别
有些朋友问我，如何评价项目经理这个职能？我通常的看法是，门槛很低，上限很高。这篇文章会更聚焦些，谈谈汽车软件项目经理如何从“入门”走到“很高的上限”。134个能力点（6大领域）人的能力是很多元的，在谈
-
一份汽车软件需求的生成过程
这是来源于ASPICE 3.1的一张追溯图，非常流行。尽管ASPICE并不是绝对的标准，但我们可以作为讨论框架。今天讲的是软件需求。1生成软件需求的4个步骤抛开理论，面对一个真实项目时，首先该思考的是如何一步一步展开工作
-
汽车软件单元测试的要点与意义
测试是一个非常基础的概念，这种基础让大家可以随意在它前面添加各种定语。 尽管这种添加的背后多数是不同的分类维度，但让测试本身成为了繁杂概念的集合，这也让我们总有种无法把握的烦躁感。 单元测试就是这堆让人烦躁的繁杂概念之一
-
一文深扒“确定性执行”
本文来源：智车科技 确定性执行是目前汽车电子市场的技术热点，但是笔者仍觉得此项技术需更多的验证，因为这项技术是有难度的，对系统的稳定性、鲁棒性都有要求。此外，确定性执行是否适合所有的域控制器仍然是一个未知数
-
拆解马斯克FSD V12自动驾驶直播
马斯克最近试驾直播了特斯拉最新自动驾驶软件FSD V12，马斯克表示，FSD V12基本上重写了之前所有的代码，采用了从感知最后到车辆控制的端到端大模型算法，大约 99% 的代码都是神经网络的。特斯拉的 FSD V12 的工作原理就像人脑一样，使用神经网络和眼睛（摄像头）
-
自动驾驶汽车在实际应用中需要解决的技术问题
新能源汽车自动驾驶是指利用先进的传感器、计算机和人工智能技术，使新能源汽车能够在不需要人工驾驶的情况下自动行驶和执行各种驾驶任务。自动驾驶汽车在实际应用中需要解决以下几个关键技术问题：传感器技术：有效的传感器系统是实现自动驾驶的基础
