论文部分内容阅读
摘 要：软件定义汽车是近年来汽车电子化的发展趋势之一，软件的迭代开发在车辆的开发中扮演越来越重要的角色，而且相对于传统的设变更频繁、更快速。为适应该趋势需要建立控制器软件类数据的管理规范，搭建软件类数据的管理平台，从而将软件类数据纳入到研发、制造、质量返修、售后所有汽车产品生命周期的管理中。本文介绍了控制器软件类数据管理系统的要点。该系统涉及到软件零部件化的理念、软件版本的定义、软件类数据分类与EBOM搭建、軟件的产线灌装与售后升级的逻辑。通过软件接口打通了研发数据（EBOM）与制造管理系统、售后诊断仪系、OTA系统之间的对接。在多款车型上的应用表明，该系统满足了对软件唯一性的识别，实现了软件类数据与整车制造数据流的结合，并得到生产线的在线软件灌装和售后的在线升级等规模化的一体化应用，为控制器的软件开发独立化、快速迭代以及业务的数字化转型创造了系统化的平台基础。
关键词：软件定义汽车;软件分类;软件版本;软件BOM;软件识别逻辑;电子数据生命周期;配置数据
中图分类号：U461 文献标识码：A 文章编号：1005-2550（2021）05-0003-08
The Systematic Development of Software Data Management in Design、Manufacturing、Aftersales for Passenger Vehicles
JIANG Ying-zhong1， ZHONG Ling1， LU Yong-shan2， SHI Bao-feng1， WAN Qing1
（ 1.Technical Center， Dongfeng Motor Corporation， Wuhan 430056， China;
2.Dongfeng Passenger Vehicle Company， Wuhan 430056， China ）
Abstract： In recent years， software-Defined-Vehicle （SDV） is one of new trends for vehicle E&E development. SW development with iteration become more and more important， faster and more frequent than the traditional design change in vehicle development. In order to implement this trend， it is necessary to define the SW data management rule， build SW data management platform， and then all SW data is to be bring into the vehicle life-cycle management which includes design， manufacturing， quality repair and aftersales. The paper introduces the main points of the SW data management systems development for passenger vehicles. The system development involves the concept of considering SW as part， SW version definition， SW data classification and its BOM construction， the logic determination for the SW writing on the OEM assembly line and updating in the aftersales dealers. The R&D data （EBOM ） is got through with the manufacturing management system， the aftersales diagnostic terminals and OTA system by SW interfaces. The systematic appliance in passenger vehicles presents the independent design meets the uniqueness of SW data recognition， the flow combination of SW data and vehicle manufacturing information. The scaled use of SW data on-line writing in the OEM assembly line and the SW data refresh in the dealers is implemented successfully. It is the base for independent SW development and quick iteration as well as the digital transformation of business.
Key words： Software-Defined-Vehicle（SDV）; SW Classification; SW Version;SW BOM; SW Recognition Logic; Electronics Data Life-Cycle; Configuration Dat 1 车 软件定 义汽
1.1 概念及趋势
传统的汽车开发流程通常分为前期预研、方案设计、工程设计、生产准备、试生产和批量生产等节点，该流程是基于物理零部件开发基础上的理念。在电子控制技术引入汽车之后，控制器软件被作为控制器的一部分进行管控，以硬件的附属品方式存在。软件不是作为单独的零部件被纳入整车开发的管理。这种汽车控制器和控制器软件的开发方式是软硬一体化的开发方式。
从智能手机等消费类电子软件的快速迭代升级，到特斯拉等新兴造车企业的有偿销售或付费订阅一些特定功能，行业提出了软件定义汽车或软件赋能汽车的概念。随着智能网联汽车兴起，出现了软件的开发和迭代越来越快，软件开发和迭代周期远远小于物理零件的设计验证周期的趋势。将车辆软件开发从控制器物理零件独立出来，建立独立的软件开发组织，进行独立的开发管理，是适应该趋势的方案。在新车型量产时搭载具备可扩充一定功能的接口和算力的控制器硬件及一部分功能，在后期软件开发成熟时再进行新功能释放，让车辆用户以选装方式付费购买。这是汽车控制器器软件开发的软硬件分离方式，其特点是软件被视作汽车的独立零部件。这种开发方式正在快速发展中。
1.2 对汽车控制器软件管理带来的挑战
软件类数据在整车企业的产线上灌装越来越多，在售后进行在线软件灌装或升级的需求也越来越多。软件类数据版本的识别、选择和匹配逻辑与传统零部件管理要求不同，这对整车企业的软件类数据管理提出了挑战。
部分汽车企业采用达索PLM产品数据管理系统进行控制器机械零部件管理，但未对控制器软件类数据进行系统化管理。随着软件类数据管理日益复杂且频繁，线下管理方式越来越无法满足业务需求。
在供应商提供控制器时，部分、甚至整体软件没有灌装在其存储器中。在整车厂总装车间，需要补充部分软件或整体软件的灌装、车型配置数据的写入。在售后，同一硬件编号的控制器需进行软件/标定数据的在线刷写，和车型配置数据的写入，以完成控制器整体的功能设置。在发布了新的控制器软件版本后，需经过售后系统对车辆控制器进行在线软件升级。在此场景下，亟待企业对软件进行单独管理，以解决因软件版本带来的控制器硬件多品种、软件升级时需直接更换控制器硬件带来的高成本等问题。
2 控制器的设计BOM（EBOM）
2.1 设计理念：软件类数据零部件化
引入BOM的概念，将软件类数据零部件化，通过给软件类数据赋予单独零部件号，将软件类数据纳入BOM管理。软件类数据的零件号编码规则与一般零部件相同。
软件类数据零部件是非数模类零部件。其数据以文档形式，作为该零部件的附件与其关联，并随BOM结构一起传输到下游制造和售后系统。
将软件类数据视作单独的零部件管理后，软件的开发就可以独立于硬件。通常电子硬件开发、验证周期长，软件的独立发布和管理为软件的单独开发创造了条件。
相同电子硬件和不同软件组成不同的控制器，实现有差异的功能。软件的分离与独立管理，既保证了硬件的通用性，又通过软件的差异化来对应同平台但有差异功能的车型变化需求。
2.2 软件生命周期定义
对软件的生命周期管理，不同整车企业有不同的管理规范。有的企业规定软件升级即换号。该规则在PLM上容易实现，但是不足之处是产生过多零件号，管理成本提高，同时给工程师对软件的可追溯性带来难度。
在软件类数据零部件化后，对软件生命周期的定义应基于以下两个原则：
软件差异可以数学模型表达，PLM数据管理系统可以识别唯一性;
适当的管理成本，即适应OEM及其供应商对软件的变更频率，适应软件定义汽车的发展趋势。
鉴于在控制器开发阶段软件频繁变更，而且考虑OEM专业工程师对软件继承性的识别度，在车辆小批量生产（PT）及之前开发阶段，软件被视作一个生命周期進行管理。在小批量生产以后的阶段，如果软件升级和前一版具有可互换性，视作一个生命周期;如果没有可互换性，或者属于重大质量改进问题需要区分，软件升级时采用新软件零件号，视作一个新的生命周期。
2.3 软件类数据分类
除了控制器的零件号、硬件零件号外，存在多种不同类型的软件类数据，而且这些软件类数据在不同的场景下需要进行不同的组合实施升级。为了使系统能够识别，本文对需要赋予零件号的软件类数据进行了分类。
2.4 OEM版本号定义
基于2.2的软件生命周期管理原则，定义软件类数据OEM版本，作为软件类数据的一个特征量使数据管理系统可以识别唯一性。软件类数据零件号+软件类数据版本号，保证了软件类数据的唯一性。每一次升版，版本号升级，实质上相当于TeamCenter所管理软件每次变更时的变号。但是，这里软件类数据零件号不变，OEM版本号升级，又便于开发工程师和制造、售后工程师对软件类数据继承性的识别。
软件类数据OEM版本用V①.②.③④表示，范围为数字0-9。软件版本具有唯一性，每一个软件代码（bit）变化都导致该版本的变化。在开发过程中，开发商（供应商）可以有自己的中间过程版本，但开发商发布的版本需要与OEM版本一一对应。
V ① . ② . ③ ④
表示版本修正号
表示功能版本号
表示开发阶段号
①②③④要写入到ECU存储器及印刷到控制器标签中。ECU存储器中用2个字节xxxx存储，第一个x表示①;第二个x表示②;第三、四个xx表示③④。 2.5 控制器设计EBOM设计
控制器的EBOM设计要达到多项目的：
设计工程师通过系统化的手段可追溯控制器零件号、软硬件零件号/版本号/实体数据及其匹配关系;
使后续所构建系统能识别整车产线需要灌装的软件类数据及其信息，并可選择提供对应实体数据（对不需要的数据不予下发）;
能为产线下线车辆提供对应的控制器及其硬件、软件类数据信息，并提供终检数据信息基准;
为车辆生产完成后构建车辆电子生命周期数据库提供信息来源;
使后续所构建系统能识别售后软件类数据升级、备件更换等场景所需的软件类及其信息，并可选择提供对应实体数据;
为OTA后台提供对应的实体数据及其信息。
2.5.1 EBOM结构构建
EBOM的结构需要使系统能够识别整车产线以及售后备件更换时是否需要灌装软件。构建平行式BOM结构，对应在产线和售后备件更换时需要灌装的软件类数据模式;构建下挂式BOM结构，对应在产线、售后备件更换时不需要灌装软件类数据模式。采购的控制器的EBOM结构构建方式应对应于软件类数据是否已包含在采购的控制器中。当供应商提供的控制器不包含软件类数据，需要在OEM产线灌装软件类数据。在EBOM系统中，该控制器的软件类数据以平行结构予以构建。反之亦然。
将系统进行平行或下挂构建便于总装产线设备自动识别哪些车辆控制器的软件类数据需要灌装，哪些不需要灌装。当系统识别平行结构时，自动从MAS系统下载数据。
2.5.1.1 平行结构
控制器中所包含软件类数据，如果需要在乘用车整车厂产线灌装（采购时不包含），则采用平行式数据结构构建。以下是平行结构典型案例。
（圆圈所示SW、标定数据CAL、配置值BEC）
平行构建的零部件在升级发布时可分开进行。
2.5.1.2 下挂结构
控制器中所包含软件类数据，如果在整车厂产线不用灌装（采购时已包含），则采用下图下挂式数据结构。
采用该结构时，由于HW、SW、标定数据等属于ECU总成的一部分，所以当下挂的每一个部分升级时，ECU总成需要同步升级。
实际的软件类数据EBOM结构，还考虑到软件匹配等应用场景，比2.5.1.1和2.5.1.2更复杂、更完整。
（圆圈所示硬件HW、软件SW、自举程序Bootloader）
2.5.2 控制器EBOM属性设计
控制器的EBOM包含壳体、支架固定螺栓等传统实物BOM，也包含了本文新增的软件类零件BOM。后者是系统需要识别、并传输到产线和售后设备的数据。为此，还需对控制器EBOM中软硬件数据进行属性定义。
2.5.2.1 控制器总成的总线属性
该属性定义是为了区分CAN控制器（含CAN通讯模块的以太网控制器）、LIN控制器、Keyword 2000等不同类别的控制器。LIN、Keyword 2000协议的控制器，在产线制造、售后不进行直接的软件类数据灌装或刷写，其配置数据是通过关联的CAN控制器刷写的。定义CAN控制器总成的属性，使其软硬件类数据就被信息系统选择，并向下游传输。
2.5.2.2 软件类数据属性
控制器总成中对软件类数据通过一个标识码的数字，如85进行属性定义。系统识别85的类别后，将软件类数据零件号、OEM版本号和控制器其它属性一起进行关联传输。
2.5.2.3 硬件属性
和软件类数据属性一样，通过一个类别的数字对硬件属性进行定义，便于其零件号、硬件OEM版本号与其它控制器属性一起进行传输。
2.5.2.4 OEM版本号
该属性中为2.4节定义的OEM版本号（分软件类数据版本号和硬件版本号）。该版本号是与软硬件零件号一起传输到下游，作为软件灌装或升级的逻辑识别、产线控制器软硬件一致性终检的关键识别参数。
2.5.2.5 中英文统一简称
统一CAN控制器定义标准的中英文简称，作为零件号之外的控制器识别的辅助属性。控制器内存、软件发布系统、诊断协议、售后软件升级管理系统及诊断仪保持英文简称的一致性为产线终检、售后特别是空白件换装的控制器识别提供系统识别的特征量。
2.5.3 配置值BEC（Bill of Configuration）
在产线和售后对控制器可写入不同的配置值来适配不同的车辆配置。通过配置表达构建配置EBOM。信息系统从订单系统和生产管理系统获得车辆配置后结合配置表达，找到该VIN车辆对应的配置值，产线EOL设备将该各列配置值写入到对应车辆的控制器中，完成车辆配置。同时，售后车辆在更换控制器后，通过诊断仪对车辆VIN以及控制器名称的读取和上传，信息系统从车辆制造后保存的该VIN车辆和该控制器对应的配置值，下发给诊断仪进行配置值的写入，完成换件后自动配置的任务。
下表3是配置表达值BEC的构建案例示意，其中KA0A01T等是车辆的功能标志。
售后进行备件更换时，系统通过车辆VIN和记录的该车辆生产时的BEC值，返回给诊断仪进行对应车辆控制器的配置值写入，激活控制器的功能。
3 软件类数据管理系统的构建
按照信息系统的开发模式，先定义业务规则和数据流程，然后进行信息系统方案设计、开发实现、测试、上线。
软件类数据的升级规则基于严格数学唯一识别性的普遍规则，也针对多种特殊场景制定灵活的特定规则，保证系统可以优先应对新出现的紧急情况。
3.1 数据流的定义 构建好EBOM后，定义控制器的数据流如何从EBOM结合产线生产系统MES到达生产初始化设备EOL，和每一台车辆VIN结合进行软件类数据的灌装，如软件、标定数据的灌装以及控制器配置值的写入。车辆完成生产后，建立以VIN为基础的车辆电子信息数据库。这是该车辆电子生命周期（VLM-Vehicle Life-cycle Management）管理的起点。VLM数据库是后续质量返修、OTA（Over-The-Air）升级、售后诊断仪软件升级提供车辆及控制器数据信息的基础。反过来，后续的质量返修、OTA升级、诊断仪售后升级控制器软件后也反馈最新信息来更新VLM数据库。
以下是概要数据流框架。针对每一个子环节，需进行详细的数据二级流程的定义。
3.2 信息管理系统的构建
建立业务流程和数据流后，进行电子电器制造及售后管理系统MAS的构建。它连接PLM产品数据管理系统和MES生产执行系统，并包含制造设备子系统和售后设备子系统。它的数据来源是PLM系统和MES系统。
4 数据管理系统的开发及运用
4.1 EBOM的构建及数据管理系统的开发
在产品数据管理系统中，对所有CAN控制器构建完整的软件EBOM，包括定义软件零件号、建立版本的迭代以及配置表达一览表。当软件类数据随控制器EBOM发布后，制造数据管理单位和采购部门、制造管理部门等协商决定EBOM的适用时间点。
通过建立和EBOM、MES系统的对接接口，开发制造&售后诊断程序、车辆配置信息管理模块、制造设备子系统、车辆电控数据全生命周期管理模块以及售后设备子系统，并进行系统测试及联调，完成了车辆软硬件数据管理MAS系统的开发。
4.2 应用案例
东风汽车公司技术中心按照本论文阐述的技术在2019年完成了EBOM软件类数据管理系统的建设，并联合东风乘用车公司将其应用到2019年以后的所有新车型的开发、量产和售后服务中。
4.2.1 产线应用
4.2.1.1 产线的软件自动灌装
在PLM设计系统构建的控制器EBOM数据，经过MSK、MAS系统与产线订单系统MES对接，抓取对应VIN车辆的软件实体、标定数据、配置值以及对应的电子信息（零件号、零件类别、版本號），通过EOL制造设备子系统在线、自动灌装到该VIN对应车辆的控制器中。
该应用通过系统化自动匹配大幅降低产线手动灌装软件的时间，同时保证软件类数据版本的准确性。
4.2.1.2 产线组装时的电子缺陷发现
在乘用车组装线上，该系统比较EOL设备检测到的每一台车辆所有控制器的零件号、版本号等信息，并和PLM发布的EBOM进行比较。当发现不一致时实施报警提醒，达到装车防错的目的，有效提高装车质量。
4.2.1.3 车辆生命周期电子数据库（VLM）
当车辆正常下线后，产线终检EOL（End-Of-Line）设备从车辆中读取各控制器的电子信息，上传到系统的车辆生命周期管理（VLM）模块，形成以车辆VIN为基础的车辆生命周期电子数据管理的初始库，包含控制器零件号、控制器名称、控制器硬件版本号、数据类型、控制器软件/标定数据零件号及其版本号、控制器配置值等信息。质量返修、售后升级、OTA升级后反馈给VLM进行该数据库的更新，保持与实际车辆电子数据状态的一致性。
4.2.2 售后应用
4.2.2.1 MAS系统与售后系统对接
售后软件类数据的管理更复杂。它既要对应现在软件迭代生产后的车辆，又要对应过去生产的市场保有车辆，即要规划不同软件类数据零件号、版本的迭代升级路径。
开发售后设备子系统（售后软件类数据管理子系统），即图6中的售后设备子系统。售后设备子系统和MAS管理子系统建立软件接口。一方面，售后设备子系统可以从管理子系统获得基于车辆识别码VIN的所有控制器软件、标定数据、配置值等当前信息，并支持或提供该信息的出厂原数据。另一方面，可以从管理子系统获取该控制器软件最新发布版本用于售后升级，在升级后将信息反馈至MAS管理子系统，并更新全生命周期管理模块的车辆电子数据信息，使VLM保持最新状态。如图9所示。
4.2.2.2 售后软件的在线升级
通过以上和MAS系统的对接，实现售后软件的在线识别和升级。
在售后，软件类数据升级按照车辆VIN/控制器名称 + 软件版本号or 控制器零件号/软件零件号+ 软件版本号的组合规则进行升级。组合规则保证了软件与车辆、软件与硬件的正确匹配。
当车辆控制器无更换，可读取控制器零件号/软件零件号时，采用控制器零件号/软件零件号 + 软件版本号的升级规则。版本号升级遵循递进规则。当售后进行备件更换，不能读取车辆新控制器的零件号/软件零件号时，采取VIN /控制器名称 + 软件版本号的升级规则。
当软件后台版本号小于车辆控制器存储的软件类数据版本号时，不予升级。当后台版本号与控制器版本号相同时，提醒用户是否覆盖刷写。当后台版本号大于控制器版本号时，点击即可实现控制器软件升级。
4.2.2.3 售后自动配置
在售后更换部分控制器后，需要重新进行配置。通过读取车辆VIN，诊断仪终端向售后后台反馈VIN和控制器名称，再通过MAS系统的VLM数据库，可以找到该车辆、该控制器生产时的配置值。把该配置值通过售后系统传给诊断仪终端，完成在线配置。
4.2.2.4 数据安全管理
售后系统和经销店对接，对外需要公开，所以软件类数据安全成为重要管理事项。采用如下手段提升售后数据安全管理： 售后设备子系统部署设置防火墙和Internet 连接。
诊断工具登录及软件下载均有授权机制。
售后设备子系统对软件下发进行加密，终端只有通过植入的解密算法才能解密软件，中途截获的软件不能使用。
4.2.3 对OTA车辆数据的提供
随着软件迭代速度的加快，特别是特斯拉车型的自动驾驶软件的OTA导入，车辆OTA从信息娱乐IVI和全液晶仪表的SOTA发展到嵌入式软件的FOTA。通过和OTA的软件接口对接，MAS系统的VLM模块为OTA提供车辆信息和控制器的数据来源，在纯电动车型上实现了SOTA和整车控制器VCU、组合仪表、空调控制器AC等嵌入式软件的FOTA升级，图10。
5 结论
软件定义汽车、软件赋能汽车是汽车产业在机械操控、电气化后又一重要的技术发展趋势。本文通过控制器的软件类数据零部件化的定义、软件类数据的分类、控制器EBOM设计、数据流的定义以及数据管理系统的框架设计、开发以及车型的应用结果，展示该系统化设计的合理性和正确性，实现了软件类数据从设计、制造到售后的自动识别和系统传输，实现了产线在线软件灌装、在线配置、车辆终检，以及售后的在线软件升级、自動配置等诸多应用。需要指出的是，该系统化设计和系统建立，为OTA提供数据来源，也是实现OTA的必要基础。
随着乘用车电子类数据的不断丰富和发展，以及智能售后诊断与迭代的需求，该系统化的设计开发将不断迭代完善，促进企业数字化转型。
参考文献：
[1]蒋映中，吴泽民，孙学志，苟斌，王永峰，张帆，车辆设计、生产、售后一体化的软件分层开发体系，2014中国汽车工程学会年会论文集，2014CG-VE072，624-627页.
[2]孟天闯，李佳幸，黄晋，杨殿阁，钟志华，软件定义汽车技术体系研究，《汽车工程》2021年第4期，459-468页.
[3]蒋映中，吴泽民，冯超，孙学志，张帆，乘用车整车电气系统开发的新趋势及实现方式，2013中国汽车工程学会年会，文章编号：2013 CN-ET085 .
[4]安晶，王斌，王伟，基于Teamcenter软件的BOM管理系统开发研究，现代制造工程，2015年第3期，16-20页.
[5]NUGROHO S ，HADI S ，HAKIM L . Comparative analysis of software development methods between parallel，V-shaped and iterative[J]. International Journal of Computer Applications，2017，169（11）， pp.7-11.
[6]蒋映中，张翼鹏，苟斌，张凡武，吴泽民，杨诚，东风风神乘用车整车电气架构的开发，中国汽车工程学会汽车电子技术分会第十届（2012）年会暨学术研讨会，15-20页.
关键词：软件定义汽车;软件分类;软件版本;软件BOM;软件识别逻辑;电子数据生命周期;配置数据
中图分类号：U461 文献标识码：A 文章编号：1005-2550（2021）05-0003-08
The Systematic Development of Software Data Management in Design、Manufacturing、Aftersales for Passenger Vehicles
JIANG Ying-zhong1， ZHONG Ling1， LU Yong-shan2， SHI Bao-feng1， WAN Qing1
（ 1.Technical Center， Dongfeng Motor Corporation， Wuhan 430056， China;
2.Dongfeng Passenger Vehicle Company， Wuhan 430056， China ）
Abstract： In recent years， software-Defined-Vehicle （SDV） is one of new trends for vehicle E&E development. SW development with iteration become more and more important， faster and more frequent than the traditional design change in vehicle development. In order to implement this trend， it is necessary to define the SW data management rule， build SW data management platform， and then all SW data is to be bring into the vehicle life-cycle management which includes design， manufacturing， quality repair and aftersales. The paper introduces the main points of the SW data management systems development for passenger vehicles. The system development involves the concept of considering SW as part， SW version definition， SW data classification and its BOM construction， the logic determination for the SW writing on the OEM assembly line and updating in the aftersales dealers. The R&D data （EBOM ） is got through with the manufacturing management system， the aftersales diagnostic terminals and OTA system by SW interfaces. The systematic appliance in passenger vehicles presents the independent design meets the uniqueness of SW data recognition， the flow combination of SW data and vehicle manufacturing information. The scaled use of SW data on-line writing in the OEM assembly line and the SW data refresh in the dealers is implemented successfully. It is the base for independent SW development and quick iteration as well as the digital transformation of business.
Key words： Software-Defined-Vehicle（SDV）; SW Classification; SW Version;SW BOM; SW Recognition Logic; Electronics Data Life-Cycle; Configuration Dat 1 车 软件定 义汽
1.1 概念及趋势
传统的汽车开发流程通常分为前期预研、方案设计、工程设计、生产准备、试生产和批量生产等节点，该流程是基于物理零部件开发基础上的理念。在电子控制技术引入汽车之后，控制器软件被作为控制器的一部分进行管控，以硬件的附属品方式存在。软件不是作为单独的零部件被纳入整车开发的管理。这种汽车控制器和控制器软件的开发方式是软硬一体化的开发方式。
从智能手机等消费类电子软件的快速迭代升级，到特斯拉等新兴造车企业的有偿销售或付费订阅一些特定功能，行业提出了软件定义汽车或软件赋能汽车的概念。随着智能网联汽车兴起，出现了软件的开发和迭代越来越快，软件开发和迭代周期远远小于物理零件的设计验证周期的趋势。将车辆软件开发从控制器物理零件独立出来，建立独立的软件开发组织，进行独立的开发管理，是适应该趋势的方案。在新车型量产时搭载具备可扩充一定功能的接口和算力的控制器硬件及一部分功能，在后期软件开发成熟时再进行新功能释放，让车辆用户以选装方式付费购买。这是汽车控制器器软件开发的软硬件分离方式，其特点是软件被视作汽车的独立零部件。这种开发方式正在快速发展中。
1.2 对汽车控制器软件管理带来的挑战
软件类数据在整车企业的产线上灌装越来越多，在售后进行在线软件灌装或升级的需求也越来越多。软件类数据版本的识别、选择和匹配逻辑与传统零部件管理要求不同，这对整车企业的软件类数据管理提出了挑战。
部分汽车企业采用达索PLM产品数据管理系统进行控制器机械零部件管理，但未对控制器软件类数据进行系统化管理。随着软件类数据管理日益复杂且频繁，线下管理方式越来越无法满足业务需求。
在供应商提供控制器时，部分、甚至整体软件没有灌装在其存储器中。在整车厂总装车间，需要补充部分软件或整体软件的灌装、车型配置数据的写入。在售后，同一硬件编号的控制器需进行软件/标定数据的在线刷写，和车型配置数据的写入，以完成控制器整体的功能设置。在发布了新的控制器软件版本后，需经过售后系统对车辆控制器进行在线软件升级。在此场景下，亟待企业对软件进行单独管理，以解决因软件版本带来的控制器硬件多品种、软件升级时需直接更换控制器硬件带来的高成本等问题。
2 控制器的设计BOM（EBOM）
2.1 设计理念：软件类数据零部件化
引入BOM的概念，将软件类数据零部件化，通过给软件类数据赋予单独零部件号，将软件类数据纳入BOM管理。软件类数据的零件号编码规则与一般零部件相同。
软件类数据零部件是非数模类零部件。其数据以文档形式，作为该零部件的附件与其关联，并随BOM结构一起传输到下游制造和售后系统。
将软件类数据视作单独的零部件管理后，软件的开发就可以独立于硬件。通常电子硬件开发、验证周期长，软件的独立发布和管理为软件的单独开发创造了条件。
相同电子硬件和不同软件组成不同的控制器，实现有差异的功能。软件的分离与独立管理，既保证了硬件的通用性，又通过软件的差异化来对应同平台但有差异功能的车型变化需求。
2.2 软件生命周期定义
对软件的生命周期管理，不同整车企业有不同的管理规范。有的企业规定软件升级即换号。该规则在PLM上容易实现，但是不足之处是产生过多零件号，管理成本提高，同时给工程师对软件的可追溯性带来难度。
在软件类数据零部件化后，对软件生命周期的定义应基于以下两个原则：
软件差异可以数学模型表达，PLM数据管理系统可以识别唯一性;
适当的管理成本，即适应OEM及其供应商对软件的变更频率，适应软件定义汽车的发展趋势。
鉴于在控制器开发阶段软件频繁变更，而且考虑OEM专业工程师对软件继承性的识别度，在车辆小批量生产（PT）及之前开发阶段，软件被视作一个生命周期進行管理。在小批量生产以后的阶段，如果软件升级和前一版具有可互换性，视作一个生命周期;如果没有可互换性，或者属于重大质量改进问题需要区分，软件升级时采用新软件零件号，视作一个新的生命周期。
2.3 软件类数据分类
除了控制器的零件号、硬件零件号外，存在多种不同类型的软件类数据，而且这些软件类数据在不同的场景下需要进行不同的组合实施升级。为了使系统能够识别，本文对需要赋予零件号的软件类数据进行了分类。
2.4 OEM版本号定义
基于2.2的软件生命周期管理原则，定义软件类数据OEM版本，作为软件类数据的一个特征量使数据管理系统可以识别唯一性。软件类数据零件号+软件类数据版本号，保证了软件类数据的唯一性。每一次升版，版本号升级，实质上相当于TeamCenter所管理软件每次变更时的变号。但是，这里软件类数据零件号不变，OEM版本号升级，又便于开发工程师和制造、售后工程师对软件类数据继承性的识别。
软件类数据OEM版本用V①.②.③④表示，范围为数字0-9。软件版本具有唯一性，每一个软件代码（bit）变化都导致该版本的变化。在开发过程中，开发商（供应商）可以有自己的中间过程版本，但开发商发布的版本需要与OEM版本一一对应。
V ① . ② . ③ ④
表示版本修正号
表示功能版本号
表示开发阶段号
①②③④要写入到ECU存储器及印刷到控制器标签中。ECU存储器中用2个字节xxxx存储，第一个x表示①;第二个x表示②;第三、四个xx表示③④。 2.5 控制器设计EBOM设计
控制器的EBOM设计要达到多项目的：
设计工程师通过系统化的手段可追溯控制器零件号、软硬件零件号/版本号/实体数据及其匹配关系;
使后续所构建系统能识别整车产线需要灌装的软件类数据及其信息，并可選择提供对应实体数据（对不需要的数据不予下发）;
能为产线下线车辆提供对应的控制器及其硬件、软件类数据信息，并提供终检数据信息基准;
为车辆生产完成后构建车辆电子生命周期数据库提供信息来源;
使后续所构建系统能识别售后软件类数据升级、备件更换等场景所需的软件类及其信息，并可选择提供对应实体数据;
为OTA后台提供对应的实体数据及其信息。
2.5.1 EBOM结构构建
EBOM的结构需要使系统能够识别整车产线以及售后备件更换时是否需要灌装软件。构建平行式BOM结构，对应在产线和售后备件更换时需要灌装的软件类数据模式;构建下挂式BOM结构，对应在产线、售后备件更换时不需要灌装软件类数据模式。采购的控制器的EBOM结构构建方式应对应于软件类数据是否已包含在采购的控制器中。当供应商提供的控制器不包含软件类数据，需要在OEM产线灌装软件类数据。在EBOM系统中，该控制器的软件类数据以平行结构予以构建。反之亦然。
将系统进行平行或下挂构建便于总装产线设备自动识别哪些车辆控制器的软件类数据需要灌装，哪些不需要灌装。当系统识别平行结构时，自动从MAS系统下载数据。
2.5.1.1 平行结构
控制器中所包含软件类数据，如果需要在乘用车整车厂产线灌装（采购时不包含），则采用平行式数据结构构建。以下是平行结构典型案例。
（圆圈所示SW、标定数据CAL、配置值BEC）
平行构建的零部件在升级发布时可分开进行。
2.5.1.2 下挂结构
控制器中所包含软件类数据，如果在整车厂产线不用灌装（采购时已包含），则采用下图下挂式数据结构。
采用该结构时，由于HW、SW、标定数据等属于ECU总成的一部分，所以当下挂的每一个部分升级时，ECU总成需要同步升级。
实际的软件类数据EBOM结构，还考虑到软件匹配等应用场景，比2.5.1.1和2.5.1.2更复杂、更完整。
（圆圈所示硬件HW、软件SW、自举程序Bootloader）
2.5.2 控制器EBOM属性设计
控制器的EBOM包含壳体、支架固定螺栓等传统实物BOM，也包含了本文新增的软件类零件BOM。后者是系统需要识别、并传输到产线和售后设备的数据。为此，还需对控制器EBOM中软硬件数据进行属性定义。
2.5.2.1 控制器总成的总线属性
该属性定义是为了区分CAN控制器（含CAN通讯模块的以太网控制器）、LIN控制器、Keyword 2000等不同类别的控制器。LIN、Keyword 2000协议的控制器，在产线制造、售后不进行直接的软件类数据灌装或刷写，其配置数据是通过关联的CAN控制器刷写的。定义CAN控制器总成的属性，使其软硬件类数据就被信息系统选择，并向下游传输。
2.5.2.2 软件类数据属性
控制器总成中对软件类数据通过一个标识码的数字，如85进行属性定义。系统识别85的类别后，将软件类数据零件号、OEM版本号和控制器其它属性一起进行关联传输。
2.5.2.3 硬件属性
和软件类数据属性一样，通过一个类别的数字对硬件属性进行定义，便于其零件号、硬件OEM版本号与其它控制器属性一起进行传输。
2.5.2.4 OEM版本号
该属性中为2.4节定义的OEM版本号（分软件类数据版本号和硬件版本号）。该版本号是与软硬件零件号一起传输到下游，作为软件灌装或升级的逻辑识别、产线控制器软硬件一致性终检的关键识别参数。
2.5.2.5 中英文统一简称
统一CAN控制器定义标准的中英文简称，作为零件号之外的控制器识别的辅助属性。控制器内存、软件发布系统、诊断协议、售后软件升级管理系统及诊断仪保持英文简称的一致性为产线终检、售后特别是空白件换装的控制器识别提供系统识别的特征量。
2.5.3 配置值BEC（Bill of Configuration）
在产线和售后对控制器可写入不同的配置值来适配不同的车辆配置。通过配置表达构建配置EBOM。信息系统从订单系统和生产管理系统获得车辆配置后结合配置表达，找到该VIN车辆对应的配置值，产线EOL设备将该各列配置值写入到对应车辆的控制器中，完成车辆配置。同时，售后车辆在更换控制器后，通过诊断仪对车辆VIN以及控制器名称的读取和上传，信息系统从车辆制造后保存的该VIN车辆和该控制器对应的配置值，下发给诊断仪进行配置值的写入，完成换件后自动配置的任务。
下表3是配置表达值BEC的构建案例示意，其中KA0A01T等是车辆的功能标志。
售后进行备件更换时，系统通过车辆VIN和记录的该车辆生产时的BEC值，返回给诊断仪进行对应车辆控制器的配置值写入，激活控制器的功能。
3 软件类数据管理系统的构建
按照信息系统的开发模式，先定义业务规则和数据流程，然后进行信息系统方案设计、开发实现、测试、上线。
软件类数据的升级规则基于严格数学唯一识别性的普遍规则，也针对多种特殊场景制定灵活的特定规则，保证系统可以优先应对新出现的紧急情况。
3.1 数据流的定义 构建好EBOM后，定义控制器的数据流如何从EBOM结合产线生产系统MES到达生产初始化设备EOL，和每一台车辆VIN结合进行软件类数据的灌装，如软件、标定数据的灌装以及控制器配置值的写入。车辆完成生产后，建立以VIN为基础的车辆电子信息数据库。这是该车辆电子生命周期（VLM-Vehicle Life-cycle Management）管理的起点。VLM数据库是后续质量返修、OTA（Over-The-Air）升级、售后诊断仪软件升级提供车辆及控制器数据信息的基础。反过来，后续的质量返修、OTA升级、诊断仪售后升级控制器软件后也反馈最新信息来更新VLM数据库。
以下是概要数据流框架。针对每一个子环节，需进行详细的数据二级流程的定义。
3.2 信息管理系统的构建
建立业务流程和数据流后，进行电子电器制造及售后管理系统MAS的构建。它连接PLM产品数据管理系统和MES生产执行系统，并包含制造设备子系统和售后设备子系统。它的数据来源是PLM系统和MES系统。
4 数据管理系统的开发及运用
4.1 EBOM的构建及数据管理系统的开发
在产品数据管理系统中，对所有CAN控制器构建完整的软件EBOM，包括定义软件零件号、建立版本的迭代以及配置表达一览表。当软件类数据随控制器EBOM发布后，制造数据管理单位和采购部门、制造管理部门等协商决定EBOM的适用时间点。
通过建立和EBOM、MES系统的对接接口，开发制造&售后诊断程序、车辆配置信息管理模块、制造设备子系统、车辆电控数据全生命周期管理模块以及售后设备子系统，并进行系统测试及联调，完成了车辆软硬件数据管理MAS系统的开发。
4.2 应用案例
东风汽车公司技术中心按照本论文阐述的技术在2019年完成了EBOM软件类数据管理系统的建设，并联合东风乘用车公司将其应用到2019年以后的所有新车型的开发、量产和售后服务中。
4.2.1 产线应用
4.2.1.1 产线的软件自动灌装
在PLM设计系统构建的控制器EBOM数据，经过MSK、MAS系统与产线订单系统MES对接，抓取对应VIN车辆的软件实体、标定数据、配置值以及对应的电子信息（零件号、零件类别、版本號），通过EOL制造设备子系统在线、自动灌装到该VIN对应车辆的控制器中。
该应用通过系统化自动匹配大幅降低产线手动灌装软件的时间，同时保证软件类数据版本的准确性。
4.2.1.2 产线组装时的电子缺陷发现
在乘用车组装线上，该系统比较EOL设备检测到的每一台车辆所有控制器的零件号、版本号等信息，并和PLM发布的EBOM进行比较。当发现不一致时实施报警提醒，达到装车防错的目的，有效提高装车质量。
4.2.1.3 车辆生命周期电子数据库（VLM）
当车辆正常下线后，产线终检EOL（End-Of-Line）设备从车辆中读取各控制器的电子信息，上传到系统的车辆生命周期管理（VLM）模块，形成以车辆VIN为基础的车辆生命周期电子数据管理的初始库，包含控制器零件号、控制器名称、控制器硬件版本号、数据类型、控制器软件/标定数据零件号及其版本号、控制器配置值等信息。质量返修、售后升级、OTA升级后反馈给VLM进行该数据库的更新，保持与实际车辆电子数据状态的一致性。
4.2.2 售后应用
4.2.2.1 MAS系统与售后系统对接
售后软件类数据的管理更复杂。它既要对应现在软件迭代生产后的车辆，又要对应过去生产的市场保有车辆，即要规划不同软件类数据零件号、版本的迭代升级路径。
开发售后设备子系统（售后软件类数据管理子系统），即图6中的售后设备子系统。售后设备子系统和MAS管理子系统建立软件接口。一方面，售后设备子系统可以从管理子系统获得基于车辆识别码VIN的所有控制器软件、标定数据、配置值等当前信息，并支持或提供该信息的出厂原数据。另一方面，可以从管理子系统获取该控制器软件最新发布版本用于售后升级，在升级后将信息反馈至MAS管理子系统，并更新全生命周期管理模块的车辆电子数据信息，使VLM保持最新状态。如图9所示。
4.2.2.2 售后软件的在线升级
通过以上和MAS系统的对接，实现售后软件的在线识别和升级。
在售后，软件类数据升级按照车辆VIN/控制器名称 + 软件版本号or 控制器零件号/软件零件号+ 软件版本号的组合规则进行升级。组合规则保证了软件与车辆、软件与硬件的正确匹配。
当车辆控制器无更换，可读取控制器零件号/软件零件号时，采用控制器零件号/软件零件号 + 软件版本号的升级规则。版本号升级遵循递进规则。当售后进行备件更换，不能读取车辆新控制器的零件号/软件零件号时，采取VIN /控制器名称 + 软件版本号的升级规则。
当软件后台版本号小于车辆控制器存储的软件类数据版本号时，不予升级。当后台版本号与控制器版本号相同时，提醒用户是否覆盖刷写。当后台版本号大于控制器版本号时，点击即可实现控制器软件升级。
4.2.2.3 售后自动配置
在售后更换部分控制器后，需要重新进行配置。通过读取车辆VIN，诊断仪终端向售后后台反馈VIN和控制器名称，再通过MAS系统的VLM数据库，可以找到该车辆、该控制器生产时的配置值。把该配置值通过售后系统传给诊断仪终端，完成在线配置。
4.2.2.4 数据安全管理
售后系统和经销店对接，对外需要公开，所以软件类数据安全成为重要管理事项。采用如下手段提升售后数据安全管理： 售后设备子系统部署设置防火墙和Internet 连接。
诊断工具登录及软件下载均有授权机制。
售后设备子系统对软件下发进行加密，终端只有通过植入的解密算法才能解密软件，中途截获的软件不能使用。
4.2.3 对OTA车辆数据的提供
随着软件迭代速度的加快，特别是特斯拉车型的自动驾驶软件的OTA导入，车辆OTA从信息娱乐IVI和全液晶仪表的SOTA发展到嵌入式软件的FOTA。通过和OTA的软件接口对接，MAS系统的VLM模块为OTA提供车辆信息和控制器的数据来源，在纯电动车型上实现了SOTA和整车控制器VCU、组合仪表、空调控制器AC等嵌入式软件的FOTA升级，图10。
5 结论
软件定义汽车、软件赋能汽车是汽车产业在机械操控、电气化后又一重要的技术发展趋势。本文通过控制器的软件类数据零部件化的定义、软件类数据的分类、控制器EBOM设计、数据流的定义以及数据管理系统的框架设计、开发以及车型的应用结果，展示该系统化设计的合理性和正确性，实现了软件类数据从设计、制造到售后的自动识别和系统传输，实现了产线在线软件灌装、在线配置、车辆终检，以及售后的在线软件升级、自動配置等诸多应用。需要指出的是，该系统化设计和系统建立，为OTA提供数据来源，也是实现OTA的必要基础。
随着乘用车电子类数据的不断丰富和发展，以及智能售后诊断与迭代的需求，该系统化的设计开发将不断迭代完善，促进企业数字化转型。
参考文献：
[1]蒋映中，吴泽民，孙学志，苟斌，王永峰，张帆，车辆设计、生产、售后一体化的软件分层开发体系，2014中国汽车工程学会年会论文集，2014CG-VE072，624-627页.
[2]孟天闯，李佳幸，黄晋，杨殿阁，钟志华，软件定义汽车技术体系研究，《汽车工程》2021年第4期，459-468页.
[3]蒋映中，吴泽民，冯超，孙学志，张帆，乘用车整车电气系统开发的新趋势及实现方式，2013中国汽车工程学会年会，文章编号：2013 CN-ET085 .
[4]安晶，王斌，王伟，基于Teamcenter软件的BOM管理系统开发研究，现代制造工程，2015年第3期，16-20页.
[5]NUGROHO S ，HADI S ，HAKIM L . Comparative analysis of software development methods between parallel，V-shaped and iterative[J]. International Journal of Computer Applications，2017，169（11）， pp.7-11.
[6]蒋映中，张翼鹏，苟斌，张凡武，吴泽民，杨诚，东风风神乘用车整车电气架构的开发，中国汽车工程学会汽车电子技术分会第十届（2012）年会暨学术研讨会，15-20页.