[Dcm] Vehicle Diagnostic Communication Part 77 [Simulation 16]

Check the results of the SecurityAccess simulation. Check the message level. Check the CAN line level. SecurityAccess behavior depends on session state and security state. SecurityAccess behavior depends on session state, security state, and S3 timeout.

[Dcm] Vehicle Diagnostic Communication Part 76 [Simulation 15]

I wrote Python code for the SecurityAccess simulation. There is a large amount of work to be done to make sure SecurityAccess works. Support sessions. Sequence. Seed in security unlocked state. Transition to locked state on session transition. Session transitions due to S3 timeouts.

[Dcm] Vehicle Diagnostic Communication Part 75 [Simulation 14]

Check the results of the DiagnosticSessionControl simulation. Confirmation of message level. Confirmation of CAN line level. NegativeResponse can be automatically determined and returned by Dcm or by adding your own code. Message length and parameter abnormality are judged automatically. Rejections due to vehicle status are returned with an original code.

[Dcm] Vehicle Diagnostic Communication Part 74 [Simulation 13]

I wrote a Python code for simulation of DiagnosticSessionControl. Communication patterns include error patterns. Non-existent session. Wrong message length for a DiagnosticSessionControl request.

[Dcm] Vehicle Diagnostic Communication Part 73 [Simulation 12]

Review of AUTOSAR Dcm simulation configuration The Python code on the off-board tester side is the same as we have used so far. Modifications will be made as needed. The order in which the simulations are run is as follows. DiagnosticSessionControl. SecurityAccess. TesterPresent. ReadDataByIdentifier. WriteDataByIdentifier.

[Dcm] Vehicle Diagnostic Communication Part 72 [Simulation 11]

I wrote the configuration code for Dsp. Mostly security, session definition and association with DID.

[Dcm] Vehicle Diagnostic Communication Part 71 [Simulation 10]

Dsp is the application layer. It is divided into ISO14229-1 dependent and manufacturer dependent, and manufacturer dependent is handled by callback functions. The DID-related part of Dsp is the most complicated. Once you know DID, other configurations are relatively easy.

[Dcm] Vehicle Diagnostic Communication Part 70 [Simulation 9]

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

[Dcm] Vehicle Diagnostic Communication Part 69 [Simulation 8]

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.

[Dcm] Vehicle Diagnostic Communication Part 68 [Simulation 7]

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.

[Dcm] Vehicle Diagnostic Communication Part 67 [Simulation 6]

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.

[Dcm] Vehicle Diagnostic Communication Part 66 [Simulation 5]

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.

[Dcm] Vehicle Diagnostic Communication Part 65 [Simulation 4]

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

[Dcm] Vehicle Diagnostic Communication Part 64 [Simulation 3]

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.

【振り返り】ブログ開設三周年記念記事【技術ブログのPV数と収益】

祝3周年。 記事数は1000オーバー。 技術ブログとしてのアクセス数と収益の話。 ここにきて頭打ち。 一応、継続するが振り返りは今回を最後にする予定。

[Dcm] Vehicle Diagnostic Communication Part 63 [Simulation 2]

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

[Dcm] Vehicle Diagnostic Communication Part 62 [Simulation 1]

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.

[DoCAN] Vehicle Diagnostic Communication Part 61 [UDS 22]

The following is an example of a specific transmission/reception of the WriteDataByIdentifier service. I have explained examples of transmission/reception including NRC$78.

[DoCAN] Vehicle Diagnostic Communication Part 60 [UDS 21]

Explanation of the request message for the WriteDataByIdentifier service. Unlike the ReadDataByIdentifier service, one DID is fixed. Explanation of the response message of the WriteDataByIdentifier service. In practice, NRC$78 may be interleaved.

[DoCAN] Vehicle Diagnostic Communication Part 59 [UDS 20]

The WriteDataByIdentifier service has been explained. Usage scenarios. Communication characteristics tied to non-volatile memory.

[DoCAN] Vehicle Diagnostic Communication Part 58 [UDS 19]

Confirmed single DID transmitted and received. Confirmed transmitting and receiving multi-DIDs. Confirmed some DIDs are undefined patterns.

[DoCAN] Vehicle Diagnostic Communication Part 57 [UDS 18]

Explanation of the request message for the ReadDataByIdentifier service. Multiple DIDs can be set. There may be a limit on the number of DIDs that can be set, and it is an error if the number is exceeded. It is also an error if the response message exceeds 4095 bytes. Explanation of the ReadDataByIdentifier service response message Combination of DID and dataRecord. In case of multiple DIDs, the above combination is placed in one message.

[DoCAN] Vehicle Diagnostic Communication Part 56 [UDS 17]

Explanation of the usage scenario of the ReadDataByIdentifier service. Vehicle status monitoring (verification during development, failure analysis after market release). Forced operation status monitoring during vehicle assembly. Freeze data acquisition at the time of failure detection.

[DoCAN] Vehicle Diagnostic Communication Part 55 [UDS 16]

Explanation of the messages of the TesterPresent service. Explanation of suppressPosRspMsgIndicationBit. PositiveResponse suppression. NegativeResponse is returned. PositiveResponse after NRC$78 is also returned.

[DoCAN] Vehicle Diagnostic Communication Part 54 [UDS 15]

There is a service called TesterPresent service that does nothing. The TesterPresent service has the following usage scenarios. Checking for communication. Node presence/absence check. Session maintenance. The TesterPresent service is a service that must be supported.

[DoCAN] Vehicle Diagnostic Communication Part 53 [UDS 14]

Explain the basic flow of the SecurityAccess service. Explain the actual messages in the basic flow of the SecurityAccess service. Security is applied to resources. Service. DID.

[DoCAN] Vehicle Diagnostic Communication Part 52 [UDS 13]

The SecurityAccess service is purposely troublesome procedure, which is the security strength. Must transition to non-defaultSession in advance. Must wait 10 seconds after IGon. If you make a mistake unlocking, you have to IGoff once.

[DoCAN] Vehicle Diagnostic Communication Part 51 [UDS 12]

The SecurityAccess service has two major message patterns. requestSeed. Odd sub-functions. sendKey. Even sub-functions.

[DoCAN] Vehicle Diagnostic Communication Part 50 [UDS 11]

Review of P2 time. P2 time is 1 second Explanation of P2* time P2* time is 5 seconds. When the off-board tester receives NRC$78, it switches from P2 time to P2* time. When the off-board tester receives NRC$78 again, it extends P2* time from there.

[DoCAN] Vehicle Diagnostic Communication Part 49 [UDS 10]

Click here for back issues.Introduction.Explanation of ISO 14229, UDS.I will explain PositiveResponse and NegativeRespon

[DoCAN] Vehicle Diagnostic Communication Part 48 [UDS 9]

Explains the session as defined in the ISO for DiagnosticSessionControl Request message of DiagnosticSessionControl. Response message of DiagnosticSessionControl. P2 time and P2* time of the relevant session can be obtained.