Hello Readers,
My name is Sharana basava, and I work as a junior software engineer at Luxoft India. I'm happy to share this post, in which I relate my previous experience with Autosar diagnostics and Memory Stack.
Introduction about Autosar - The number of ECUs has been increasing for body, transmission, chassis, and information domains because many drivers want to have safe assistance and convenience system. And software development for automotive applications has become increasingly important. Currently, software controls a large number of functions that make use of linked networks. it is interaction of those functions that contribute to an increasing complexity, and that requires a standard, controlled software environment. Autosar (AUTomotive open system architecture) is a standardized and open software architecture for automotive ECU(Electronic Control Unit). Autosar is a cooperation of automotive manufactures, automotive suppliers, tool vendors and semiconductors vendors. The autosar development partnership is focused on managing the growing complexity in the development of automotive electric/electronic (E/E) architectures.
Diagnostics in autosar- Diagnostics is a key feature for all high-end vehicles. It provides a very user-friendly approach to find and analyze faults in the vehicle. It makes fault detection and correction very simple and precise. It even finds the possible cause of fault. Thus, provides precaution that need to be checked and fixed otherwise the same fault may occur again. Automotive Open System Architecture (AUTOSAR) consortium has specified UDS 14229 specification for development of diagnostic services in automobile. The specification has been designed in order to define common requirements for diagnostic systems in automotive industry, irrespective of the (serial) data link. ISO 14229-1 is a standard protocol for diagnostic services which specifies data link independent requirements of diagnostic services. It allows a diagnostic tester/client to control diagnostic functions in an on-vehicle ECUs/server such as an electronic fuel injection, automatic gear box, etc connected to a serial data link embedded in a vehicle. It describes different diagnostic services that can be used by application developer for diagnostic tools.
CLASSIC AUTOSAR DIAGNOSTICS
In classic AUTOSAR the diagnostic function is implemented through three different modules i.e., DCM, Diagnostics Event Manager (DEM) and Function Inhibition Manager (FIM). The DCM is responsible for UDS message request reception, processing and response transmission regarding diagnostic request from tester/client. The DEM monitor and log the events/faults in vehicle for diagnostic parameters. The FIM disable the functionality after receiving status from the DEM regarding the respective functionality.
A. Diagnostic Communication Manager
The DCM module provides functionality to manage communication between DEM and application/RTE to get diagnostic data or to execute diagnostic service for the tester/client/application. The functionality of the DCM module is used by external diagnostic tools during the development, manufacturing or service phase of the automobile [10]. It ensures diagnostic data flow and manages the diagnostic state, like diagnostic sessions and security state. Furthermore, it checks if the diagnostic service request is supported and whether the service may be executed in the current session according to the diagnostic states. It is network-independent as all the specifics of network viz CAN [17], FlexRay [18], Ethernet [19], LIN or MOST. It is handled outside of the Dcm module in the Protocol data unit router (PduR) [20]. Thus PduR module provides a network-independent interface to the DCM module for execution of UDS messages.
B. Diagnostic Event Manager
The DEM is responsible for processing and storing diagnostic events (errors) and associated data in vehicle. Further, it provides fault information to the DCM regarding all stored diagnostic trouble code (DTCs) from the event memory. It also offers interfaces to the application layer and to other basic software (BSW) modules. Thus, it handles and stores the events detected by diagnostic monitors in both, Software Components (SW-Cs) and BSW modules of the classic AUTOSAR platform.
Memory stack- The main purpose of NvM (Non-volatile Memory Manager) module is to read/write data from/to non-volatile memory by memory block Id. NvM module can receive error information of each module from Diagnostic Event Manager (Dem) module and write it to non-volatile memory. And NvM module can read the error information from non-volatile memory and send it to Dem module. But it is impossible for NvM module to read/write data from/to non-volatile memory.
In AUTOSAR layered software architecture there is memory cluster for two types of Flash and EEPROM memory respectively. Memory cluster can be used to abstract from memory hardware components and provide standardized access to internal/external non-volatile memory. AUTOSAR Memory cluster consists of NvM, MemIf (Memory Abstraction Interface), Ea (EEPROM Abstraction), Fee (Flash EEPROM Emulation), Fls (Flash Device Driver), and Eep (EEPROM Device Driver. In case of current AUTOSAR memory cluster, there are some restrictions. Previous structure can read/write only data of non-volatile memory but it can't read/write data of volatile memory. And previous structure can read/write only data by
only memory block id but it can't read/write data by specific memory address.
Top comments (0)