ECU hardware needs to be tested to ensure safety of the vehicle and consequently ensure compliance to ISO26262. These tests are comparable with the power on self test (POST) which we have in our PCs. However unlike POST HW tests in AUTOSAR can run in startup, normal execution or shutdown and they can run in foreground as well as in background. Below is a general description of functionality of the Tests , the test methodology vary from HW to HW.
CoreTst: The general objective of test by software is to detect failures in processing units which lead to incorrect results. Core Test performs test by software of processing units during micro-controller start-up and run-time.It is located in the MCAL Layer. The Core Test Driver provides several tests to verify dedicated core functionality like e.g. general purpose registers or Arithmetical and Logical Unit (ALU). Core Test reports errors in dedicated memory and bus interfaces (e.g. Tightly Coupled Memories, caches, systems bus) and dedicated supporting functionality (e.g. interrupt controller) to the diagnostic event manager (DEM) as production errors. Errors inside the CPU (e.g. ALU, Prefetch queue, registers) cannot be reliably reported to DEM, as these faults affect the correct operation of the Core itself
RAMTst: The general objective of RAM Test is to detect permanent failures which can cause corruption in the volatile memory. The RAM Test driver performs a test of the physical health of the RAM cells, it is not intended to test the contents of the RAM. Furthermore, RAM used for registers is also tested. Different algorithms exist to test RAM. They target different sets of fault models, achieve different coverages, result in different run-times and are either destructive or non-destructive. Coverage also depends on the underlying physical RAM architecture. An ECU safety analysis must be performed to determine which RAM Test diagnostic coverage rate (Low, Medium or High) is required. Appropriate RAM Test algorithms and further configuration parameters are then selected at compile time. At run time, the application software may choose between the compiled algorithms (and between further parameters). The RAM Test driver supports synchronous test methods called “foreground test” and asynchronous tests called “background test”. During the execution of a RAM test algorithm, no other software shall be allowed to modify the RAM area under test. RAM Test reports errors to the diagnostic event manager (DEM) as production errors
FlsTst: This Flash test module provides algorithm to test invariable memory. Invariable memory can be data/program flash, program SRAM, locked cache and is either embedded in the micro-controller or memory mapped connected to the micro-controller. The test service can be executed at any time after MCU initialization and it is up to the user of the Flash Test Driver to choose the suitable test algorithm and the right execution place to fulfill the safety requirements of the system. The test service itself is dependent on the storage concept of the system. Therefore, the availability of different test algorithms is configurable
Posts
I heard in modern automotive controller , controller itself do functional safety features . Any idea about that?
ReplyDelete