1. Objective

Isolate PEER_MSG_KIND_AB_SAMPLE traffic from the multiplexed ab-peer channel without making GP aware of the platform, transport OSAdapter, or Gateway topology.

The application shall use only SCP/Platform_RTE logical channel APIs. Platform and deployment binding shall remain outside GP.

- ProtocolAdapter DDS		- OSAdapter FreeRTOS
Uses OS sockets provided by		Provides OS primitives:
the active OSAdapter to		- Memory & Clocks/Timers
transfer data.		- Threading / Mutexes
		- Logging & OS Sockets

+----------------------------—+ +------------------------—+

2. Deployment model

flowchart LR
    subgraph SCP["SCP logical channels"]
        A(("A")) ---|ab-crosscompare| B(("B"))
        A ---|ab-peer| B
    end
    A -.->|inter-site link to the same role on the other site| OTHER["A or B of the other site"]
    A -->|ab-relay-*| GW["Gateway"]
    B -->|ab-relay-*| GW

ab-crosscompare is an A↔B channel. It is not a Gateway channel.

Existing A/B↔Gateway relay channels remain unchanged:

ab-relay-train
ab-relay-il
ab-relay-ctc
ab-relay-util

3. Platform-agnostic boundary

GP shall not:

include DDS, POSIX, socket, or operating-system OSAdapter headers;
select a transport OSAdapter;
resolve hosts or ports;
register osadapter-specific routes;
encode deployment topology into transport code.

GP shall:

request the logical channel ab-crosscompare;
use SCP/Platform_RTE channel lifecycle, send, receive, and close APIs;
preserve existing application payload and cyclic timing semantics.

The SCP/platform layer shall own:

logical-channel binding;
endpoint and port resolution;
OSAdapter selection;
connection setup and teardown;
platform-specific transport implementation;
deployment-specific A/B and Gateway topology.

A POSIX/DDS implementation may provide the binding, but that implementation must remain outside GP.

4. Checkpoint-gated staging

AB_SAMPLE transmission remains governed by ADR-034.

Required flow:

flowchart TD
    PE["post_execute"] --> STAGE["stage AB_SAMPLE in SCP-independent pending-send queue"]
    STAGE --> CP{"checkpoint result confirms matching program path"}
    CP -->|success| COMMIT["commit through ab-crosscompare"]
    CP -->|failure| DISCARD["discard pending cross-compare sample"]

The redesign shall reuse the existing generic staging mechanism:

add AB_GP_STAGE_DEST_CROSSCOMPARE;
add ab_gp_channel_stage_crosscompare();
extend ab_gp_channel_commit_pending_sends();
dispatch committed data through the logical ab-crosscompare channel.

No second staging queue or duplicate checkpoint discipline shall be created.

5. Receive path

AB_SAMPLE shall be received only from ab-crosscompare.

Required changes:

add SCP channel storage for the dedicated channel;
poll the dedicated channel independently;
remove AB_SAMPLE demultiplexing from ab-peer;
remove checkpoint-side AB_SAMPLE interception;
remove cached_ab_sample and has_cached_ab_sample;
preserve checkpoint, site-state, negotiation, and fault-message handling on ab-peer.

ctx->cyc_peer_sessions population and comparator behavior shall remain unchanged.

6. Lifecycle

The dedicated logical channel shall be:

opened through SCP/Platform_RTE during GP link initialization;
available before cyclic execution starts;
closed during the normal GP shutdown path;
included in startup failure handling;
covered by existing link supervision and safe-state behavior.

Failure policy shall match the existing A/B peer-link safety policy. The exact mapping requires confirmation against the current SCP channel-service contract before implementation.

7. Interfaces

The preferred application-facing interface is logical and osadapter-neutral:

rte_status_t rte_channel_service_setup(
    rte_channel_service_t *storage,
    const char *logical_channel_name);

The implementation shall use:

"ab-crosscompare"

No GP API shall expose hostnames, ports, DDS routes, sockets, or OSAdapter objects.

If the current SCP API cannot bind this logical channel without GP registering OSAdapter routes, the SCP API/osadapter integration must be extended first. GP must not compensate by calling an OSAdapter directly.

8. Safety and communication assumptions

The channel is a closed, fixed-participant A↔B communication channel.
The existing AB_SAMPLE framing, size, cycle association, and comparator checks remain safety-relevant and must not be weakened.
Separation of physical/logical channels reduces protocol cross-contamination but does not replace EN 50159 defensive measures.
Sequence/cycle validation, source identity, timeout supervision, and disagreement reaction remain mandatory.
The fail-safe response remains the existing REBOOT/safe-state behavior.
CCF mitigation is not provided by channel separation alone; independent platform/osadapter implementations and deployment diversity require separate justification.

SIL/THR claims, channel openness classification, and required EN 50159 measures must be confirmed from the project safety requirements and licensed standard editions before approval.

9. Verification plan

Before implementation:

map every AB_SAMPLE send, receive, cache, and staging call;
identify all SCP channel lifecycle paths;
confirm channel configuration is supplied outside GP;
confirm both A and B resolve the same logical channel symmetrically;
confirm Gateway configuration does not consume ab-crosscompare.

After implementation:

unit-test staging commit and discard;
test dedicated-channel send/receive;
test checkpoint interleaving;
test channel-open and channel-close failures;
test cross-compare AGREED and DISAGREE paths;
run static analysis and MISRA checks;
run both live fault-injection scenarios;
verify no platform/osadapter include or call remains in GP;
verify all existing A/B↔Gateway relay tests remain unchanged and pass.

10. Explicit non-goals

This change does not:

move cross-compare decision logic into SCP;
remove GP's explicit comparator invocation;
change Gateway relay channels;
introduce a Gateway route for cross-compare;
implement real DDS;
change redundancy topology;
claim full zero voter-awareness.

Full application transparency remains a separate architectural activity: the SCP would need to own comparison invocation and disagreement handling, with requirements and safety justification established independently.

11. Approval gate

Implementation may start only after confirming:

ab-crosscompare is an SCP logical A↔B channel;
GP can open it without osadapter-specific code;
staging remains checkpoint-gated;
checkpoint receive code no longer needs to consume AB_SAMPLE;
existing Gateway channels remain unchanged;
safety requirements and failure response are approved.