AUTOSAR 教程

总结

AUTOSAR：汽车行业的软件标准化与协同开发平台

AUTOSAR（汽车开放系统架构）是汽车电子软件开发的标准化解决方案，旨在支持分布式的、功能驱动的汽车电子系统。它由全球的汽车制造商、零部件供应商、研究及服务机构共同参与并推动，已发展为一个涵盖汽车控制器（ECU）标准软件架构的开放平台。

AUTOSAR的核心优势

1. 提高软件复用度：AUTOSAR的标准化架构促进了跨平台软件的复用，降低了开发成本。

2. 促进软件交换与更新：标准化的接口和架构使得软件模块易于交换和更新，提升了软件的灵活性和可维护性。

3. 减少开发错误：通过先期架构级别的定义和验证，AUTOSAR有助于减少软件开发中的错误。

4. 优化软件质量：减少手工代码量，降低测试验证的复杂度，从而提高了软件质量。

5. 标准化数据交换：使用统一的数据交换格式，促进了不同厂商间的合作与交流。

AUTOSAR的组成与原则

AUTOSAR规范由分层架构、方法论、应用接口和一致性测试四部分组成。其原则在于“统一标准、分散实现、集中配置”，即标准由联盟成员共同制定，但实现方式由各自公司决定，并通过集中配置完成最终的软件系统集成。

AUTOSAR的参与者与影响者

AUTOSAR联盟的成员包括宝马、大众、福特、丰田、BOSCH、大陆集团等全球领先的汽车及零部件企业。中国的长城汽车、东风汽车、一汽集团等也加入了AUTOSAR联盟。然而，值得注意的是，一些新兴的汽车制造商，如特斯拉，并未加入AUTOSAR，可能意味着他们拥有自己独特的E/E开发流程和控制器软件架构。

AUTOSAR的应用领域

AUTOSAR适用于动力总成、底盘、车身和驾驶辅助系统等领域的ECU软件开发，为这些系统提供了实时调度、通信、诊断、存储管理、功能安全和信息安全等功能。

总结

AUTOSAR为汽车电子软件开发提供了一个标准化的、开放的平台，有助于促进不同厂商间的合作与交流，降低开发成本，提高软件质量。随着汽车电子技术的不断发展，AUTOSAR将继续在汽车行业中发挥重要作用。

AUTOSAR，即汽车开发系统架构（Automotive Open System Architecture），是一套支持分布式的、功能驱动的汽车电子软件开发方法和电子控制单元上的软件架构标准化方案，目前 AUTOSAR 联盟已经包括宝马、大众、福特、丰田、BOSCH、大陆集团等众多汽车企业、汽车电子企业等。

本教程将介绍 AUTOSAR 的基本理念、开发方法论，及其定义的软件架构各模块的含义，例如应用层、基础软件层、RTE 层等。并通过新能源汽车电机控制器的开发案例引导学员掌握应用技巧。

AUTOSAR 简介

AUTOSAR 是 AUTomotive Open System ARchitecture 的缩写，即汽车开放系统架构。它是由全球各家汽车制造商、零部件供应商以及各种研究、服务机构共同参与的一种汽车电子系统的合作开发框架，并建立了一个开放的汽车控制器（ECU）标准软件架构。

AUTOSAR 联盟是在 2003 年由 9 家汽车行业的巨头（宝马、博世、大陆、戴姆勒、福特、通用、PSA、丰田、大众）建立的。这 9 家公司后来也称为 AUTOSAR 联盟的核心成员。截至 2020 年 3 月， AUTOSAR 已经拥有了 57 家高级成员、50 家开发成员、142 家普通成员以及 20 家观察员公司及机构，包括全球各大主流整车厂、一级供应商、标准软件供应商、开发工具和服务提供商、半导体供应商、高校和研究机构等。许多中国厂商也是 AUTOSAR 联盟成员，例如长城、东风、一汽、上汽、吉利、蔚来、拜腾、宁德时代等。

比较特殊的是，目前炙手可热的特斯拉却没有加入 AUTOSAR。这意味着他们很可能拥有自己的一套 E/E 开发流程和控制器软件架构。

AUTOSAR 的作用

经过十余年的努力，AUTOSAR 已经发展为一个完善的软件平台，可以为应对软件复杂性问题提供重要的技术支撑，并且可以让 Tier1 和 OEM 更专注于软件功能的设计与开发。

基于 AUTOSAR 平台，用户可以开发动力总成、底盘、车身和驾驶辅助系统等领域的 ECU 软件。它涵盖了构建现代 ECU 所需的实时调度、通信、诊断、存储管理、功能安全和信息安全等功能。

使用 AUTOSAR 规范，可以带来以下作用或优势：

• 提高软件复用度，尤其是跨平台的复用度；

• 便于软件的交换和更新；

• 软件功能可以进行先期架构级别的定义和验证，从而减少开发错误；

• 减少手工代码量，减轻测试验证负担，提高软件质量；

• 使用一种标准化的数据交换格式，方便各厂商之间的合作交流。

总的来说，使用 AUTOSAR 可以在保证软件质量的同时，大大降低开发的风险与成本。（当然，成本是相对的）

AUTOSAR 的原则

AUTOSAR 提倡的原则是：在标准上合作，在实现上竞争。

也就是说，标准由大家共同制定，但具体的实现方式由各个公司自行探索。其核心思想在于 “统一标准、分散实现、集中配置”。

• 「统一标准」是为了给各个厂商提供一个开放的、通用的平台；

• 「分散实现」要求软件系统高度的层次化和模块化，同时还要降低应用软件与硬件平台之间的耦合；

• 「集中配置」将不同厂商开发的所有模块的配置信息以统一的格式集中整合并管理起来，形成一个完整的配置系统，从而完成最终的软件系统集成。

谁要关注 AUTOSAR

首先是 OEM（主机厂），因为采用 AUTOSAR 可以为他们带来很大的好处，使得其对于软件采购和控制拥有更灵活和更大的权利。

其次是汽车电子零部件供应商（尤其是软件供应商），因为 AUTOSAR 不仅在软件的功能上、接口上进行了一系列的标准化，还提出了一套规范化的开发流程和方法，这也意味着会有更多的软件供应商进入汽车电子行业。

AUTOSAR 规范组成

AUTOSAR 规范主要包括分层架构（Software Architecture）、方法论（Methodology & Template）、应用接口（Application Interfaces）和一致性测试（Conformance Testing）四部分内容。

其中，分层架构是实现软硬件分离的关键，它使汽车嵌入式系统控制软件开发者摆脱了以往 ECU 软件开发与验证时对硬件系统的依赖。关于 AUTOSAR 分层架构的详细介绍请看这里。

相关链接

• 官方网站：https://www.autosar.org

AUTOSAR 发展现状

发展历程

随着电子技术在动力总成控制、底盘控制、车身控制以及车载信息娱乐系统等各个部分所占的比重越来越大、所占的整车成本也越来越高，电子技术已悄悄成为汽车各方面功能拓展和性能提升的重要技术支撑。

为了满足汽车电子硬件系统的多样性，提高软件的模块化和复用度，减少研发成本、降低研发周期。因此在 2003 年，基于先前 EAST-EEA 项目的研究成果，由全球汽车制造商、零部件供应商及其他电子、半导体和软件系统公司联合建立了汽车开放系统架构联盟（Automotive Open System Architecture），即 AUTOSAR。

AUTOSAR 联盟从 2003 年成立至今，成员队伍不断壮大，标准内容日臻完美。下图是 AUTOSAR 联盟成员（2010年5月）的展示图，AUTOSAR 联盟成员按等级划分为核心成员（Core Partner）、高级成员（Premium Member）以及合作成员三类正式成员。基本涵盖了世界上各大著名整车厂、零部件厂商、半导体厂商以及软件工具供应商。

为了迎合未来汽车智能化、网联化的需求，AUTOSAR 联盟推出了一个全新的平台 —— 自适应 AUTOSAR 平台（AUTOSAR Adaptive Platform，AP），并将现有平台更名为经典 AUTOSAR 平台（AUTOSAR Classic Platform，CP）。目前，AUTOSAR 经典平台的最新版本为 R20-11。

应用现状

AUTOSAR 规范在国外的应用相较于国内更早、更普遍、更成熟。大众、博世、通用、德尔福、菲亚特等公司已将符合 AUTOSAR 规范的软件应用于它们的 ECU 产品。

• 德国大众集团与 MathWorks、Elektrobit（EB）等公司联合开发了符合 AUTOSAR 规范的车身舒适控制系统，并应用于帕萨特车型。

• 马瑞利公司将 AUTOSAR 应用于菲亚特汽油发动机平台，并进行了硬件的环测试和不同工况 2 万千米行程的实车测试。此外，他们还将 AUTOSAR 运用于车灯控制、动力总成控制等电控系统。

• ETAS 公司成功将宝马 5 系发动机管理系统开发为符合 AUTOSAR 规范的控制系统。开发人员利用 ASCET 进行软件组件开发，管理软件组件端口及其运行实体；使用 RTA-OS 开发 AUTOSAR 操作系统，配置、划分、管理任务；应用 RTA-RTE 连接应用层和基础软件层；代码集成后，进行了硬件在环仿真，结果表明与传统开发方法相比复杂度降低 50%。

近年来，随着国内新能源汽车相关控制器正向开发需求的增长，AUTOSAR 规范在国内越来越受到大家的关注。

AUTOSAR 系统架构

2003 年，由全球汽车制造商、零部件供应商及其他电子、半导体和软件系统公司联合建立了汽车开放系统架构联盟（Automotive Open System Architecture），即 AUTOSAR。并联合推出了一个开放化的、标准化的汽车嵌入式系统软件架构 —— AUTOSAR 规范。

与传统 ECU 软件架构相比，AUTOSAR 分层架构的高度抽象使得汽车嵌入式系统软硬件耦合度大大降低，两者对比如下图所示。

AUTOSAR 分层架构是实现软硬件分离的关键，它使汽车嵌入式系统控制软件开发者摆脱了以往 ECU 软件开发与验证时对硬件系统的依赖。

在 AUTOSAR 分层架构中，汽车嵌入式系统软件自上而下分别为应用软件层（Application Software Layer，ASW）、运行时环境（Runtime Environment，RTE）、基础软件层（Basic Software Layer，BSW）和微控制器（Microcontroller）。为保证上层与下层的无关性，在通常情况下，每一层只能使用下一层所提供的接口，并向上一层提供相应的接口。

AUTOSAR 应用软件层

AUTOSAR 应用软件层（Application Software Layer，ASW）包含若干个软件组件（Software Component，SWC），软件组件间通过端口（Port）进行交互。每个软件组件可以包含一个或者多个运行实体（Runnable Entity，RE），运行实体中封装了相关控制算法，其可由 RTE 事件（RTE Event）触发。

AUTOSAR 运行时环境

AUTOSAR 运行时环境（Runtime Environment，RTE）作为应用软件层和基础软件层交互的桥梁，为软硬件分离提供了可能。RTE 可以实现软件组件间、基础软件间以及软件组件和基础软件之间的通信。

RTE 封装了基础软件层的通信和服务，为应用层软件组件提供了标准化的基础软件和通信接口，使得应用层可以通过 RTE 接口函数调用基础软件的服务。此外，RTE 抽象了 ECU 之间的通信，即 RTE 通过使用标准化的接口将其统一为软件组件之间的通信。由于 RTE 的实现与具体 ECU 有关，所以必须为每个 ECU 分别实现。

AUTOSAR 基础软件层

AUTOSAR 基础软件层（Basic Software Layer，BSW）又可分为四层，即服务层（Services Layer）、ECU 抽象层（ECU Abstraction Layer）、微控制器抽象层（Microcontroller Abstraction Layer，MCAL）和复杂驱动（Complex Drivers）。

各个软件层又由一系列基础软件组件构成，包括系统服务（System Services）、存储器服务（Memory Services）、通信服务（Communication Services）等。它们主要用于提供基础软件服务，包括标准化的系统功能和功能接口。

服务层

服务层（Services Layer）提供了汽车嵌入式系统软件常用的一些服务，其可分为系统服务（System Services）、存储器服务（Memory Services）以及通信服务（Communication Services）三大部分。提供包括网络通信管理、存储管理、ECU 模式管理和实时操作系统（RTOS）等服务。除了操作系统外，服务层的软件模块都是与 ECU 平台无关的。

ECU 抽象层

ECU 抽象层（ECU Abstraction Layer）包括板载设备抽象、存储器硬件抽象、通信硬件抽象和 I/O 硬件抽象。该层将 ECU 结构进行了抽象，负责提供统一的访问接口，实现对通信、存储器以及 I/O 的访问，从而不需要考虑这些资源是由微控制器片内提供的，还是由微控制器片外设备提供的。该层与 ECU 平台相关，但与微控制器无关，这种无关性正是由微控制器抽象层来实现的。

微控制器抽象层

微控制器抽象层（Microcontroller Abstraction Layer，MCAL）是实现不同硬件接口统一化的特殊层。通过微控制器抽象层可将硬件封装起来，避免上层软件直接对微控制器的寄存器进行操作。微控制器抽象层包括微控制器驱动、存储器驱动、通信驱动、I/O 驱动等模块。

复杂驱动层

由于对复杂传感器和执行器进行操作的模块涉及严格的时序问题，难以抽象，所以在 AUTOSAR 规范中这部分没有被标准化，统称为复杂驱动（Complex Drivers）。

AUTOSAR 软件组件

前面说到，AUTOSAR 应用软件层（Application Software Layer，ASW）包含若干个软件组件（Software Component，SWC）。软件组件不仅仅是应用层的核心，也是一些抽象层、复杂驱动层等实现的载体。

由于软件组件包含的概念较多，因此本文将单独介绍 AUTOSAR 软件组件的相关概念，这些知识也是后续进行应用层、抽象层等开发的基础。

概述

AUTOSAR 软件组件大体上可分为原子软件组件（Atomic SWC）和部件（Composition SWC）。其中，部件可以包含多干原子软件组件或部件。

原子软件组件则可根据不同用途分为以下几种类型：

• 应用软件组件（Application SWC）

• 主要用于实现应用层控制算法。

• 传感器/执行器软件组件（Sensor/Actuator SWC）

• 用于处理具体传感器/执行器的信号，可以直接与 ECU 抽象层交互。

• 标定参数软件组件（Parameter SWC）

• 主要提供标定参数值。

• ECU 抽象软件组件（ECU Abstraction SWC）

• 提供访问 ECU 具体 I/O 的能力。该软件组件一般提供引用 C/S 接口的供型端口（Server 端），由其他软件组件（如传感器/执行器软件组件）的需型端口（Client 端）调用。此外，ECU 抽象软件组件也可以直接和一些基础软件进行交互。

• 复杂设备驱动软件组件（Complex Device Driver SWC）

• 推广了 ECU 抽象软件组件，它可以定义端口与其他软件组件通信，还可以与 ECU 硬件直接交互。因此这类软件组件的灵活性最强，但由于其和应用对象强相关，从而导致其可移植性较差。

• 服务软件组件（Service SWC）

• 主要用于基础软件层，可通过标准接口或标准 AUTOSAR 接口和其他类型的软件组件进行交互。

值得一提的是，上述这些软件组件有的仅仅是概念上的区分，从具体实现及代码生成角度而言都是相通的。

AUTOSAR 数据类型

AUTOSAR 规范中定义了三种数据类型（Data Type）：

1. 应用数据类型（Application Data Type，ADT）

2. 实现数据类型（Implementation Data Type，IDT）

3. 基础数据类型（Base Type）

三种数据类型的具体说明如下。

应用数据类型

应用数据类型（Application Data Type，ADT）是在软件组件设计阶段抽象出来的数据类型，用于表征实际物理世界的量，是提供给应用层使用的，仅仅是一种功能的定义，并不生成实际代码。

ADT 从应用逻辑的角度描述数据，体现该数据在现实中的物理语义、物理取值范围、物理单位等。在 ADT 中通常会关联一个计算公式（Computation Method），描述数据从物理（值）范围到内部数字（位）级别的转换关系。一般地，在功能定义的过程中，我们会使用 ADT 的方式对数据进行描述，此时，各应用之间的通信还处于 VFB（Virtual Function Bus）的阶段。

实现数据类型

实现数据类型（Implementation Data Type，IDT）是代码级别的数据类型，是对应用数据类型的具体实现；它需要引用基础数据类型（Base Type），并且还可以配置一些计算方法（Compute Method）和限制条件（Data Constraint）。

在 AUTOSAR 中，对于应用数据类型没有强制要求使用，用户可以直接使用实现数据类型。而如果使用了应用数据类型，那么必须进行数据类型映射（Data Type Mapping），即将应用数据类型和实现数据类型进行映射，从而来对每个应用数据类型进行具体实现。

基础数据类型

基础数据类型（Base Type）是从 Bit 或 Byte 的角度描述底层平台（Platform）支持的原生类型，这些原生类型最终构建了 IDT 的实现。

完整的 AUTOSAR 数据类型定义包含 ADT、IDT 和 Base Type，且 ADT 和 IDT 之间需要定义映射关系，IDT 和 Base Type 之间需要定义关联关系。ADT 和 IDT 各有关注点和使用场合，实际应用过程中，当我们对物理语义不是很关心的时候，可以只定义 IDT 而不定义 ADT。

AUTOSAR 应用接口

在 AUTOSAR 规范中，将不同模块间通信的接口划分为以下三类：

1. AUTOSAR 接口（AUTOSAR Interface）

2. 标准 AUTOSAR 接口（Standardized AUTOSAR Interface）

3. 标准接口（Standardized Interface）

三种应用接口在 AUTOSAR 架构中的示意图如下图所示。

具体说明如下：

• AUTOSAR 应用接口（AUTOSAR Interface）是从软件组件的端口衍生而来的通用接口，用于描述数据或服务。它由 RTE 提供给软件组件，可以作为软件组件间通信的接口，也可以作为软件组件与 I/O 硬件抽象层或复杂设备驱动层间的接口。AUTOSAR 接口非标准，可自定义，但在 AUTOSAR 规范中目前已对车身、底盘及动力传动系统控制领域的应用接口做了一些标准化工作。

• 标准 AUTOSAR 接口（Standardized AUTOSAR Interface）是一中特殊的 AUTOSAR 接口，在 AUTOSAR 规范中有明确的定义。由 RTE 向软件组件提供 BSW 中的服务，如存储器管理、ECU 状态管理、“看门狗”管理等。

• 标准接口（Standardized Interface）在 AUTOSAR 规范中以 C 语言中 API 的形式明确定义。主要用于 ECU 上的 BSW 各模块间、RTE 和操作系统间、RTE 和通信模块间，应用软件组件不可访问。

AUTOSAR 虚拟功能总线

虚拟功能总线（Virtual Function Bus，VFB）是对 AUTOSAR 提供的所有通信机制的一种抽象，是所有软件组件进行交互的桥梁。通过虚拟功能总线，软件组件之间的通讯细节被抽象出来，软件组件通过 AUTOSAR 定义的接口对通讯进行描述，即可最大程度地独立于具体的通讯机制，实现与其他软件组件和硬件的交互。

AUTOSAR 虚拟功能总线的示意图如下图所示。

如果从整车级别去看待整车上所有的功能模块，主要有两种通信形式：

1. 在单个 ECU 内部的通信（Intra-ECU Communication）

2. 在多个 ECU 之间的通信（Inter-ECU Communication）

如果使用传统的系统设计方法，则会带来一个问题，即在定义整车级别的应用层软件架构的时候会受到具体实现手段的束缚，这主要体现在与底层软件的接口。AUTOSAR 为了实现一种“自顶向下”的整车级别的软件组件定义，提出了虚拟功能总线（VFB）的概念。

使用虚拟功能总线，可以使得负责应用层软件的开发人员不用去关心一个软件组件最终在整车中的哪个 ECU 中具体实现，从而使得应用软件的开发可以独立于具体的 ECU 开发。因此，可以让应用软件开发人员专注于应用软件组件的开发。而 VFB 的真实通信实现则由 RTE 和基础软件来保证，从这一角度来看，RTE 是 AUTOSAR 虚拟功能总线的具体实现。

AUTOSAR 方法论

AUTOSAR 方法论（AUTOSAR Methodology）中车用控制器软件的开发涉及系统级、ECU 级和软件组件级。

• 系统级主要考虑系统功能需求、硬件资源、系统约束，然后建立系统架构；

• ECU 级根据抽象后的信息对 ECU 进行配置；

• 系统级和 ECU 级设计的同时，伴随着软件组件级的开发。

上述每个环节都有良好的通信接口，并使用统一的 arxml（AUTOSAR Extensible Markup Language）描述文件，以此构建了 AUTOSAR 方法论。

下图展示了 AUTOSAR 方法论中“自顶向下”的软件组件设计和 VFB 实现方法。

在开发 AUTOSAR 之前，需要先编写系统配置描述文件，包括以下三部分内容：

1. 软件组件描述（SW-Component Description）：包含系统中所涉及的软件组件的接口信息，例如数据类型、端口接口、端口等；

2. ECU 资源描述（ECU Resource Description - HW only）：包含系统中每个 ECU 所需要的处理器及其外设、传感器、执行器等信息；

3. 系统约束描述（System Constraint Description）：包含总线信号、软件组件间的拓扑结构和一些映射关系等信息。

基于上述系统配置输入描述文件，系统配置根据 ECU 资源和时序要求，将软件组件映射到对应的 ECU 上，生成系统配置描述文件（System Configuration Description）。该文件包含了设计过程中非常重要的一个描述 —— 系统通信矩阵，其描述了网络中所有运行的数据帧及其对应的时序和内容。

从系统级到 ECU 级的过渡操作是指 ECU 信息抽取（ECU Extract）。在系统配置阶段已经将每个 ECU 所包含的所有软件组件、网络通信等信息封装好，ECU 信息抽取阶段只需将待配置 ECU 信息抽取出来即可，服务于之后的 ECU 配置。

ECU 配置过程主要是对 RTE 和 BSW 的配置。

• 在 RTE 配置阶段，需要将软件组件的运行实体映射到相应的操作系统任务；

• 在 BSW 配置阶段，需要详细配置 BSW 层中所需要用到的模块，一般有操作系统、通信服务、ECU 抽象层和微控制器抽象层等。

然后根据 ECU 配置信息生成 BSW 和 RTE 代码，再结合软件组件级实现的应用代码，最终进行代码集成，编译链接，生成单片机可执行文件。

AUTOSAR 经典平台

AUTOSAR 自适应平台

AUTOSAR CP 和 AP 对比

AUTOSAR SOME/IP 协议

SOME/IP全称Scalableservice-Oriented Middleware over IP，基于IP的可扩展面向服务的中间件。

SOME/IP协议于2011年由BMW集团的Lars Völker设计，并于2013年纳入AUTOSAR 4.1规范，其在规范里定义如图1所示。在车载以太网的协议架构中，SOME/IP位于应用层(如图2所示)，提供面向服务的通信接口。其通信方式为AUTOSAR中提到的CS接口的概念，就是客户端(client)和服务端(Server)，当有请求发出时，SOME/IP才会发出数据，否则不发送数据，类似于COM模块的Direct模式，这样总线上就没有不必要的数据，降低总线负载。同时在整车电子电气架构中可以将Classical AUTOSAR和Adaptive AUTOSAR桥接起来，如图3所示。

SOME/IP主要为应用层提供API接口，创建CS接口，通过TCP/IP协议进行通信。而SOME/IP的访问方式分为三种，分别是事件通知、远程过程调用和访问进程数据。

• 事件通知与传统的CAN通信类似，服务端端周期性或者事件变化时向客户端发送特定的数据，如图4所示。

• 远程过程调用是当客户端有请求的时候，向服务端发送请求命令，服务端解析命令，并作出相应的响应，如图4所示。

• 访问进程数据可以使客户面向服务器写入(Setter)或者读取(Getter)数据，其方式如图6所示。

SOME/IP 数据格式

• Message ID(Server ID) ：16bit，服务的ID，标识出一个服务；

• Message ID(Method ID) ：16bit，方法的ID，表示出一个方法；

• Length：报文长度，32bit，标识从request ID到报文结束的总长度；

• Request ID(Client ID) ：客户端ID，16bit。区分不同的客户端；

• Request ID(Session ID) ：会话ID，区分同一个客户端的多次调用；

• Protocol Version ：协议的版本号，固定值为x01；

• Interface Version：服务接口版本；

• Message Type ：报文类型，在AUTOSAR中，总共包含五种，包括REQUEST，REQUEST_NO_RETURN，NOTIFICATION，RESPONSE，ERROR；

• Return Code ：返回码，包括四种，REQUEST，REQUEST_NO_RETURN，NOTIFICATION，RESPONSE；

• Payload ：数据段，用于放置需要传输的数据。

SOME/IP开源库 vsomeip

AUTOSAR DoIP 协议

UDS诊断作为汽车ECU里的一个服务功能，位于应用层，它的实现需要有网络的支撑，我们把基于CAN总线实现的UDS诊断称为DoCAN，基于Ethernet实现的UDS诊断称为DoIP

Diagnostic communication over Internet Protocol，我们把通过以太网协议，承载UDS数据，实现诊断通信的这种方式称为DoIP

相比DoCAN中CAN网络的封闭性，DoIP由于Ethernet的互联互通，可以实现车与车、车与人的远距离诊断通信

DoIP在传输层以下的规范遵循ISO 13400，而应用层还是遵循ISO 14229不变，这样可以保证UDS诊断在不同车载网络上的可移植性

ISO 13400-2规定了外部测试设备与车辆ECU之间的诊断通信要求，包括：

• 网络层协议IP

• 传输层协议TCP/UDP

• 对网关的要求（网关如何集成到现有网络总）

• 对测试设备的要求（如何发现车辆并建立通信）

支持DoIP的车辆网络架构图如下