前言：本文首次发表于中国汽车工程学会2018年年会并收录于其论文集。 虽然已经过去近四年了，但文中提到的方法论对于国内从事ECU开发的机构仍然具有重要的指导意义，并且并未过时。 有兴趣参与本次交流的可以扫描文末“汽车软件联合开发方法论”交流群或添加作者微信一起交流。

概括

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

其中，技术合作是软件协同开发模式的核心内容，主要包括职责分工、开发计划、接口定义、资源管理和软件开发环境五个核心要素。 本文一一讨论了各个要素的背景、特点和应对方案。 精心制作的。 同时，还明确了知识产权的归属、使用和保密规则，避免参与软件开发的各方技术泄露或一方使用开源软件，造成整体侵权。产品。 最后，参与软件开发的各方还必须分担产品责任。 为此，本文提供了产品职责划分的参考原则。

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

介绍

由于产品多样性、复杂性高、需求快速持续变化，以及与整车及零部件制造商的关系日益密切，汽车领域软件工程长期以来由电子控制单元驱动的开发模式正在逐渐转变为功能驱动。 面向架构的软件合作开发模式意味着电控单元的软件不再完全由电控单元供应商自行开发，而是与客户共同开发。

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

随着AUTOSAR标准的不断成熟和在全球范围内的普及，软件协同开发模式得到了前所未有的推广。 由于AUTOSAR强调应用软件与硬件的解耦，因此针对电控单元软件提出了三层架构概念，如图1所示，使得应用层软件的开发无需关注应用层软件的特点。控制器硬件，可以方便地实现在不同主机厂、不同供应商、不同整车平台之间的灵活互换，极大地促进了软件协同开发模式的应用。

图1 三层软件架构[1]

在中国，新能源汽车市场的快速发展带动了一系列新型汽车电子控制单元的研发，如管理汽车动力电池的电池管理控制器、控制汽车电机的电力电子单元、电源控制单元等。用于车辆电源的电子装置。 车辆控制器协调和控制系统。

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

为了使产品可靠性满足汽车级要求并缩短开发周期，在AUTOSAR标准的启发下，这些公司逐渐将研发重点从完整的电控单元软硬件转向纯应用层软件，剩下的基础软件软件和硬件部分是从传统零部件供应商处采购的，如博世、大陆集团等公司，如图2所示。

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

01

技术开发方法

与软件完全由单个组织独立开发的传统模式相比，软件合作开发模式涉及两个甚至更多的软件开发组织。 在实际的开发过程中，一定是在职责划分、开发计划、接口定义、资源规划等方面。 只有在软件开发环境的五个方面进行统筹规划和协调，才能使项目按期高质量完成，如图3所示。

图3 软件协同开发模型的五个关键要素

1.1 职责分工

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

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

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

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

通常国内客户不会对此部分进行任何开发，完全交给基础软件供应商。 然而，通用、大众等欧美汽车巨头大多都有自己定制的基础软件需求，特别是在通讯和诊断方面。 这时，您需要使用客户提供的基础软件组件来替换您相应的组件。

另外，关于应用层软件和基础软件的分类标准，建议各方以AUTOSAR标准作为沟通的参考。 对于AUTOSAR标准中不支持但客户急需用基础软件实现的功能，可以开发成复杂的驱动程序。

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

开发流程中的职责划分可以参考汽车领域广泛采用的V模型开发流程。 例如，供应商负责应用层软件的基本软件接口需求分析，而客户则负责组织实施系统集成和验证。 表1列出了典型的软件协同开发模式在开发过程维度的职责划分。

表1 软件协同开发模型中开发过程职责定义

1.2 发展规划

在软件协同开发模式中，由于应用层软件大部分是客户的责任，所以台架和整车的测试也是客户的责任。 这使得以往项目中控制器开发计划完全由供应商主导的模式不再适用。 相反，主导控制器的开发计划。 基础软件的开发计划必须与客户的开发计划相匹配。 在这种客户主导、多方参与的模式下，制定项目开发计划变得更加困难，项目开发节奏更快，项目按期完成的不确定性大大增加。

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

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

该发展规划将基础软件的发展分为四个阶段。 这四个阶段的主要开发内容如表2所示。前三个阶段是主要开发阶段，第四个阶段是验证和优化阶段。

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

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全球标准，深入研究其基础软件架构、应用接口和方法论等规范，提高自身汽车电子软件开发能力，掌握行业标准。统一基础软件开发“语言”。 ”推动汽车电子软件高效高质量发展。

作者个人微信二维码（备注姓名+单位+工作方向）以及作者建立的行业交流群。 更多内容请点击文末阅读原文并访问汽车软件开发公益社区。