What Is an ECU Message? Identifiers, Broadcast and Interpretation
An ECU message is a packet of data that an electronic control unit places on a vehicle network so other modules can use it. Engine speed, wheel speed, gear position, door status and warning-lamp requests all travel this way. On most modern cars the network carrying these messages is Controller Area Network (CAN), though other buses exist. Understanding a car ECU data message comes down to three ideas: how it is identified, how it is broadcast, and how its bytes are turned into meaning.
Identifiers
On a CAN bus, every message frame begins with an identifier. Classic CAN supports two formats: a standard 11-bit identifier, which allows 2,048 distinct values, and an extended 29-bit identifier for networks that need many more. The identifier describes the content of the message rather than the address of a recipient. A frame with a particular identifier carries the same kind of information each time it appears, such as a group of engine-related values, and in a properly designed network only one ECU is supposed to transmit a given identifier during normal operation.
The identifier also sets priority. When two ECUs begin transmitting at the same instant, CAN resolves the conflict bit by bit. A dominant bit (logical 0) overrides a recessive bit (logical 1), so the frame with the numerically lower identifier wins arbitration and continues, while the other controller stops and retries once the bus is free. Because the winning frame is not damaged, no time is lost to collisions. This is why network designers commonly assign lower identifiers to data that is time-critical or safety-relevant.
Some protocols add structure to the identifier. SAE J1939, widely used in heavy trucks and buses, splits the 29-bit identifier into a priority field, a parameter group number that describes the content, and a source address that names the sender. Diagnostics over CAN, defined in ISO 15765-4, reserves specific identifiers for scan-tool traffic; in the 11-bit scheme, 0x7DF is the functional request and 0x7E8 through 0x7EF carry ECU responses. Outside such standards, the identifiers used for normal passenger-car traffic are chosen by each manufacturer.
Broadcast
CAN is a broadcast network. Every frame placed on the bus reaches every node connected to that segment, and normal traffic has no destination field. Each ECU decides for itself whether a message matters, usually through acceptance filters in its CAN controller that pass only the identifiers it has been configured to use. A transmission controller, for example, may consume engine torque and accelerator data while ignoring climate-control traffic that crosses the same wires.
Messages are sent on different schedules. Many are cyclic, repeated at fixed intervals whether or not the values have changed. Others are event-driven, sent when something happens, such as a switch being pressed, and some combine both approaches. Cyclic transmission lets receivers notice when a sender goes silent: if an expected message stops arriving within its timeout, the receiving ECU can record a communication fault, which is the origin of many lost-communication U-codes. The acknowledgment bit in each frame only confirms that at least one node received it correctly, not that the intended consumer acted on it.
Most vehicles contain several networks running at different speeds, often grouped by function, and joined by a gateway module. The gateway forwards selected messages between segments, so a given message may appear on one bus but not on another. Diagnostic communication is layered on top of this broadcast medium as a request-and-response exchange: a scan tool sends a request, and the addressed ECU or ECUs reply using their assigned response identifiers.
Interpretation
A raw frame consists of the identifier, a data length code, and a data field of up to 8 bytes in classic CAN or up to 64 bytes in CAN FD. The bytes themselves carry no units or labels. A single frame usually packs several signals, each defined by a start bit and a bit length. One value might occupy 12 bits spread across two bytes, while a neighboring signal is a single bit acting as an on/off flag.
Turning raw bits into a physical value requires a definition for each signal: byte order (little-endian, often called Intel, or big-endian, often called Motorola), whether the value is signed, a scale factor and an offset, and the valid range. The physical value is typically the raw number multiplied by the factor plus the offset. Certain raw values may be reserved to mean not available or error. Manufacturers keep these definitions in network database files, commonly in the DBC format, and they are generally proprietary. Definitions shared by enthusiasts are usually reverse-engineered and therefore inferred rather than confirmed.
Standardized data is the exception. The emissions-related parameters requested through OBD-II service 01 are defined in SAE J1979, so their meaning is the same across compliant vehicles. Engine speed, for instance, is returned as two bytes, A and B, and calculated as (256 × A + B) ÷ 4 to give revolutions per minute. Many proprietary messages also include a rolling counter and a checksum, which receivers use to detect stale, repeated or corrupted data.
Practical implications and limits
For most owners, the accessible window into ECU messages is the OBD-II diagnostic connector. Generic scan tools rely on standardized diagnostic requests, so they show a defined set of emissions-related data on any compliant vehicle. Manufacturer-level tools can display much more because they know proprietary diagnostic services and message definitions. A generic tool that shows only limited data does not mean the vehicle lacks other information.
Passive logging of raw traffic is possible on some vehicles, but whether normal network traffic is visible at the connector depends on the electrical architecture. Many newer designs place a gateway between the diagnostic port and internal buses and pass only diagnostic communication. Identifiers, signal layouts and scaling can also change between model years, markets, trim levels and even software updates, so a definition verified on one vehicle should not be assumed to apply to another.
Reading messages and sending them are very different activities. Injecting frames can conflict with a legitimate ECU, set fault codes, or alter the behavior of systems such as braking, steering or driver assistance, and some vehicles authenticate messages to reject unexpected senders. CAN is also not the only bus in use: LIN serves low-speed body functions, while FlexRay and automotive Ethernet appear in some architectures, each with its own frame format. For diagnosis and repair, the manufacturer's service information remains the authoritative reference for a specific vehicle.