EAST-ADL是在ITEA的EAST-EEA项目中得到发展的^[15]。EAST-EEA项目的目的是减少硬件对于汽车软件的依赖性，允许更多针对软件配置的灵活性。据称，需要ADL是为了管理软件和硬件的规格。EAST-ADL随后被应用于诸如EASIs的项目中^[16]，并在ATESST项目中得到完善，变成EAST-ADL2^[17]。

EAST-ADL的范围包括了开发汽车软件所需的工程信息：功能和软件本身、需求、硬件和环境。图9.13显示了EAST-ADL2中用于组织系统信息的抽象层次。

9.5.6.1 系统模型组织

（1）车辆层面

这种抽象层面代表了用户对于车辆的感知。该模型包含了车辆和它提供的功能。由抽象的、独立实施的形式所表达的需求可以指派。这也就是说，可以配置车辆，它定义了在一个特定车辆中需要包含哪些功能。

（2）分析层面

此层面包含具备E/E架构功能性抽象描述的模型。尽管已经做出了一些选择，但重点是系统应该做什么，而不是如何去做。例如，进行包括独立实施的接口定义在内的初期功能分解，抽象行为可以包含，且需求可以分配。这些模型被用于分析和获得实际的解决方案之前也就是设计阶段的早期评估。这也是一种调查在整个生命周期中系统主要特性的手段，而不必进入更加详细的设计。

（3）设计层面

设计层面包括E/E架构功能与硬件的详细规定。对功能接口进行了详细规定，冗余被添加，且针对效率、具体硬件、中间件等的适应性也被包括在内。尽管软件设计层面相对于编码、组件化、任务分配等还是一个具有一定自由度的功能描述，但软件设计层面规范等同于最终实施。应用软件和中间件是彼此分离的，但是它们都在设计层面上以这种程度的细节得到了体现。硬件表征包含ECU、总线、传感器和执行器等，它们是规范、分析和功能行为配置所必需的。

图9.12 AUTOSAR方法(www.daowen.com)

（4）实施层面

软件实施层面模型代表了代码、任务分配、通信/数据交换实施、中间件配置等方面的最终实现。硬件表示与设计层面上的表征具有相同的划分。更详细的硬件规定比如电路图和VHDL语言描述，都不在EAST-ADL2表示范围之内，且通常不是功能/软件开发所必需的。

图9.13 用于组织针对电子与电器架构和环境的系统模型的EAST-ADL2抽象层面

EAST-ADL2依赖AUTOSAR建模概念来捕获实施层面的系统。AUTOSAR结构与实体之间在更高抽象层面上的“实现”关系，被用来从实施到更抽象实体的连接。这提供了必要的从一个或几个AUTOSAR实体到一个或几个EAST-ADL2实体间的可追踪性。

9.5.6.2 环境建模

E/E架构下的环境，通常被称为植物模型，它表现在每个抽象层次上。其目的是为了捕捉考虑到环境的假设，并允许在其中进行车辆功能的分析和仿真。

E/E架构因为处于较低抽象层面，所以其细节程度增加了。该环境模型的特性是独立于抽象层面之外的，并且由分析的需要所决定。例如，一个用于安全分析的仿真可能拥有一个非常简单的发动机模型，然而分析一个齿轮的选择策略却需要更加细节的处理。需要包含这样一组不同的环境模型，以应付不同的需求。

9.5.6.3 可追踪性

EAST-ADL支持一个包含几个部分或者包含几个表现前述抽象层次（子）模型的集成模型。在不同的抽象层面及模型不同部位的实体之间存在彼此联系。例如，分析和设计层面上的组件间“实现”连接识别出它们所实现的特征。