RTE RBC 2oo2 Reference Application 0.1.0 build 0006685
SIL 4 2oo2 Dual-Site Fault-Tolerant ERTMS Radio Block Centre Reference Architecture
Loading...
Searching...
No Matches
ab_gp_channel_checkpoint.c File Reference

Checkpoint rte_channel OSAdapter adapter over the A<->B peer link. More...

#include "ab_gp_channel_checkpoint.h"
#include "rte/oal/log/rte_log.h"
#include "rte/oal/timer/rte_timer.h"
#include "../../common/common_config.h"
#include "ab_gp_channel_types.h"
#include "ab_gp_channel_util.h"
#include "ab_gp_channel_negotiate.h"
#include "ab_gp_sibling_state.h"
Include dependency graph for ab_gp_channel_checkpoint.c:

Go to the source code of this file.

Functions

static void ab_gp_channel_checkpoint_note_peer_frame (ab_gp_channel_context_t *ctx)
 Records that a CHECKPOINT_REQUEST/REPLY was just seen from the peer, for the lookback check in ab_gp_channel_checkpoint_backend_recv().
static bool ab_gp_channel_checkpoint_peer_recent (const ab_gp_channel_context_t *ctx)
 True if the peer exchanged a checkpoint frame with us within the last RTE_EXAMPLE_AB_CHECKPOINT_LOOKBACK_CYCLES cycles.
rte_status_t ab_gp_channel_checkpoint_backend_send (void *channel, const void *data, size_t data_size)
 rte_channel_send_fn for the checkpoint transport: wraps the given rte_vital_message_t in a PEER_MSG_KIND_CHECKPOINT_REQUEST frame and sends it on the peer link. The matching reply is NOT waited for here - ab_gp_channel_io.c's peer rx task auto-responds to the peer's own REQUEST with a REPLY on its side, and ab_gp_channel_checkpoint_backend_recv() below is what waits for OUR REQUEST's REPLY to come back.
static rte_status_t poll_for_checkpoint_frame (ab_gp_channel_context_t *ctx, void *data, size_t data_size, uint32_t timeout_ms)
 Step 3: last-ditch live poll for whatever remains of this round's budget.
rte_status_t ab_gp_channel_checkpoint_backend_recv (void *channel, void *data, size_t data_size, uint32_t timeout_ms)
 rte_channel_recv_fn for the checkpoint transport: waits (bounded by timeout_ms) for a PEER_MSG_KIND_CHECKPOINT_REPLY to arrive in ctx->checkpoint_reply_slot - written by ab_gp_channel_io.c's peer rx task, the only thread that ever calls rte_netlink_receive() on the peer link.

Detailed Description

Checkpoint rte_channel OSAdapter adapter over the A<->B peer link.

The built-in AppManager checkpoint (ADR-019/ADR-034) is a synchronous A->B->A rendezvous run as the LAST per-cycle stage. The peer can only answer it from its OWN next pre_execute(), so a fresh round trip needs >= one full RTE_EXAMPLE_AB_CYCLE_PERIOD_MS - longer than RTE_EXAMPLE_AB_CHECKPOINT_MAX_DELAY_MS's steady-state budget. It only ever completed in-window when host scheduling jitter was low enough to keep A's and B's cycle phases aligned; on a loaded CI runner / VM the phase drifts and the rendezvous times out -> SAFE-state -> reboot loop. Widening the budget was tried and reverted repeatedly (see RTE_EXAMPLE_AB_CYCLE_PERIOD_MS's revert history).

backend_recv() therefore confirms this cycle when EITHER a real matching peer frame is on hand (retained by the per-cycle pump, or live-polled), OR the peer exchanged any checkpoint frame with us within the last RTE_EXAMPLE_AB_CHECKPOINT_LOOKBACK_CYCLES cycles ("lookback" - a local cycle-counter check, immune to sub-cycle phase). A genuinely silent peer still fails the rendezvous after N+1 checkpoint-quiet cycles, preserving REQ-CHECKPOINT-003's bounded reaction, just measured in cycles. Same-program-path divergence (vs. mere liveness) is caught every cycle by the cross-comparator (ab_gp_channel_crosscompare.c), not here. See docs/TIMING_AND_DATA_LOSS_ANALYSIS.md finding 10.

Definition in file ab_gp_channel_checkpoint.c.

Function Documentation

◆ ab_gp_channel_checkpoint_note_peer_frame()

void ab_gp_channel_checkpoint_note_peer_frame ( ab_gp_channel_context_t * ctx)
static

Records that a CHECKPOINT_REQUEST/REPLY was just seen from the peer, for the lookback check in ab_gp_channel_checkpoint_backend_recv().

Local functions

Definition at line 42 of file ab_gp_channel_checkpoint.c.

◆ ab_gp_channel_checkpoint_peer_recent()

bool ab_gp_channel_checkpoint_peer_recent ( const ab_gp_channel_context_t * ctx)
static

True if the peer exchanged a checkpoint frame with us within the last RTE_EXAMPLE_AB_CHECKPOINT_LOOKBACK_CYCLES cycles.

Definition at line 49 of file ab_gp_channel_checkpoint.c.

◆ ab_gp_channel_checkpoint_backend_send()

rte_status_t ab_gp_channel_checkpoint_backend_send ( void * channel,
const void * data,
size_t data_size )

rte_channel_send_fn for the checkpoint transport: wraps the given rte_vital_message_t in a PEER_MSG_KIND_CHECKPOINT_REQUEST frame and sends it on the peer link. The matching reply is NOT waited for here - ab_gp_channel_io.c's peer rx task auto-responds to the peer's own REQUEST with a REPLY on its side, and ab_gp_channel_checkpoint_backend_recv() below is what waits for OUR REQUEST's REPLY to come back.

Global functions

Parameters
channelThis ab_gp_channel_context_t, as void* (rte_channel's own opaque-handle convention).
dataThe rte_vital_message_t to send.
data_sizeMust be exactly sizeof(rte_vital_message_t).
Returns
RTE_STATUS_OK on success; RTE_STATUS_INVALID_PARAM for a bad argument; RTE_STATUS_HARDWARE_FAULT if the peer link is currently down; otherwise whatever rte_netlink_send() itself returns. Sends under ctx->peer_send_mutex - see ab_gp_channel_types.h's own doc for why.

Definition at line 64 of file ab_gp_channel_checkpoint.c.

◆ poll_for_checkpoint_frame()

rte_status_t poll_for_checkpoint_frame ( ab_gp_channel_context_t * ctx,
void * data,
size_t data_size,
uint32_t timeout_ms )
static

Step 3: last-ditch live poll for whatever remains of this round's budget.

Polls ctx->com.peer_channel in <= 20ms slices until a matching CHECKPOINT_REQUEST/REPLY frame arrives, the deadline passes (RTE_STATUS_TIMEOUT), or a hard read error occurs. A SITE_STATE frame seen along the way is stored into ctx->peer_site_state and handed to rte_site_role by the sibling source, same as the per-cycle peer pump (pre_execute's on_peer_frame_received()).

Definition at line 98 of file ab_gp_channel_checkpoint.c.

◆ ab_gp_channel_checkpoint_backend_recv()

rte_status_t ab_gp_channel_checkpoint_backend_recv ( void * channel,
void * data,
size_t data_size,
uint32_t timeout_ms )

rte_channel_recv_fn for the checkpoint transport: waits (bounded by timeout_ms) for a PEER_MSG_KIND_CHECKPOINT_REPLY to arrive in ctx->checkpoint_reply_slot - written by ab_gp_channel_io.c's peer rx task, the only thread that ever calls rte_netlink_receive() on the peer link.

Parameters
channelThis ab_gp_channel_context_t, as void*.
dataDestination for the received rte_vital_message_t.
data_sizeMust be exactly sizeof(rte_vital_message_t).
timeout_msMaximum time to wait for a NEW reply.
Returns
RTE_STATUS_OK with *data populated if a fresh reply arrived in time; RTE_STATUS_INVALID_PARAM for a bad argument; RTE_STATUS_TIMEOUT if none arrived within timeout_ms.

Definition at line 173 of file ab_gp_channel_checkpoint.c.