现在，我们将讨论汽车领域的特点和需求（参见参考文献[Gri03]），它们与产品线工程方面相关。这些特征可分为：变异的领域、产品配置和过程相关的特征。

7.2.2.1 变异性

7.2.2.1.1 变异性的来源

汽车电子的产品和产品研发制品的高变化度存在几个来源：

•在主要市场及其他市场（例如欧盟、美国、日本）存在的不同客户的需求——包括功能和价格。

•在车身变异体（例如豪华轿车、旅行车）和传动系统变异体之间所需的功能和应用程序约束的差异性。

•不同国家或市场之间的制度和法律约束的差异。这些规定和限制越来越多地影响着功能。

•新客户的期望，以及起源于工业领域中、得到最好部分控制的汽车工业的新技术标准。这里的主要案例是通信和娱乐。

由于这些原因，今天的豪华汽车开发项目是基于一套功能套件，它包括几千项技术功能。基于以上标准，这些功能需要选择或取消选择。

这种可变性是在详细的规范、设计模型、实施和测试结果水平上的进一步提高。这种变异部分来自功能的变化，部分来自不同的实现变体，例如由传感器和执行器的变体引起的。

这种情况就意味着需要支持项目的工具，该工具要具有高度复杂的变异模型。此外，在产品设置过程中，需要支持成组、并透明地管理大量决策的概念^[KKL+98]。

7.2.2.1.2 产品之间复杂的依赖关系

在汽车领域，支持变异体之间诸如“需要”和“排除”的关系非常重要。这些依赖关系存在不同的来源：它们可能来自于管理决策，它们可以基于逻辑事实（例如，一个没有后窗的配送车辆不需要后刮水器），或者它们可能起源于对设计和实施水平的依赖（例如，不同的显示变体对提供的功能与操作功能的人机界面，具有深远的影响）。一些依赖关系需要明确的定义（例如在一个特征模型中），而其他一些依赖关系可以来自于更详细的规定或设计模型（比如，通过适当定义的规则）。这里的困难是：为了在产品配置期间做出正确的决策，要决定哪一个依赖关系需要推导。

管理中心位置的所有依赖关系（定义的和派生的）而无须手工重新定义派生的依赖关系是必要的。相反，派生依赖关系应该选择可见，并加上对它们的显式或隐式定义的参考。需要两种分析来支持这样的依赖性：逻辑一致性分析，如果缺少这一条的话，这会妨碍产品配置的有效性；基于依赖关系的对象分析，需要添加到变异体上，以达到有效的产品配置。

7.2.2.1.3 异质变异机制的合作

我们已经表明了在产品开发过程中变异的来源。在汽车领域，需要在整个生命周期中控制变异：在开发工具链中；在生产数据库中；在营销系统中；和在售后服务系统比如诊断和软件更新系统中。

目前针对具体过程方面行之有效的工具包括例如需求管理或功能建模。这种工具有时提供务实的生长机制来支持变化。这意味着，需要一种综合的方法来支持工程，在不同的流程步骤中，采用不同的变异机制。在对接这些机制时，为了避免组合式爆炸，在具体流程步骤和中心变异模型之中的变异体信息之间需要定义一个接口。

7.2.2.1.4 针对变异体的不同观点(www.daowen.com)

一种面向产品线的开发方法需要支持变异概念，它不仅与工程相关，而且也与管理、市场营销、生产、采购和销售、客户相关。然而，涉及的不同的参与者和活动导致了不同的需求和期望。例如，开发工程师需要一个比管理者要求的更细粒度的特征模型。此外，在实现决策层面变异性的变化一般不必做得让营销和销售人员可见。另一个案例是变异性包装，目的在于减少客户在配置过程中的决策量，或在于强调给客户一定的功能组合。因此，很明确的是，产品线的工具需要提供和管理对产品线性能和变异的广泛观点。

7.2.2.2 产品配置

7.2.2.2.1 复杂配置

产品配置不仅出现在最终产品上，而且也出现在许多中间样机上，这些样机是概念评价、系统集成和测试所需要的。通常在研发过程中，第一个样机是一辆基本配置汽车，然而，这个基本配置通常是要变化的。对于这样的决定，产品线的工具支持能够检查针对变化点之间的所有依赖关系是至关重要的。在汽车领域，这些依赖关系对于人工检查来说，已经变得太复杂了。

7.2.2.2.2 随时间变化的复杂精度

在汽车软件开发领域，变异捆绑在产品生命周期的不同阶段，例如，基本特征是选择在开发阶段，国家代码是绑定在生产阶段，额外的预装软件功能可以在售后阶段激活。工具必须支持这些不同约束力时间的变化点。

7.2.2.3 与流程有关的特性与需求

7.2.2.3.1 域和产品工程流程没有干净的分离

与传统的软件工程领域常见做法相反，汽车领域的研发工程几乎不惜一切代价要保持它们的最后期限，否则由于开发、生产、销售和汽车原始设备制造商（OEM）的营销基础设施的缘故，成本将大幅上升。因此，开发项目有时被迫减少甚至很晚才取消计划的功能，或为一个单一的产品线实施特定的权宜之计的解决方案，以应付技术难点或保证高水平的质量。

以上情况被以下实际情形搞得进一步复杂化：这些和车型相关的特定的解决方案违背了最初的计划——有时采用了这种车型未来几代车上的技术方案，甚至采用了其他车型上的技术方案，因此，这些方案可以成为新的标准的解决方案。在大多数情况下，如果这会发生的话，它是不可能提前预测的。相反，特定的权宜之计有时是为了与原先预定的解决方案竞争。

虽然贯穿所有开发工程的严格复用是可取的，但从严格意义上说，把它们组织成单一产品线实际上是不可能的。相反，我们需要能够制定整个产品线的常用策略，它允许各部门负责产品系列的一部分——比如梅赛德斯-奔驰c级车电子平台——在一定程度上（允许）偏离该级车一部分。在汽车领域的产品线的方法和工具必须提供这样的局部偏差的支持，同时要促进产品线为导向的开发主要目标，即技术构件严格的复用最大化。

7.2.2.3.2 与供应商同步的战略

汽车OEM面临着有必要把大量供应商的隐秘产品线策略整合为自己的产品线策略。通常供应商的产品线的进化完全正交于制造商的产品线，因为供应商是用以往不同的战略与几个生产商接触。当这个挑战是不容忽视时，产品质量和成本在相当大的程度上就是负面影响。因此，产品线工程的方法和工具，提供整合多个独立开发的下属产品线的手段是必需的，也就是说，把那些供应商整合到一个更高层次的产品线，该产品线的制造商没有披露所有的机密细节需要。

7.2.2.3.3 与变化的管理流程同步

当前变更管理流程必须调整到一个面向产品线的研发。汽车产品线的方法和工具必须提供支持用于复杂的变更管理。特别的是，它必须能够揭示产品线的战略变化对成本和进度的影响，必须能够把这些变化推进到受影响的研发产品上，并相应地修改它们。

7.2.2.3.4 非常困难的增量导入

一步一步引入产品线的方法、过程和工具，在许多领域中是必要的。但是，这对汽车领域是特别真实，且逐步引入的先决条件在这里是特别复杂的。汽车系统的寿命已经给出这个问题的缘由：一代高级车型的生命周期通常包括3年的研发、6年的生产和销售，以及15年的运行、维护和客户服务。因为与遗留系统的兼容性必须遵守，所以甚至某一车型的子系统不能被集成到一个产品线基础的一个步骤中。相反，自底向上的方法更现实：首先，规模小且局部化的产品线设置为选定的子系统（例如，刮水器或空调），或甚至设定为单个研发产品（例如，需求模块或一组测试案例）；在下一步骤中，它们将被集成到一个更大的、更高层次的子域产品线，比如通信、车身电子或发动机控制。然后，它们将进一步整合成一个完整车型的综合产品线。方法和工具必须允许用自底向上的方式，逐步介绍产品线技术。