Click here for back issues.
https://www.simulationroom999.com/blog/diagnostic-communication-en-back-issue/
Introduction.
Let’s simulate ISO-TP. series.
In this issue, I will explain the configuration details of CanTp.
Specification for AUTOSAR-CanTp configuration
We will now go into the details of the AUTOSAR-CanTp configuration.
This can also be done by looking at the AUTOSAR-CanTp specification…
AUTOSAR_SWS_CANTransportLaye r4.3
Again, let’s pull out the specifications that seem pertinent.
Requirement No. | Requirement | Summary |
---|---|---|
[SWS_CanTp_00035] | A CAN NSduId shall only be linked to one CAN LSduId that is used to transmit SF, FF, FC and CF frames. | The point is to determine the CANID to be used in the SF/FF/FC/CF frame. In fact, it is one transaction for sending/receiving, so as a result, communication is not possible without two NSduId’s. It is similar to USB endpoints. |
[SWS_CanTp_00122] | Each connection channel is independent of the other connection channels. This means that a connection channel uses its own resources, such as internal buffer, timer, or state machine. | A channel does not depend on other channels. Incidentally, a channel encompasses resources such as buffers, timers, state machines, etc. Similar to USBpipe and TCPsocket. |
[SWS_CanTp_00340] | Data structure type for the post-build configuration parameters. | The configuration definition should be a post-build parameter. It does not need to be embedded as code and may be embedded. |
Well, you don’t know what I am talking about with all this.
More simply put, there is
- There is the concept of channels.
- It must have a structure to manage internal state transitions, etc.
- The configuration definition can be parameters to be determined after the build.
The specifics are described in the AUTOSAR_SWS_CANTransportLayer.pdf in section 10.2 Containers and configuration parameters and thereafter.
(Again, many will despair…)
Configuration structure of AUTOSAR-CanTp
This is a quick way to get a full picture by looking at the figure.
It is not described in the AUTOSAR specification, but the figure looks like this.
You may have seen this diagram and thought it looks like UML.
That’s exactly right, and the AUTOSAR specification is also supposed to describe the configuration structure in UML.
But for some reason, only CanTp does not show such a representation.
I am guessing…
AUTOSAR’s predecessor is called OSEK.
OSEK (Offene Systeme und deren Schnittstellen für die Elektronik in Kraftfahrzeugen; English: “Open Systems and their Interfaces for the Electronics in Motor Vehicles”) is a standards body that has produced specifications for an embedded operating system, a communications stack, and a network management protocol for automotive embedded systems.It has produced related specifications, namely AUTOSAR. OSEK was designed to provide a reliable standard software architecture for the various electronic control units (ECUs) throughout a car.
Wikipedia(https://en.wikipedia.org/wiki/OSEK)
It seems that CanTp is following the same specifications that have been in place since this OSEK era.
Therefore, it may be left as it is because it can be used as it is.
I think the priority is lowered because of the priority of the work to create the standard specifications and because it is OK to leave the proven ones as they are.
We can’t start complaining here, so we’ll just have to accept this fact.
Regarding the actual configuration work
Normally, we would have used a configurator, but this time, since we have forced to pull out only CanTp, we will have to define the actual state of the structure manually.
It’s not that complicated, so I’ll try to write about it in the next article.
Conclusion.
- The configuration structure of CanTp is described in the AUTOSAR specification.
- However, there is no UML description.
- The update priority may have been lowered since it has been followed since the OSEK era.
- This time, we will define the corresponding structure entity manually without using a configurator.
Click here for back issues.
コメント