写在前面
汽车进入智能化时代，产品与技术的复杂度直线上升，传统的研发体系已经无法满足需求，需要升级进化，以支撑智能汽车的开发。
本文从技术的视角，分析研发体系应该如何升级，以满足智能汽车的复杂功能和复杂项目的需求，并呈现智能汽车研发体系的纵向演变史和未来方向。
研发体系是新产品开发的重要支撑，能够有效地综合管理产品、质量、进度、资源、成本、平台、架构等研发活动中涉及到的方方面面。通常，研发体系是一套完善的系统，可以支持全生命周期的研发过程。
从传统汽车时代进入智能汽车时代，无论是车辆上的模块，还是搭载的功能，都变得越来越复杂，数量增多的同时，集成度也大大增加。那么，对应的研发体系，自然也要同步升级，以满足智能汽车开发的要求。
本文从研发体系的关键要素和流程出发，探讨汽车智能化的研发体系，相对于传统汽车是如何升级进化的，并结合实际，梳理汽车研发体系的纵向演变历程，帮助读者加深理解。
研发体系的关键要素
研发体系作为一套完善的系统，本身就是复杂的，包含多个组成要素，是保障新技术、新产品能够成功开发落地的前提。对于智能汽车，其研发体系所包含的关键要素如图1所示。
图1 研发体系的关键要素
需求管理，可以提供完备且可追溯的需求输入，确保所有需求都能被准确记录和跟踪。
项目管理，通过对项目的计划、风险、周期等的管控，并协调资源与相关方，来确保项目完成交付。
投资组合管理，管理的是研发资源，包括工具、人力、时间等，并合理分配到各研发要素中。
质量管理，基于流程规范、交付标准和测试体系，监督并保证产品质量，包括过程质量和交付质量。
流程管理，能够串联上下游团队，基于需求实现协作分工，制定需求规范和交付标准。
知识平台，提供与产品和研发有关的各类知识，包括业务、技术和流程知识等，并能持续迭代更新。
CBB（Common Building Blocks）平台，即共用基础模块平台，能够将相关的技术、模块和功能平台化，实现即选即用。其中技术来自于技术开发项目，模块来自于架构团队，功能来自于系统团队。
工具链，是研发活动的重要支撑，不仅能有效提高质量和效率，还能支持持续创新，降低研发成本。
组织架构，通过定义职能团队、人才梯队、技术能力和职责边界，实现完善的团队分工与协作机制。
完善的研发体系，能够有效整合以上这些关键要素，确保产品研发过程的高效性、规范性和创新性，实现产品的顺利交付和市场成功。
研发的完整流程
研发体系的各项要素，不是单一的、分散的，而是在研发活动中，通过一套完整的流程，产生关联，共同推进研发过程的顺利开展。
图2展示了研发的完整流程，分析了从产品需求到产品开发的完整过程，直观反映了研发体系中各关键要素间的交互与依赖关系，以及各环节的边界与分工，能够指导研发活动的有效开展。
图2 研发的完整流程
业务战略和技术趋势会决定研发体系的长期目标，通常是3年以上的长期目标，以明确公司的发展方向，确保所有的业务活动和技术开发都朝同一个方向迈进，避免盲目和短视的决策。
业务路线和技术路线决定研发的过程目标，是业务战略和技术趋势的阶段性体现，确保方向明确，不偏离。正确的业务路线和技术路线，能够让产品具备竞争力，在市场上脱颖而出。
产品规划和技术规划制定了短期内、具体的产品开发需求。产品规划会提出新产品的应用场景、功能需求、性能要求等内容，技术规划根据产品的开发目标，制定技术开发目标，满足产品开发的需求。
在产品规划完成后，就进入正式的产品开发阶段。根据新产品与公司已有平台或已有产品之间的关系，可能会直接进行产品开发，也可能先进行产品预研。产品开发，尤其是量产项目的产品开发，是研发体系的核心。
如果新产品可以直接延用公司的现有平台或现有产品，就可以基于成熟方案，复用其技术、模块、功能、流程等，直接进行产品开发。复用的方式能够显著提高开发效率、降低成本，并减少开发过程中的风险和不确定性，保证产品质量的可靠性和稳定性。
如果新产品包含新的功能、模块，或者需要集成新技术、引入新工具等，都需要进行新的探索，形成新产品开发的最佳实践并固化，更新平台，更新流程规范，以支撑产品的量产开发。产品开发的最佳实践，主要指系统设计和流程规范。
系统设计包括功能设计、模块设计和技术集成。
新功能需要重新进行功能设计，属于行为设计和动态设计，一般由系统工程师承接。对于新产品提出的新功能需求，以及更高的性能指标要求，如更好的用户体验、更低的成本等，需要首先开展预研工作，找到合适的方案。
功能可以通过一个或多个模块来实现，可以将不同的模块组合成平台化的功能方案，增强可复用性，如果现有的模块不能满足新功能需求，则需要开发新的应用技术并集成到子模块中。功能的颗粒度主要通过功能组、主功能、子功能、任务等结构化方式来管理。
新模块需要重新进行模块设计，属于结构设计和静态设计，一般由架构师承接，需定义各模块的边界、功能和接口。模块可以分为应用模块、应用服务、基础服务和系统模块：
应用模块承担业务逻辑，可以内部集成简单专业技术逻辑，一般直接调用。
应用服务封装业务共性的逻辑部分，并对接口进行服务化设计，可以降低上层应用的复杂度并支持独立开发，适用于专业技术相对复杂的场景。应用服务如果进一步抽象，可以转为基础服务，如工业控制领域的解释器算法，从专用算法抽象成通用算法框架。
基础服务不包含具体的业务逻辑，但可以显著降低上层应用的复杂程度，如分布式通讯、确定性调度、配置管理等。以分布式通讯为例，可以让应用层只需要提出业务通讯需求，而不用关心底层实现。既然基础服务与业务无关，那么集成到具体的系统中时，就需要二次开发，增加业务的相关配置，例如通讯矩阵设计就是通讯Server的二次开发，Client也需要基于SDK开发消息收发任务。
系统模块负责管理和维护整个系统，但基本不涉及核心业务要素，包括系统状态机、产线测试、售后测试、哨兵防盗和守护进程等。系统模块更像是应用模块，而不是基础服务。
产品预研中的新技术，不是指开发新的技术，而是技术集成，以验证技术工程应用的可行性，主要包含专业技术和通用技术。
专业技术是与业务强耦合的技术，比如某些工艺算法逻辑，如果是简单的专业技术，可以直接调用接口，封装到应用模块中；如果是相对复杂的专业技术，可以封装成服务，固化共性的技术要素。
通用技术与业务无关，通常需要二次开发才能满足具体的业务需求，通用技术的框架部门会固化到基础服务中，作为核心逻辑支持扩展和二次开发。
新流程是优化功能或模块开发的质量和效率而引入的，需要通过产品预研的验证，并固化成最佳实践SOP（Standard Operating Procedure，标准操作程序），包括功能开发、模块开发、技术集成的SOP，以及编译、调试、CICDCT、版本管理等基础流程的SOP。
应用技术开发是对技术规划的落地，会将基于业务目标制定的技术规划，集成到产品系统中。应用技术开发与产品预研中的新技术集成不同，更侧重于技术原理的研究，而不是工程化的研究。应用技术的开发包括专业技术开发和通用技术开发。
前面提到，专业技术与业务强耦合，既可以提供直接调用接口，也可以服务化，服务化能够降低应用的复杂度，但需要投入更多的资源。
通用技术一般与具体业务没有直接关联，其集成和应用通常会涉及到C/S结构。Server封装了通用技术的核心和框架部分，并定义了Client模板。Client继承模板后经过二次开发才能与Server集成。以分布式通讯服务为例，Server端封装了通讯底层机制，而Client端基于模板开发Send/Recv功能来收发消息，并封装为CommunicateAdaptor。
工程技术与工具链的开发，能够显著提高研发体系的质量和效率，包括专业工具开发、通用工具开发和基础工具开发。专业工具用于专业技术开发、集成和调试的过程，通用工具用于通用技术的开发、基础服务C/S二次开发、集成和调试等过程，基础工具支持研发的基础流程，如编译、调试、CICD、版本管理等。
如何推动研发体系进化
研发体系的进化本质就是由于业务规模和复杂度的提升，导致研发团队变革的过程，以保障复杂产品的高质高效交付。研发体系的进化升级，可以让团队聚焦业务、降低成本、保证开发质量、提升开发效率。
业务和技术的变化是研发体系进化的主要驱动力。
在业务层面，随着业务的不断扩展和多样化，系统架构需要优化，以应对新需求，同时，研发流程和平台也需进行相应调整。这种调整旨在将研发的变量部分聚焦于业务，从而提高整体效率和适应性。
可以说，应用模块和研发流程的复杂化是业务复杂度提升的直接结果，这就要求研发团队更关注模块化和流程的优化。
在技术层面，随着汽车智能化的发展，用户对产品性能和质量的期望也在不断提高，更高的要求需要引入新的技术，从而提升产品的竞争力，还能带来更好的用户体验。
新技术的引入会对现有的研发流程和工具链提出新的挑战。为适应更高的技术要求，研发流程和工具链都需要不断优化，不仅包括工具和技术层面的改进，还涉及到团队技能的提升和组织结构的调整，以确保新技术能够顺利落地并发挥其应有的价值。
研发体系的升级进化，主要通过拆解业务要素、剥离技术要素、优化流程方法实现。
拆解业务要素：当更多的业务需求出现时，一般先由应用模块承接。
当业务复杂度越来越高时，会导致应用模块变得越来越复杂，此时需要拆解应用模块，以降低其复杂度。可以通过把业务拆解为多个功能组、主功能、子功能、子任务的方式来降低业务的复杂度。
剥离技术要素：当技术变得复杂时，需要通过剥离技术要素来降低业务复杂度。
对于专业技术，可以直接调用或者让专业技术服务化，技术服务化往往更有效果；对于通用技术，可以将其进一步抽象，转变成基础服务，彻底剥离业务要素，例如，通用智能（AGI）相比于专业智能，更能应对复杂场景和业务需求。通用技术的抽象化，往往要求更高，适用范围更广，开发过程更复杂，规范化要求更高，技术上更难实现。
优化流程：研发流程变得复杂时，需要通过优化流程来升级研发体系。
对于新的功能开发、模块开发和技术集成，最佳方式就是固化为流程SOP，包括需求规范、交付标准、设计规范、操作规范等。另外，通过流程SOP和过程监督机制，可以有效保障过程质量。
可以提升功能、模块和技术的通用性，让其变得可复用，让产品开发变成搭积木式的流水线工作，增加过程鲁棒性，减少新开发的成本。
基于流程中的薄弱项和关键痛点，可以设计开发工具，优化工程技术和相关工具链，让开发流程更规范，同时提升开发过程的质量和效率，并保障交付质量。
通过以上方法措施，能够让研发体系持续进化，提高研发效率、降低成本、保证质量，最终实现公司的战略目标。
研发体系演变历程
车载智能化的研发体系，从传统汽车时代到现在的智能汽车时代，主要经历了三个阶段：项目型研发体系→矩阵型研发体系→平台型研发体系。
第一代：项目型研发体系
传统汽车时代，智能化的功能和模块很少，主要是针对个别需求立项，通过单一项目的方式来推进智能化的研发，针对每个项目独立进行开发，缺乏统一的标准和平台支持。
图3 项目型研发体系
典型的项目型研发体系如图3所示。产品团队承接来自用户、销售、售后、生产等部门的需求，不过，此时的需求往往非常简单，甚至有些前台部门并不清楚自己的需求是什么。
产品团队会将前端的需求转化成对新产品的整机需求，传递到开发团队，开发团队完成产品研发，并交付给测试团队进行测试验证。同时，产品团队也会与测试团队合作，以确保产品符合最初的开发目标。
可见，项目型研发体系适合单一项目的简单业务需求，通常具备以下特点：
业务简单，项目工作量小、过程简单、易于管理，不需要拆解业务，也没必要构建专门的职能组织架构。
项目单一，无需过多考虑复用性，更不需要建立技术、模块、功能的平台，即选即用。
技术简单，容易实现，无需过多对技术探索进行投入。
方案简单，功能往往是非常清楚简洁的，基本不需要考虑系统架构。
项目驱动，关注短期的项目收益，忽略技术预研、平台和流程规范建设等长期投资。
第二代：矩阵型研发体系
随着智能化在整车上的占比越来越大，业务和技术的复杂度都大幅增加，简单的项目型研发体系已经无法满足开发需求，此时需要建立新的矩阵型研发体系。在经典平台Autosar成熟之前，行业已经在探索更复杂的研发体系，以支撑相对复杂的产品研发。
图4 矩阵型研发体系
如图4所示，研发体系从项目型升级到矩阵型，主要从以下方面考虑：
将单一的开发团队，拓展并建立专门的系统、结构、硬件和软件职能团队，以及对应的测试团队，并变革相应的研发流程，让各新增部门能够协作分工复杂的研发工作。
其中，系统团队承接来自产品团队的整机需求，并分别由系统架构师和系统工程师，完成系统的结构设计和行为设计，实现完整的功能架构。
结构、硬件、软件团队作为专业细分方向的部门，承担系统需求的技术实现，并长期积累专业技术，搭建技术平台。
项目的增加要求模块和功能支持跨项目复用，以提高研发的质量和效率，此时需要对技术和模块的可复用性，以及标准化、工具链的投入，需要加大力度。
应对技术复杂度的增加，需要制定技术路线，构建技术平台，确定核心技术，申请专门的技术开发项目，由各职能团队预研并积累技术要素。
尤其需要关注产品复杂度提升导致的质量问题，要有更高的质量管理办法。对于过程质量，应该制定正向的研发流程和规范标准，并专人监管；对于交付质量，应通过有效的测试验收标准来把关。
第三代：平台型研发体系
如果说矩阵型体系的目标是服务化、中台化、可复用和规范化，那么第三代的平台型研发体系的目标就是实现技术开发和业务开发的彻底解耦。让做业务的人不需要懂技术，只要按照相应的需求规范，把业务诉求以不同形式给到技术开发即可，不需要关心底层实现，可参考工业控制的教导程序、通讯开发的通讯矩阵等。
在经典平台AUTOSAR成熟之后，业务变得更加复杂，产业链整体需要协同合作，才能做好智能汽车产品。在行业通用的规范基础上，出现了各种可复用的基础模块和支持全流程开发测试的工具链，标志着平台型研发体系的形成。
图5 平台型研发体系
从图5中可以看出，平台型研发体系新增的模块主要是非功能架构和通用技术。
对于功能架构来说，一项很重要的原则是不能出现任何非功能的基础服务模块，因为要彻底解耦通用技术要素和业务要素。非功能架构则引入基础服务组件，基于通用技术框架设计应用模块、应用服务等上层模块和基础服务之间的交互视图，包括接口关系和任务分工。
常见的通用技术包括功能安全、信息安全、确定性调度、分布式通讯、系统自适应运行管理、资源自适应分配、高性能计算、数据闭环、存算一体等。通用技术的构建开发和应用的体系化，属于平台开发工作，可以参考CAN总线的通讯开发，会包括工具链、中间件、通讯矩阵等中间交付物、设计集成二次开发等流程规范和集成框架。
上述的新增开发工作，需要相应的工具来提高效率和质量，通常需成立专门的工具链开发团队。
平台型研发体系庞大而负责，往往需要一部分研发人员脱离业务，专职维护平台体系。
由于平台的构建需要大量投入，因此一般的小团队是难以实现的。不过，对于复杂产品的开发和大量并行的项目，平台型研发体系能够显著降低研发成本，提高研发质量和效率。
三代研发体系的主要特点对比
研发体系
项目型
矩阵型
平台型
需求管理
产品的业务要素简单，项目也少
把复杂业务需求拆分给各职能团队
业务要素和技术要素更新迭代速度非常快
方案架构
解决方案简单、技术要素非常少
解决方案有一定的复杂度，提供标准模块和专业技术
需要研发体系有很强的扩展性和平台化，才能支持需求频繁变更
流程体系
几乎没有流程规范标准
基于技术特点，实现了不同层级的需求承接、设计、分解和实现
ASPICE流程最新的趋势是多V模型，支持功能安全等非功能开发
组织架构
没有任何基于技术特点的职能拆分，大部分被要求作为全栈工程师工作
根据技术特点设立了系统、结构、硬件、软件、测试等团队
需要更多角色脱离业务专注技术开发和集成，专注非功能开发、平台开发和维护
项目管理
几乎没有任何项目管理体系
产品开发项目管理主要关注业务要素的分阶段开发过程。技术开发项目资源很难保证
基于新流程，串联功能和非功能开发，协调依赖和开发顺序
质量管理
业务简单，质量问题不多，自然也没有质量管理体系
有一定的过程质量和交付质量管理方法
交付质量需要有更成熟的平台支撑，比如3C串联了HIL、SIL、MIL、PIL、UTST等测试方案
产品管理
只关注最终交付，不太关注产品中间状态的标准和质量
有简单的产品中间状态管理
有成熟的制品管理体系和平台
知识平台
知识需求少，不太关注知识平台
知识平台关注业务知识和专业技术知识
知识爆炸的时代，不仅要有很好的知识体系和平台，还要宣导给大家，真正运作起来
技术平台
技术需求少，不太关注技术平台
聚焦专业技术的规划和开发
通用技术爆发，需要投入大量的资源做技术开发和积累
模块平台
模块化、组件化需求少，复用需求少，不太关注模块平台
侧重业务应用模块和业务服务模块
应用服务和基础服务的大量增加，可以优化系统结构、降低系统复杂度
功能平台
功能简单，不太需要功能标准化
侧重功能架构方案
非功能需求的比重大量增加
工具链平台
只有必要的开发工具，缺少设计工具和测试工具
围绕功能开发测试有一定的工具链体系
应用服务和基础服务都依赖成熟的体系、规范和工具链
投资组合
项目驱动，关注短期收益，标准化平台长期投入非常少
投资侧重业务开发、业务规范和专业技术开发上
需要加大研发平台相关的投资比重，优化系统架构，提高研发效率和质量
研发体系未来进化方向
未来，智能汽车的研发体系应该更关注新型的通用基础技术，并通过技术开发和产品预研，找到产品开发的最佳实践，简化上层应用的复杂度。同时，根据研发体系的关键要素，梳理相关流程、架构、工具链、知识技能、产品管理、资源投入和组织架构等，做好相应的调整和优化，以保障复杂产品高质高效的交付。
目前需关注的通用技术主要有：SOA、功能安全、信息安全、算法服务化、数据底座、数据闭环、确定性调度、系统自适应运行管理&资源自适应分配、高性能计算/存算一体、可视化诊断等。
SOA涉及通讯、运行和功能安全。
现阶段的AP Autosar仅关注到进程和功能组的生命周期运行管理，还缺少服务、状态机等软件实体的生命周期管理。SOA可以实现业务数据流的封装解耦，让服务使用者无需关心其内部接口，服务调用者也无需关心内部故障和诊断接口。
功能安全，涉及故障监控和故障诊断、故障存储和清除、故障聚合、故障树、故障处理、服务降级等机制。
目前很多模块都跨层级地关注了大量多余的故障信息，但实际上每个模块在外部只需要关注其调用的接口是否出现故障。因此，可以考虑可视化地去追踪故障前后各模块的状态和行为，通过标准框架支持各组件二次开发，无需关心底层故障流及其处理机制。
算法平台化、引擎化，让业务团队聚焦功能逻辑和工艺策略，无需过多关注算法实现，类似参考工业领域的算法引擎和教导程序。
当前的普遍做法是大算法、小功能，即功能只是在给算法打杂，所有的策略和功能逻辑都通过算法直接实现。后续可以考虑将算法做成原子化的模块，供功能调用，或通过端到端的思路将参数分配给功能，让功能的逻辑策略作为算法大模型的可变参数，从而让算法产生数据给到功能。
数据底座可以支持功能和算法的容器化部署。
数据底座的来源是上层应用的声明，类似cp swc生成rte，再通过网络和其他应用同步更新数据。基于数据底座，统一管理数据，可以扩展很多应用，如数据采集、数据前处理等等。另外，数据底座可以支持应用的快速移植部署。
确定性调度可以通过时序图、状态机和流程图自动生成调度代码，以保证各模块的状态调度和协同、任务调度和协同。
合理的系统自适应运行管理和资源自适应分配，可以让系统始终运行在最佳状态，比如始终处于最小功耗状态。
高性能计算能够实现CPU、NPU、GPU、DSP等的提供统一开发和动态部署框架，存算一体可以将数据计算任务捆绑，降低数据运输成本，提高计算效率。
此外，应用服务相关的一些专业技术内容，仍然需要持续关注。
结语
本文通过研发体系的关键要素，分析智能汽车的发展是如何推进研发体系进化的，并系统性梳理了研发体系的进化史，以及未来方向。
总的来说，研发体系的进化核心意义就在于两点：一是实现技术要素和业务要素解耦，降低应用层的复杂度，让系统变量设计聚焦到业务要素；二是优化产品开发过程，探索最佳实践，迭代研发平台，从根本上提高质量和效率。
研发体系庞大而复杂，很难通过一篇文章完全讲解清楚，本文只展示了个人的一些理解，有待继续深入展开。希望本文能够成为与各位同行交流的起点，后续进一步探讨架构方法论、新技术、新应用等话题，期待与各位专家的互动和交流。
热门跟贴