文/Gavin Cheng
近日里，拜读了多位大佬关于软件定义汽车的文章，颇有感触。作为一名在汽车行业奋斗多年的老兵，本着Good Good Study, Day Day Up的要求，现向各位同仁分享下个人的浅见。
在软件定义汽车的变更思潮下，汽车行业本身的变化、主机厂和供应商的变革以及相关技术的升级和更新已经在多位大佬的帖子中有相关的讨论，这里不再赘述。本文将从主机厂的角度出发，从四个方面分析主机厂的“内功的修炼”。
1. 组织架构调整
首先，相对于造车新势力，传统的主机厂大多属于庞然大物。考虑到是聚焦一个车型平台或车型的开发，因此仅针对该层级组织架构加以讨论。
从国内众多主机厂的组织结构来看，一个车型平台或车型的开发执行组织机构通常包括：动力域、底盘域、新能源域、智能驾驶域、车身域（或电子电气域）等，与之匹配的还有财务部、采购、试制、工厂和销售等，不同的主机厂可能在部门划分和命名上略有不同。 在此基础上，不同的主机厂因各自实力不同，再以项目为单位，按单军团或是集团军的形式开发整车，征战市场。
在软件定义汽车的浪潮下，各家主机厂基本都做出了相应的组织调整如大众、上汽等，先后成立相关的软件开发部门或公司。但问题是，调整后的组织架构能否匹配该公司现有整车开发和软件开发成熟度，进而缩短整车开发周期和降低成本？因此，个人认为调整后的目标组织应从如下三个维度加以评估：
1、整车开发和软件开发成熟度的匹配：（1）整车开发是正向开发还是半正向开发？（2）整车电子电气架构是集中网关式的、域控制器式的、Zonal控制器式的、还是中央集中式的？（3）整车核心控制器或模块的软件是外委开发、同第三方联合开发、还是独立开发？（4）目前公司现有软件开发人员数量和能力等。调整后的组织架构在保证整车开发的基础上，优化和促进软件开发流程的落地。
2、组织架构的进化：调整后的组织架构不是一成不变的，伴随着一个个车型项目的开发过程，主机厂的软件开发成熟度的升级、软件开发人员团队的壮大、行业的软硬件基础环境的更新，竞争对手的提升等因素，当量变达到质变时，主机厂需要及时调整各自的组织架构。
3、独立的话语权：主机厂的领导或高管多是动力、底盘等出身，而当前的软件开发部门或公司的领导多是从电子电气或其他软件行业产生，暂且不论不同平台或车型的软件开发策略，该软件部门在技术上的话语权是必须在组织架构层面上得到保证的。
2. 整车开发流程优化--软件开发流程的定义
下图是网上找的国内某主机厂在2010年前的整车开发流程，其中是没有整车级的EE架构及电气开发流程的。经过这么多年的发展，该流程的升级版已经包括的整车级的EE架构及电气开发流程（或类似的流程）。
说个题外话，有人将未来的汽车形容成“一个智能手机+四个轮子”以说明软件对汽车的重要性，但个人认为，无论多么智能的手机，如果无法实现打电话或通讯的功能，则不能称其为手机，毕竟人们在购买手机或平板电脑时需要的服务是不同的。
同理，无论车辆多么智能、安全、互联，如果不能提供基本的出行服务，则其就不是汽车，人们也不会为了满足出行服务而购买。
再回到整车开发流程。如图所示，不论软件如何定义汽车，整车开发过程中，产品规划、成本、市场、质量、造型、采购和制造等非软件工作的绝对工作量并未有丝毫的减少，但由于软件设计开发等工作的绝对工作量的增加（目前在研的主流车型控制器数量在80~120左右，而市场在售的一般家用车型控制器数量在30~50左右），导致软件及相关工作在一辆整车开发工作总量中的相对占比大幅增加，参考未来的市场发展和汽车的新四化，软件工作占比还将持续增加。那么在这样的形式下，主机厂要如何确保整车项目的顺利开发呢？答案是定义整车级的软件开发流程，这对于任何一个主机厂都是在接下来几年内必须要解决的一个问题。整车项目级的软件开发流程的建立应从以下三个维度加以评估：1、同现有整车开发流程的匹配：以整车制造流程为例，需要根据造车目标，定义整车功能成熟度，进而明确在每一轮造车前软件的功能成熟度。据此，排布定义每轮造车前的软件设计、开发和验证等工作的要求和时间计划。在软件工作量占比不断增加的背景下，在整车开发过程中，保证软件开发工作同其它工作流程（如造型、制造等）的匹配，进而保证整车项目正常交付和上市。2、流程的兼容性：考虑到不同车型平台和车型的开发范围和策略的不同(全新车型平台、动力升级车型、上车身升级车型和年款等)，整车级的软件开发流程，要能够适配不同的开发范围、开发时间和造车要求。3、流程的进化：分析内容可参看方面一中“组织架构的进化”。
首先要说明，作为最后讨论的整车功能需求数字化平台的建立并不是不重要，恰恰相关，在本文讨论的三个方面中，它可能是主机厂后面几年或相当长的一段时间内需要静下心、认认真真、踏踏实实去做的一件事。做成，则企业活下去。不成，和马克思谈理想去吧。无论是软件定义汽车还是其它相关的说法，个人认为，它只是给未来的汽车发展提供了一个手段或思想，而一个正向开发真正落地的经过车型和市场检验的整车功能需求平台才是每个主机厂生存下去的立身之本。而目前，多数主机厂的整车功能需求定义中存在的典型问题如下。1、功能设计工具及平台问题。如功能、系统和ECU的设计开发以Word等描述性文档为载体，主机厂各部门间、主机厂同各供应商间据此执行整车的设计开发。真是一场正在经历的噩梦，每天都是无休止的会议沟通、协调和扯皮。2、系统设计没有按照功能需求定义执行。由于部分控制器是半正向开发或主机厂工程师能力不足，系统设计需求定义有歧义或存在未定义的部分，结果就是供应商做成什么样，主机厂就用什么样的，如果要按需求更改，要么是无休止的扯皮，要么就是拿钱解决。3、整车和EE架构平台落地后的异形问题。主机厂的需求变更频繁或为了降本和规避开发风险引入多家供应商，直接导致车型平台化开发无法到达预期目标或打着平台化开发的旗号各自为战，进而造成落地后的EE架构平台和设计目标相去甚远。1、整车功能复杂度与整车开发周期的矛盾，目前以100各控制器的整车为例，一个开发迭代周期在20~30周左右（各家主机厂略有不同），这个周期还可能被延长并且软件质量无法有效保障。如何保证整车功能在计划和预算内高质量的交付是我们大家要思考的问题。2、整车功能或软件异常时问题的责任与解决。现在整车出了问题，有供应商 来承担，因为软件是他们开发的。可未来，应用软件是有主机厂独立开发或同第三方联合开发的，那么出了问题要怎能解决呢？ 参考目前某些主机厂独立承担部分软件开发的部门或公司，如果真的出了问题（软件程序Bug或无法按时交付等），通常的做法就是“躺在地上装死”， 毕竟都是一个老板，你有问题可以上升啊！等到老板最终拍板了，不论拍板的结果如何，这个拖延的时间是争取到了。3、整车数字化平台建立的基础。在整车功能和需求平台的基础上，引入SOA 进行整车软件开发，因而，主机厂需要梳理和细化定义原子服务、组合服务和业务服务等，结合最终的EE架构、基础软件平台、控制器平台等形成整车功能需求数字平台；如果整车功能需求平台没有建立好，那么在其之上的整车功能需求数字平台就是一个空中楼阁，至于基于SOA的整车软件的开发更是没指望的事情。为解决或规避上述问题，为整车数字平台的搭建做好准备，现阶段个人认为主机厂应采用如下几点建议。1、基于模型的系统设计即MBSE。借用前人的话：MBSE下，工程研制工作由过去的“80%劳动、20%创造”转变为“20%劳动、80%创造”。2、改革组织架构和健全开发流程，确保技术部门，尤其是软件部门在整车开发过程中的话语权，明确权责定义。用组织架构、流程等驱动和保证设计活动的有效落地。3、 整车功能需求数字平台的落实，以“研”为主，以某车型为载体，分阶段、分模块的试制落地。4、匠心造车。说易行难，希望各主机厂能够从领导到工程师，静下心来，踏踏实实的把自己的平台做好，以车型开发实践来验证。最后，再次重申，无论是软件定义Anything、SOA、RTOS、BSW抑或是MBSE，它们都不是什么新东西，在其它行业已经存在并应用，主机厂只是需要在本次行业技术升级和市场迭代中应用它们以获取最大的优势，取胜之道还在于内功的修炼。