Safe API Framework 0.1.0 build 384e6ae
Layered API framework for safety-related applications (ERTMS RBC reference targeting CENELEC EN 50128 SIL 4)
Loading...
Searching...
No Matches
rte_dual_msgchannel.h File Reference

"Channel" layer of ADR-020: one EN 50159-defended message channel over one already-open rte_netlink_handle_t. More...

Include dependency graph for rte_dual_msgchannel.h:
This graph shows which files directly or indirectly include this file:

Go to the source code of this file.

Data Structures

struct  rte_dual_msgchannel_t
 One rte_dual_msgchannel_t instance's state. Caller-owned storage (REQ-DUAL-MSGCHANNEL-001); opaque in practice, exposed here (not via RTE_DECLARE_STORAGE) only because its size is already small and fixed - callers must still treat every field as private and only reach it through the functions below. More...
struct  rte_dual_msgchannel_config_t
 Configuration for rte_dual_msgchannel_init(). More...

Macros

#define RTE_DUAL_MSGCHANNEL_MAX_PAYLOAD   248U
 Max payload bytes usable via rte_dual_msgchannel_send()/ _receive() - bounded by rte_vital_message_t's own fixed 248-byte payload field (rte_checksum.h).

Functions

rte_status_t rte_dual_msgchannel_set_resync_on_sequence_error (rte_dual_msgchannel_t *channel, bool enable)
 Turns sequence resynchronisation on or off (default off after init).
rte_status_t rte_dual_msgchannel_init (rte_dual_msgchannel_t *channel, const rte_dual_msgchannel_config_t *config)
 Initializes a rte_dual_msgchannel_t: starts both sequence counters at 0.
rte_status_t rte_dual_msgchannel_send (rte_dual_msgchannel_t *channel, const uint8_t *payload, uint8_t payload_size, rte_duration_ms_t timeout_ms, uint32_t *out_sequence)
 Wraps payload in a rte_vital_message_t (this channel's own sender_id and next sequence_number) and sends it over config->link, blocking at most timeout_ms.
rte_status_t rte_dual_msgchannel_receive (rte_dual_msgchannel_t *channel, uint8_t *out_payload, uint8_t payload_max_size, rte_duration_ms_t timeout_ms, uint8_t *out_payload_size, uint32_t *out_sequence)
 Receives one frame over config->link, blocking at most timeout_ms, verifies its CRC-64 and sequence continuity (rte_checksum_vital_message_verify() against channel->expected_sequence) and its sender_id against config->expected_peer_id, and extracts the payload.
rte_status_t rte_dual_msgchannel_reset_sequence (rte_dual_msgchannel_t *channel)
 Resets both sequence counters to 0. Intended to be called by the caller (typically rte_dual_channel_t) exactly once, immediately after config->link has been freshly (re)established with the peer - the same idea as a mechanism RBC_GP once had and has since removed (2026-10-04): a cycle-counter reset after a peer-link reconnect. A fresh link needs a fresh, mutually agreed starting sequence rather than fighting over whatever counters were left over from before the disconnect.

Detailed Description

"Channel" layer of ADR-020: one EN 50159-defended message channel over one already-open rte_netlink_handle_t.

Every frame sent/received is a rte_vital_message_t (rte_checksum.h - already the framework's established EN 50159-style envelope, reused here rather than reinvented, the same way rte_channel_checkpoint() (ADR-017) already reuses it): sequence_number defends against repetition/deletion/resequencing, sender_id (checked against config->expected_peer_id on receive) defends against masquerade, timestamp_ms supports delay/staleness detection by the caller, and crc64 defends against corruption. See ADR-020 section 1.

This is the lower of the two protocol layers ADR-020 defines - rte_dual_channel_t (rte_dual_channel.h) is the upper layer, adding its own DATA/ACK/STATE frame-kind header inside this layer's payload and redundant-link fan-out on top of a single rte_dual_msgchannel_t like this one.

REQ-DUAL-MSGCHANNEL-001: no dynamic allocation; caller supplies storage and an already-open rte_netlink_handle_t. REQ-DUAL-MSGCHANNEL-002: send/receive never block longer than the caller-supplied timeout_ms. REQ-DUAL-MSGCHANNEL-003: rte_checksum_crc64_init() must already have been called by the application before any rte_dual_msgchannel_* call (module-global singleton state, ADR-020 does not re-init it). REQ-DUAL-MSGCHANNEL-004: sender_id is checked against config->expected_peer_id before CRC/sequence verification; a mismatch is rejected with RTE_STATUS_HARDWARE_FAULT without advancing expected_sequence (masquerade defense). REQ-DUAL-MSGCHANNEL-005: a CRC or sequence-continuity failure yields RTE_STATUS_DATA_CORRUPTION and leaves expected_sequence unchanged.

Definition in file rte_dual_msgchannel.h.