Search code examples
drivercan-busautosarcommunication-protocol

AUTOSAR CAN Stack Implementation Hints

My task is to create a software stack for a CAN module using the latest release of AUTOSAR (R19-11). I will not be using any configuration tools. From what I've read on the AUTOSAR website, these are the modules that I have to implement: CAN Driver, Interface, State Manager, PDU Router and AUTOSAR COM. Since I'm not going to use frames which have more than 8 bytes of data, I won't need the CAN Transport Protocol module.

When sending PDUs down the stack, some modules add metadata to these received PDUs (which are called SDUs locally), and then send them to the next layer. I've read that we must allocate unique IDs to these PDUs. Also, we must have a routing table (inside the PDU Router) which will be used to determine the destination of every PDU based on their IDs.

My questions are:

  • How are IDs assigned?
  • What would an ID look like?
  • For a given CAN frame, do I have to allocate a different ID based on a PDU's current location in the stack? (COM, State Manager, Interface or Driver)
  • Knowing that a user (the Application layer) can define an arbitrary number of CAN frames, how does the PDU Router know beforehand what a certain PDU's ID and what it's destination would be?
  • What would a message transmission (or reception) look like, starting from the Application layer and ending at the CAN Driver module?
  • What metadata (or PCI - Protocol Control Information, as it is called in AUTOSAR) will be added by the modules which are receiving a PDU? For example: The application sends data 0xAA. COM receives this PDU and adds a specific PCI, then sends it down to PDU Router and so on. What would the SDU + PCI = PDU look like at each stage?
Solution

  • Actually, the advantage of configuration tools in AUTOSAR is, that you do not have to fiddle around in the code and its configuration by hand all the time.

    Well, not implementing CanTp means too, you do not have customer diagnostics (UDS)? And btw., CAN-FD has frames up to 64 bytes.

    The definition of the PduIdType is in AUTOSAR_SWS_CommunicationStackTypes Ch. 8.1.1. SWS_COMTYPE_00005, SWS_COMTYPE_00006, SWS_COMTYPE_00007, SWS_COMTYPE_00014.

    In short, they are unsigned integers, zero-based and consecutive in order to be used as config index into the modules configuration. And they are created for each BSW module, so you have a set of CanIf-PduIds, PduR-PduIds, IpduM-PduIds, Com-PduIds, SecOC-PduIds, and they could also be split between Rx and Tx (so a set of RxPduIds starting at 0, and set of TxPduIds starting also at 0). So, a CanFrames PDU can have different PDU-IDs in CanIf, PduR, Com, etc. and multiplexed Frames are split into separate PDUs with different PduIds for each multiplexer.

    Another chapter to read about it is the AUTOSAR_TPS_EcuConfiguration Ch. 3.4 COM-Stack configuration.

    It contains the Concept of Handle-IDs, their definition, assignment, even naming convention and some use-cases.