Diagnostic Fault Injection for Coverage Testing AUTOSAR Components
The AUTOSAR standard defines Basic Software (BSW) services that run in the AUTOSAR run-time environment. The services include Diagnostic Event Manager (Dem), Function Inhibition Manager (FiM), and NVRAM Manager (NvM) services. In the AUTOSAR run-time environment, AUTOSAR software components typically access BSW services using client-server or sender-receiver communication.
Learn about a function inhibition integration model, which integrates two sensor components, a monitor component, and an operation cycle component. The sensor components call BSW FiM and Dem (and NvM) services, the monitor component calls BSW FiM and Dem services, and the operation cycle component calls a BSW Dem service. Then learn how AUTOSAR diagnostic faults can be defined in a test harness to better simulate and verify component models using basic software services.
Published: 26 Oct 2022
JAMES RICHMOND: Hi, I'm James. Today I'm going to show you how you can use diagnostic fault injection as a tool for gaining coverage on AUTOSAR components, which are making calls into basic software. The model I'm going to show you today is an example above. I can find that by opening the Simulink start page, click on the Examples tab, and find the AUTOSAR Blockset examples. We have a fair few, so I'll open them all in documentation.
I can scroll down the list to the basic software examples. This is the one that I'm looking for. This is a throttle position monitor component. It takes input from a primary and secondary sensor. There were four calls into basic software, two for each sensor to see if each sensor is stuck too high or stock too low.
If the primary sensor is failing, we switch to the secondary sensor. If both of the sensors are failing, we use another caller to report a more general failure for this component. And the component itself outputs the default value. In order to check the coverage of this component, I can use the Coverage Analyzer app. I can enable the tool and Simulink to analyze the coverage.
We can see here, we don't have full coverage yet. This is due to the basic software callers, which currently output default values. This is my test harness model. The component we looked at before is in the top right. I have an AUTOSAR diagnostic service component block, which shows those five basic software client ports, which I have associated with unique IDs.
We can focus on the first one. Here, I have a Dem Status Override block, also provided by AUTOSAR Blockset, which is associated with that same event ID. I'm using it to override the test failed bit with the value provided by an input port signal. This is the one which the getFailed caller block in the component model is monitoring. I also have control over the other bits of the UDS status by if I want to enhance my simulation in future.
I've set up some test conditions to permeate through the true and false values for these four callers to gain full coverage. Now I can run coverage analysis again with these permeated conditions. And I can see I have full coverage of my component.
So that's a review of how to gain coverage on an AUTOSAR component which is making basic software calls by overwriting bits of the UDS status. You can find more information about this example in our documentation. Thanks for listening.