汽车软件开发方法的困局

汽车电子与软件 2023-05-07 20:54


导读

 软件定义汽车给汽车产业带来了新的机遇,同时它也给汽车研发带来了新的危机。我们希望能去掉“危”而抓住“机”,追赶汽车研发变革的风口。


参观了2023年的上海车展,新汽车的展台摩肩接踵,传统汽车的展台热度不敷往年。又看了同期纽约车展的视频,暮气沉沉的纽约车展与新锐的上海车展好像处在不同的时空位面。面对这样的场景,内心真是无限感慨。近些年,中国汽车行业将是一个高度“卷”的时代,“卷”完国内再“卷”世界,大家都在拼命狂奔向前。软件定义的新汽车就如同一辆漂亮的跑车在一路狂奔,然而它的前路可能是水坑,也可能是泥潭。我们需要看清前方的道路,把握好汽车的方向,才能避免状况的发生,最终在“卷”的狂潮中幸存下来。为了成为存活最久的那个人,我们需要擦亮双眼,探索发现问题,再分析问题找到问题的答案。
我们先从软件定义汽车的定义入手软件定义汽车(Software Defined Vehicles,SDV)即软件将深度参与到汽车的定义、开发、验证、销售、服务等过程中,并不断改变和优化各个过程,实现体验持续优化、过程持续优化、价值持续创造。这里可以看到,软件定义汽车有别于传统汽车,它的典型特征是软件的“深度”参与和“持续”变化,也就是说汽车相关软件的变化会深度参与到汽车的整个生命周期中。
新事物与新挑战
软件定义汽车的新特性给汽车产业带来了想象空间。正如现在人们常说的,软件定义的汽车等于加了四个轮子的手机。汽车也可以与手机一样,产品交付到用户手中的时刻,不再是产品研发的终点,反而是汽车软件研发全新的起点。在汽车的生命周期中,各种汽车的应用会如同手机应用一样被安装到汽车上,给汽车赋予全新的能力。
既然汽车是安装了四个轮子的手机,那么我们是否可以用手机生态的研发逻辑来指导软件定义汽车的研发呢?显然是有问题的。软件定义的汽车既有计算机相关的部分,也有四个轮子”的机械部分,汽车产品是一个高度复杂的综合体。并且,汽车是交通工具,它具有很高的功能安全要求,这也是手机产品不具备的特征。显然,这些特征决定了手机研发模型无法完美支撑软件定义汽车的研发过程。

理论的危机

“理论来源于实践,但科学的理论形成之后又对实践产生重要指导作用,对人们从事新的实践活动提供必要理论指导” 。软件定义汽车是新生事物,一切都在发展中。在,软件定义汽车研发不缺少实践过程,然而理论创新也需要提到议事日程上来,为研发实践提供必要的指导。

图1:V模型
我们知道,传统汽车研发有成熟的理论模型即V模型。V模型是对瀑布模型的细化和完善。本质上是测试驱动的研发模型,每个开发阶段都对应一个测试阶段。V模型是一个高度严格的模型,下一阶段依赖上一个阶段的输出,工作必须一个阶段一个阶段地进行。
V模型为传统汽车产品的高质量交付提供了理论支撑。V模型是基于SOP(start of production)为研发终点而建立的过程模型。V模型为传统的汽车制造提供了很好的面向终点的过程约束。但是,V模型继承于瀑布模型,因为瀑布模型的特征,导致研发开始之前,必须有非常明确的需求,这也导致需求的变更会带来非常昂贵的研发代价。
不得不承认,V模型在汽车行业的影响是非常深远的。比如汽车行业非常流行的ASPICE和各种基于V模型的汽车相关标准。但是,对于软件定义汽车,V模型的影响力反而是新汽车研发的负担。汽车行业研发人员在V模型的影响下思维模式根深蒂固,面对软件研发敏捷性的要求,这里需要的是改变,首先是思想层面的转变。
他山之石可以攻玉吗?
传统汽车研发理论无法适应新的挑战,那么他山之石可以攻玉吗?从2023年上海车展博世公司的展台可以看出,汽车行业正在借用“他山之石”,如下图。图中莫比乌斯环的造型,正是互联网生态流行的DevOps研发模型。

图22023年上海车展博世展台的DevOps造型

我们先看看DevOps的定义:DevOps(Development和Operations的混成词)是一种重视“软件开发人员(Dev)”和“IT运维技术人员(Ops)”之间沟通合作的文化、运动或惯例。通过自动化“软件交付”和“架构变更”的流程,来使得构建、测试、发布软件能够更加地快捷、频繁和可靠。

图3:DevOps模型

DevOps强调使用敏捷的方法提供更快的产品交付的速率,比如可以支撑业务部门“每天部署10次”的要求,为了支持这个过程,强大的自动化手段是一切的根本保证。DevOps理论是经过实践的,是在现今互联网世界行之有效的生产利器。DevOps在互联网世界的成功,正是很多汽车企业争相引入DevOps研发理念的根本原因。
互联网世界的DevOps,诞生于互联网,服务互联网,水乳交融。但是,面对汽车的世界它却有些水土不服。互联网的DevOps是工作在可控的计算机环境中,它是一种全部电子化的,纯数字化的,“软”的生产空间。它是环境可控,输入输出可控,自身模型已经数字化的工作环境,这是人类现今最理想的数字生产环境。
然而,软件定义的汽车,除了“软”的一面,还有“硬”的一面。不能忘记,软件定义的汽车是加了四个轮子的手机,除了“手机”之外还有“四个轮子”。汽车是复杂的软硬件结合的混合体,它“硬”的一面就导致了它验证成本会成指数级的增加,DevOps的循环速率会被严重拖慢,甚至成为断裂的莫比乌斯环。
汽车是运行在开放环境的物理实体产品。汽车与环境,汽车与人,都发生复杂的交互和反馈。换句话说,汽车被复杂的物理环境和人类活动等因素扰动,再加上无法量化的汽车自身的物理模型,这些都导致了DevOps闭环运行的挑战。
DevOps源于互联网,它并不是为解决汽车问题而开发的方法论,简单的全盘采用一定会带来问题。很多车企在宣讲自己是面向软件定义的车企,是DevOps支撑的研发体系。但是,在实际工作中由于缺乏可以落到实处的方法论,面对汽车特有的实际问题,DevOps无法覆盖或简单套用。这就如同穿着室内用的拖鞋去跑山路,“鞋”不对“路”,脚一定会痛。
测试的危机
V模型和DevOps都有可取的地方,也都有其自身的不足。但无论哪个方法论,无论什么系统体系,“测试驱动”和“测试先行”的理念并没有过时。“没有测试的系统都是有问题的系统!”这句话是不变的真理。软件定义汽车的危机,本质上是测试的危机。批量化的工业产品与个性化的使用的矛盾导致的危机。这里所讲的测试是更广义的基于车辆的问题发现和问题修复的工作,即包括传统的验证测试,标定,也包括研发状态的集成测试和问题的定位。
批量化的工业产品与个性化的使用的矛盾这就导致测试永远是不充分的。测试是资源和范围的平衡,如下图所示。理想的测试覆盖是对每一个所发布产品进行全面的测试。比如猛士军车,每一辆都是跑过一万公里的路试后才会交到部队的手中。是的,部队拿到的永远是二手车,但它是最稳定最可靠的二手车。但对普通的消费类产品,我们不可能对每辆车进行一万公里测试,这是资源和成本不允许的。测试永远是在做一个平衡,用最少的资源可以验证最大化的目标系统。

图4:资源与范围的平衡

目标系统本身的差异性影响测试的范围。我们知道手机的众包测试,它是为了验证适配不同类型手机而进行的海量测试。如果汽车系统可以提供百分之一百标准化的抽象层,汽车应用只要兼容这个抽象层就可以运行在所有的汽车系统上。这样就只需要测试一个目标系统,就可以代替全体目标系统的测试。然而这是不现实的事情,在高度标准化的Android生态下也需要众包测试来验证目标系统的类型差异。何况汽车的复杂度远远大于手机,其标准化的道路会遥远而漫长。因此,众包测试也可能是软件定义汽车需要采取的测试策略。

目标系统与外部交互的差异性影响测试的范围汽车系统会与环境和人进行交互,并且做出响应。时间,空间和人的交互都会改变汽车系统的响应行为。这就要求我们,只有汽车系统进行了全空间域和全时间域的测试才是完备的验证测试。也就是说,在所有时间和空间发生的事情都测试一遍,逻辑上才是全域覆盖的完备测试。但是我们知道这是不可能做到的事情,汽车系统测试必须做出妥协:一种方式是时间和空间变化对目标系统的扰动很小可以忽略不计;另一种方式是我们在时间上和空间上目标系统都一直伴随存在一个测试系统,发现问题就及时修正,当修正地足够快且足够多的时候就可以无限逼近测试的全覆盖了。

软件定义的汽车隐含地提供了个性化产品服务的特征,“持续”导致研发态永远在路上,个性化导致测试资源需要分布更细的粒度和更大的范围。我们知道资源永远是有限的,那么在现有的资源下我们提供的测试方案:

  • 空间域上,目标对象符合标准化的部分尽量做大,同时为标准化部分提供最大的资源,覆盖最多最重要的内容;
  • 空间域上,目标对象拥有公共属性的小集合,我们提供较多的资源覆盖测试;
  • 空间域上,目标对象个性化的内容,投入最少的资源捕获最不常见的边缘场景。
  • 在时间域上,测试伴随软件定义汽车的全部生命周期。在时间轴上,资源的投入梯度递减。


多种因素导致软件定义汽车测试的危机,测试的危机严重影响了DevOps的循环,严重的以至于撕裂莫比乌斯环。难道我们必须退化到传统的瀑布模型吗?显然不是,我们需要新的方法处理汽车研发的新问题。

中国的智慧

V模型侧重流程和验证,属性偏“硬”;DevOps侧重文化和惯例,属性偏“软”。俗话说量体裁衣,看菜吃饭”,我们需要的是软件定义汽车自己的研发理论模型,而不是简单的拼接或缝合。面对软件定义汽车这样新的研发场景,我们需要寻找的是一种具有高度复杂硬件,在高度复杂交互环境和高度安全要求下实施软件研发的工作模型。当然,这里一定有继承,这里也一定有扬弃,在不断推进实践基础上的理论创新”的指引下提出我们的思考。

前面我们论述了“软件定义汽车的危机,本质上是测试的危机”,所以,首先我们要继承“测试先行”和“测试驱动”的核心理念。接着,我们试图寻找一个简单的,直观的,可运行的测试驱动模型,裁剪繁琐的流程过程,追求极致敏捷,追求自动与智能。我们先从“测试驱动”的理念入手,观察软件定义汽车研发,探索我们的思考。我们从两个视角进行观察,一个是从空间视角,另一个是从时间视角

我们先从空间的视角观察软件定义汽车研发。一切的来源还是需求,根据测试驱动的理念,需求经过演化在空间上我们得到一个二元系统,一个是面向最终产品功能的目标系统;另一个是面向产品支持运作的支撑系统。无论是目标系统还是支撑系统,都是可运行系统。这里所说的可运行系统强调的是系统的可执行性,即被万物皆代码驱动的(万物皆代码,everything as code),而不是文档驱动的系统。测试驱动且测试先行的二元系统模型如下图。

图5:测试驱动的二元系统

支持系统是测试驱动且测试先行的系统,是以测试为主体,包含研发运维的综合系统。支撑系统优先于目标系统进行部署和执行。根据这个模型,汽车产品是目标系统与支撑系统的统一体。基于测试先行的原则,支撑系统的生命周期不但早于而且长于目标系统。软件定义汽车产品是符合冰山模型的产品,一部分在前台,一在后台。前台是冰山露出水面的部分,后台是冰山水面下的底座,底座的支撑系统才是整个产品的核心竞争力。

图6:海中冰山理论

我们再时间的视角观察软件定义汽车研发。从空间的角度我们获得了一个二元结构模型。二元模型是一个中心两个系统的模型。一个中心就是以产品需求为中心。这里的需求不是封闭的需求,而是在汽车整个生命周期持续变化的需求。全生命周期持续变化的需求要求我们必须面对时间域的变化,并且必须提供可持续性的解决办法。二元结构模型结合可持续的解决方案,我们得到下图的太极模型:

图7:太极汽车研发模型
我们回忆一下中国古人的智慧——认识世界的方法论。“无极生太极,太极生两仪(两仪即阴阳两个系统)”。这里借用“太极两仪”理论,我们赋予它现代的解读:无极即客观世界,太极即人类对客观世界观察获得的认知(需求的认知)。太极是由两个系统构成的,它们是人类认识世界的两个方面,它们互为存在条件,互相转化,互相推动运转。无极到太极是一个持续的人类认知过程(从客观世界归纳需求),太极到两仪也是一个持续变化的系统(从需求演变为两个系统)。也就是说无极到太极和太极内的两仪都是动态发展变化的过程。
我们把太极模型应用到汽车产品的研发过程中。目标系统是实际参与汽车产品运行的运行时系统,它与驾驶者和驾驶环境进行互动,并且执行驾驶动作。支撑系统伴随目标系统,为目标系统提供研发、验证、测试,标定等环节的支撑。支撑系统与目标系统一样是全技术栈的,并且在硬件量产前,可以使用更多的技术栈和算力来搭建面向自动化和智能化的研发环境,提供更精细的调试,测试和标定等服务。
支撑系统不但在研发态的环境下运行,也与交付态的目标系统伴随运行,与目标系统处于相同的算力空间,获得相同的信息输入。但是,支撑系统和目标系统是被隔离的,通常支撑系统不参与执行的过程,以保证汽车产品的功能安全特征。无论是目标系统还是支撑系统,我们强调的是“可运行的”和“代码驱动”的软件可定义。以软件定义的支撑系统支持软件定义的目标系统,即以“软件定义”支持“软件定义”,是太极模型的根本特征。
测试应用与目标应用是能够互相转化的根据测试驱动的原则,当一个软件应用发布到目标环境以前,都必须通过测试才能安全地发布到目标系统。由于软件定义汽车带来的面向个体的软件定制,基于两个系统的原则,我们就需要为个体提供研发测试环境,这样才可以保证个性化软件的高质量发布。对于软件应用,这个过程相当于应用从支撑环境向目标环境的流动,再从目标环境升级到更高版本进入到支撑测试环境。这就是应用在两个系统中的互相转化,并且是持续的螺旋上升的过程。太极模型也体现了两级应用转化的过程。
我们总结一下,太极模型是从一个需求中心演化出的二元系统模型,它是即有系统结构特征也有动态行为特征的可执行模型。太极模型是面向全生命周期的动态模型,它的服务对象是动态变化的需求。太极模型中的元素可持续改进并且可以互相转化。
太极模型可以帮助我们梳理汽车研发的思路。比如,我们在规划汽车域控的时候,面对个性化的软件定义需求,是不是在硬件层就需要考虑目标系统和支撑系统在域控内的预埋?是不是在软件操作系统层或中间件层就考虑两个系统的隔离和分割?是不是也要考虑应用在目标与支撑系统中的转化问题?我们将持续探索太极汽车研发模型来解决这些问题。从汽车研发实践中来,到汽车研发实践中去,在本系列文章【极限汽车研发】实践中,我们会不断思考,不断完善

更多的思考

理论是基础,也是我们迈出的第一步,然而只有理论是不够的,“知行合一”才是面对问题的根本方法。软件定义汽车研发的挑战是全方位的,理念的挑战,流程的挑战和工具链的挑战,这一切都需要我们通过思考和实践来一一解决
软件定义汽车改变了汽车软件的生命周期,这里一定需要一个崭新的流程,一定需要引入全新的角色才能适应新的变化。新的情况也会带来工具链危机,没有趁手的工具一切理论都只能停留在理论。我们会在本系列的其它文章中详细讨论这些问题。
最后,最核心的危机是人才的危机! 传统的车企需要跨领域的高级人才,没有人才,一切理论,流程和工具都无法发现和创造。我们相信随着汽车产业与软件产业的高度融合,人才也会在这个过程中逐渐培养出来,理论也会从实践中完善起来,只要我们不断努力探索,一切的危机都不再是“危机”,而是新的机遇。

—END—

添加下方信加入汽专业交流群

(仅限专业人士)

汽车电子与软件 主要介绍汽车电子软件设计相关内容,每天分享一篇技术文章!
评论
  • 这篇内容主要讨论三个基本问题,硅电容是什么,为什么要使用硅电容,如何正确使用硅电容?1.  硅电容是什么首先我们需要了解电容是什么?物理学上电容的概念指的是给定电位差下自由电荷的储藏量,记为C,单位是F,指的是容纳电荷的能力,C=εS/d=ε0εrS/4πkd(真空)=Q/U。百度百科上电容器的概念指的是两个相互靠近的导体,中间夹一层不导电的绝缘介质。通过观察电容本身的定义公式中可以看到,在各个变量中比较能够改变的就是εr,S和d,也就是介质的介电常数,金属板有效相对面积以及距离。当前
    知白 2025-01-06 12:04 173浏览
  • 彼得·德鲁克被誉为“现代管理学之父”,他的管理思想影响了无数企业和管理者。然而,关于他的书籍分类,一种流行的说法令人感到困惑:德鲁克一生写了39本书,其中15本是关于管理的,而其中“专门写工商企业或为企业管理者写的”只有两本——《为成果而管理》和《创新与企业家精神》。这样的表述广为流传,但深入探讨后却发现并不完全准确。让我们一起重新审视这一说法,解析其中的矛盾与根源,进而重新认识德鲁克的管理思想及其著作的真正价值。从《创新与企业家精神》看德鲁克的视角《创新与企业家精神》通常被认为是一本专为企业管
    优思学院 2025-01-06 12:03 119浏览
  • 在智能家居领域中,Wi-Fi、蓝牙、Zigbee、Thread与Z-Wave等无线通信协议是构建短距物联局域网的关键手段,它们常在实际应用中交叉运用,以满足智能家居生态系统多样化的功能需求。然而,这些协议之间并未遵循统一的互通标准,缺乏直接的互操作性,在进行组网时需要引入额外的网关作为“翻译桥梁”,极大地增加了系统的复杂性。 同时,Apple HomeKit、SamSung SmartThings、Amazon Alexa、Google Home等主流智能家居平台为了提升市占率与消费者
    华普微HOPERF 2025-01-06 17:23 145浏览
  • 大模型的赋能是指利用大型机器学习模型(如深度学习模型)来增强或改进各种应用和服务。这种技术在许多领域都显示出了巨大的潜力,包括但不限于以下几个方面: 1. 企业服务:大模型可以用于构建智能客服系统、知识库问答系统等,提升企业的服务质量和运营效率。 2. 教育服务:在教育领域,大模型被应用于个性化学习、智能辅导、作业批改等,帮助教师减轻工作负担,提高教学质量。 3. 工业智能化:大模型有助于解决工业领域的复杂性和不确定性问题,尽管在认知能力方面尚未完全具备专家级的复杂决策能力。 4. 消费
    丙丁先生 2025-01-07 09:25 80浏览
  •     为控制片内设备并且查询其工作状态,MCU内部总是有一组特殊功能寄存器(SFR,Special Function Register)。    使用Eclipse环境调试MCU程序时,可以利用 Peripheral Registers Viewer来查看SFR。这个小工具是怎样知道某个型号的MCU有怎样的寄存器定义呢?它使用一种描述性的文本文件——SVD文件。这个文件存储在下面红色字体的路径下。    例:南京沁恒  &n
    电子知识打边炉 2025-01-04 20:04 100浏览
  • 根据Global Info Research项目团队最新调研,预计2030年全球封闭式电机产值达到1425百万美元,2024-2030年期间年复合增长率CAGR为3.4%。 封闭式电机是一种电动机,其外壳设计为密闭结构,通常用于要求较高的防护等级的应用场合。封闭式电机可以有效防止外部灰尘、水分和其他污染物进入内部,从而保护电机的内部组件,延长其使用寿命。 环洋市场咨询机构出版的调研分析报告【全球封闭式电机行业总体规模、主要厂商及IPO上市调研报告,2025-2031】研究全球封闭式电机总体规
    GIRtina 2025-01-06 11:10 104浏览
  • 村田是目前全球量产硅电容的领先企业,其在2016年收购了法国IPDiA头部硅电容器公司,并于2023年6月宣布投资约100亿日元将硅电容产能提升两倍。以下内容主要来自村田官网信息整理,村田高密度硅电容器采用半导体MOS工艺开发,并使用3D结构来大幅增加电极表面,因此在给定的占位面积内增加了静电容量。村田的硅技术以嵌入非结晶基板的单片结构为基础(单层MIM和多层MIM—MIM是指金属 / 绝缘体/ 金属) 村田硅电容采用先进3D拓扑结构在100um内,使开发的有效静电容量面积相当于80个
    知白 2025-01-07 15:02 75浏览
  • 根据环洋市场咨询(Global Info Research)项目团队最新调研,预计2030年全球无人机锂电池产值达到2457百万美元,2024-2030年期间年复合增长率CAGR为9.6%。 无人机锂电池是无人机动力系统中存储并释放能量的部分。无人机使用的动力电池,大多数是锂聚合物电池,相较其他电池,锂聚合物电池具有较高的能量密度,较长寿命,同时也具有良好的放电特性和安全性。 全球无人机锂电池核心厂商有宁德新能源科技、欣旺达、鹏辉能源、深圳格瑞普和EaglePicher等,前五大厂商占有全球
    GIRtina 2025-01-07 11:02 68浏览
  • By Toradex 秦海1). 简介嵌入式平台设备基于Yocto Linux 在开发后期量产前期,为了安全以及提高启动速度等考虑,希望将 ARM 处理器平台的 Debug Console 输出关闭,本文就基于 NXP i.MX8MP ARM 处理器平台来演示相关流程。 本文所示例的平台来自于 Toradex Verdin i.MX8MP 嵌入式平台。  2. 准备a). Verdin i.MX8MP ARM核心版配合Dahlia载板并
    hai.qin_651820742 2025-01-07 14:52 45浏览
  • PLC组态方式主要有三种,每种都有其独特的特点和适用场景。下面来简单说说: 1. 硬件组态   定义:硬件组态指的是选择适合的PLC型号、I/O模块、通信模块等硬件组件,并按照实际需求进行连接和配置。    灵活性:这种方式允许用户根据项目需求自由搭配硬件组件,具有较高的灵活性。    成本:可能需要额外的硬件购买成本,适用于对系统性能和扩展性有较高要求的场合。 2. 软件组态   定义:软件组态主要是通过PLC
    丙丁先生 2025-01-06 09:23 85浏览
  • 本文介绍Linux系统更换开机logo方法教程,通用RK3566、RK3568、RK3588、RK3576等开发板,触觉智能RK3562开发板演示,搭载4核A53处理器,主频高达2.0GHz;内置独立1Tops算力NPU,可应用于物联网网关、平板电脑、智能家居、教育电子、工业显示与控制等行业。制作图片开机logo图片制作注意事项(1)图片必须为bmp格式;(2)图片大小不能大于4MB;(3)BMP位深最大是32,建议设置为8;(4)图片名称为logo.bmp和logo_kernel.bmp;开机
    Industio_触觉智能 2025-01-06 10:43 87浏览
  • 每日可见的315MHz和433MHz遥控模块,你能分清楚吗?众所周知,一套遥控设备主要由发射部分和接收部分组成,发射器可以将控制者的控制按键经过编码,调制到射频信号上面,然后经天线发射出无线信号。而接收器是将天线接收到的无线信号进行解码,从而得到与控制按键相对应的信号,然后再去控制相应的设备工作。当前,常见的遥控设备主要分为红外遥控与无线电遥控两大类,其主要区别为所采用的载波频率及其应用场景不一致。红外遥控设备所采用的射频信号频率一般为38kHz,通常应用在电视、投影仪等设备中;而无线电遥控设备
    华普微HOPERF 2025-01-06 15:29 127浏览
我要评论
0
点击右上角,分享到朋友圈 我知道啦
请使用浏览器分享功能 我知道啦