AUTOSAR's fault detection mechanisms and diagnostic tools are essential for the maintenance of high-quality outbound code in either the Classic or Adaptive AUTOSAR platforms. Automotive embedded control unit (ECU) software developers depend on these tools and the quality they help maintain. So do their customers, including the original equipment manufacturers (OEMs) and their suppliers. The people who will drive the vehicles, and the technicians performing maintenance on them, rely not only on the assurance of quality from the AUTOSAR fault detection and diagnostic services, but they also count on the proper containment and communication of errors in the event of an ECU fault.
Diagnostic services also play a large part in keeping the entire vehicle operating optimally. In the old carbureted days of internal combustion engines (ICEs), fault detection was largely limited to tools outside of the vehicle. Diagnostic services were limited entirely to the observational skills of the driver and service technician. Mechanics used anything from their own eyes and ears to pressure gauges, oscilloscopes, and micro-cameras in their efforts to identify and locate errors within a vehicle’s systems. While AUTOSAR’s built-in fault detection and diagnostic toolsets may not make all the older tools obsolete in every diagnostic case, they are certainly a leap forward and help everyone in the supply chain and beyond to keep our modern vehicles well-maintained and functionally safe. These services comprise a comprehensive and standardized toolkit for robust and reliable fault detection in AUTOSAR-compliant ECU software.
Diagnostic data exchange between development partners is often required when building ECU software in AUTOSAR. This presented challenges due to the multiple formats in use, the quantity of data, and the potential for corruption or loss of data. Several tools emerged and were incorporated into the AUTOSAR developer toolset to help address these challenges.
From 2014 on, beginning with the AUTOSAR 4.2.1 revision, developers had a new tool to add to their fault detection stack, called the Diagnostic Extract Template (DEXT). This extraction template allowed data to be easily exchanged across formats without loss of information, making it possible for teams of collaborators to work on vehicle diagnostics development with very high accuracy. This was an important step forward, even allowing the possibility for OEMs to collaborate with suppliers or with one another, to develop new diagnostic tools.
DEXT joined other data exchange formats, most notably the Open Diagnostic eXchange (ODX), built-in and based on the eXtensible Markup Language (XML) and used for diagnostic data. Another heavily used older format was the ECU configuration module (ECUC), which defined parameters for all other Basic Software modules to use.
The Classic and Adaptive platforms handle fault detection and diagnostics in different ways because of their unique architectures, standards, and intended applications. To learn more about the differences between the Classic and Adaptive AUTOSAR platforms, we recommend starting with this LHP blog, entitled “What Is Adaptive AUTOSAR?”. It is important to remember that Adaptive AUTOSAR is not intended to replace the Classic platform; they each have unique strengths and qualities that make them well-suited to building software components for ECUs well into the future.
The AUTOSAR platform was a single entity from its 2002 inception until early 2017, when the AUTOSAR organization produced its second major offering, Adaptive AUTOSAR. With this release, the platform split, and the original iteration continues to exist and receive updates as AUTOSAR Classic. The two platforms operate under different standards and are built on different architectures (signal-level for Classic AUTOSAR, service-oriented for the Adaptive platform).
AUTOSAR Classic is its own robust and vital platform, in use for many ECU applications worldwide. Engine control ECUs in Internal Combustion applications, or an antilock braking system, are examples of very good applications for a Classic AUTOSAR ECU. The Classic platform, though, is not suited to the needs of certain automotive features. Also, it cannot fully take advantage of the newer resources available to developers now.
Adaptive AUTOSAR, however, can take full advantage of such industry-wide improvements as automotive ethernet (higher bandwidth), or multi-core ECU processor units, for example. Because of this, the Adaptive platform is more well-suited to the demands of newer industry-wide features requiring vehicle connectivity or environment sensing, such as the Advanced Driver Assistance Systems (ADAS), where safety-critical actions may be taken by the vehicle.
Since the two platforms are built differently, it makes sense for them to handle fault detection differently, and for their diagnostic services to behave in different ways.
Fault detection recognizes and identifies faults – bad or broken sections within a line or block of code that either provide undesirable instructions or cannot provide any instructions at all – by isolating instances of unusual or unwanted behavior, malfunctions, or loss of function within an ECU. Diagnostics include systematic analytics for identifying faults, maintaining the software, and keeping those instances of unwanted software behavior rooted out. Diagnostic services help developers make coding decisions with the best information about the software’s behavior regarding faults or potential faults. Diagnostics help with early detection of faults before they can cause errant behavior, and with checking for errors in software updates. Newer methods of updating ECU software, like over-the-air (OTA) updates in which large numbers of vehicles can be instantly affected once an update goes live, make early detection of faults more important than ever.
For decades, mechanics and service technicians invested time and effort into building the skills for fault detection before the introduction of ECUs or the AUTOSAR development platform. However, components and systems with diagnostic standards and tools built into their ECUs have been a great help for diagnostic work. In particular, the ease and accuracy of fault reporting that the AUTOSAR diagnostic services provide are a giant step forward in accurately diagnosing, isolating, and solving an ECU fault.
AUTOSAR fault detection and diagnostics tools also assist developers, suppliers, and original equipment manufacturers (OEMS) to remain in continuous compliance with safety and performance regulations. These are separate elements of AUTOSAR design, but their intended functions tend to run together and operate symbiotically. They can monitor the “health” of a particular electronic control unit (ECU), and can also detect and report on faults or errors within the larger overall system of ECUs in place throughout the vehicle.
For AUTOSAR Classic, fault detection is straightforward, as this platform relies exclusively on a central Diagnostic Event Manager (DEM; see Diagnostic Tools, next section). The DEM responds to detected faults in actuators and sensors, including failures within ECUs, and sends the appropriate signals to the Diagnostic Service module with all the information possible about the fault.
Within Adaptive AUTOSAR, the newer platform’s flexibility and dynamic nature lead to a distributed approach over multiple software components rather than an overall diagnostics manager and service module. The individual software components instead monitor their own “health” and perform reporting of detected faults rather than signaling a detected fault’s details to the central DEM.
AUTOSAR’s diagnostic services include a “stack” of built-in tools for monitoring the reliability and fault-free operation of vehicle systems. These tools and services are located within the basic software layer, though they monitor more than basic layer functions only. As an overview, these services include the Diagnostic Communication and Event Managers (DCM and DEM, respectively), for recording internal system errors, setting diagnostic error codes, and communicating between ECUs and external diagnostic tools. Classic AUTOSAR does include subroutines to read and clear trouble codes, perform ECU internal testing, and other functions. Besides these managers and routines, the Classic platform uses a Function Inhibition Manager (FIM) to inhibit, or suppress, particular functions within an ECU’s code if the Event Manager has been signaled that those functions contain errors or failures. When an ECU is still in development, programmers can also use AUTOSAR’s Development Error Tracker (DET) module while initially generating function code to track down bugs and code errors. Finally, the Diagnostic Log and Trace (DLT) service provides a framework for recording and sorting errors into category types.
In Adaptive AUTOSAR, diagnostic services are implemented differently. The diagnostic services present in Classic AUTOSAR still exist in Adaptive, but their implementation and the way they interact with the ECU’s software are different. Just as the fault detection services shifted their focus from a central service in the Classic platform to individual components each handling their own fault detection in the Adaptive platform, the diagnostics tasks are similarly distributed more broadly in Adaptive AUTOSAR.
Additionally, the release of the Service-Oriented Vehicle Diagnostics (SOVD) standard by the Association for Standardization of Automation and Measuring Systems (ASAM) prompted the AUTOSAR organization to publish a technical update for the Adaptive platform, “Explanation of Service-Oriented Vehicle Diagnostics1.” This bulletin gave details on how Adaptive AUTOSAR complied with the SOVD standard and gave guidance for developers for implementing AUTOSAR within the SOVD standard, with some use cases.
Adaptive platform diagnostics are powerful and flexible, and tend to focus on individual software components diagnosing themselves (rather than the centralized and unified diagnostics of Classic AUTOSAR). These factors make Adaptive AUTOSAR’s diagnostics both more powerful than what is allowed in the Classic platform, and somewhat less easy to explain in one sitting because the exact definition tends to vary more case-by-case than in instances of the Classic platform.
The approaches and actual methods of implementation for fault detection and diagnostic services are rather different between Classic and Adaptive AUTOSAR, reflecting changes in both ECU and vehicle-wide hardware, as well as software architecture and the prevailing approach to resource usage. The respective platforms utilize their given resources efficiently to provide robust and reliable error detection and diagnostic reporting for improved ECU software development, more efficient maintenance and repair, and safer operation.
1 AUTOSAR.org, “Explanation of Service-Oriented Vehicle Diagnostics.” November 2023. https://www.autosar.org/fileadmin/standards/R23-11/AP/AUTOSAR_AP_EXP_SOVD.pdf
Felice Ferri: Apr 30, 2024 4:02:22 PM
The Power of Real-Time Alerting Real-time alerting can be thought of as both a concept and a loose set of rules within the discipline of analytics....
Steve Neemeh
