======1、诊断的功能简介=======

1、概述

概述
文章概要：本文概述了汽车故障诊断功能，对比了AP诊断系统所在的自适应平台（AP）相对于经典平台（CP）的优势，分析了自适应平台下的诊断系统物理组成和服务端软件结构以及在此基础上的诊断通信消息的传输。

1.1、什么是汽车故障诊断？
当汽车存在故障隐患，技术状况变差，或是已经部分或完全丧失工作能力时，往往需要在不解体（或仅卸下个别小件）汽车的条件下，为确定汽车技术状况或查明故障部位、原因而进行检测、分析和判断。
1.2、诊断系统出现的背景和意义
随着计算机技术越来越广泛地融入到汽车工程中，整车内的总线网络结构由于ECU的增加而愈加复杂，汽车电子开发验证的复杂度也随之提高，对产品的前期设计开发、整车制造生产、售后工程部门的维修处理等方面提出了挑战。因此各OEM迫切需要一套满足高准确性、实时性、高效性的汽车诊断系统来应对现阶段分离式的软件设计、测试流程。
目前最主要的措施之一是对基于AUTOSAR的ECU软件架构进行统一规划来实现车辆故障诊断的标准化。
1.3、诊断功能主要模式
对于整车厂而言，诊断模式分为两类：在线诊断和离线诊断。

在线诊断模式（Onboard Diagnostic System），通过车内模块自带的诊断系统对ECU软硬件及各传感器参数进行某些常见的故障实时监控与发现，当系统判断电控系统出现故障时，会以仪表警示灯的形式来告知驾驶者，并通过ECU内的EEPROM或Flash对相关故障诊断码DTC进行存储，以便后续车辆被送至售后出由工程师对其进行故障检测时读取分析处理。

离线诊断模式（Offboard Diagnostic System），即将外部设备接在OBD诊断口或通过无线信号等方式与整车网络的各ECU进行通信，对各模块数据进行监控和检测分析。诊断设备通过发送满足诊断协议定义的诊断服务来实现诸如对已存储DTC的读取和清除等，利用其他整车控制指令来实现对车辆的动静态控制。

1.4、诊断系统对故障进行哪些处理？
汽车故障诊断系统利用ECU来监测控制系统各组成部分的工作情况，发现故障后自动启动故障记录和处理逻辑。汽车故障诊断模块不仅能够存储记忆汽车故障，还能够实时提供汽车各种运行参数。外部诊断设备通过一定的诊断通信规则与ECU建立诊断通信，并读取这些故障和参数，同时解析出来供外部测试人员分析。故障诊断记录处理，并将这些处理的信息通过诊断通信传输给外部诊断设备。

======2、AUTOSAR经典平台与自适应平台=======

2.1、AUTOSAR简介

汽车开放系统架构（AUTOSAR）是当前汽车电子领域普遍应用的软件架构。它是由包括BMW、DAIMLER、GM、TOYOTA、福特等主机厂和包括博世、大陆等供应商牵头成立的一个标准发展组织定义的一个开放参考的ECU软件架构。该架构的提出是汽车电子E/E系统发展的一个重要历程杯。

发展AUTOSAR的想法最开始于2003年，初衷是为了避免反复重复开发功能相同相近的软件模块。使用独立于系统的标准软件平台，可缩短产品上市时间，减少开发工作，并可从同一组组件中开发出更多产品，提高产品质量。

目前AUTOSAR分为经典平台Classic Platform AUTOSAR（CP）和自适应平台Adaptive Platform AUTOSAR（AP）两个平台。最早的经典平台（CP）目前已广泛应用于传统嵌入式ECU中，如发动机控制器、电机控制器、整车控制器、BMS控制器等等，而自适应平台（AP）未来会更多的应用于如ADAS、自动驾驶等需求高计算能力、高带宽通信、分布式部署的下一代汽车应用领域中。

2.2、经典平台架构组成及其特点

经典平台在最高抽象级别上将运行在控制器上的软件分为三层：应用层Application，运行时环境Runtime Environment(RTE)和基础软件Basic Software(BSW)。

其中，应用层不依赖于硬件，软件模块间通过RTE交互，并通过RTE访问BSW。

RTE体现了Application的所有接口。

BSW又分为3大层：服务层、ECU抽象层、MCU抽象层，和复杂驱动。

服务层又细分为不同的服务组件，比如系统服务、存储服务、通信服务等。

AUTOSAR经典平台（Classic Platform）架构图

经典平台的主要特点有：
l 基于C语言面向过程开发
l 采用FOA架构（function-oriented architecture）
l 基于信号的静态配置通信方式（LINCAN…通信矩阵）
l 硬件资源的连接关系局限于线束的连接
l 静态的服务模块，模块和配置在发布前进行静态编译、链接
l 大部分代码静态运行在ROM，所有application共用一个地址空间
l 基于OSEK OS

2.3、自适应平台架构组成及其特点

自适应平台定义了一个ARA运行时环境（AUTOSAR Runtime for Adaptive Applications）。分为两种接口类型：service和APIs。平台由平台服务（Platform Service）和平台基础（Platform Foundation）分组的多个功能栈（功能集群）组成。每个功能栈：

l 聚合了自适应平台功能
l 定义了功能栈需求规范
l 从应用程序和网络角度描述软件平台的行为
l 但不限制最终在自适应平台中的具体软件架构设计
l 每台（虚拟）计算机必须至少有一个包含平台基础（Platform Foundation）的实例，而服务功能栈（Platform Service）可能分布于车载网络中。
l 相比于经典平台，用于自适应平台的运行时环境（ARA）在运行时动态链接服务和客户端。

AUTOSAR自适应平台（Adaptive Platform）架构图

自适应平台的主要特点有：
l 基于C++语言面向对象开发
l 采用SOA架构（service-oriented architecture）
l 基于服务的SOA动态通信方式（SOME/IP…）
l 硬件资源间的连接关系虚拟化，不局限于通信线束的连接关系（互联网）
l 服务可根据应用需求动态加载，可通过配置文件动态加载配置，并可进行单独更新
l application加载到RAM运行，每个application独享（虚拟）一个地址空间
l POSIX-basedOS（LinuxPikeOS…），兼容性广，可移植性高

2.4、自适应平台对比经典平台的优势

统嵌入式ECU主要实现替代或增强电气系统的功能。这些ECU中的软件主要根据输入的电气信号和来自车载网络上其他ECU的输出信息来控制其输出的电气信号，它们在整个车辆寿命中往往不会发生明显变化。

而下一代的车辆运用，比如自动驾驶，将需要更复杂、更高计算资源的软件，并满足更严苛的完整性和安全性要求。这些软件需要实现比如环境感知、行为计划等功能，并需要将车辆融入到外部后台系统和基建系统中。随着外部系统的不断发展或改进的功能，要求车辆中的软件能够不断被更新。

经典平台(CP)满足了传统嵌入式ECU的需求，但对上述ECU的需求无法满足。因此AUTOSAR指定了另外一个软件平台，即自适应平台(AP)。AP更专注提供高性能计算和通讯机制，并提供灵活的软件配置，例如支持无线更新软件(FOTA)。

自适应平台的优势：

l ECU更加智能：基于SOA通信使得AP中ECU可以动态的同其他ECU提供或获取服务，动态同其他ECU进行连接
l 更强大计算能力：基于SOA架构使得AP能够更好支持多核、多ECU、多SoCs并行处理，提供更强大的计算能力
l 更加安全：基于SOA架构使得AP中各个服务模块独立，可独立加载，IAM管理访问权限
l 敏捷开发：Adaptive AUTOSAR服务不局限于部署在ECU本地可分布于车载网络中，使得系统模块可灵活部署，并可后期灵活独立更新（FOTA）
l 高通信带宽：基于Ethernet等高通信带宽的总线通信
l 更易物联：基于以太网的SOA通信，更易实现无线、远程、云连接，部署Car-2-X应用
l 系统兼容：通过SOMEIP等协议AP可以同CP/Non-AUTOSAR等ECU
以下我们将针对自适应平台的诊断系统进行介绍。

======3、自适应平台的诊断系统组成=======

3.1、诊断系统的物理组成

通常情况下，一个汽车诊断系统除了包括车内的ECU和总线组成的拓扑网络外，还会包含自带的诊断系统，以及外部接入的诊断设备。其中，外部诊断设备可以是通过OBD口接入的，也可以是无线信号远程连接的。

以总线式拓扑为例，汽车诊断系统的主要物理组成：

诊断系统物理组成图

3.2、诊断服务端的软件架构

诊断设备通过发送满足诊断协议定义的诊断服务来实现诊断功能控制，车内ECU对诊断设备的服务请求做响应类型的响应。相对地，诊断设备称为客户端，而响应服务的ECU内部相关诊断管理模块（DM）称为服务端。

DM的功能分为两层：UDS传输层和应用层。UDS协议（Unified Diagnostic Services）即ISO14229，统一诊断服务，是诊断服务的规范化标准，属于诊断的应用层协议。

在应用层，DM实现了诊断的两个主要构建块：诊断事件管理（DEM）和诊断通信管理（DCM）。

在UDS传输层，诊断消息基于DoIP协议实现传送。DoIP是一种车辆发现协议，旨在与诊断设备进行车外通信。车载或远程诊断通常使用其他传输协议，因此提供了使用自定义传输层扩展平台的API。

诊断功能的服务端模块组成关系及其在ECU内部的位置：

诊断服务端模块组成图

在AUTOSAR自适应平台上，应用层可以分成多个软件集（SoftwareCluster），每个集群都有自己的诊断地址。因此，DM为每个软件集群实例化一个诊断服务器，该服务器在软件集群给定的范围内实现诊断。

DM通过标准化或用户定义的UDS传输协议处理与诊断客户端的连接。DM实现特定传输协议的子组件称为传输协议处理程序。

UDS传输层和应用层之间的链接由传输协议管理器实现，它向两个方向发送UDS消息：来自诊断客户端的UDS请求被转发到各自负责的诊断服务器实例，诊断服务器实例创建的UDS响应被发送到相应的传输协议处理程序。

诊断管理模块的通信数据流：

诊断通信消息数据流图