Signals versus services
A CAN signal is broadcast to receivers configured in advance; a service is discovered and called. One example value walked through both, with SOME/IP, DDS and the COVESA Vehicle Signal Specification.
- CAN signals
- SOME/IP
- DDS
- COVESA VSS
A CAN frame is a broadcast. A controller puts a value into a frame, wheel speed say, and sends it. Which other controllers use that value was settled when the system was configured, not while the car runs. AUTOSAR’s Classic Platform is built this way: its ports are signal-oriented and statically configured.
CAN has grown without changing that shape. Classical CAN runs up to 1 Mbit/s. CAN FD lifted the payload past 8 byte to as much as 64, and CAN XL allows a data field of up to 2048 byte.
A service is a different shape. SOME/IP, specified by AUTOSAR, covers remote procedure calls, event notifications and the wire format. A client calls a method and gets a response, or subscribes and is told when something changes. In AUTOSAR Adaptive the client finds the service at runtime instead of being wired to it in advance.
DDS is a third shape. It is a data-centric publish-subscribe model, with quality-of-service settings that govern delivery. The version here is 1.4, from March 2015.
COVESA’s Vehicle Signal Specification sits above all of this. It does not move data; it names it. One tree, rooted at Vehicle, and every signal gets a dotted path. A sensor is read-only, an actuator can be written, and an attribute stays fixed through an ignition cycle.
I have left out the SOME/IP service discovery message format and the DDS wire protocol. I have not read those specifications, and I would rather leave a gap than guess at fields.
Discover the service
Before anything is called, the client has to find the service. AUTOSAR Adaptive builds this in: applications discover and use services at runtime. The service discovery message format is not shown here, because that specification is not among the sources.
AUTOSAR Adaptive: Service-oriented architecture: applications discover and use services at runtime
| CAN signal | SOME/IP service | DDS publish-subscribe | |
|---|---|---|---|
| Shape | Signals in frames, wired up at configuration time | Remote procedure calls, event notifications, serialization | Data-centric publish-subscribe with QoS |
| Payload | CAN FD up to 64 byte; CAN XL 1 to 2048 byte | UDP 0 to 1400 byte; larger over TCP or SOME/IP-TP | Not given by the sources used here |
| Defined by | ISO 11898-1:2024 (Classic, FD and XL) | AUTOSAR SOME/IP protocol specification, R25-11 | OMG DDS 1.4 |
The Vehicle Signal Specification tree
A slice built from the rule set's own example paths. Open a branch, pick a node.
Vehicle
Branch · Groups other nodes
A branch groups the nodes below it. Nodes are addressed from the root to the leaf with period-delimited paths.
VSS rule set: Nodes addressed root to leaf with period-delimited paths
The third element type is the attribute: a value that does not change within an ignition cycle, such as brand, colour or model. The rule set names these examples but the pages used here give no paths for them, so none are drawn in the tree.
Sources
AUTOSAR Classic AUTOSAR Classic Platform. R25-11.
- Communication via RTE and VFB; ports are signal-oriented and statically configured
- Ports are signal-oriented and statically configured
CiA: history CAN in Automation, History of CAN technology. as read October 2026.
- ISO 11898 physical layer up to 1 Mbit/s
CiA: CAN FD CAN in Automation, CAN FD: the basic idea. as read October 2026.
- Payload up to 64 byte
- CAN FD payload up to 64 byte
- Arbitration phase limited to 1 Mbit/s; data phase limited by the transceiver
CiA: CAN XL CAN in Automation, CAN XL. as read October 2026.
- Data field 1 to 2048 byte
- Data field 1 to 2048 byte; 11-bit priority ID
AUTOSAR SOME/IP SOME/IP Protocol Specification (AUTOSAR FO PRS, Doc ID 696). R25-11, 2025-11-27.
- Remote procedure calls, event notifications, serialization
- Header layout; message types; Method ID ranges; UDP payload and SOME/IP-TP limits
- Message types 0x80 RESPONSE and 0x81 ERROR; 0x20 flag for TP
- Fields: notifier, getter, setter; notifier sends the value after subscription, events only on change
- Message type 0x02 NOTIFICATION; recommended Method ID range for events
- Scope of SOME/IP
- UDP payload and SOME/IP-TP limits
- Doc ID 696, R25-11
AUTOSAR Adaptive AUTOSAR Adaptive Platform. R25-11.
- Service-oriented architecture: applications discover and use services at runtime
- DDS security; signal-to-service translation
OMG DDS Data Distribution Service. v1.4, 2015.
- DCPS model; version 1.4, March 2015
- Data-centric publish-subscribe (DCPS) model; version history
- APIs and communication semantics (behaviour and QoS)
- DCPS model
- Version 1.4, March 2015
COVESA VSS COVESA Vehicle Signal Specification. v6.1.
- A syntax and a catalogue for vehicle signals
- COVESA initiative: a syntax and a catalogue for vehicle signals; latest released version 6.1
VSS rule set VSS Rule Set: Basic Rules. v6.1.
- Single tree rooted at Vehicle; period-delimited paths
- Single tree with root branch Vehicle
- Example paths in the single tree rooted at Vehicle
- Nodes addressed root to leaf with period-delimited paths
VSS data entries VSS Rule Set: Sensors, Actuators and Attributes. v6.1.
- Sensor, actuator and attribute element types
ISO 11898-1 Road vehicles — Controller area network (CAN) — Part 1: Data link layer and physical coding sublayer. Ed. 3, 2024 (catalogue abstract).
- Edition 3, 2024
Everything here is paraphrased from the pinned sources, not quoted, and figures are attributed to them. Anything illustrative is labelled as such. Where a source is silent the page says so instead of filling the gap.