Unified Diagnostic Services (UDS)

It’s a diagnostic communication protocol used in electronic control unit (ECU).

It is defined in the ISO 14229 standard. It is the application layer of the OSI reference model and is independent of the bus-system. The protocols for specific bus-systems like CAN and K-Line etc. are defined in separate standards viz. ISO 15765-3 (CAN). This way, the OEMs are not bound to use any specific communication system in the vehicle.

UDS protocol is used to diagnose fault at the service center. It allows diagnostic tester (client) to control diagnostic functions in an on-vehicle Electronic Control Unit (ECU, server) such as an electronic fuel injection, automatic gear box, anti-lock braking system, etc. connected to a serial data link embedded in a road vehicle.

Diagnostic Services:

Used within ECU for below operations

1. Diagnostic and Communication Management
2. Data Transmission
3. Stored Data Transmission
4. Input / Output Control
5. Remote Activation of Routine
6. Upload / Download

There are many diagnostic services used/defines by ISO standards.

Below are the diagnostic services used in Automotive:

Diagnostic Session Control (0x10)

The DiagnosticSessionControl service is used to enable different diagnostic sessions in the server(s). 

A diagnostic session enables a specific set of diagnostic services in the server(s). This service provides the capability that the server(s) can report data link layer specific parameter values valid for the enabled diagnostic session (e.g. timing parameter values). The user of this International Standard shall define the exact set of services and/or functionality enabled in each diagnostic session. 

Session Types:

Message Format:

ECU Reset (0x11)

This service requests the server to effectively perform an ECU reset based on the content of the Reset Type parameter value. After an ECU reset has been executed, the default session is active.

Message Format:

AUTOSAR Basics

AUTOSAR is AUTomotive Open System ARchitecture. It was founded in 2003. It is a worldwide development partnership of vehicle manufacturers, suppliers, tool developers, service providers and companies from the automotive electronics, semiconductor and software industry.

Objective of AUTOSAR is to create and establish an Open and Standardized software architecture for ECUs.

Motto  : Co-operate on standards, Compete on implementation 

Reality : Current struggle between OEM and Tier 1 Suppliers

Benefits:

Reduce development efforts and improve quality.

Facilitate portability, scalability to different vehicle variants, maintainability over the lifetime of vehicle. 

OEM has flexibility to choose software from different suppliers Software sharing becomes easy.

Architecture:

AUTOSAR gives a layered top-down structure for software with relation between the software components.

The layered architecture of AUTOSAR can be divided into Basic Software(BSW), Runtime Environment(RTE) and Application/Software Component layer.

Basic Software layer can be further subdivided into Micro-controller Abstraction Layer(MCAL), ECU Abstraction Later, Services Layer and Complex Device Driver(CDD) Layer.

Service Layer is the layer above the ECU abstraction layer , mostly independent of the hardware and responsible for providing the basic BSW functionality to the application.

ECU Abstraction Layer is the layer above the MCAL layer which houses the interface components and the drivers for the hardware components outside the micro-controller on the ECU. Its basic responsibility is to make the layer above it independent of the hardware available on the ECU. Its lower interfaces are hardware dependent and the upper interfaces are hardware independent.

Micro-controller Abstraction Layer (MCAL) is the lowest layer in the layered AUTOSAR architecture and it communicates with the hardware directly. Its basic responsibility is to make the layer above it independent of hardware. It houses the low level drivers of the micro-controller.

Complex Device Driver (CDD) is a layer through which the hardware can be accessed through the RTE by the application software component directly without going through the various layers of AUTOSAR. This layer is used by the applications which have high timing constraints and for the requirements which are not described by AUTOSAR. This layer is micro-controller and ECU hardware dependent.

Runtime Environment is the layer separating the Basic Software and Application Software. The software architecture above it becomes component level than the layered architecture in the Basic Software. RTE is the ECU level instantiation of the Virtual Function Bus(VFB). RTE is ECU specific. The application software components without the BSW communicate with each other over the Virtual Function Bus (VFB).