Skip to main content

CAN Bus Transport

High-throughput, frame-based field bus integration.

CAN bus is a deterministic, broadcast transport designed for real-time systems. MapsMessaging integrates with CAN via SocketCAN and ingests frames as fast as the bus allows.

The bus itself defines throughput, ordering, and arbitration. There is no concept of connection state, retries, or flow control at the transport layer.

Features​

  • Native SocketCAN integration
  • Zero connection setup
  • Deterministic arbitration at the hardware level
  • High-frequency frame ingestion
  • Low latency, low overhead
  • Suitable for embedded and industrial systems

When to Use CAN Bus​

CAN bus is recommended when:

  • Interfacing with embedded systems or vehicles
  • Deterministic timing matters more than payload size
  • The data source controls transmission rate
  • Reliability is handled at the protocol level (e.g. NMEA 2000, J1939)
  • Extremely low overhead is required

If you need reliable delivery, large payloads, or remote clients, use TCP instead.

Transport Characteristics​

Unlike TCP or UDP, CAN bus:

  • Is broadcast, not point-to-point
  • Has no sessions or connections
  • Uses hardware arbitration, not software flow control
  • Delivers fixed-size frames
  • Cannot be back-pressured by the receiver

MapsMessaging operates as a passive consumer. The bus is always the limiting factor.

Endpoint Usage​

CAN bus endpoints inherit common settings from EndPointConfigDTO, but most fields are ignored due to the stateless nature of CAN.

- name: "Canbus Interface"
  url: canbus://::/
  deviceName: can1
  protocol: n2k

Notes​

  • url is a logical identifier, not a network address
  • deviceName must refer to an existing SocketCAN interface
  • protocol determines frame decoding and topic mapping

Message Handling Model​

  • Frames are read continuously from the bus
  • No acknowledgement or retransmission is performed
  • Unknown frames may be forwarded as raw payloads (protocol-dependent)
  • Decoding and routing are handled by the configured protocol layer

The server does not throttle reads. If the bus is saturated, that is by design.

Security Notes​

  • CAN bus has no native authentication or encryption
  • Physical access equals network access
  • Use isolated networks or gateways where required
  • Security must be enforced at higher protocol layers or externally

Operational Notes​

  • Bus speed and topology define throughput
  • CPU usage scales with frame rate, not configuration
  • Multiple consumers can safely read the same CAN interface
  • MapsMessaging does not interfere with arbitration or timing

When NOT to Use CAN Bus​

Avoid CAN bus when:

  • Payloads exceed CAN frame limits
  • Remote access is required
  • Encryption or authentication is mandatory
  • The data source cannot tolerate packet loss

Choose CAN bus when you want reality, not comfort.