如果一个公司在现场有产品，那么在一步之内实现标准是不现实的，也是不明智的。在所有研发阶段，逐步实现与引导成熟的有联系的流程来确保质量是必要的。事实上，明智的做法是：逐渐接近AUTOSAR标准来收集混合平台上的第一次经验，并针对研发制订具体的、明确的、可控的目标。重要的是不仅要理解AUTOSAR模板和计划的简单使用，而且要理解AUTOSAR开发过程的基本新概念，且通过使用它来获得经验。

在大多数情况下，AUTOSAR的一致性的ECU研发并不是从头开始的，而是修改现有系统达到一个符合AUTOSAR标准的系统。

几种混合系统是可能的：

•一些BSW模块可能被AUTOSAR BSW模块取代。这并不显示出整个AUTOSAR概念的适用性。AUTOSAR的优点是整个BSW堆栈被标准化了。就这一点来说，不仅单一模块而且模块之间的交互也被定义。只有采用了整个AU-TOSAR BSW，规范的整体优势才能实现。

•BSW模块集群可能被AUTOSAR BSW集群取代。这个说法对于从定义的集群，例如COM堆栈中取得特定优势是有意义的。因为对于几个供应商来说，出售特定的集群在AUTOSAR出现之前，完全适合商业模式的这样一种变体，是目前一个通常的商业模式。可以说，它是聊胜于无。

•RTE的实施可以添加到起初非AUTOSAR兼容的BSW之上，且可以用于某些应用程序中，但不是全部。这个说法对于试验系统中使用的应用程序来说，是一个可能的移植路径。这是一个迈向ICC1等级的第一步。不推荐把它用于批量生产，因为它需要额外的内存，且没有任何功能优势。

•一种系统方法可以用于指定系统，但可能不能用于设计AUTOSAR架构和实施。

它不仅需要一个用于实施流程的移植场景，而且需要它适应系统。因为它们的变化通常与结构重组有关，所以流程变化所花的时间超过架构的变化时间，且可能是较早成立的。在本节的其余部分，我们打算描述从一个ECU移植到AU-TOSAR ECU上的必要步骤。我们以一个案例的标题、先决条件、后置条件的形式介绍这些步骤，并给出详细描述。

案例标题：

改变现有非AUTOSAR ECU，目的是包含AUTOSAR BSW、RTE和ASW组件。

先决条件：

带非AUTOSAR软件的ECU可用。

后置条件：(www.daowen.com)

带AUTOSAR软件的ECU可用。

描述：

•决定一个ICC1、ICC2或ICC3 ECU架构。词语“不从头开始”包含通常训练有素的软件开发过程存在。有必要分析现有软件架构和构建的流程。检查现有的BSW如何与RTE交互。决定要走哪条路。现有BSW能够满足ICC3轻微的变化吗？或者是研发一个ICC1系统更适合？这样的决定不能由供应商对自己的产品做出。如果OEM打算在这个ECU上运行其他供应商的ASW组件，那么还必须考虑来自这些额外ASW组件的需求。

•描述ECU类型、连接性和使用ECU资源模板的资源。这一步可以由半导体供应商直接完成。作为文档的一部分，模板可以与硬件一起交付。

•开发针对应用程序层的架构。分析早已在ECU上运行的应用软件。从逻辑上把应用程序划分成组件。把这些组件拆分为独立于硬件和独立于硬件组件。第一组将作为除RTE（使用底层BSW）之外的ASW组件运行。第二组可能作为一个复杂的设备驱动程序实施。

把独立的硬件组件转换成ASW组件。从传统应用程序中提取单个组件。意味着所有的内部和外部的通信需要分析。组件使用的数据类型和接口根据这一分析来建模。实际组件——它可能是一个极微小的组件、传感器组件或一个参与者组件——通过使用这些接口来建模。

除了它的通信外，组件的内部行为也需要进行分析。传统代码中基于周期性的和基于事件的功能是按照运行实体来建模的。

•完成系统配置步骤。集成商使用系统模板的系统约束部分来设计映射约束。计划在相同ECU上运行的所有组件映射到系统生成步骤中的硬件上。

在ECU提取器的帮助下，提取生成步骤的输出。对实施、配置和测试的必要信息，单一ECU要把它们分离出来。现在，可以运行AUTOSAR RTE生成器合约阶段。它生成了应用程序程序员所需的一组头文件来实施组件。在接口和连接器的帮助下，把组件们连接在一起。

•集成ECU。配置BSW——比如线程使用与线程优先级、总线——系统通信参数（如CAN帧优先级）等。RTE生成阶段使用RTE生成器。如果ECU所有必要的软件已经汇集，包括BSW代码、RTE代码和ASW组件代码，那么就可以构建ECU软件图像。下载此图像到目标中并测试它。

具体步骤不能由AUTOSAR来定义。很多开发人员对这个现象感到失望，因为他们希望从标准中得到更具体的流程建议。但发布合适的流程不是这个标准的责任。这是一个竞争的舞台。因此，每个公司都对流程负责。同时，甚至期望得到指导方针也会被拒绝。这将干扰标准本身。所以，AUTOSAR的边界是非常清楚的。