交流群 | 进“传感器群/滑板底盘群”请加微信号：xsh041388

交流群 | 进“域控制器群”请加微信号：ckc1087

备注信息：传感器/滑板底盘/域控制器+真实姓名、公司、岗位

前言：本文首发于2018年中国汽车工程学会年会，并被收录于其论文集中。虽然距今过去已经近四年，但文中所提到的方法论对于国内从事ECU开发的组织仍具有重要的指导意义，毫不落伍。有兴趣参与这方面交流的，可扫描文末的“汽车软件联合开发方法论”交流群或添加作者微信，共同交流。

摘要

相对于传统的汽车电控单元软件开发模式，软件合作开发模式具有客户主导，多方参与，接口繁杂，资源受限，工具多样，责任共担等一系列新的特点。本文从技术合作，知识产权和产品责任三个方面详细介绍了软件合作开发模式的主要特点，并结合大量项目上的实践经验，提出了建议的合作开发解决方案。

其中，技术合作是软件合作开发模式的核心内容，主要包括五个核心要素：职责分工，开发计划，接口定义，资源管理和软件开发环境，文中针对各个要素的背景，特点及应对方案逐一进行了详细阐述。同时，针对知识产权的归属、使用及保密规则也进行了清晰的定义，从而避免参与软件开发的各方技术的泄露或者某一方使用开源软件导致产品整体侵权。最后，共同参与软件开发的各方对于产品责任也必然要共同承担，为此，本文给出了可供参考的产品责任划分原则。

关键词：软件合作开发，汽车电子，知识产权，产品责任

引言

由于产品的多样性、高复杂度、快速与持续的变更需求以及日益紧密的汽车整车和零部件厂商关系，汽车领域软件工程长久以来由电控单元驱动的开发模式正逐渐转换为功能驱动，面向架构的软件合作开发模式，即电控单元的软件不再由电控单元供应商完全开发，而是与客户共同进行开发。

软件合作开发模式使得在电控单元中集成客户定制化的控制策略成为可能，这一模式有利于管理汽车E/E系统日益增长的复杂性，对产品进行灵活快速的更新和升级，同时提高软件的重用度以满足更高质量目标的要求。

随着AUTOSAR标准的不断成熟和在全世界范围内的普及，软件合作开发模式得到了前所未有的推动。由于AUTOSAR强调应用软件和硬件之间的解耦，针对电控单元软件提出了三层架构的概念，如图1所示，使得应用层软件的开发无需关注控制器硬件特点，并且能够方便地在不同整车厂，不同供应商以及不同车辆平台之间进行灵活交换，极大地推动了软件合作开发模式的应用。

图1 三层软件架构[1]

在中国，新能源汽车市场的高速发展带动了一系列新型汽车电控单元的研发，如用于对车辆动力电池进行管理的电池管理控制器，对车辆电机进行控制的电力电子单元，对车辆动力系统进行协调与控制的整车控制器。

对于这些新型的电控单元，传统汽车零部件巨头的优势相对较小，这使得国内涌现出大量相关零部件研发企业，同时国内各大整车厂也积极尝试进行自主开发，以期掌握核心技术，实现弯道超车。

为了使产品可靠性达到汽车级的要求，同时缩短开发周期，受AUTOSAR标准的启发，这些企业逐渐将研发重点从完整的电控单元软件和硬件转换为单纯的应用层软件，其余基础软件和硬件部分则向传统零部件供应商，如Bosch，Continental等公司进行采购，如图2所示。

图2 新兴电控单元研发企业开发模式变化

01

技术开发方法

相对于传统的软件完全由单个组织独立开发的模式，软件合作开发模式由于涉及到两个甚至多个软件开发组织，在实际的开发过程中，必须在职责分工，开发计划，接口定义，资源规划以及软件开发环境五个方面做好统筹与协调，才有可能使项目以较高的质量如期完成，如图3所示。

图3 软件合作开发模式的五个关键要素

1.1 职责分工

对于软件合作开发模式，职责分工是项目开发正式启动前首先需要明确的关键内容，它为后续一系列开发活动定义了清晰的负责人，为项目实施过程可能出现的责任问题提供了方向性指导，避免可能出现的无限质量责任，同时也有利于软件开发各方对工作量的评估，合理制定开发计划，控制开发成本。职责的划分主要从两个维度进行，一个是功能维度，一个是开发过程维度。

参考图1中AUTOSAR标准对于汽车领域电控单元软件的分层方法，功能维度的职责划分首先分为应用层软件和基础软件两部分。

对于应用层软件，不同功能的控制器之间完全不同，没有一个统一的标准，需要结合具体的控制器用途，通过各方反复沟通才能确定。对于这部分的分工，通常由客户主导，同时基础软件供应商也可以根据自己的能力，提供若干应用层组件。

对于基础软件，则可以参考AUTOSAR标准对于基础软件的划分，如图4所示，进行职责分工。对于这部分的分工，主要由基础软件的提供方主导。

通常国内的客户对于此部分不进行任何开发，完全交由基础软件供应商负责开发，而GM，VW等欧美汽车巨头大多拥有自己定制化的基础软件需求，尤其是在通信和诊断方面，这时就需要使用客户提供的基础软件组件替换自身对应的组件。

另外，对于应用层软件和基础软件的划分标准，建议各方均以AUTOSAR标准为参考进行沟通。对于AUTOSAR标准中不支持，但客户又迫切要求基础软件实现的功能，可归入到复杂驱动中进行开发。

图4 AUTOSAR标准对基础软件的划分[1]

开发流程的职责划分可以参照汽车领域内广泛应用的V模型开发过程，例如，应用层软件对于基础软件接口需求的分析由供应商负责，系统集成和验证则由客户负责组织实施。表1针对典型的软件合作开发模式，列出了开发过程维度的职责划分。

表1 软件合作开发模式中的开发过程职责定义

过程	内容描述	责任方
需求分析	定义应用层软件需求规范	客户
	定义基础软件及复杂驱动需求规范	供应商
	定义接口层软件需求规范	客户
	分析客户软件接口需求，定义接口规范	供应商
软件架构设计	应用层软件架构设计	客户
	基础软件及复杂驱动架构设计	供应商
	接口层软件设计	供应商
软件实现	开发应用层软件	客户
	开发基础软件和复杂驱动	供应商
	开发客户接口层软件	供应商
软件验证	基于模拟测试环境测试基础软件和复杂驱动	供应商
	按照客户接口规范，对客户接口层进行测试	供应商
	台架及整车环境测试	客户
软件集成	集成基础软件，复杂驱动及客户接口层	供应商
	发布基础软件工程	供应商
	基于基础软件工程集成应用层软件	客户
系统验证	按照应用层需求规范验证系统功能	客户
资源管理	制定并跟踪应用层软件资源可用资源量	供应商
	测量并反馈客户端实际资源使用情况	客户
标定	应用层软件标定	客户
	基础软件标定	供应商
软件发布	应用层功能相关标定数据发布	客户
	基础软件相关标定数据发布	供应商
	应用层软件及相关技术资料归档与维护	客户
	基础软件及相关技术资料归档与维护	供应商
	发布用于生产的软件数据包	客户

1.2 开发计划

在软件合作开发模式中，由于应用层软件多由客户负责，台架及整车的试验也转为客户负责，这使得以往项目中控制器开发计划完全由供应商主导的模式不再适用，客户转而主导控制器的开发计划，基础软件的开发计划必须配合客户端的开发计划。在这种客户主导，多方参与的模式下，项目开发计划的制定变的更加困难，项目开发节奏更快，项目如期完成的不确定性大大增加。

为了尽可能地满足客户开发节点需求，作为基础软件供应商，其开发计划的制定必须与客户定义的整体开发计划紧密配合，同时深入分析客户需求，并结合自身经验，引导客户合理制定开发计划。针对采用软件合作开发模式的项目，典型的项目开发计划如图5所示。

图5 软件合作开发模式下的项目开发计划

这一开发计划将基础软件的开发划分为四个阶段，这四个阶段的主要开发内容如表2所示。其中前三个阶段为主体开发阶段，第四个阶段为验证优化阶段。

表2 基础软件各开发阶段内容定义

开发阶段	开发内容	软件成熟度
第一阶段	标准操作系统服务； 基本数据存储服务； 硬件信号操作接口； CAN /LIN网络信号访问接口； 数据测量与标定功能； 标准软件刷新功能； 软件开发环境搭建；	20%
第二阶段	客户定制数据存储服务； 复杂硬件信号操作接口； 客户定制CAN/LIN网络信号访问接口； 网络管理功能； 故障管理操作接口； 常规诊断通信服务；	60%
第三阶段	复杂诊断通信服务； 功能安全服务； 客户定制软件刷新功能；	90%
第四阶段	客户端台架及实车道路试验支持； 软件实时性及鲁棒性优化； 软件发布与生产准备；	100%

1.3接口定义

客户软件接口开发是软件合作开发模式中最主要的工作，这项工作从项目的启动一直持续到项目结束，甚至在项目批产后仍需要对接口进行持续维护，是整个项目开发过程中人力消耗最多的工作。这主要是由于以下几个特点导致：

客户接口需求数量多。软件合作开发模式中接口的数量主要受控制器技术复杂度以及软件合作开发参与方数量的影响。技术复杂度越高，参与软件合作开发的组织越多，则彼此之间所需定义的接口数量就越多。以某电池管理控制器项目为例，基础软件开放给应用层软件的操作接口总计有约3500个。对于发动机控制器等更加复杂的ECU，接口的数量还会大大增加。

客户接口需求变型多。在《人月神话》一书中，作者布鲁克斯提到，可变性是软件系统的内在根本特征，是导致软件开发复杂性的主要原因之一 。对于软件合作开发模式，这一特性被进一步放大了。

接口变型之所以多，一方面是由于接口本身往往有多个属性，以最常见的ADC转换结果读取接口为例，它具有接口函数名称，期望读取的AD转换通道，AD转换结果存储地址，AD转换结果数据长度，AD转换结果分辨率，AD转换结果有效性信息，AD转换结果更新频率，接口可用时机等8个典型属性，如图6所示，而其中每一个属性都可能受到实际需求的影响而发生变化。

图6  ADC转换结果读取接口典型属性

另一方面则是由于不同的项目所要求的接口不同。在具体的项目应用过程中，由于不同的客户软件架构或者功能特性的不同，对于接口的需求往往也多种多样。

例如对于常规的CAN信号接口，有些客户希望能够提供对消息帧进行解析功能，从而直接获取对应的信号值，而另外有些客户则要求提供消息帧级别的接口，对于消息帧的解析由客户自己处理。对于系统异常重启，有些客户仅要求提供异常重启原因读取接口，而有些客户则要求统计特定异常重启的发生次数。这些都使得接口的定义过程非常困难。

客户接口需求分析难度高。需求分析过程是软件工程中的核心内容，既是重点也是难点。软件合作开发模式由于引入了多个软件开发组织，各个软件开发组织缺乏统一的标准，缺少“共同语言”，因此需要投入大量时间进行技术沟通才可能对于接口需求达成一致的认识，导致对于接口需求的分析更加困难。

客户接口设计影响已有软件架构。大量的客户接口开发过程中，不可避免地会对已有软件架构产生影响，需要删除，新增或者变更某些已有平台性组件，这也使得软件架构的维护工作量大幅度增加。

AUTOSAR标准的提出为参与软件合作开发的各方提供了统一的“语言”，可以有效地解决客户软件接口开发中的难题。首先，AUTOSAR标准对于接口需求的定义规定使用统一的形式（ARXML文件），大大降低了需求分析的难度和工作量。其次，AUTOSAR标准采用RTE的形式通过工具自动生成接口，基础软件供应商只需建立自身BSW接口与客户所需接口之间的映射关系，大大简化了接口的开发过程。

当然，AUTOSAR标准内容非常多，并具有很强的专业性，这对于参与软件合作开发的各方均提出了较高的能力要求，同时需要采购相应的开发工具，一定程度上增加了开发成本。

1.4 ECU资源预算

不同于消费类电子产品，受限于成本和可靠性的要求，汽车领域电控单元内部的资源往往非常有限，存储资源只有几兆字节，甚至几千字节，而CPU运行频率往往也只有几十MHz，甚至几MHz，与消费类电子动辄几GHz的频率相差甚远。在软件合作开发模式中，必需对各参与方的ECU资源使用进行管理，提前做好预算，并在开发过程中进行持续跟踪，避免出现ECU资源不足的情况。

软件合作模式中所关注的ECU资源主要有存储资源，CPU资源和堆栈资源三类，其中存储资源主要包括RAM，Flash，EEPROM等各种不同的存储介质，CPU资源主要是各个任务执行时间和周期所占整个CPU运行时间的百分比；如图7所示。在软件合作开发模式下，为了便于高效的统计和分析这些资源，在基础软件中开发相关的资源统计功能，同时开发对应的资源自动化分析工具，十分有必要。

图7  ECU资源管理对象

1.5 软件开发环境

汽车领域电控单元的软件开发从快速原型到售后服务需要大量的开发工具，如图8所示。对于软件合作开发模式，各方使用的软件编译工具必须完全一致，其它工具则可根据实际情况由工具使用方灵活选择。

图8  电控单元软件开发典型工具

软件编译工具的选择通常由基础软件供应商决定，但在软件合作开发模式中，参与软件开发的各方为了尽可能统一自己内部的开发工具，往往也会有一定的要求，尤其是大型的软件开发组织。这使得软件编译工具的确定变得困难，对于基础软件供应商而言，为了尽可能满足不同的客户需求，必需支持多种主流的软件编译工具，这使得研发成本进一步增加。

除软件编译工具之外，其它的开发工具往往由各个软件开发组织自行决定。由于可能采用各种不同的开发工具，而不同开发工具之间界面风格，操作方法，结果输出形式等可能大不相同，这对于需求的分析与管理，软件的集成，测试结果的分析等研发活动的效率带来了较为严重影响，使得项目的开发进度更加难以掌控。

因此，在项目初期就应当对软件开发环境进行约定，尽可能在软件开发的各个环节使用一致的开发工具，对于无法统一的开发工具，要及早进行评估，确定对于项目计划和开发成本的影响。

02

 软件知识产权

软件合作开发模式由于涉及多个开发组织，针对软件的知识产权自然就成为一个无法回避的问题。这一问题也应当在项目初期就进行明确定义，以免后期产生争议。软件知识产权主要涉及知识产权的归属，知识产权的使用权，知识产权的保密，以及开源软件使用可能导致的知识产权侵权四方面的内容。如图9所示。

图9 软件合作开发模式中的知识产权问题

对于通过软件合作模式开发出的软件，知识产权的归属应以软件组件为单位，按照“谁开发谁拥有”原则进行划分，即客户开发的软件组件其知识产权归客户所有，而供应商拥有它所开发软件组件的知识产权。

对于软件组件的使用权，通常拥有组件知识产权的一方授予其它方非独占、临时且具有限制的权利来进行使用，例如，供应商提供的基础软件既可以给A客户，也可以给B客户等其它客户使用，使用周期通常限定为开发阶段，使用范围通常以具体项目为准。至于使用费，则取决于参与软件开发各方之间的商务合同，既可能免费，也可能收取一定的费用。

除了对软件知识产权的归属和使用权进行约定外，为了避免软件知识产权的泄露，通常参与软件合作开发的各方还可以通过目标代码而非源代码的形式进行交互，并且约定任何一方不能以任何形式公开、反汇编、反编译其它方的目标代码。

这就进一步保护了各自的知识产权。不过，由于任何一方无法看到其它方提供的源代码，这种方式增加了软件集成和调试的难度。

另外，由于开源软件的使用受开源软件许可证中各种义务，风险和限制的约束，因而可能导致各种形式的商业侵权。在软件合作开发模式中，通常约定任何一方都不能在各自提供的软件中使用开源软件，以避免可能的侵权行为。

03

质量责任

软件合作开发不仅意味着共同承担软件开发任务，还意味着共同承担责任。对于开发阶段和售后阶段出现的问题，参与软件开发的各方应当共同进行分析，以确定问题原因。对于售后阶段出现的质量缺陷的责任认定通常可以参考以下原则进行：

• 如果因某一方所提供的软件存在缺陷导致，则由其承担责任；

• 如果因软件集成未按照规定进行，则由软件集成方承担责任；

• 如果因各方软件互相影响且彼此之间影响关系没有明确说明的，则由各方共同承担责任。

• 如果因某一方使用软件导致知识产权侵权的，则由其承担责任。

04

 总结

类似于手机软件的开发模式，软件合作开发模式将是未来汽车电控单元开发的主流模式。无论对于传统电控单元供应商还是新创电控单元控制策略开发组织，都必须对软件合作开发模式客户主导，多方参与，接口繁杂，资源受限，工具多样，责任共担的特点有深入而全面的认识，并且有一套完整的合作开发解决方案，才可能使项目开发顺利进行，达到预期目的。同时，各方应充分利用AUTOSAR这一全球标准，深入研究其在基础软件架构，应用接口和方法学方面的所制定的规范，提升自身汽车电子软件开发能力，掌握业界统一的基础软件开发“语言”，推进汽车电子软件高效、高质量地开发。

作者个人微信二维码（备注姓名+单位+工作方向）及作者所建的行业交流群。

更多内容请文末点击 阅读原文，访问汽车软件开发公益社区。

参考文献

[1]. Official website of the AUTOSAR: www.autosar.org

[2]. Juergen Cordes and Markus Zetlmeisl: AUTOSAR Gets on the Road - More and More, SAE 2012 World Congress & Exhibition.

[3]. 谭晶星等: 汽车开放系统架构 AUTOSAR 综述，2009 中国汽车工程学会年会论文集.

写在最后

关于投稿

如果您有兴趣给《九章智驾》投稿（“知识积累整理”类型文章），请扫描右方二维码，添加工作人员微信。

注：加微信时务必备注您的真实姓名、公司

以及现岗位等信息，谢谢！

“知识积累”类稿件质量要求：

A：信息密度高于绝大多数券商的绝大多数报告，不低于《九章智驾》的平均水平；

B：信息要高度稀缺，需要80%以上的信息是在其他媒体上看不到的，如果基于公开信息，需有特别牛逼的独家观点才行。多谢理解与支持。

推荐阅读：

◆九章 - 2021年度文章大合集

◆当候选人说“看好自动驾驶产业的前景”时，我会心存警惕——九章智驾创业一周年回顾（上）

◆数据收集得不够多、算法迭代得不够快，就“没人喜欢我”————九章智驾创业一周年回顾（下）

◆存算一体 – 智能驾驶AI芯片的下一个战场

◆L4自动驾驶公司降维做L2前装量产，前景如何？

◆仅有“模式跑通”是不够的——矿山无人驾驶进入深水区