导读
“ 软件定义汽车给汽车产业带来了新的机遇，同时它也给汽车研发带来了新的危机。我们希望能去掉“危”而抓住“机”，追赶汽车研发变革的风口。”
参观了2023年的上海车展，新汽车的展台摩肩接踵，传统汽车的展台热度不敷往年。又看了同期纽约车展的视频，暮气沉沉的纽约车展与新锐的上海车展好像处在不同的时空位面。面对这样的场景，内心真是无限感慨。近些年，中国汽车行业将是一个高度“卷”的时代，“卷”完国内再“卷”世界，大家都在拼命狂奔向前。软件定义的新汽车就如同一辆漂亮的跑车在一路狂奔，然而它的前路可能是水坑，也可能是泥潭。我们需要看清前方的道路，把握好汽车的方向，才能避免状况的发生，最终在“卷”的狂潮中幸存下来。为了成为存活最久的那个人，我们需要擦亮双眼，探索发现问题，再分析问题找到问题的答案。我们先从软件定义汽车的定义入手：软件定义汽车(Software Defined Vehicles，SDV)即软件将深度参与到汽车的定义、开发、验证、销售、服务等过程中，并不断改变和优化各个过程，实现体验持续优化、过程持续优化、价值持续创造。这里可以看到，软件定义汽车有别于传统汽车，它的典型特征是软件的“深度”参与和“持续”变化，也就是说汽车相关软件的变化会深度参与到汽车的整个生命周期中。软件定义汽车的新特性给汽车产业带来了想象空间。正如现在人们常说的，软件定义的汽车等于加了四个轮子的手机。汽车也可以与手机一样，产品交付到用户手中的时刻，不再是产品研发的终点，反而是汽车软件研发全新的起点。在汽车的生命周期中，各种汽车的应用会如同手机应用一样被安装到汽车上，给汽车赋予全新的能力。既然汽车是安装了四个轮子的手机，那么我们是否可以用手机生态的研发逻辑来指导软件定义汽车的研发呢？显然是有问题的。软件定义的汽车既有计算机相关的部分，也有“四个轮子”的机械部分，汽车产品是一个高度复杂的综合体。并且，汽车是交通工具，它具有很高的功能安全要求，这也是手机产品不具备的特征。显然，这些特征决定了手机研发模型无法完美支撑软件定义汽车的研发过程。理论的危机
“理论来源于实践，但科学的理论形成之后又对实践产生重要指导作用，对人们从事新的实践活动提供必要理论指导” 。软件定义汽车是新生事物，一切都在发展中。现在，软件定义汽车研发不缺少实践过程，然而理论创新也需要提到议事日程上来，为研发实践提供必要的指导。
我们知道，传统汽车研发有成熟的理论模型即V模型。V模型是对瀑布模型的细化和完善。它本质上是测试驱动的研发模型，每个开发阶段都对应一个测试阶段。V模型是一个高度严格的模型，下一阶段依赖上一个阶段的输出，工作必须一个阶段一个阶段地进行。V模型为传统汽车产品的高质量交付提供了理论支撑。V模型是基于SOP（start of production）为研发终点而建立的过程模型。V模型为传统的汽车制造提供了很好的面向终点的过程约束。但是，V模型继承于瀑布模型，因为瀑布模型的特征，导致研发开始之前，必须有非常明确的需求，这也导致需求的变更会带来非常昂贵的研发代价。不得不承认，V模型在汽车行业的影响是非常深远的。比如汽车行业非常流行的ASPICE和各种基于V模型的汽车相关标准。但是，对于软件定义汽车，V模型的影响力反而是新汽车研发的负担。汽车行业研发人员在V模型的影响下思维模式根深蒂固，面对软件研发敏捷性的要求，这里需要的是改变，首先是思想层面的转变。传统汽车研发理论无法适应新的挑战，那么他山之石可以攻玉吗？从2023年上海车展博世公司的展台可以看出，汽车行业正在借用“他山之石”，如下图。图中莫比乌斯环的造型，正是互联网生态流行的DevOps研发模型。图2：2023年上海车展博世展台的DevOps造型
我们先看看DevOps的定义：DevOps（Development和Operations的混成词）是一种重视“软件开发人员（Dev）”和“IT运维技术人员（Ops）”之间沟通合作的文化、运动或惯例。通过自动化“软件交付”和“架构变更”的流程，来使得构建、测试、发布软件能够更加地快捷、频繁和可靠。
图3：DevOps模型
DevOps强调使用敏捷的方法提供更快的产品交付的速率，比如可以支撑业务部门“每天部署10次”的要求，为了支持这个过程，强大的自动化手段是一切的根本保证。DevOps理论是经过实践的，是在现今互联网世界行之有效的生产利器。DevOps在互联网世界的成功，正是很多汽车企业争相引入DevOps研发理念的根本原因。互联网世界的DevOps，诞生于互联网，服务于互联网，水乳交融。但是，面对汽车的世界它却有些水土不服。互联网的DevOps是工作在可控的计算机环境中，它是一种全部电子化的，纯数字化的，“软”的生产空间。它是环境可控，输入输出可控，自身模型已经数字化的工作环境，这是人类现今最理想的数字生产环境。然而，软件定义的汽车，除了“软”的一面，还有“硬”的一面。不能忘记，软件定义的汽车是加了四个轮子的手机，除了“手机”之外还有“四个轮子”。汽车是复杂的软硬件结合的混合体，它“硬”的一面就导致了它验证成本会成指数级的增加，DevOps的循环速率会被严重拖慢，甚至成为断裂的莫比乌斯环。汽车是运行在开放环境的物理实体产品。汽车与环境，汽车与人，都发生复杂的交互和反馈。换句话说，汽车被复杂的物理环境和人类活动等因素扰动，再加上无法量化的汽车自身的物理模型，这些都导致了DevOps闭环运行的挑战。DevOps源于互联网，它并不是为解决汽车问题而开发的方法论，简单的全盘采用一定会带来问题。很多车企在宣讲自己是面向软件定义的车企，是DevOps支撑的研发体系。但是，在实际工作中由于缺乏可以落到实处的方法论，面对汽车特有的实际问题，DevOps无法覆盖或简单套用。这就如同穿着室内用的拖鞋去跑山路，“鞋”不对“路”，脚一定会痛。V模型和DevOps都有可取的地方，也都有其自身的不足。但无论哪个方法论，无论什么系统体系，“测试驱动”和“测试先行”的理念并没有过时。“没有测试的系统都是有问题的系统！”这句话是不变的真理。软件定义汽车的危机，本质上是测试的危机。这是批量化的工业产品与个性化的使用的矛盾导致的危机。这里所讲的测试是更广义的基于车辆的问题发现和问题修复的工作，即包括传统的验证测试，标定，也包括研发状态的集成测试和问题的定位。批量化的工业产品与个性化的使用的矛盾，这就导致测试永远是不充分的。测试是资源和范围的平衡，如下图所示。理想的测试覆盖是对每一个所发布产品进行全面的测试。比如猛士军车，每一辆都是跑过一万公里的路试后才会交到部队的手中。是的，部队拿到的永远是二手车，但它是最稳定最可靠的二手车。但对普通的消费类产品，我们不可能对每辆车进行一万公里测试，这是资源和成本不允许的。测试永远是在做一个平衡，用最少的资源可以验证最大化的目标系统。
目标系统本身的差异性影响测试的范围。我们知道手机的众包测试，它是为了验证适配不同类型手机而进行的海量测试。如果汽车系统可以提供百分之一百标准化的抽象层，汽车应用只要兼容这个抽象层就可以运行在所有的汽车系统上。这样就只需要测试一个目标系统，就可以代替全体目标系统的测试。然而这是不现实的事情，在高度标准化的Android生态下也需要众包测试来验证目标系统的类型差异。何况汽车的复杂度远远大于手机，其标准化的道路会遥远而漫长。因此，众包测试也可能是软件定义汽车需要采取的测试策略。
目标系统与外部交互的差异性影响测试的范围。汽车系统会与环境和人进行交互，并且做出响应。时间，空间和人的交互都会改变汽车系统的响应行为。这就要求我们，只有汽车系统进行了全空间域和全时间域的测试才是完备的验证测试。也就是说，在所有时间和空间发生的事情都测试一遍，逻辑上才是全域覆盖的完备测试。但是我们知道这是不可能做到的事情，汽车系统测试必须做出妥协：一种方式是时间和空间变化对目标系统的扰动很小可以忽略不计；另一种方式是我们在时间上和空间上目标系统都一直伴随存在一个测试系统，发现问题就及时修正，当修正地足够快且足够多的时候就可以无限逼近测试的全覆盖了。
软件定义的汽车隐含地提供了个性化产品服务的特征，“持续”导致研发态永远在路上，个性化导致测试资源需要分布更细的粒度和更大的范围。我们知道资源永远是有限的，那么在现有的资源下我们提供的测试方案：
- 在空间域上，目标对象符合标准化的部分尽量做大，同时为标准化部分提供最大的资源，覆盖最多最重要的内容；
- 在空间域上，目标对象拥有公共属性的小集合，我们提供较多的资源覆盖测试；
- 在空间域上，目标对象个性化的内容，投入最少的资源捕获最不常见的边缘场景。
- 在时间域上，测试伴随软件定义汽车的全部生命周期。在时间轴上，资源的投入梯度递减。
多种因素导致软件定义汽车测试的危机，测试的危机严重影响了DevOps的循环，严重的以至于撕裂莫比乌斯环。难道我们必须退化到传统的瀑布模型吗？显然不是，我们需要新的方法处理汽车研发的新问题。
V模型侧重流程和验证，属性偏“硬”；DevOps侧重文化和惯例，属性偏“软”。俗话说：“量体裁衣，看菜吃饭”，我们需要的是软件定义汽车自己的研发理论模型，而不是简单的拼接或缝合。面对软件定义汽车这样新的研发场景，我们需要寻找的是一种具有高度复杂硬件，在高度复杂交互环境和高度安全要求下实施软件研发的工作模型。当然，这里一定有继承，这里也一定有扬弃，在“不断推进实践基础上的理论创新”的指引下提出我们的思考。
前面我们论述了“软件定义汽车的危机，本质上是测试的危机”，所以，首先我们要继承“测试先行”和“测试驱动”的核心理念。接着，我们试图寻找一个简单的，直观的，可运行的测试驱动模型，裁剪繁琐的流程过程，追求极致敏捷，追求自动与智能。我们先从“测试驱动”的理念入手，观察软件定义汽车研发，探索我们的思考。我们从两个视角进行观察，一个是从空间视角，另一个是从时间视角。
我们先从空间的视角观察软件定义汽车研发。一切的来源还是需求，根据测试驱动的理念，需求经过演化在空间上我们得到一个二元系统，一个是面向最终产品功能的目标系统；另一个是面向产品支持运作的支撑系统。无论是目标系统还是支撑系统，都是可运行系统。这里所说的可运行系统强调的是系统的可执行性，即被万物皆代码驱动的（万物皆代码，everything as code），而不是文档驱动的系统。测试驱动且测试先行的二元系统模型如下图。
图5：测试驱动的二元系统
支持系统是测试驱动且测试先行的系统，是以测试为主体，包含研发运维的综合系统。支撑系统优先于目标系统进行部署和执行。根据这个模型，汽车产品是目标系统与支撑系统的统一体。基于测试先行的原则，支撑系统的生命周期不但早于而且长于目标系统。软件定义汽车产品是符合冰山模型的产品，一部分在前台，一部分在后台。前台是冰山露出水面的部分，后台是冰山水面下的底座，底座的支撑系统才是整个产品的核心竞争力。
图6：海中冰山理论
我们再从时间的视角观察软件定义汽车研发。从空间的角度我们获得了一个二元结构模型。二元模型是一个中心两个系统的模型。一个中心就是以产品需求为中心。这里的需求不是封闭的需求，而是在汽车整个生命周期持续变化的需求。全生命周期持续变化的需求要求我们必须面对时间域的变化，并且必须提供可持续性的解决办法。二元结构模型结合可持续的解决方案，我们得到下图的太极模型：
我们回忆一下中国古人的智慧——认识世界的方法论。“无极生太极，太极生两仪（两仪即阴阳两个系统）”。这里借用“太极两仪”理论，我们赋予它现代的解读：无极即客观世界，太极即人类对客观世界观察获得的认知（需求的认知）。太极是由两个系统构成的，它们是人类认识世界的两个方面，它们互为存在条件，互相转化，互相推动运转。无极到太极是一个持续的人类认知过程（从客观世界归纳需求），太极到两仪也是一个持续变化的系统（从需求演变为两个系统）。也就是说无极到太极和太极内的两仪都是动态发展变化的过程。我们把太极模型应用到汽车产品的研发过程中。目标系统是实际参与汽车产品运行的运行时系统，它与驾驶者和驾驶环境进行互动，并且执行驾驶动作。支撑系统伴随目标系统，为目标系统提供研发、验证、测试，标定等环节的支撑。支撑系统与目标系统一样是全技术栈的，并且在硬件量产前，可以使用更多的技术栈和算力来搭建面向自动化和智能化的研发环境，提供更精细的调试，测试和标定等服务。支撑系统不但在研发态的环境下运行，也与交付态的目标系统伴随运行，与目标系统处于相同的算力空间，获得相同的信息输入。但是，支撑系统和目标系统是被隔离的，通常支撑系统不参与执行的过程，以保证汽车产品的功能安全特征。无论是目标系统还是支撑系统，我们强调的是“可运行的”和“代码驱动”的软件可定义。以软件定义的支撑系统支持软件定义的目标系统，即以“软件定义”支持“软件定义”，是太极模型的根本特征。测试应用与目标应用是能够互相转化的。根据测试驱动的原则，当一个软件应用发布到目标环境以前，都必须通过测试才能安全地发布到目标系统。由于软件定义汽车带来的面向个体的软件定制，基于两个系统的原则，我们就需要为个体提供研发测试环境，这样才可以保证个性化软件的高质量发布。对于软件应用，这个过程相当于应用从支撑环境向目标环境的流动，再从目标环境升级到更高版本进入到支撑测试环境。这就是应用在两个系统中的互相转化，并且是持续的螺旋上升的过程。太极模型也体现了两级应用转化的过程。我们总结一下，太极模型是从一个需求中心演化出的二元系统模型，它是即有系统结构特征也有动态行为特征的可执行模型。太极模型是面向全生命周期的动态模型，它的服务对象是动态变化的需求。太极模型中的元素可持续改进并且可以互相转化。太极模型可以帮助我们梳理汽车研发的思路。比如，我们在规划汽车域控的时候，面对个性化的软件定义需求，是不是在硬件层就需要考虑目标系统和支撑系统在域控内的预埋？是不是在软件操作系统层或中间件层就考虑两个系统的隔离和分割？是不是也要考虑应用在目标与支撑系统中的转化问题？我们将持续探索太极汽车研发模型来解决这些问题。从汽车研发实践中来，到汽车研发实践中去，在本系列文章【极限汽车研发】实践中，我们会不断思考，不断完善。
更多的思考
理论是基础，也是我们迈出的第一步，然而只有理论是不够的，“知行合一”才是面对问题的根本方法。软件定义汽车研发的挑战是全方位的，理念的挑战，流程的挑战和工具链的挑战，这一切都需要我们通过思考和实践来一一解决。
软件定义汽车改变了汽车软件的生命周期，这里一定需要一个崭新的流程，一定需要引入全新的角色才能适应新的变化。新的情况也会带来工具链危机，没有趁手的工具一切理论都只能停留在理论。我们会在本系列的其它文章中详细讨论这些问题。最后，最核心的危机是人才的危机! 传统的车企需要跨领域的高级人才，没有人才，一切理论，流程和工具都无法发现和创造。我们相信随着汽车产业与软件产业的高度融合，人才也会在这个过程中逐渐培养出来，理论也会从实践中完善起来，只要我们不断努力探索，一切的危机都不再是“危机”，而是新的机遇。—END—
添加下方信加入汽专业交流群
（仅限专业人士）
