Dear readers,
My name is Sadashiv Balawad and I am working as Junior Software Engineer at Luxoft India. Luxoft gave me many opportunities to work on various projects, which inspired me to talk about the importance of Diagnostic Development with Autosar

Introduction
The Benefits for Vehicle Manufacturers and Suppliers
OEMs and Tier 1 providers make use of many exceptional strategies for the improvement of car diagnostics. Various trade codecs are used and the implemented gear are normally adapted to every agency’s particular process. At the very cutting-edge, issues begin going on while diagnostic descriptions must be exchanged with improvement companions and used in their tool chains. This is always a time-consuming mission – if certainly it's miles possible at all to alternate statistics without any loss of facts. The AUTOSAR Diagnostic Extract Template (DEXT) gives a completely new range of possibilities for diagnostic development. The basic software program modules which might be relevant for diagnostics may be configured uniformly throughout employer barriers, as an instance OEMs and Tier 1 providers, or in collaborations between OEMs. Tasks that were previously carried out by way of the integrator at the Tier 1 dealer can now be found out in a decentralized manner the use of DEXT

DEXT Compared to Other Diagnostic Data Formats
DEXT was initially published with AUTOSAR 4.2.1. In the early stage, the description of the data transported using UDS and the UDS fault memory were standardized. AUTOSAR 4.3.0 added corresponding extensions for OBD-II, WWH-OBD, FIM (AUTOSAR Function Inhibition Manager) and SAE J1939. Consequently, at this level of content, DEXT covers the configuration of all basic software modules for diagnostics that are supported in AUTOSAR. With DEXT, it is possible to describe not only the data transported using the respective protocol, but also the origin of the data in the ECU’s application software. Only if both types of information are available it is possible to fully configure the diagnostic basic software. The diagnostic protocol and, in particular, the description of the diagnostic services and data transfer on the network, are not described. On the other hand, ODX has established itself as the data format for generic diagnostic testers. ODX describes the diagnostic protocol as well as the data transported between the ECU and the tester, together with the way this data is interpreted in a diagnostic tester. The source of the data in the ECU is of no importance for its processing in the tester and is therefore not specified in ODX. Despite this, ODX might be used as initial configuration input, primarily describing the existence and structure of the diagnostic data on the network. However, the diagnostic data must be linked to the ECU application either manually, or by means of special process steps. The information gap between ODX and ECU software is at its greatest when it comes to the description of the fault memory. For example, the debouncing or displacement algorithms used for error detection are of fundamental importance for the basic software, whereas this information is completely lacking in ODX. To some extent, the huge differences between the vehicle manufacturers’ ODX authoring guidelines further complicate the possibility of exchanging ECU configurations. In practice, processes that use the AUTOSAR-ECUC format for data exchange and initial data in the basic software rarely reach their goal. The ECUC format changes frequently and is adapted with every new version of the standard. Primarily it is designed as an input format for the embedded software code generators. ECUC also permits manufacturer-specific extensions, thus making unsuitable as a neutral exchange format.

Figure 1: Elements of the AUTOSAR Diagnostic Extract

AUTOSAR DEXT has been mainly designed to meet the necessities concerning input statistics of the simple software program.
The main elements are (Figure 1):

Selection of the diagnostic services and associated
subservices for UDS, OBD, WWH-OBD and J1939
Fault path and fault memory
Diagnostic data elements and the associated packaging
Mapping of the diagnostic data elements to the application software
Function-inhibition (FiM)
The example below illustrates the advantages of the AUTOSAR Diagnostic Extract based on a Data Identifier (DID). The AUTOSAR metamodel formally defines how a DID should be modeled. Unlike in ODX, there is no freedom of interpretation here and therefore also no risk of misunderstandings during data exchange between tools. The existence of a DID is specified by the instance of a Diagnostic Data Identifier. This instance contains the 16-bit number of the DID which is required for UDS. In addition, this instance aggregates one or more data elements, with the name and type of the DID data being defined. For the purposes of data type modeling, AUTOSAR reuses the preexisting system template metamodel. The DID itself can be used in a diagnostic service by the service instances Diagnostic ReadDataBy Identifier, Diagnostic
WriteDataBy Identifier or DiagnosticIOControl by means of a reference to the Diagnostic DataIdentifier. This is all what is needed to define the configuration of a DID in the diagnostic basic software (BSW). However, the basic software must still interact with the application software in order to read, write, or overwrite the DID. That is why DEXT contains an additional element: diagnostic mapping. It describes the connections between the diagnostic elements in the basic software, such as routines,
DID data, events, and the software components (SWCs) of the application layer. To this end, the interfaces of the software components must be suitably modeled in a way that adheres to a modeling pattern defined in AUTOSAR. Various communication patterns exist to access a function call on a client/server interface or read/write data via a sender/receiver interface. In the past, integrators had to manually configure thousands of connections of this type between the ports in the basic software and the application software. When DEXT is used, this operation can be automated and performed at the OEM/Tier 1 supplier. Integrators take over the mapping rather than having to generate it manually themselves for a large number of different connections. This reduces the probability of error, while simultaneously saving time and increasing quality

Scenarios and Roles in Distributed Diagnostic Development
Currently, there are considerable differences between the diagnostic development processes that are used today. In addition to the tools and their exchange formats, there are major differences in the contribution of OEM and TIER1. In practice, all the possible variants can be found: from end-to-end design by the OEM through combined diagnostic development by the OEM and Tier 1 supplier and on to complete development performed exclusively by the Tier 1 supplier.
Table a provides an overview of typical diagnostic processes.

Table a: Diagnostic processes among the OEM and Tier 1 supplier

This topic will be try to explain more in the next part

Thank you