背景与意义

随着汽车市场对整车功能，特别是电气功能的多元化要求越来越高，整车厂在研发新款或者改款车型时都设计很多车型配置，目的就是满足客户对整车功能的不同需求，即让客户可以根据自己的喜好能够挑选出适合自己的配置车型。但是，如此多的市场需求和功能配置组合，对整车厂而言，在产品设计和开发阶段，带来的开发和管理成本就会随着配置组合数量的增加而增加。

例如，不同配置车型的设计过程中开发成本，验证成本，生产过程中零件的物流管理，售后阶段的备件的供应和管理成本等。尤其是控制器类的零部件，因为整车功能，特别是电气功能就是依靠整车控制器完成。配置的多元化所带来的成本增加基本上集中在控制器零件上。

现阶段，整车厂在开发控制器时，正努力做到尽量满足配置功能的前提下，控制器的硬件设计相同，用软件上的差异来实现不同功能配置，这样确实能比单纯地针对配置来设计控制器所带来成本低一些，但是针对客户对整车配置的快速变化，以及市场对于车型改款和更新速度的需求，还是有些力不从心的。例如，车型改款后，一旦有功能更新，即便是硬件相同，控制器同样需要成本来设计开发新版本软件来实现配置更新，功能升级，这个成本主要是开发、验证和物流管理。

故在满足市场对车型配置需求的前提下，如何基于平台化概念设计开发控制器，尤其是软件，是整车厂降低开发成本的关键。

本文针对市场对车辆配置需求不断变化的情况，基于相同硬件设计的控制器的前提，提出一种控制器平台化软件开发方案，目的是满足市场对车型配置需求的同时，重点降低车型开发或改款时零部件的开发管理成本，以及促进产品平台化。

控制器以此方法开发平台化软件后，整车厂在生产车辆时，利用控制器的诊断功能，在下线装配过程中，由下线诊断设备通过发送诊断报文的方式，将装配车辆的配置和功能信息发送给控制器后，控制器会自行开启和关闭相关功能，从而实现功能配置变换。

控制器平台化软件开发策略

整车的配置功能几乎均由控制器的软件实现，针对车辆不同配置的情况，在控制器硬件相同的情况下、利用软件的差异来实现不同配置。但即使如此，不同配置的车型还是需要装配不同软件版本的零件，若再将软件固化，则这个控制器产品就只能用于该款车型的该种配置。

如果以后市场需要车型配置升级或遇到改款的情况，又会需要成本来开发和管理零件。再或者遇到客户的特殊需求，例如希望在原有的配置上，增加或者减少功能，而这些功能是基于现有车辆条件根本就无法组合在一起的。或者即便能实现，也需要拆解车辆更换零件，这肯定会涉及成本增加，也会引起客户抱怨。

所以，为适应市场和客户对配置需求的快速变化，降低控制器零件的开发和管理成本，控制器软件开发策略是十分重要的，特别是灵活性和可配置性。下面分别描述控制器平台化软件开发策略和基于该策略在装配车辆时如何实现功能配置。

本文提出的平台化软件开发策略实际上是先将车型的配置转换为该控制器需要实现的功能，在硬件设计不变的前提下，将所有该控制器要实现的功能都用软件实现。但是在应用软件上，将每个功能留有接口，用于控制器实际实现功能的信息输入。

在开发之前，需要先将整车或者整个平台车型的配置拆解到每个控制器，这样，每个控制器就会有功能描述文档，作为开发控制器的输入。并且，用一个字符串VOD（Vehicle Option Data）来描述整车配置，每个控制器也有一个字符串CDS（Coding Data String）描述功能列表。VOD和CDS这两个字符串的每个字节都需要对应每个车型配置和控制器功能，当然如复杂的配置和功能，也可以用多个字节与之对应。因为每个车型配置都是由各个控制器实现各自功能组合而成的，即在已知车型配置的情况下，每个控制器需要实现的功能也就确定了。

根据以上描述，图1描述了开发前期需要执行的工作。

最后一步，当整车配置VOD和控制器功能CDS定义完成后，需要定义VOD与每个控制器的CDS的逻辑计算关系，即当已知整车信息及配置要求情况下，如何计算出每个控制器的CDS。CDS确定后，控制器则已经知道需要在该车实现什么功能。该字符串是控制器实现功能的纲领，控制器根据字符串内容，来实现与之对应的功能，CDS指导着控制器软件功能的实现。

故控制器在开发阶段，软件的开发是基于整车所有配置的所有功能，而车上控制器需要实际执行什么功能，则根据实际CDS数据内容来实现。如何定义CDS，即CDS与功能之间的对应方式是尤为重要的。

1.功能开关和选择

CDS字符串内容决定了控制器在车上应该实现的功能内容，故每个功能与CDS字符串中的每个字节的对应关系是需要明确定义的。

根据实际功能，有两类对应关系。第一类是功能开关和选择，即CDS字符串的字节对应的是控制器的执行功能，而该字节的数值不同则意味着该功能的开启和关闭，或者是功能的选择。

关于功能开关，例如00表示某个功能关闭，01则需要控制器开启该字节对应的功能。而关于功能选择，例如02代表是A功能，03代表着要实现B功能，而这两个软件逻辑是不同的。

下面以组合仪表为例，仪表在不同配置车型上显示的信息是不同的，档位就是其中一项，自动档车型则仪表应显示PRND档位信息，而手动档车型应该显示数字。当开发过程中，这两种显示逻辑都应该集成在组合仪表的软件中，并留有接口，用于功能执行信息输入。在组合仪表的CDS中字符串中挑选一个字节，并赋予定义。例如，00代表手动档，01代表自动档。当整车的配置信息确定后，即VOD字符串信息确认后，如果配置是自动档，那么根据VOD和CDS的逻辑对应关系，组合仪表CDS该字节的数值是01，软件就会执行自动档位信息逻辑，例如P、R、N和D位。如果是0，档位显示就会变为数字档位和R。

功能实现的基础就是要求控制器软件集成所有功能并留有接口，与控制器功能配置信息CDS字符串定义的功能进行对应，即每位数据都要关联到控制器功能软件的配置，继而根据字符串实际数值实现具体功能。

至于VOD与CDS的逻辑计算关系，就是当整车配置信息VOD确定后，与该配置对应的每个控制器的功能列表，即CDS字符串也已确定了。举例说明两者的逻辑计算关系，如图2所示，当车辆的配置信息固定后，即VOD信息固定后，每个控制器需要执行的功能也已固定，即得到了每个控制器CDS字符串的内容，根据定义，控制器来实现对应的功能。

2.参数输入

除了功能开关和选择类型的输入之外，为了更好实现产品开发平台化以及节约车型升级的控制器软件开发成本，另一种方式是在CDS字符串中定义功能参数，通过直接输入参数数值实现功能，当然在产品开发过程中，软件将预留参数接口，根据平台化的车型、配置等实际情况写入参数。

现以车身控制器举例说明该种方式，车身控制器有驱动玻璃升降的功能，在平台车型中，不同类别的车型，例如轿车、SUV、MPV，由于结构不同，要求驱动玻璃升降的堵转电流值也是不同的，为了达到平台化效果，将控制器执行该功能的参数定义在CDS字符串中，在已知车型信息的条件下，将与之对应功能执行所需要的参数值基于CDS定义直接输入，从而控制器实现功能。

此两种方式，VOD与CDS的逻辑计算关系类似，如图3所示，某些功能与控制器软件中设置的参数关联，并且在CDS中定义对应功能字节，即可根据平台车型的配置需求，直接更新参数即可。

如图3所示，由于平台车型不同，导致配置和车型本身是有差异的，当车型信息和配置固定后，即VOD信息固定后，每个控制器需要执行的功能也已固定，功能实现所对应的参数也已得知，即得到了每个控制器CDS字符串的内容，根据数值，控制器来实现对应的功能。

无论哪种输入方式，在开发前期，都需要先将平台车型的所有配置分解到各个控制器中，形成每个控制器的功能列表，基于此，定义车辆配置信息VOD和每个控制器的功能信息CDS这两个字符串，并且形成对应的逻辑计算关系。开发控制器软件过程中，将所有功能全部集成，并留有对应CDS定义的接口，用于将来实现具体功能。

控制器平台化软件应用

当控制器开发完成后，接下来就是如何应用，即如何基于开发前期的定义，让控制器实现具体的功能。

应用的方式是通过控制器的诊断功能，诊断功能属于控制器的系统功能，包含在控制器应用软件中。应用过程如图4所示。

实际上，功能应用的关键是将控制器要实现的具体功能通知给控制器，以实现软件配置。将参数写入控制器的工作需要在车辆装配时完成，车辆配置根据订单确定后，其VOD内容也已经确定，装配过程中，由下线检测设备，在已经VOD的情况下，计算出每个控制器的CDS，并通过发送诊断服务报文的方式发给相应控制器，从而实现控制器相应的软件配置。图5为具体应用过程，具体流程步骤如下：

1）下线设备获得整车配置信息VOD。

2）根据VOD与CDS的逻辑关系，计算出控制器诊断DID的数值。

3）下线设备将DID通过诊断功能发送给控制器，实现写入。

4）根据DID内容，控制器实现对应的功能。

下线检测设备以发送诊断服务的方式，将记录CDS内容的DID数值发送给控制器，控制器收到诊断信息后，先予以设备正响应，表示信息已经收到后，控制器就会根据内容实现具体的功能，之后将车辆重新上电，控制器就会基于车辆配置实现具体的功能。

实践分析

本文对控制器平台化软件开发策略到实际应用进行了理论分析，下面进行仿真分析，用于验证理论。模拟步骤如下描述：

1）先定义一些车辆实际配置VOD和诊断DID，根据上述软件开发策略，模拟出一个控制器，即组合仪表，该控制器正常的客户和诊断功能，其功能CDS来源于车辆配置，基于VOD与CDS正确的逻辑关系。

2）使用上位机软件模拟下线检测设备，可以发送诊断服务，将描述CDS的DID发送给模拟控制器，并判断模拟控制器的响应是否正确。之后通过诊断功能，将模拟控制器重新启动。

3）从模拟人机界面，观察模拟控制器，即组合仪表能否按照CDS内容来实现具体功能。

根据以上模拟验证步骤，先定义整车配置。上位机界面显示VOD内容，其中描述了整车配置信息，就是基于当前实际车辆的配置信息定义的。其中，“name”列是配置描述，“reserved”

是为将来车型平台配置拓展预留的，“Value”列是描述在VOD中的描述方式，包含功能开启和关闭类型以及参数输入类型，“Description”是用来进行功能补充描述的，便于区分功能和使用者理解。

根据车辆的配置信息，根据逻辑计算公式，算出模拟控制器组合仪表应该实现的功能信息CDS。当得到控制器CDS内容后，对应的诊断DID的数值内容即已知晓，将DID通过诊断服务写入到控制器当中，点击“Do Coding”的按钮，诊断服务即已经发出，得到控制器的正向响应后，上位机软件显示成功，显示界面和诊断报文。

从诊断报文和上位机显示的状态来看，模拟控制器组合仪表确实已知应实现的功能内容，应该实现对应的功能，图6是以档位信息为例，从模拟人机界面判断控制器是否正确执行了功能。

图6  模拟组合仪表显示信息

从图6可以看出，模拟控制器组合仪表显示了自动档位信息，但是由于没有连接实际的变速器，会报出功能受限的错误，但是均已经实现了功能列表CDS定义的功能。

从整个仿真过程可以看出，本文提出的控制器软件开发和应用策略是可以实现对应功能的，满足平台不同车型配置需求。

结论

本文提出的基于诊断功能的控制器软件开发方法，主要是为了减少整车厂针对相同ECU用不同软件来实现车辆不同配置的客户功能的开发管理成本，以及方便已批产车型拓展和配置升级的开发策略，基于以上理论分析和仿真验证，其可以在整车开发过程中应用。该策略的研究不仅可以满足市场对平台不同车型配置的多样化需求，最主要的是降低车型开发或改款时控制器零部件的开发和物流管理成本，以及促进产品开发设计平台化。