一、敏捷：应对软件定义汽车时代的开发模式变革
（原创 E 迪捷软件）
随着软件定义汽车典型应用场景的落地，汽车从交通工具转向智能移动终端的趋势愈发明显。几十年前，一台好车的定义主要取决于高性能的底盘操稳与动力系统；几年前，一台好车的定义主要取决于智能化系统与智能交互能否满足终端用户的用车体验；相信不久后的将来，一台好车的定义将变成：全车传感器与数据驱动方式定义智能移动终端。本文将从开发模式变革来讨论软件定义汽车所需要的改变，并介绍软件定义汽车模式下的典型应用场景。
传统汽车的软件开发采用 V 字形瀑布式开发模式，如下图所示。
由于各开发部分之间相对独立，更多只是在部分内部展开局部性优化，缺乏系统级平台级的开发全局观，很难做到整体优化。同时，各部分的开发时间并不全然一致，进度顺序依赖很容易造成队列效应，一旦出现某个部分开发发生延误时，便会影响整体的开发进度。每个阶段都过于依赖上个阶段成果，就会导致开发成本较高且周期过长，与“软件定义汽车”涉及的【缩短产品上市周期、产品基于消费者需求、支持不断的迭代、对市场需求迅速响应】等要求相矛盾。
因此，软件定义汽车背景下，汽车软件开发将由传统的瀑布式开发向敏捷开发模式转变。敏捷式开发模式既有利于达到密切的协调合作，最大限度地减少管理成本，同时因其灵活的工作模式能够使开发团队与用户实现高度互动，采用最低可行性产品的形式快速满足用户需求，并在使用中不断创新迭代，实现持续开发、持续集成、持续交付，体现软件定义汽车的优势。主要体现如下：
传统控制器的开发，遵循 V 型开发流程，以整车厂的需求为输入，考虑信息安全和功能安全，严格执行设计、实现、验证的完整流程，最终也以控制器为对象完成需求的验收，有利于保障需求的完整实现。同时，整个流程也有质保、流程、售后等部门参与其中进行评审和审核，以此形成良好的质量管理和质量保证体系。但整个流程相对封闭，不符合软件快速迭代的开放性和扩展性要求。
传统汽车软件的开发场景明确，软件与硬件紧密耦合，对于嵌入式软件的交付，并没有明确的“软件交付”的概念，软件随着控制器硬件一起交付。技术层面来看，应用软件与基础软件一起集成和固化，有着明确统一的释放节点。随着软件定义汽车时代的到来，“软硬分离，软软分离”逐渐成了主旋律，嵌入式软件从依附于硬件的一堆“代码”真正脱胎换骨为独立可售卖的产品；且这项产品可以在整个车辆的生命周期内持续产生价值。从嵌入式软件开发和验证的技术层面，这样的趋势使得软件要能够快速迭代，持续更新持续交付。
在传统控制器开发中，在项目前期形成相对完备的系统架构和软件架构，再向下分解到软件组件，经由详细设计到达软件开发。这样的开发模式适合控制器的产品形态，依赖成熟技术的完整积累。面向开放架构/持续交付的软件特性，在项目管理上，敏捷成为了关键词，软件交付不再是统一固定的交付节点，软件模块在整个车辆生命周期都有新增的机会：模块化软件具备单独交付的条件和场景，随之而来的是软件的设计/开发/测试/验证的节点也随之迭代起来，变化和持续交付是常态，这对整体的软件项目管理提出了更高的要求。
综上，汽车软件开发模式由传统的瀑布式开发向敏捷开发模式的变革，将为软件定义汽车落地面带来巨大挑战。
在应对上述变革的诸多方案中，CI/CD是不可忽视的敏捷属性。
不同的汽车ECU提供不同的服务，对底层操作系统给的要求也不同。在电子电气系统架构从分布式向域集中式演进的大背景下，各种功能模块都集中到少数几个计算能力强大的域控制器中。如何在域控制器中使用CI/CD的敏捷方法，助力软件的开发、测试和验证呢？
国产自主可控的天目全数字实时仿真软件SkyEye，可以通过全数字仿真技术，实现汽车所需嵌入式软件的敏捷开发。基于SkyEye所搭建的嵌入式系统虚拟化运行环境，工程师可不受物理硬件限制，随时访问目标系统，快速搭建虚拟硬件模型并提前进行开发、测试和验证工作，实现高效率、高质量的软件交付。
同时，SkyEye支持主流的嵌入式硬件平台，可运行国内外主流的操作系统，对国产生态的支持尤为出色。通过利用基于LLVM的动态二进制翻译技术，SkyEye可使虚拟处理器在典型的桌面计算机上运行速度达到2000MIPS以上。
基于SkyEye的虚拟硬件和CI/CD工作流紧耦合，可应用于汽车软件开发的全生命周期：
参考文献
软件定义汽车产业生态创新白皮书V1.0
二、一文总览当今汽车软件开发全景
（原创 大果树 ARVOINSIGHT价值洞察）
在当今数字化浪潮中，软件开发不仅是技术领域的核心驱动力，更是企业创新与商业成功的战略支点。特别是软件定义汽车的时代，软件开发的规范化管理成为车企的难言之痛：软件版本如此多，如何测试？全量测试还是采样测试？软件版本发布如何管控？软件质量如何保障？软件功能为什么总是赶不上造车的节奏？软件是如何集成的？敏捷会让车企的软件开发一夜之间发生神奇的变化？….
本篇文章以科普的方式探讨软件开发理论基础、关键模型、实战技巧以及组织与人才发展等重要议题，旨在为读者提供一幅全景式的软件开发导图。
一、软件开发基石：软件开发生命周期模型的选择
软件开发生命周期模型是组织软件开发活动的框架，它定义了开发过程中的阶段、顺序、迭代方式以及各阶段间的关联（见图1）。
图1
软件开发生命周期模型，大家耳熟能详的是经典的瀑布模型和敏捷开发模型。
瀑布模型：
瀑布模型遵循严格的线性顺序，从需求分析到详细设计，再到编码、测试和维护，每个阶段必须在前一阶段完全完成后才能开始。瀑布模型适用于需求稳定、技术路径清晰的项目，但其僵化性可能导致应对变化的能力较弱，一旦前期需求定义有误，后续阶段修正的成本极高。
关于瀑布模型，我们需要知道，目前看到的瀑布模型（见图2）更多是停留在了理论模型基础之上。实际上，在1980s, Fred Brooks, 著名的产品开发畅销书《人月神话》作者，图灵奖获得者，在NASA内部会议上指出，“在超过370亿美金的投资项目中，只有2%的项目使用了纯粹的瀑布模型，75%的项目或夭折或没有使用.”
图2
在现实的世界里，更多的是采用了基于瀑布模型演化的进化模型，如螺旋模型、V模型等。他们都融合了瀑布模型的结构化特点与迭代思想。螺旋模型特别适用于高风险项目，通过反复的风险评估和原型迭代降低不确定性；而V模型（见图3）强调开发与测试的对应关系，确保每个阶段的验证与确认工作紧密相连。
V模型成为了产品工程，特别是软硬一体的嵌入式产品开发的核心骨架，也是产品开发使用最为广泛的模型。像汽车行业的ASPICE标准、功能安全的ISO26262标准、信息安全的ISO21434标准，基本都是根据V模型制定了相应的规范要求。
图3
敏捷模型：
敏捷开发模型则以快速响应变化为宗旨，倡导迭代开发和持续集成。它强调团队协作、用户参与以及适应需求的灵活性，通过短周期的迭代（如Scrum中的Sprint）快速产出可用软件，并根据反馈进行调整。敏捷模型更多地关注了软件开发过程中的工程实践，对于软件交付后的运营提及不多。交付后的管理更多的还是采用传统的软件生命周期管理的模式。
敏捷软件开发模型同样存在多种实操模型，例如XP、FDD，等。目前应用最广的还是团队级敏捷SCRUM模型（见图4）
图4
敏捷开发在实际落地过程中有两种具体的项目管理方式：基于时间盒的迭代计划（见图5）和基于流的迭代计划（见图6）。采用不同的迭代计划，将决定了敏捷项目每个冲刺（SPRINT）的交付内容。我们需要注意的是，因为产品形态及产品技术架构的复杂度不同，组织架构的不同，如果迭代规划方式选择与之不匹配，敏捷反而会引入更多的混乱和内卷。
例如，如果产品是单一架构的（monolithic Architecture）且功能依赖多，如果采用时间盒的迭代规划方式，会出现待开发的新功能不得不削足适履，进行功能分拆用户故事，确保能在一个时间盒的窗口交付，反而导致大量的模块之间的相互依赖，交易成本（Transaction Cost）剧升，协调工作冗长。从系统论的维度看下来，反而是降低了效率。针对这种情况，要么是改变时间盒的跨度，要么是采用基于流的迭代工作模式。
图5 （来源：From Prince2 Agile）
图6（来源：From Prince2 Agile）
软件开发的模型选择：
“There's no singular technique or process that will bring about significant improvements in software development productivity”
- No Silver Bullet—Essence and Accidents of Software Engineering
Gerald Weinberg, Fred Brooks, and Grady Booch
面临乱花渐欲迷人眼以及病急乱投医的汽车软件开发，到底如何选择自己的软件开发模式呢？正如Fred Brooks所言，没有单一技术或模型能够显著提成软件开发效率。我们需要的是因地制宜，选择适合自己组织和产品属性的研发活动的模型。
在实际工作中，我们应该且必须学以致用，灵活适配合适的软件开发模型，而不是简单地照猫画虎，仿照各种敏捷框架，如站会、结对编程......（题外话：其实，适配性（Adapability）才是业务敏捷的精髓所在）。
不管选择何种开发模型，其核心目的是更快、更好地交付客户价值和业务价值。具体来讲，可以基于Stacey矩阵，选择合适的开发模型（图7）。当然，除了Stacey矩阵提供的需求确定性和技术确定性的两个维度外，还需要考虑团队的成熟度，团队成员的技能经验，工作地点分布，团队规模以及组织文化等因素。
图7
二、需求分析与架构设计的艺术
软件开发始于需求的获取与需求开发的过程（通常将这个过程称为需求工程阶段）。需求的获取主要是从市场需求、用户需求、业务等维度展开，理解并分析企业所在的行业、国家、地区适用的法律法规等，综合定义软件产品的需求。
近几年来，随着国内互联网造车的兴起，互联网用户需求分析的工具也逐步引入到垂直行业，也成为国内传统造车企业纷纷攘攘去学习的重心。但从第一性原理来看，需求获取的原理没有改变，变化的是传统企业缺少需求获取的数字化手段，缺少人物画像的细节管控。
需求获取的方法手段很多，我们总结如图8所示。
图8
在对软件产品功能进行定义的过程中，往往是综合采用多种方法，确保功能能够满足最大数量的用户期望。同时，我们要关注，对于ToC业务与ToB业务的需求获取方法，也存在着差异。无论是从调研对象，调研数量以及调研方法，在实际过程中，要注重理论与实践的结合。
这里，特别给大家推荐一个用来识别或改进产品可用性功能需求（Usability）的强大工具–用户历程地图（题外话：对于其他如非功能性需求的定义与改进，建议采用其他工具方法）。图9展示了对电车用户充电活动的用户历程地图，通过一张纸，可以清晰地将产品功能的优劣以及待创新的功能点描述清楚。
图9
需求获取只是开启了整个软件开发的序幕。我们下一步要做的是需求的确认。需求的确认，是确保软件产品的开发“做正确的事”。需求确认的方法包括了VOC，焦糖布丁法，Y分析法，数据分析法等等。
为什么要进行需求的确认呢？其实，这涉及到了人类认知的过程，如图10所示，当我们看到现实的人形机器人图片时，我们会根据自己的认知(Perception)和我们个人的知识（Knowledge）对其进行描述。然后，我们将我们自己脑海里，经过自己认知过滤过的图片，用自己的知识，包括文字语言对其进行描述，这个过程，将不可避免的引入人为的错误。所以，在专业的产品研发环境中，我们意识到这个人类认知的过程偏差，所以需要建立规范的工具方法，如需求文档的评审、需求撰写的规范等，作为“获取正确需求”的底线保障，确保最大可能地不失真。而敏捷思想里强调的“客户合作胜于客户合同”，也正是基于这个不可更改的事实做出的更合理的过程建议。
图10
需求的开发包括需求分析与需求的分解与分配的过程。它是软件产品开发“正确做事”的过程。这个过程可以使用类似FAST功能分析图、EFFBD图、UML建模或者其他建模工具实现，也可以使用其它不同的工具方法，如KJ法、KANO法、QFD法、Pugh矩阵法等等，帮助我们有效工作。
需求开发从产品定义语境出发，逐步细化分解功能，最后分配到子系统和模块。这个过程是用户可见的功能和可感知的非功能性期望，转化为我们软件产品能力的过程。如果是0到1的产品开发，这个过程与产品架构设计交互迭代，最终形成产品的雏形；如果是基于原有产品架构的功能增加，则更多的工作是基于原有架构进行需求分配的过程。当然，不排除原有系统需要重构，才能满足客户的功能要求的情况。
而架构设计则是将技术需求转化为系统的蓝图，涉及功能模型定义、架构评估方法选择、物理架构布局等多个环节。软件产品常见的技术架构包括了C/S架构、MVC架构、分层的SOA架构等。但具体的架构设计，要考虑的不仅关乎技术实现，更是一种权衡艺术（Trade-Off），需要在功能、成本、时间、用户期望等多种因素间寻求最佳平衡。
如图11，当面对客户“过河”的需求，架构设计可能需要考虑桥梁、船只、潜水艇，飞机等多种解决方案，每种方案背后代表了不同的技术复杂度、投资规模与时间周期，系统架构就是需要在不同的解决方案中选择最合适的，而不仅仅是技术最优的。
图11
在架构设计过程中，可以运用启发式问题法、KJ法、QFD等工具进行评估与决策，有助于识别最合适的架构。同时，评估软件架构的有效性，还可以通过创建原型、迭代开发、模型模拟等方式获取直观反馈，必要时引入量化指标进行深度分析。
康威定律揭示了一个重要规律：软件架构往往反映出组织内部的结构。这意味着，良好的组织设计有助于催生高效、协调的软件架构，反之亦然。因此，在软件开发过程中，应充分考虑组织架构对技术实现的影响，确保架构设计既能满足功能需求，又能顺应组织协作模式。
软件编码是将设计转化为可执行代码的过程，需要遵循相应的编程语言规范和组织内部编码标准（例如，谷歌C++代码规范：Google_Cpp_Style_guide_CN.pdf (sosohu.github.io)），辅以静态代码扫描、动态测试及代码评审等工作，确保代码质量。伴随着AIGC的泛化，AI 辅助编码和代码评审也逐步成为现实，比如Github Copilot X，可以协助程序员实现结对编程。同样，类似ChatGPT，也可以帮助我们实现代码评审的工作。例如，我们把下面这段冒泡算法的C代码（图12）输送给ChatGPT，GPT会给出非常中肯的评审建议以及重构后的代码，大大减少了代码评审的工作量。图13是ChatGPT重构后的代码。GPT的反馈如下。他不仅仅反馈了代码的逻辑错误，对程序的性能也给出了建议（第2条反馈）冒泡排序算法的内层循环条件for (j = 0; j < len - 1 - i; j++)中的len - 1 - i可能会导致数组越界。应该将内层循环条件修改为for (j = 0; j < len - 1; j++)。
- 在冒泡排序算法中，如果数组已经是有序的，仍会执行完所有的比较和交换操作，造成了性能上的浪费。可以在内层循环中增加一个判断条件，如果没有发生交换，即可提前退出循环。
需要注意的是目前GPT仍然是概率算法，他的反馈需要一定的人工复核，确保剔除AI给出的噪音反馈。测试则是软件质量的守护神，涵盖单元测试、集成测试、功能测试、系统测试及验收测试等不同层次，目的是尽早发现问题、减少后期修复成本、确保软件符合客户需求与期望。无论是在V模型或者敏捷开发模型中，软件测试活动的目的是一致的，而测试活动贯穿整个开发周期（图14所示的V模型）。早期集成测试能有效缩短交付周期，提高客户满意度。测试执行过程从时间顺序上可以分为三大部分：单元测试，集成与功能测试和系统验证与验收测试（图15）。单元测试聚焦单个代码单元的功能正确性；集成与功能测试检查模块间交互与整体功能完整性；系统与验收测试则验证软件系统在真实环境下的表现是否满足需求。通过及早发现问题，测试不仅能节约成本，还能提升软件的稳定性和可靠性，为市场成功奠定坚实基础。在实际操作过程中，无论是敏捷或是V模型，测试过程并没有这么严格的顺序区分，往往是循环迭代的反复过程。对于如何确保已经验证的功能仍然是可信的，往往是需要经验和智慧的积累。关于软件测试，我们必须清晰地认识到“测试不是银弹。穷尽测试是不可能也不现实的”。所以，端到端的软件质量保障，从需求到设计，从编码到测试，全链路的保障才是我们需要竭尽全力的目标。伴随着AGI及数字化技术的发展，测试技术手段也在日益改进，新的测试技术开始逐步开始向RPA，AI赋能的测试手段方向发展（见图16）。而对汽车行业软件开发而言，自动化测试技术、RPA、AI、新的应用场景的测试也慢慢开始渗透，成为测试团队的新挑战。四、软件发布：舞动的韵律
进入开发阶段后，采用CI/CD（持续集成/持续部署）的实践，包括代码提交、规则检查、代码评审、预编译、软件包构建、内部发布、测试验证以及对外发布等一整套流程，确保软件质量的持续性和稳定性。在这一过程中，构建Sanity、自动化测试以及各类环境下的验证是必不可少的环节（见图17）。CICD在软件开发全生命周期中体现的核心思想是快速反馈、频繁交付和可靠质量。通过自动化构建和部署流水线，让开发团队能够迅速响应变化，减少人工干预带来的延误和错误，确保软件在各个阶段都能高效地完成集成、测试和部署，最终达到高质量、高效率的产品交付目标。在软件的维护阶段，针对存在的问题和错误进行及时修复，根据用户反馈和市场需求持续进行功能改进与性能优化。对于汽车行业的嵌入式软件而言，还涉及到与硬件结合的复杂集成测试，以及类似FOTA，SOTA（空中下载技术）更新等特殊的软件升级场景。此外，汽车行业软件发布遵循项目生命周期的各个阶段，如工程样车（EP）、产品及过程验证（PPV）、预试生产（PP）、试生产（P），直至正式投产（SOP）。在整个过程中，项目质量管理扮演着关键角色，不仅要保证软件产品的质量和性能，还要确保软件开发与发布过程符合既定的质量标准和国标、企标。- 技术研发着眼于长远，追求技术先进性与知识积累，目标是开发出具有竞争优势的技术成果，为未来的市场化产品提供技术支持（TPF过程）。
- 产品研发更直接面向市场，关注产品创新与商业化进程，旨在快速推出符合用户需求的新产品，创造价值与利润（PMF过程）。
如图18所示，技术研发和产品研发在生命周期、市场定位、技术难度、管理手段等方面存在显著差异，但均需紧密围绕用户需求展开。技术研发往往领先数年，承担探索未知、孵化前沿技术的角色；产品研发则紧跟市场脉搏，力求在短期内实现产品的更新换代。二者相互依赖，共同推动企业技术创新与产品迭代的良性循环。当然，因为技术研发与产品研发的定位不同，企业在实际管理过程中，不能把产品研发的管理手段，比如某款车型研发，简单地套用到技术研发管理中（比如，某款新材料、新动力电池或平台架构等）。软件开发的成功离不开强大的组织支撑与人才队伍建设。研发组织应注重能力建设，涵盖组织架构设计、业务流程梳理、数字化工具链集成（如禅道管理软件，CICD工具链，云端软件DevOPS工具链等）、知识管理、信息安全等多个维度。同时，建立健全绩效考核与激励机制，确保人才的成长与发展与组织战略目标相一致。人才发展方面，提供管理与专业技术两条晋升通道，满足不同类型人才的职业发展需求。管理路线涵盖研发主管、经理、总监等。专业技术路线包括了高级项目经理、产品经理、质量经理等专业角色；专业技术路线还包括了技术专家、高级专家、资深专家等技术精英。通过明确的职业发展路径，激发人才潜能，形成稳定且富有活力的人才梯队，避免“重技术，轻职业化”的问题。根据PRTM的产品开发能力成熟度评估模型（图19），软件开发组织的成熟度可以分为5级。建议优秀的车企应该向成熟度4级（Stage 3）努力，提升组织的核心竞争力，确保打赢汽车智能化和汽车产业数字化这一仗！本文为我们勾勒出一幅从理论到实践、从模型选择到组织构建的全景图。无论是初涉软件行业的新人，还是寻求优化研发流程的企业管理者，都可以从中汲取宝贵的知识与经验，助力在瞬息万变的科技浪潮中稳操胜券。软件开发并非孤立的编程活动，而是涵盖了需求分析、架构设计、编码实践、测试保障、技术研发、产品研发、组织管理与人才培育等多元要素的系统工程。唯有深入理解并妥善驾驭这些要素，方能在激烈的市场竞争中立于不败之地。三、软件定义汽车2-汽车软件开发与方法
（原创 动力哥 汽车动力总成）
现代汽车已经从一个机械设备演变成一个依赖软件正确运行的分布式信息物理系统。从利用软件来优化车辆表现到车载娱乐系统的编辑，软件为汽车行业的发展带来了大量的新机遇。现代汽车中分布着各类电子设备，而一个遍布着各类软件产品的汽车平台，也一定是消费者喜闻乐见的。来自老美的特斯拉，披着汽车制造的软件公司，它以软件驱动创新而闻名，通过持续向车辆推送软件更新，使车主每天都可以享受到最新的车辆功能。（个人觉着百分之七八十的车主都是因为这点选择的特斯拉，毕竟哪位司机朋友不想着天天老车新开）密集的软件系统带来了新的机遇，但必须意识到的是，在这些软件发布给用户之前，必须要经过更细致的设计、实施、验证和确认工作。近几年来，国外特斯拉、国内“蔚小理”等造车新势力的出现，可以明显发现，机械工程对汽车工业发展的主导性正在逐渐降低，而电子和软件工程正在逐渐掌握话语权。严格的软件工程流程可以在保证不额外增加系统复杂性的前提下提升软件质量，并确保这些代码不会在交通场景下导致致命的危害。在软件工程中，一个重要的环节是软件系统的高层设计，这种概念用更通俗易懂而统一的称呼，可以称呼为软件架构。一个软件的架构可以为软件设计者提供一个规范框架，告诉他们一个软件功能是怎样拆分为各个软件组件以及这些组件之间又是如何交互的。软件架构的设计通常在软件开发的早期阶段就已完成，是将其作为软件被拆分为组件以及功能被系统化到不同组件的基础依据。早期的汽车工业，车辆上并不存在电子产品，直到上个世纪70年代，为了顺应市场对提升燃油效率的诉求，电子喷油装置被应用在了汽车上，拉开汽车电子化的序幕。在最初的10年时间里，大部分的汽车软件都是深度嵌入某单一功能域内的电子装置中，例如动力总成系统中的电子燃油喷射装置，电气系统中的中控锁、电子点火装置等。由于当时车辆的电子设备较少，而车辆的安全功能又通过机械的方式得到保障，因此汽车软件的架构通常是整体式的，不同设备的软件之间并不存在通信交互。在1980年代，如中央计算机等创新不断出现，使得车辆一些基本行驶数据可以被读取和显示，人机交互进入了新的篇章。在嵌入式软件方面，一些受软件算法控制的新功能出现，如ABS防抱死制动系统和电子变速器等。在1990年代，更多消费者可见的电子功能出现，最值得注意的便是车载信息娱乐的导航系统等，车辆信息的实时可视化意味着更多重要电子组件的整合，如动力总成的控制器、GPS信号接收器以及信息娱乐显示等设备之间进行数据的交互。在2000年代初，经过20年的快速发展，汽车软件已经成为汽车行业创新的主导因素，大量的硬件导致大量的软件，造成了人力物力的极大浪费，AUTOSAR标准的应运而生，它的出现为汽车软件架构提供了开放式的解决方案，当相同软件应用到不同硬件平台时，所需要进行的软件变更大幅减少，就好像汽车中的计算机引入了一个普适的操作系统，让不同汽车制造商可以方便地共享同一功能组件。在此之前，汽车软件都是基于某一独立的车辆内部网络的分布式结构进行设计的，现在，一种全新的汽车电子设计方法被提出，无线汽车的概念被提出，车与车通信、车与基础设备通讯，以为无人驾驶成为软件架构发展的推动力，一些新成员粉墨登场，售卖给消费者的汽车不再是最终产品，而是一个可以在全生命周期随时部署新功能平台，特斯拉的汽车产品就是这一理念的先行者。需求过程是软件开发流程生命周期中的初始阶段，软件产品的质量定义为，软件满足用户需求、隐形期望和专业标准的程度，这足以说明需求对软件质量的重要影响。（专门研究人员在奔驰的研究中表明，一辆现代汽车的需求规格说明如果拆分到组件层面，总长度可达到十万页的数量级，这些需求文档会被分发到数量庞大的供应商，用于开发各自ECU产品）汽车软件的架构和高层描述通常属于OEM的业务范畴。OEM会决定他们设计的车辆具备哪些功能以及哪些需求是嵌入在软件及电气系统中的。它们还负责将系统层面的需求分解为特定软件组件的需求，然而，软件组件的详细设计及后续的实施则是供应商（包括Tier-1、Tier-2和Tier-3）或OEM内部软件开发团队负责的领域。他们需要进行软件组件的需求解读，组件架构设计，软件的实施、集成及测试，然后将软件交付至OEM。软件开发流程是汽车软件开发过程中的核心，软件开发流程为软件开发实践提供了一个骨架并确保了它的严谨性。软件开发的流程包含“阶段”“活动”和“任务”三个要素，它们规定了参与者需要完成的工作，总体上看，上述各阶段可以排列成V（Verification和Validation模型）型曲线，它取材自多个国际工业标准，例如 ISO / IEC 26262等，常被用于安全关键系统的开发。将整车层级逐步分解到组件层级的需求，俗话说万事开头难，需求工作做足且后期不变更，可以更有效的保证后期任务在有效时间节点内完成。AUTOSAR是汽车软件研发的重要灵感源泉，因此，当我们探讨软件需求时，不妨先看看AUTOSAR标准中的需求格式。在该标准中，需求大多以文本形式出现。需求的结构并没有什么特殊之处，和一般意义上的需求类似，它包含了需求的描述、理由和用例。文本需求被用于描述车辆的最高级别属性，通常在两个阶段出现，一是需求阶段，用于定义高层车辆功能规范，另一个则为组件设计阶段，用于制定大规模软件需求规格说明。定义文本类型需求的工作很少是从零开始的。它们通常是基于模型制定，被用来在模型的基础上进一步描述软件系统的内部工作细节。当要传递需求的概览或提供需求的上下文时，需要用到另外两种需求的表现形式是“用例”和“模型”。用例描述了在规格说明下一个参与者和系统之间的一系列交互。下图所示的是用例的例子，参与者在用例“无钥匙启动”中与车辆进行交互。相应的图表被用来表示存在哪些交互以及这些交互过程中包含多少参与者。在汽车工业，用例形式的需求规格说明最常见的应用场景是描述车辆功能的依赖关系，即为实现某个特定的用例，参与者(驾驶员或其他道路车辆）和被设计的车辆（系统）之间是如何交互的。基于用例的需求规格说明通常使用如图所示的UML序列图进行描述。另一种能为需求提供更多上下文表达方式的是模型，这种方式一般可以采用两种格式，类似于UML的模型和Simulink模型。建立良好的需求和构建元素数据库是汽车软件工程成功的关键，这是由于汽车市场的可变性基础上，即软件产品必须具备可配置性，作为消费者，我们肯定是希望自己的车可以配置最新的最强大的硬件、电子系统及软件功能。除此之外，仍然需要将硬件与硬件、软件与软件以及最终的软件硬件集成在一起，再进一步集成到整车电子电气系统中。需要注意的是由于不同的软件模块开发可能以不同的步长来进行，因此集成步骤也不是同时集成的。需求始于高的抽象层级，并逐渐向更细节更低的抽象层级发展。而测试则正好相反，测试工程师会从单元测试（最小的颗粒度）开始执行，对逐个函数或逐行代码进行测试。进一步，他们将对整个组件进行测试（即将多个单元连接在一起），最后再向整个系统实施及单元测试和车辆整体功能测试推进。以下对各阶段的测试进行简单说明，单元测试是最基本的测试，在独立的软件上执行，单元测试的目标是发现与源代码中的原子级功能及方法的实施有关的缺陷。自动化测试用例是单元测试的常用方案。测试用例将个性化的方法和达成期望质量所必需的数据相结合。在执行测试后，再将测试结果和期望结果对比。当发现测试用例中的某个问题，利于快速描述缺陷位置甚至给出缺陷修复意见。组件测试有时也称为集成测试，其目的是测试某组件内不同单元问题代码的集成。组件测试和单元测试的主要区别在于，根据不同的工况来模拟被测组件或者组件组合的运行环境。在汽车系统中，组件测试通常采用软件建模工具（Model-In-the-Loop，MIL,软件/模型在环）或者硬件模拟器（Hardware-In-the-Loop，HIL，硬件在环）来模拟测试环境，又由于组件测试在模拟环境下进行，非功能特性通常是无法被测试的，若想测试的话则需要模拟的细节非常详细，这会带来更高昂的测试成本。（笔者从事的行业中，若使用通用的HIL设备价格是一个数，若要实现自己期望而冷门的需求，则需要另附额外的资金，会使得整套HIL设备十分昂贵）系统测试是在整个系统集成完成之后，将系统作为一个整体进行测试的阶段。系统测试的目标是在多个维度上检查系统是否满足规格说明中的要求。所验证为的维度包括，1.是否具备规定的功能；2.是否可以与其他独立系统交互；3.是否可以继续扩展；4.高负载下是否可以运行；5.是否满足性能要求；6.可靠性是否达标；7.是否符合法律法规要求。（在汽车领域，此类测试一般使用具有完备电器系统且没有地盘和硬件设备的实验台架来进行完成）功能测试式验证系统的功能是否按照规格说明书要求正常运行，作为对采用用例形式定义的功能需求的回应，以下以一个测试用例来进行说明。从以上说明可以总结的到设计位于V型的左半边，测试位于右半边，不同的阶段可以总结为，1、需求 (requirements engineering)：该阶段用于创建有关软件功能的设想并将设想分解为多个需求（关于应该实现什么的碎片化信息）。2、软件分析 (sofiware analysis)：该阶段用于执行系统分析，做出关于将功能分配到系统中不同逻辑部分的高层级决策。3、软件架构设计 (software architecting)：该阶段，软件架构师将描述软件区其组件的高层设计，并将这些组件分配至相应的计算节点(ECU)。4、软件设计 (software design)：该阶段用于软件各组件的详细设计。5、实施(implementation)：在该阶段，用相关的编程语言实施组件的设计。6、测试 (testing)该阶段，软件以多种方式进行测试。在实际的软件开发方法中，目前市面上最主流并且广泛使用的方法是基于MathWorks公司出品的商用软件Matlab中的Simulink可视化工具来进行汽车嵌入式系统的建模、仿真和集成。汽车软件设计中使用的模型通常反映了汽车功能的行为，因此，模型是在能够反映物理世界而非软件世界的形式体系内创建的。其过程如下图所示。下面描述一个经典的ABS实例(使用Matlab/Simulink可视化工具)。首先，在设计过程的开始，汽车的功能被描述为一个数学函数，函数的输入和输出被数据流所定义，表明使用数学模型来描述汽车功能。此过程中需要将车轮的打滑、力矩和速度的相关物理过程描述为以时间为自变量的函数（或多个函数)。当确定好数学上的描述之后，将所有的方程翻译成一组Simulink模块。在将数学方程转换为Simulink模块和函数的过程中。需要关注的是数据的流动方向和反馈回路，例如，在ABS示例模型中，车轮的打滑取决于车速，车速反过来又与车轮滑移有关。若Simulink库中不包含的功能，需要通过现有的模块或在Matlab中手写代码，以描述一些标准库中不包含的功能，完成建模和测试之后，完成建模和软件的一些测试工作之后，模型将被生成为目标语言代码（通常是C 或者C++具体选择取决于系统要求）。下为MathWork文库中防抱死制动系统ABS模型，此示例说明如何建立一个简单的防抱死制动系统ABS模型。它对车辆在紧急制动状况下的动态行为进行仿真，此模型使用理想的防抱死制动控制器，该控制器使用基于实际滑动与期望滑动之间的误差控制。在施加制动之前，车轮以对应于车辆速度的初始角速度旋转。使用单独的积分器来计算车轮角速度和车辆速度。同时使用两个速度来计算滑动，引入了用角速度表示的车辆速度。根据下述表达式，可以看出当车轮速度与车辆速度相等时，滑动为零；当车轮锁定时滑动等于1。合适的滑动值为0.2，这意味着在车辆速度相同的情况下，车轮转数等于非制动状况下转数的0.8倍。这将最大限度地提高轮胎和道路之间的粘附，并通过可用摩擦最大限度地缩短停止距离。轮胎和道路表面之间的摩擦系数mu是滑动的经验函数，称为mu-slip曲线。使用Simulink查找表将MATLAB变量传递到模块图中来创建mu-slip曲线。模型将摩擦系数mu乘以车轮上的重量W来得到作用在轮胎圆周上的摩擦力Ff。车辆质量除以Ff可得出车辆减速度，模型对其进行积分以获得车辆速度。将期望的滑动值设置为mu-slip曲线达到峰值时的滑动值，这是使制动距离最小化的最优值。下图显示了ABS仿真结果。图中的第一个图显示了车轮角速度和相应的车辆角速度。此图表明，在未锁定的情况下，车轮速度始终低于车辆速度，车辆速度在不到 15 秒的时间内变为零。该种建模的方法可以称为“基于模型的设计方法-MBD，Model Based Design”，采用的是图形化设计和自动代码生成，是不同于基于手工编程和纸上规范的传统变成方法。在本期主要内容中，介绍了为什么发展汽车软件工程、目前主流的汽车软件开发流程以及简单说明了基于MBD开发方法。回顾历史，从1970年的简单发动机控制算法，到2000年的先进安全系统，到2010年的先进车联网技术，2020年的自动驾驶算法技术，汽车的软件数量明显增加，且呈指数上升，汽车软件技术革新带来很多挑战的同时也带来了大量的新机遇。最后，借用博世的一句话“毫无疑问，我们必须以持续改善现状为目标，必须一致努力做到更好，而不是安于现状”。注：文章中引用数据和图片来源网络
1、如您转载本公众号原创内容必须注明出处。
2、本公众号转载的内容是出于传递更多信息之目的，若有来源标注错误或侵犯了您的合法权益，请作者或发布单位与我们联系，我们将及时进行修改或删除处理。
3、本公众号文中部分图片来源于网络，版权归原作者所有，如果侵犯到您的权益，请联系我们删除。
4、本公众号发布的所有内容，并不意味着本公众号赞同其观点或证实其描述。其原创性以及文中陈述文字和内容未经本公众号证实，对本文全部或者部分内容的真实性、完整性、及时性我们不作任何保证或承诺，请浏览者仅作参考，并请自行核实。
夜雨聆风
