-
Notifications
You must be signed in to change notification settings - Fork 71
8. Frames and Addressing
CANbus addressing is a confusing subject. We'll limit ourselves in this chapter to schemes used in ZOE (as far as we know), knowing there are more high level protocols in use in the real world. Also, we will not discuss the physical and DLC layer of CANbus, as this is always taken care of by the hardware controllers.
Frames are the basic units of transmission on the CANbus. It can transport a payload of 0-8 data bytes, independent of the Frame Format described below. Higher level protocols can use one or two of those data bytes for encapsulation or additional addressing, making the actual maximum size discussion possibly vague, but at the frame level it is 0-8. Note that in the CanZE code we do not strictly adhere to the Frame nomenclature when exchanging ISO-TP messages. We might need to clean this up later.
CANbus denotes two frame formats, which can co-exist and does on the same physical CANbus.
This is described in CAN 2.0 A and CAN 2.0 B. This is the format using an 11 bit identifier (0x000 - 0x7ff). IDs in this format are sometimes called "legislative identifiers". This format is the only one used in ZOE Ph1.
This is described only by CAN 2.0 B). This is the format using a 29 bit identifier (0x00000000 - 1fffffff). IDs in this format are sometimes called "extended identifiers". This format is used by some ECUs in ZOE Ph2.
Note that the term "extended" is used in this Frame Format context simply as operating in 29 bits ID mode. Unfortunatelu, in the CANbus world, the term "extended" has a different meaning in different contexts.
CANbus denotes 4 different frame types: Data frame, Remote frame, Error frame and Overload frame. In this document we will only reference the Data frame type and thus this is assumed implicitly.
We use the term Message here loosely as an array of bytes of arbitrary length that needs to be transported from one device on the CANbus to another. Two types of messages exists. Again, in the CanZE source code the Message class has a slightly different meaning.
These messages are only visible in Ph1 ZOE cars and therefor by definition of the base format type. In Ph2, the Security Gateway hides these messages. It's a pure single frame oriented message where control data is packed in a 64 bit frame. There is no flow control, error correction beyond the DLL level, and no implicit meaning. In ZOE, the type of message is completely defined by it's 11 bit ID, and the ID is always smaller than 0x700. Since CANbus in itself is a broadcast network without concepts as "source" and "destination", the ID's should really be read as such: it defines the meaning of the packet. For example, in a frame with ID 0x1f6, the meaning of bits 19-20 show if the brake pedal is pressed. Note that an ID does not define the sending ECU: though a specific ID is always send by the same ECU, that single ECU can and usually does transmit several different IDs.
Pure CANbus messages are usually associated as direct control and can in that sense be regarded as replacement of actual elaborate wiring.
ISO-TP is a higher level protocol (HLP) with it's main function being the transmission of longer messages than the CANbus limitation of 8 bytes. ISO-TP defines how a message should be dis(assembled) to fit CANbus frames and how those frames should be sequenced. In addition, it provides a flow control mechanism and defines several addressing modes, expanding on the concept of the 11 and 29 bit IDs frame formats.
ISO-TP messages are usually associated with diagnostics. Many higher level protocols exist which we will not delve into here. While ISO-TP is not a connection type protocol, it's mostly used in "request - response" type of communication and we use it extensively in CanZE to query data from ECUs.
ISO-TP defines 5 different addressing modes, of which ZOE uses two visibly, depending on the model. When speaking of the ID of a message, it is exactly the same as the ID of the lower protocol frames. Note that some of the modes not mentioned here use the "extended" nomenclature. This is not the same as using the extended frame format and is actually allowed in both.
In normal addressing, the ID of the messages is used exclusively as "source" or "destination" and a single ECU therefor is associated with two IDs. Normal Addressing can be used in either 11 or 29 Frame formats. In ZOE, normal addressing IDs are 11 bits only and have an ID between 0x700 and 0x7ff.
An example is Climate Control ECU, 764 (from) and 744 (to) for both Ph1 and Ph2.
Normal fixed Addressing is only possible in 29 bit Frame Format. Like normal addressing the ID of the message can be regarded as a simple "source" or destination. However, in this mode, the ID is divided into three groups with a specific meaning.
- bits 28-16: fixed 0x18DA for one-to-one communication (other values have different meanings but are not used in ZOE Ph2)
- bits 15-8: target or destination address
- bits 7-0: source address
An example is the LBC in Ph2: 18DAF1DB (from) and 18DADBF1 (to). F1 is the tester/CanZE, DB the LBC.
https://en.wikipedia.org/wiki/CAN_bus https://can-isotp.readthedocs.io/en/latest/isotp/addressing.html