How to use Manufacturer permission and Supplier permission for verification of a diagnostic request in Vector stack.

As per the Autosar_SWS_DCM

All received requests must go through these verification's before it is accepted by the DSD. Manufacturer permission and Supplier permission provide the option of adding runnables or callouts for the request Indication and Confirmation. This allows the user to plug in code that get executed before and after the request has been received and processed. This is what a typical verification sequence would look like with Manufacturer and Supplier Indications and Confirmations are enabled

This leads us to some of the question that I have tried answering below,

Q: What is the execution flow when the MI verification has failed?

Request will be rejected before the DCM internal verification is done. A negative response can be sent, or the request can be rejected without sending any response. In this case neither of the SI will be invoked and nor the DCM internal verification. But, on the way back MC will be triggered.

Q: What is the execution flow when the SI verification has failed?

Request has already gone through MI and internal verification within DCM and has now reached the SI for verification. If it gets rejected by the SI it can send a negative response or not send any response to the service request. The request will not reach DSD. On the way back, the SC and then MC will be triggered.

Q: Will the MC & SC execute if the request has been rejected by the MI, SI or the internal verification within DCM?

Yes. It will still be called. The Confirmation call is triggered to notify that the execution of the service has been completed. Whether only the MC will be triggered or both MC and SC will be triggered depends on the whether the request was accepted by the DCM internal verification. If the request had cleared the internal checks then both SC and MC will be triggered, else only the MC.

For example, let’s say the request received had an invalid SID. This request will be rejected after the internal verification of DCM. The response to this will be NRC SNS 0x11. The sequence of calls will be MI — DCM Internal checks — MC. In this case SI and SC will not be triggered.

How do we use this?

Case 1: Verify that the vehicle is parked and not moving before any DID can be written.

This check should be performed after the request has been verified for its SID, Session and Security Level. The check for vehicle speed or gear position to determine that the vehicle is stationary can be added to SI. Only when the SI has cleared the request, it will be processed else it will be rejected and on it way back SC and MC will be triggered.

Case 2: When a request to jump to boot is received, applications need to set some flags in the No-Init Ram Section or in the Reset Register etc. At first glance, this step can be added to either of the Supplier notifications or even the Manufacturer notifications and be done with it. This is not the case when you investigate different aspects of the problem.

1. Let’s say the request was a valid one and it has passed all the checks of DCM. In that case the typical call sequence would be MI — DCM — SI — DSD — SC — MC.
2. Let’s assume the request has been rejected by DSD, in this case should the flag be set? Definitely no. Now, if the operation of setting the flags was done in SI, the flag would have been set without considering whether the request has been finally accepted or not. To avoid this, we make use of the SC. In SC we have the information to make that decision. In Vector DCM stack, the Confirmation prototype provides parameter Dcm_ConfirmationStatusType. This tells you if the response to the request was positive or negative and even if that response was sent out successfully or not.
   DCM_RES_POS_OK (0U)
   DCM_RES_POS_NOT_OK (1U)
   DCM_RES_NEG_OK (2U)
   DCM_RES_NEG_NOT_OK (3U)

How do I use this in my project?

Using this is simple. All you need is to

1. Enable the ManufacturerNotification and SupplierNotification in DcmGeneral.
2. Create Runnables in the DCM SWC
3. Set the triggers for these runnables as ServiceRequestNotification & ServiceRequestManufacturerNotification.
4. Make sure the ports between DCM Service Component and Application component are connected.
5. Write your checks in the runnables and you are good to go.