AUTOSAR

I wrote the configuration code for Dsd. The corresponding security level and session entity are in Dsp and only referenced from Dsd.

Dsd is a sub-module whose purpose is to distribute to each service. At the same time, it also determines the security level and sessions to be supported. For the above purposes, it has the following configuration parameters Existing service definition. Support service definition. Definition of the security level and sessions that the service can support.

I wrote the code for the Dsl structure definition. The end of the list is when Arc_EOL is TURE. ArcCore (OpenSAR) proprietary specification. Callback functions can be defined to trigger diagnostic service start/stop, valid service request, and session transition.

Dsl (Diagnostic Session Layer) is Session related sub-module. It manages P2 time, P2* time, S3 time, etc. It also contains the PudId of CanTp that is actually used.

The content of AUTOSAR-Dcm structure consists of dsl, dsd, and dsp. Some are const defined and some are defined by variables for work. There are about 50 structures for configuration in total.

Review of AUTOSAR-Dcm interface functions. I implemented the interface functions of AUTOSAR-Dcm.

The interface specification of AUTOSAR-Dcm is figured out. The buffers for communication are managed by AUTOSAR-Dcm, which is a memory-saving and copy-saving design implementation. AUTOSAR-Dcm consists of three sub-modules. dsl: Diagnostic Session Layer. dsd: Diagnostic Service Dispatcher. dsp: Diagnostic Service Processing.

Check AUTOSAR-Dcm specification (r3.3). Check AUTOSAR-Dcm interface. NRC$78 is just SingleFrame as AUTOSAR-CanTp.

AUTOSAR-Dcm simulation configuration review. Review of services used in AUTOSAR-Dcm simulation. Listed specific items to be checked. Will also include confirmation of responsePendingCount, the number of times NRC$78 replies are received.