如果说按车型开发，即来一个车型做一次定义，则本条并不适用，因为每次有车型上马时均会有人重新审视原有功能定义是否可以复用或部分借用到新车型上来。 而如果按平台来开发，则需包含此平台上所有可能出现的车型相关的配置，若有一个新车型启动，它的配置可能为原先设计的A配置，再有一个新车型启动，它的配置可能为原先设计的B配置，也许一个大功能项的设计持续了2年，但它能适用到后续5年上的所有车型中，这便是一种高效的工作思路，唯一的缺陷是要求做规划的人有一定的前瞻能力，不能今年设计的东西到后年已经过时了，那就只能推倒重来。
　　在此，对于车型配置这块，也举三点。
　　第一，同一硬件下的不同配置。如是否有自动雨刮，或者在有自动雨刮时是否带车速感应功能。这只是软件上的不同，和硬件不相关。
　　第二，不同硬件下的配置差异。如前雨刮是采用LIN线控制还是硬线控制。这除了软件上的不同外，硬件电路也有所不同，均分别列出。即使是同样用硬件控制的方式，那么是否存在输入开关的差别，比如整个公司在开关上对这一平台或架构的车型，它的雨刮开关是否有多种不同的配置，如果有，均需要在雨刮子系统的需求中写明，以让雨刮控制模块全部兼容进来。另再举一例为相同功能的不同硬件，如同是自动雨刮功能，但对于控制开关来说有自动雨刮和没自动雨刮功能的车型可能都采用同一开关，而不需要一个开关有自动档另一个开关没有，这是一种投机取巧的做法，但只要不会让用户迷惑，某种情况下是可行的。
　　第三，性能参数上的差异。这也是同一硬件下的差别，因为它是“性能”，此处仅指由软件所决定的性能参数。比如某一功能在A车型上的延时时间是5s但到B车型上的延时是8s，这可能是由于车型的定位或地区不同而造成的需求不同，不过无论如何设计时均需包含这些不同。

　　以上的三种类型均是采用软件标定来实现，在第四章中会提到标定及其实现。

（2015-1-11 发表于本人QQ空间）