# Fault Handling Mechanisms Based on Cross-Protocol Redundancy in Classic AUTOSAR Communication

Valentin Mordel, Michaël Lauer, Daniel Loche, Philippe Cuenot, Rob Vingerhoeds

► To cite this version:

Valentin Mordel, Michaël Lauer, Daniel Loche, Philippe Cuenot, Rob Vingerhoeds. Fault Handling Mechanisms Based on Cross-Protocol Redundancy in Classic AUTOSAR Communication. 13th European Congress of Embedded Real Time Systems (ERTS), Feb 2026, Toulouse, France. 10.82331/ERTS.2026.12. hal-05513490

HAL Id: hal-05513490

https://hal.science/hal-05513490v1

Submitted on 19 Feb 2026

HAL is a multi-disciplinary open access
archive for the deposit and dissemination of sci-
entific research documents, whether they are pub-
lished or not. The documents may come from
teaching and research institutions in France or
abroad, or from public or private research centers.

L'archive ouverte pluridisciplinaire HAL, est
destinée au dépôt et à la diffusion de documents
scientifiques de niveau recherche, publiés ou non,
émanant des établissements d'enseignement et de
recherche français ou étrangers, des laboratoires
publics ou privés.

<figure><img src="image_1.png" /></figure>

Distributed under a Creative Commons CC BY 4.0 - Attribution - International License
# Fault Handling Mechanisms Based on Cross-Protocol Redundancy in Classic AUTOSAR Communication

Valentin Mordel¹, Daniel Loche², Michaël Lauer³, Philippe Cuenot⁴, and Rob Vingerhoeds⁵

1,2,4 AUMOVIO France SAS
firstname.lastname@aumovio.com

1,3,5 Fédération ENAC ISAE-SUPAERO ONERA, University of Toulouse
firstname.lastname@isae-supaero.fr

## ABSTRACT

As automotive Electrical/Electronic (E/E) architectures evolve toward zonal designs, communication between High-Performance Computing nodes (HPC) and Zonal Computing Units (ZCU) becomes a critical point of failure, as disruptions may affect multiple safety-critical functions simultaneously. This paper proposes a communication recovery mechanism based on AUTOSAR that takes advantage of the simultaneous presence of CAN and Ethernet links between HPC and ZCU to establish a redundant communication path. The mechanism is implemented on a real HPC-ZCU platform and evaluated through detailed timing instrumentation covering fault detection, switchover completion, and end-to-end properties such as latency, jitter and availability. The measured switchover time remains well below the recovery budgets typically required by time-critical functions, demonstrating the feasibility of a fail-operational behaviour within Classic AUTOSAR. Beyond the experimental results, the paper analyses the runtime sequence (detection, decision, reconfiguration), the preservation of communication properties across protocols, and the safety implications of the approach and concludes with perspectives for extending the method to broader fault scenarios.

**Index Terms** — Embedded systems, Classic AUTOSAR, CAN, Ethernet, Fault tolerance, Network reconfiguration, Safety, Software-Defined Vehicle (SDV)

## 1. INTRODUCTION

Modern vehicles are undergoing a profound transformation toward highly connected and software-driven systems. The growing demand for advanced functionalities such as automation, remote updates, and service integration has significantly increased the complexity of in-vehicle electronic systems. In current vehicles, this complexity is reflected by the large number of Electronic Control Units (ECUs) distributed across multiple functional domains [12], which challenges the scalability and long-term maintainability of traditional electrical/electronic (E/E) architectures.

To address these limitations, the automotive industry is progressively transitioning toward more centralized E/E architectures. These architectures rely on powerful central computing nodes and a reduced set of distributed controllers responsible for input/output management [4]. This evolution, illustrated in Figure 1, enables wiring reduction, hardware consolidation, and improved software reuse, which together contribute to lowering system integration and manufacturing costs. It therefore constitutes a key enabler for the emergence of Software-Defined Vehicles.

<figure><img src="image_2.png" /><figcaption>Figure 1. Evolution of automotive E/E architectures: from distributed to zonal HPC-based models</figcaption></figure>

However, this transition introduces critical challenges to system dependability, particularly in terms of communication related to safety and availability. According to Road vehicles – Functional safety (ISO 26262) [1], the correct functioning of safety-critical systems must be ensured within bounded timing constraints, which defines the maximum allowed time from fault occurrence to the successful recovery or transition to a safe state. As more Automotive Safety Integrity Level (ASIL) functions are hosted on central nodes, the communication paths between High-Performance Computer (HPC) and Zonal

<footnote>Valentin Mordel et al. This is an open-access article distributed under the terms of the Creative Commons Attribution 4.0 License, which permits unrestricted use, distribution, and reproduction in any medium, provided the original author and source are credited.</footnote>
Control Unit (ZCU) become mission-critical. Any disruption, such as the loss of a Controller Area Network (CAN) link, can affect multiple functions simultaneously. Modern E/E architectures embed multiple inter-node communication protocols such as CAN, and Ethernet, each serving distinct functional and performance requirements. This heterogeneity allows the use of multiple networks to build redundancy and maintain service availability to mitigate risk of communication failure.

This paper addresses the problem of communication resilience in centralized automotive E/E architectures. As computation is increasingly concentrated on central nodes and multiple vehicle functions depend on shared communication paths, the loss of a single in-vehicle network may lead to a temporary or complete loss of functionality. In current automotive systems, such communication failures are often handled through coarse recovery strategies, such as resetting the affected control units, which may interrupt services and degrade availability, including for safety-related functions. To overcome these limitations, this work proposes a fault-handling approach that preserves communication continuity by exploiting the coexistence of multiple in-vehicle communication technologies. When a communication channel becomes unavailable, the proposed mechanism enables a runtime reconfiguration that allows data exchanges to be maintained without resetting the involved control units. The approach is implemented on a representative centralized platform and experimentally evaluated by decomposing the fault-handling process into detection, decision, and reconfiguration phases. The resulting measurements provide quantitative insights into the impact of such recovery strategies on latency, jitter, and overall service availability, and illustrate their potential contribution to fail-operational behaviour in future zonal architectures.

The remainder of the paper is organised as follows. Section 2 details the AUTOSAR-based communication architecture and the runtime execution of the proposed CAN-to-Ethernet switchover mechanism. Section 3 presents the experimental platform, the fault-injection setup and the measurement methodology, and reports the resulting timing and quality-of-service metrics. Section 4 discusses the results in the light of timing and safety considerations and outlines possible extensions of the mechanism for future zonal E/E architectures. Section 6 positions this contribution relative to existing work on communication fault tolerance and AUTOSAR-based recovery strategies. Finally, Section 7 summarises the main contributions and concludes the paper.

## 2. MECHANISM IMPLEMENTATION

The AUTOSAR standard defines a modular and supplier-independent software architecture widely adopted in the automotive industry, enabling interoperability, software reuse, and compliance with functional safety requirements such as ISO 26262. In this work, the proposed fault-handling mechanism is implemented within Classic AUTOSAR communication stacks deployed on both nodes of the considered E/E architecture.

The following paragraphs describe how the proposed runtime reconfiguration is realised within the AUTOSAR communication stack, focusing on the routing of application

data from the software components down to the network interfaces.

In Classic AUTOSAR, application data are packaged by the COM module into Protocol Data Units (PDUs), which represent the logical messages exchanged between ECUs together with their communication attributes. The PDU Router (PduR) forwards each PDU to one or more predefined communication paths according to a static routing table. In our design, the HPC is configured with two alternative paths for the same PDU: one over CAN and one over Ethernet. These paths are organised into mutually exclusive Routing Path Groups, a PduR mechanism that groups several routes under a single activation switch. Only one group is enabled at a time, so a single communication path is active for the PDU. At runtime, the HPC selects the appropriate group when a CAN bus-off occurs, thereby redirecting the emission of the same logical PDU to Ethernet without modifying the application.

On the receiving side, the ZCU requires no dynamic reconfiguration. It is configured according to the standard AUTOSAR communication model, with a statically defined PDU identifier and signal layout shared by both the CAN and Ethernet variants. As a result, the ZCU can accept and decode the message on either network without modification, while the application continues to process an unchanged and coherent stream of data.

<figure><img src="image_3.png" /><figcaption>Figure 2. Modules Involved in Nominal and Reconfigured Communication Paths in Classic AUTOSAR</figcaption></figure>

Figure 2 illustrates the data path followed by the application message in both nominal and reconfigured modes. Under normal conditions, the signal flows from the application down to the CAN driver through COM, the PDU Router and the CAN Interface. When a CAN fault is detected, the same signal is rerouted at PduR level along the Ethernet path (EthIf, Eth Drv). The reconfiguration itself is triggered by BswM, which monitors the network state and activates the appropriate Routing Path Group in PduR. Because BswM is a control module rather than part of the data path, it is not shown in the figure, and its behaviour is described in detail in Section 2.1.

The proposed mechanism enables dynamic switching between communication protocols at runtime without impacting the Software Component (SWC) logic. This level of runtime adaptability is not yet a standard concern in current OEM
design practices, but is increasingly necessary in the context of flexible, fault-tolerant E/E architectures.

## 2.1. Runtime Execution Sequence

The proposed fault-handling mechanism relies on a specific runtime sequencing of existing Classic AUTOSAR modules, enabled by the concurrent availability of both CAN and Ethernet networks. This coordinated use of standardised components in an unconventional execution order is central to the mechanism and is summarised in Figure 3.

The fault considered in this work is a physical disconnection of the CAN network, which causes repeated transmission errors at the controller level. These errors increment the Transmit Error Counter (TEC) and eventually lead the controller to a bus-off state once the TEC reaches its threshold of 256, as defined in ISO 11898-1. The first failed transmission represents the earliest observable symptom of the fault, while the bus-off condition is only declared after consecutive transmission failures, following the increment mechanism detailed in Section 3.2.

When a bus-off occurs, the CAN Driver (CanDrv) notifies the CAN Interface (CanIf) through the standard callback CanIf_CtrlrBusOff(). The CAN Interface then reports the event to the CAN State Manager (CanSM) using CanSM_CtrlrBusOff(). The CAN State Manager processes this information in its main function and updates its internal state to BUS_OFF for the affected CAN controller. This state change is subsequently forwarded to the Basic Software Mode Manager (BswM) via the event-based callback BswM_CanSM CurrentState().

Upon detecting the transition to the CANSMBUS_OFF state, the BswM evaluates the corresponding rule defined in our configuration. Once this rule is validated, a dedicated action list is executed. This behaviour departs from the default AUTOSAR configuration and is specific to the proposed fault-handling mechanism. Within this action list, two routing actions are performed through the PDU Router (PduR) using PduR EnableRouting(): the Routing Path Group targeting Ethernet is activated, while the Routing Path Group targeting CAN is deactivated. As a result, the affected PDUs are rerouted over Ethernet without duplication.

When the CAN controller enters the bus-off state, the AUTOSAR CAN stack may clear its transmit buffers. With the single-buffer COM configuration used in this study, this behaviour can lead to the loss of at most one PDU instance per software component at the time of failure. This lost instance is immediately replaced by the next periodic emission over Ethernet once the routing switch becomes active, which bounds the impact of the reconfiguration to a single update period. Beyond this baseline behaviour, an extension of the mechanism is discussed in Section 5.

## 2.2. Temporal Decomposition and Timing Metrics

The proposed mechanism aims to keep communication services available despite a CAN fault. Its practical value therefore depends on how quickly the system detects the fault, decides to switch away from the nominal path, and restores delivery through the redundant network. In this subsection, we define

the timing metrics used to characterise these behaviours and to support the experimental validation of the mechanism presented in Section 3, whose objective is to assess, on a real HPC-ZCU platform, whether the mechanism satisfies the fault-handling performance required for fail-operational behaviour.

We decompose the switchover into three consecutive phases: detection, decision and reconfiguration, which capture the observable dynamics of the stack. Detection spans from the first failed CAN transmission observed at the driver to confirmation. Decision covers the interval during which the recovery policy authorises the switchover. Reconfiguration is the time needed to update routing until the alternative Ethernet path becomes active. The overall switchover time is therefore

$$T_{\text{total}} = T_{\text{detection}} + T_{\text{decision}} + T_{\text{reconfiguration}}$$

These timing metrics guide the instrumentation phase and the subsequent safety interpretation. By quantifying $T_{total}$ and its components, we can determine whether the mechanism restores communication fast enough for functions hosted on the HPC. This relationship between the measured reaction time and the communication criticality of the hosted functions ultimately determines the operational relevance of the mechanism. It defines which functions can safely rely on it without violating their recovery time constraints. The concrete instrumentation points and data processing methods used to obtain these measurements will be presented in Section 3.

# 3. MEASUREMENT METHODOLOGY AND TIMING RESULTS

Building on the mechanism and temporal decomposition established in Section 2, this section evaluates the approach experimentally on a representative HPC-ZCU test bench. We describe the dual-network platform, define the fault model and its injection, and map detection, decision and reconfiguration into measurable quantities with a protocol for collecting and correlating observations under fault. We report two groups of measurements: switchover timing, decomposed into detection, decision, reconfiguration and total recovery, and service quality under switchover with latency and jitter before and after reconfiguration. Interpretation and discussions are deferred to Section 4.

## 3.1. Experimental Platform

To validate the proposed communication fault handling mechanism, we deploy it on a physical test platform that reproduces key features of centralised E/E architectures. The experimental platform consists of a HPC and a ZCU. Both nodes are interconnected via a CAN bus and an Ethernet link. The Test Orchestrator PC manages both ECUs and controls a COM interface positioned between the nodes to observe and control CAN/Ethernet traffic. Figure 4 shows the test bench setup.

CAN is used for time-critical control data, while Ethernet handles non-critical or high-bandwidth communication under nominal conditions. In the event of a CAN failure, Ethernet acts as a backup channel to preserve service continuity. The HPC acts as the emitting node where runtime reconfiguration is
<figure><img src="image_4.png" /><figcaption>Figure 3. Sequence Flow of a Fault-Tolerant Mechanism in AUTOSAR</figcaption></figure>

performed, while the ZCU remains a conventional receiver and accepts the same application message regardless of the path. CAN is configured in CAN FD at 500 kbit/s. Ethernet uses UDP in best-effort mode without any specific optimisation. To assess system behaviour under fault conditions, the network and ECUs are instrumented to allow precise timing measurements, focussing on fault detection and reconfiguration latency.

<figure><img src="image_5.png" /><figcaption>Figure 4. Representative HPC-ZCU platform for the development of cross-protocol redundancy mechanisms</figcaption></figure>

The importance of testing on representative hardware is supported by Meyer et al. [7], who highlight that accurate fault detection depends on the fidelity of communication timing to real-world conditions. By anchoring our experiments in a realistic HPC-ZCU configuration, we ensure the relevance of the observed module behaviour and timing for future automotive deployments. This platform provides the basis for the next subsections, where we specify the fault model and injection procedure, the instrumentation and metrics, and the measurement protocol used to quantify the switchover timing and service quality.

## 3.2. Fault Injection

The goal of the fault injection is to validate that the proposed mechanism maintains service availability in the presence of a permanent CAN communication failure. To this end, a reproducible hardware fault is introduced on the CAN bus shared between the HPC and the ZCU, ensuring that frame transmissions consistently fail and trigger the standard CAN

error-handling mechanisms. In practice, the fault is injected by introducing a permanent short-circuit between the two CAN bus wires using a relay board. This fault prevents successful frame transmission without modifying ECU power or bus termination.

Whenever the HPC attempts to transmit a dominant bit, it still reads a recessive level on the bus and the controller detects a bit error by monitoring the mismatch between its transmit and receive paths. As a result, each transmission attempt of the reference PDU fails under the sustained short-circuit fault, and the transmitter's error counter escalates as defined in CAN ISO 11898-1. The transmit error counter (TEC) is incremented by +8 on each failed transmission attempt and decremented by -1 after a successful transmission. Bus-off is entered when $TEC \ge 256$. With a sustained short-circuit, no frame can be successfully transmitted, so after 32 consecutive failed attempts ($32 \times 8 = 256$) the controller exceeds the threshold and the CAN driver declares bus-off. In our runs, the relay is actuated as a hard short-circuit and kept closed for the duration of the experiment. Brief glitches are possible but are not used here. Triggering is manual from the orchestrator PC at chosen instants. Each run starts from a nominal state with the periodic PDU active. Reproducibility follows from the deterministic electrical short produced by the relay and from keeping the network and software parameters identical to Section 3.1.

## 3.3. Metrics and Measurement Protocol

We evaluate the proposed mechanism using a set of metrics together with a dedicated measurement protocol. On one side, we focus on fault-handling timing, that is how quickly the mechanism detects a CAN fault, decides the switchover and restores delivery on Ethernet. On the other, we assess the communication performance of CAN and Ethernet in terms of latency, jitter and periodicity before and after switchover. Detailed formulas and numerical results are given in Sections 3.4 and 3.5.

The timing aspects are captured through four instants $t_0$ to $t_3$ observed on the transmitting HPC node. The instant $t_0$ corresponds to the first failed CAN transmission
of the periodic message used as our timing reference. It marks the first observable symptom of the physical fault on the bus. The instant $t_1$ corresponds to the call to CanIf_CtrlrBusOff(), when the CAN Driver reports that the controller has entered the bus-off state. The instant $t_2$ is the time when the CAN bus-off state has been propagated to the CAN State Manager and the corresponding BswM rule has been evaluated as true via BswM_CanSM_CondCurrentState(), which marks the decision to leave CAN. Finally, $t_3$ denotes the activation of the Ethernet Routing Path Group through PduREnableRouting(), i.e. the moment when the switchover path becomes effective. From these landmarks, we derive

$$T_{\text{detection}} = t_1 - t_0 \quad (1)$$

$$T_{\text{decision}} = t_2 - t_1 \quad (2)$$

$$T_{\text{reconfiguration}} = t_3 - t_2 \quad (3)$$

$$T_{\text{total}} = t_3 - t_0 \quad (4)$$

where $T_{\text{total}}$ is the total fault-handling time. In the remainder of the paper, $T_{\text{total}}$ is compared with recovery budgets derived from the functional safety constraints of hosted functions. The detection time $T_{\text{detection}}$ is partially constrained by the CAN error handling specified in ISO 11898 [3], through the evolution of the transmit error counter under sustained short-circuit. Decision and reconfiguration times $T_{\text{decision}}$ and $T_{\text{reconfiguration}}$ are measured experimentally using software timestamps inserted at the entry points of specific functions. These timestamps are based on an internal timer (SysTick) of the HPC core concerned and are read via a real-time debugger (Lauterbach). Section 3.4 details the resulting timing decomposition.

Beyond reaction time, we also evaluate the impact of the mechanism on communication performance. For the reference PDU, we consider end-to-end latency, jitter and periodicity, as well as a simple availability indicator. All measurements are based on timestamped traces captured on the Test Orchestrator PC, which acts as a common observation point: CAN traffic is recorded with PCAN-View [11] and Ethernet/UDP traffic with Wireshark [16], both relying on the same high-resolution system clock. For each experimental run, the traces are exported and processed off-line with dedicated Python scripts that match instances of the reference PDU across CAN and Ethernet, reconstruct message sequences and derive the timing quantities. The temporal offset between CAN and Ethernet is obtained by comparing the arrival times of identical messages at the orchestrator. For each emitted instance $k$, let $t_{\text{CAN}}^{(k)}$ and $t_{\text{ETH}}^{(k)}$ denote the reception timestamps of the CAN and Ethernet frames carrying the same application payload. The average temporal offset between CAN and Ethernet is defined as

$$\Delta t_{\text{avg}} = \frac{1}{N} \sum_{k=1}^{N} (t_{\text{ETH}}^{(k)} - t_{\text{CAN}}^{(k)})$$

which quantifies the average temporal shift introduced by the Ethernet path relative to CAN. Jitter is defined as the deviation

of the measured inter-arrival time from the configured 50 ms emission period. Let $t_k$ denote the timestamp of the $k$-th message and $\Delta_k = t_k - t_{k-1}$ the observed inter-arrival time. The instantaneous jitter is

$$J_k = |\Delta_k - P_{\text{cfg}}| \quad P_{\text{cfg}} = 50 \text{ ms}$$

The average jitter used to compare the temporal precision of CAN and Ethernet is

$$J_{\text{avg}} = \frac{1}{N-1} \sum_{k=2}^{N} |\Delta_k - P_{\text{cfg}}|$$

Temporal stability is further characterised by the distribution of the inter-arrival times $\Delta_k$, whose variance reflects the intrinsic timing regularity of each network. The detailed analysis of these traces is reported in Section 3.5.

### 3.4. Mechanism Timing Measurements

This subsection details how the fault-handling time is obtained by combining the hardware bus-off detection and the software-driven decision and reconfiguration phases. Figure 5 provides an overview of the three intervals considered: detection, decision and reconfiguration. This timeline serves as the reference for the timing decomposition used in the remainder of this section.

<figure><img src="image_6.png" /><figcaption>Figure 5. Timeline of the Detection, Decision and Reconfiguration Phases</figcaption></figure>

The first stage of the mechanism is the transition of the CAN controller to the bus-off state under the short-circuit fault model defined in Section 3.2. When the relay shorts the differential pair, the HPC can still attempt to transmit frames, but the bus is effectively held near the recessive level and no valid dominant bits can be placed on the line. Whenever the node attempts to send a dominant bit, it still reads a recessive level on the bus and the controller detects a bit error by comparing transmit and receive paths. Each transmission attempt of the reference PDU therefore fails with a transmit-side error under a persistent fault.

In order to characterise the detection phase of the proposed fault-handling mechanism, it is necessary to recall the CAN error escalation rules defined in ISO 11898 [3], as they determine how quickly a persistent transmission fault leads to a bus-off condition. According to these rules, each transmit error increments the Transmit Error Counter (TEC) by +8. The node is error-active when TEC < 128, error-passive for 128 ≤ TEC < 256, and enters bus-off at TEC ≥ 256. Because each failed transmission adds +8 to the TEC, 16 consecutive errors are sufficient to reach the error-passive threshold, and another 16 to reach bus-off.
This distinction between error-active and error-passive operation is relevant for the proposed mechanism because it directly affects the retransmission behaviour of the transmitter and, consequently, the time required to reach the bus-off state under a persistent fault. In particular, the two modes differ in how transmission errors are signalled on the bus, which determines the minimum delay between consecutive retransmission attempts and influences the overall fault escalation dynamics.

The duration between two consecutive retransmission attempts is determined by the error-handling sequence defined in ISO 11898. For an error-active transmitter, the recovery interval corresponds to the mandatory error signalling sequence composed of the Active Error Flag (6 dominant bits), the Error Delimiter (8 recessive bits), and the Intermission (3 recessive bits), for a total of 17 bit times. In the error-passive state, the same signalling elements apply, but the node must additionally wait for the mandatory Suspend Transmission Time of 8 recessive bits before accessing the bus again. This yields a worst-case recovery interval of up to 31 bit times in error-passive mode, as summarised in the normative timing bounds reported in ISO 11898.

Using these bit-level decompositions, the worst-case time required for a node to reach the bus-off state under a persistent transmission fault is obtained by summing 16 recovery intervals of 17 bit times (to reach the error-passive threshold) and 16 recovery intervals of 31 bit times (to reach the bus-off threshold),

$$T_{\text{detection}} = (16 \cdot 17 + 16 \cdot 31) T_{\text{bit}},$$

where $T_{\text{bit}}$ is the CAN bit time. With the bus configured at 500 kbit/s, $T_{\text{bit}} = 1/500,000 = 2 \mu s$, so that

$$T_{\text{detection}} = \frac{768}{500,000} \text{ s} \approx 1.536 \text{ ms}.$$

This value represents a worst-case upper bound on the hardware component of $T_{\text{detection}}$, i.e. on the interval between the first failed transmission of the reference PDU at $t_0$ and the moment when the CAN controller enters the bus-off state and can notify the upper layers at $t_1$, assuming a permanent short-circuit and no intervening successful transmissions.

The timing of the two next phases is obtained from an internal cycle counter on the HPC core. The platform uses a SysTick timer clocked at 400 MHz, providing a time base with a resolution of 2.5 ns. For each function of interest, a dedicated instrumentation point stores the current SysTick value into a global variable, which is later read non-intrusively via the Lauterbach debugger. The overhead of reading the SysTick register and writing a single memory location is negligible at the millisecond scale and is not included in the timing budget. The raw cycle counts are converted into time by dividing by the known core frequency.

Three timestamps are extracted from the instrumentation: $t_1$ at the invocation of CanIf ControllerBusOff(), $t_2$ when BswM evaluates the bus-off rule, and $t_3$ at the execution of PduR EnableRouting() that activates the Ethernet Routing Path Group. Each timestamp is obtained by converting the corresponding SysTick counter value into physical time.

For each run, the decision and reconfiguration intervals are computed as

$$T_{\text{decision}} = t_2 - t_1 \qquad T_{\text{reconfiguration}} = t_3 - t_2$$

Across 30 fault-injection runs performed under identical conditions show stable timings. The decision interval $T_{\text{decision}}$ averages 1.074 ms, with a worst-case value of 1.471 ms. The reconfiguration interval $T_{\text{reconfiguration}}$ remains nearly constant, with an average of 0.034 ms and a worst-case value of 0.035 ms corresponding to the activation of the Ethernet Routing Path Group in PduR.

To obtain a conservative fault-handling time, the computation relies on worst-case values:

$$T_{\text{total}} = T_{\text{detection}} + T_{\text{decision}} + T_{\text{reconfiguration}} \quad (5)$$

$$\approx 1.536 \text{ ms} + 1.471 \text{ ms} + 0.035 \text{ ms} \quad (6)$$

$$\approx 3.042 \text{ ms.} \quad (7)$$

This worst-case reaction time remains in the order of a few milliseconds, confirming that the mechanism can maintain communication continuity under the considered CAN fault scenario. A detailed discussion of results is presented in Section 4.

## 3.5. Quality of Service Measurements

Now that the fault-handling mechanism has been demonstrated to operate correctly, we turn to the characterisation of the nominal timing properties of the two communication channels. The goal is to quantify the temporal differences that naturally arise between CAN and Ethernet when both networks carry the same periodic signal, and to determine the extent to which these differences may affect the system once a switchover occurs. This requires establishing a baseline that captures the temporal offset between the two channels, the variability of this offset over time, and the timing stability of each network under nominal state.

The reference PDU is generated every 50 ms in the HPC and transmitted in parallel through the CAN stack (COM → PduR → CanIf → CanDrv) and the Ethernet stack (COM → PduR → EthIf → EthDrv) using UDP multicast. The reference PDU includes an incrementing counter, ensuring that each CAN frame can be matched reliably with its Ethernet counterpart at the measurement point. The experiment is conducted under light load conditions (about 3% load on both CAN and Ethernet) so that the measurements predominantly reflect the inherent timing behaviour of each protocol.

A total of 1000 matched frame pairs are analysed, which provides a sufficiently long steady-state window to obtain stable estimates of the temporal offset and of the timing variability on each network. For each matched pair, the delay

$$\Delta t = t_{\text{ETH}} - t_{\text{CAN}}$$

is computed, and the inter-arrival times on each channel are used to derive the corresponding period series. Table 1 summarises the resulting metrics.

The measurements show that the two communication channels
do not exhibit the same timing characteristics. The latency difference $\Delta t$ is positive on average, indicating that Ethernet frames tend to arrive later than their CAN counterparts, although occasional inversions are observed. Moreover, the dispersion of $\Delta t$ is significant, reflecting the variability introduced by the distinct software stacks and processing paths of the two networks. These results are obtained under contention-free conditions. On the CAN side, no arbitration occurs since a single node transmits the reference PDU. On the Ethernet side, the network operates under light load and the PDU is transmitted in a best-effort manner without any priority or quality-of-service mechanism. As a result, the observed timing differences primarily reflect the inherent behaviour of each communication stack rather than contention or collision effects.

<table><caption>Table 1. Summary of timing metrics for the simultaneous CAN and Ethernet transmission of the reference PDU.</caption><thead><tr><td>Metric</td><td>Value μs</td></tr></thead><tbody><tr><td>Average CAN-ETH delay</td><td>248.52</td></tr><tr><td>Minimum CAN-ETH offset</td><td>-302</td></tr><tr><td>Maximum CAN-ETH offset</td><td>866</td></tr><tr><td>95<sup>th</sup> latency</td><td>740.8</td></tr><tr><td>99<sup>th</sup> latency</td><td>844.88</td></tr><tr><td>Average CAN jitter</td><td>7.94</td></tr><tr><td>Average Ethernet jitter</td><td>22.27</td></tr></tbody></table>

To complement the numerical metrics, the latency difference is also represented graphically in Figure 6. The aim is to visualise how the arrival time of Ethernet frames compares to that of CAN frames over a long sequence of emissions and to assess whether any systematic tendency or noticeable dispersion emerges. The distribution shows that the latency difference $\Delta t$ takes both positive and negative values, yet remains centred around a positive mean of 248.5 µs, indicating that Ethernet frames tend to arrive later than CAN frames on average. The observed values span a few hundred microseconds, but remain small in the low-load conditions of this experiment and, therefore have little practical impact on the overall behaviour of the system. Nonetheless, their magnitude suggests that further evaluation under higher network load would be valuable to determine how these timing differences evolve in more demanding operating conditions.

Further insight into the intrinsic timing stability of each network is obtained from the jitter distributions presented in Figures 7 and 8. Representing the jitter separately for CAN and Ethernet provides a direct visual indication of how regularly each channel delivers its periodic frames, which is essential to understand their respective behaviours once a switchover occurs. The CAN jitter distribution confirms the expected regularity of CAN transmissions, with inter-frame deviations around the nominal 50 ms period remaining narrowly concentrated. In contrast, the Ethernet jitter distribution exhibits a broader spread.

The results presented in this section provide a quantitative characterisation of the proposed mechanism and its communication context. The fault injection campaign and

<figure><img src="image_7.png" /><figcaption>Figure 6. Distribution of the CAN-Ethernet latency difference.</figcaption></figure>

<figure><img src="image_8.png" /><figcaption>Figure 7. Distribution of the CAN inter-frame jitter.</figcaption></figure>

<figure><img src="image_9.png" /><figcaption>Figure 8. Distribution of the Ethernet inter-frame jitter.</figcaption></figure>

timing measurements establish the end-to-end fault-handling time from the occurrence of a persistent CAN short-circuit to the activation of the Ethernet switchover path, while the quality-of-service analysis describes the nominal timing behaviour of CAN and Ethernet when operating in parallel. These elements prepare the ground for Section 4, in which we analyse their significance for system-level performance and safety requirements.

## 4. DISCUSSION

The experimental results show that the mechanism detects a permanent CAN short-circuit and completes the rerouting to Ethernet within a few milliseconds. The temporal
decomposition highlights that the dominant contribution comes from the detection and decision phases, while the reconfiguration itself is almost instantaneous. This confirms that the achievable reaction time is primarily governed by the CAN error escalation behaviour and by the scheduling of the AUTOSAR state-management tasks. With a total fault-handling time of around 2.64 ms and a worst case at 3.042 ms, the mechanism remains compatible with a wide range of time-critical functions whose recovery budgets operate in the millisecond domain, providing a fail-operational alternative to traditional ECU reset strategies.

Once the switchover decision is taken, the activation of the Ethernet routing path at the PduR level introduces only a negligible delay (tens of microseconds). This indicates that optimisation opportunities lie mainly in the earlier phases of the sequence. Introducing an event-based trigger in addition to the periodic activations represents a promising direction to shorten the decision latency.

Quality-of-service analysis provides a baseline characterisation of the nominal timing behaviour of CAN and Ethernet when carrying the same period. CAN shows a noticeably tighter timing behaviour, while Ethernet presents a wider spread. Under the lightly loaded conditions of this study, these differences remain within a few hundred microseconds. They nonetheless define the timing background within which the switchover operates, and their magnitude may increase under higher-load or mixed-traffic conditions, as further discussed in Section 5.

Regarding the receiving side, the mechanism remains fully transparent at the application level. The ZCU continues to receive the same logical PDU with the same signal layout, independent of the transport medium. Since the routing change is handled entirely by the HPC through mutually exclusive Routing Path Groups, the ZCU observes a single, consistent PDU stream without requiring any dynamic configuration.

In addition, several AUTOSAR functional-safety mechanisms continue to operate identically after the switchover. End-to-End protections (CRC, sequence counters, DataIDs and timeout supervision), control-flow monitoring, OS timing protection and memory-partitioning guarantees remain unaffected, as these mechanisms are defined above the transport layer and remain independent of the underlying communication channel. According to the AUTOSAR Functional Safety Measures specification [2], these protections are applied at COM and RTE level and are therefore preserved as long as the software structure and runnable activation semantics remain unchanged. Since the proposed mechanism only reroutes the PDU at PduR level without altering component execution, task scheduling or memory isolation, the architectural safety properties governing data integrity, freshness and freedom from interference remain valid after the transition.

## 5. PERSPECTIVES

Several extensions of this work emerge from this discussion. During the switchover, the AUTOSAR CAN stack will clear its transmit buffers when entering bus-off, and with the single-buffer COM configuration used here, at most one PDU per SWC can be lost. This lost PDU is immediately replaced

by the next periodic emission but may incur an additional re-emission delay before being delivered on Ethernet once the routing path becomes active. This behaviour naturally suggests an extension of the mechanism: re-emitting the latest COM-buffered PDUs at the moment of the switchover to ensure that the most recent application updates are preserved, provided that their transmission periods remain sufficiently larger than the fault-handling time. Future work will examine how to generalise this retransmission strategy and assess its impact on timing and resource usage.

A second perspective is to explore the behaviour of the mechanism under higher network load and more complex traffic patterns. The present measurements were conducted with around 3% load on both CAN and Ethernet, which isolates the intrinsic timing characteristics of the protocols but does not fully reflect a heavily loaded in-vehicle networks. Increasing the load and introducing additional traffic classes or interfering flows would allow us to assess how latency, jitter, and the CAN-Ethernet offset evolve, and whether the fault-handling time and the no-loss condition remain satisfied in more demanding scenarios. This is particularly relevant for future zonal architectures in which multiple HPCs and ZCUs share common backbones and domain-specific buses.

Beyond these load-related considerations, the nature of the backup channel itself also merits deeper analysis. Although the mechanism demonstrates that Ethernet can serve as an effective switchover path, it naturally inherits different communication properties than CAN, notably in terms of timing regularity, ordering and delivery guarantees. Several extensions could therefore be considered to reinforce these properties when operating on the backup channel. In particular, selected building blocks from Time-Sensitive Networking (TSN), such as time-aware transmission, improved queue management or clock-synchronisation support could be incorporated to recover part of the determinism that is not provided by standard UDP Ethernet.

Another line of work is to broaden the fault model. The current study focuses on a permanent short-circuit leading to a clean bus-off situation. In practice, communication faults can be intermittent, asymmetric between nodes, or combined with topological issues such as partial disconnections or degraded terminations. Extending the mechanism to handle transient errors, glitch disturbances or recovery attempts on CAN (e.g. via ComM strategies or controlled re-enablement of the controller) would provide a more comprehensive view of its robustness. Such scenarios would also offer an opportunity to study reversion strategies from Ethernet back to CAN once the original bus has recovered, and to define the conditions under which such a reversion is both safe and beneficial.

Finally, the question of functional safety and availability deserves deeper examination. The present work provides an initial characterisation of the fault-handling time in a mixed AUTOSAR architecture and clarifies how the proposed reconfiguration mechanism behaves under a representative physical CAN fault. In current automotive practice, most safety mechanisms rely on fault detection followed by a transition to a safe state, rather than maintaining full service continuity. For many ASIL-rated functions, disabling the feature after a communication fault is sufficient to satisfy the safety goals,
and fully fault-tolerant behaviour is rarely implemented due to
cost, complexity, or architectural constraints.

In contrast, the mechanism explored in this paper aims to
preserve operational capability rather than merely ensure
fail-safety. By maintaining communication through a
dynamically selected redundant path, the system remains
available even under a permanent loss of the CAN
channel. Such an approach does not replace traditional
safety mechanisms but complements them by enabling a
fail-operational behaviour that remains uncommon in Classic
AUTOSAR systems.

To fully exploit the potential of this mechanism in a safety
context, the next step is to formalise its contribution to
system availability within a complete safety concept and to
quantify its diagnostic coverage. The mechanism already
provides a structured, measurable fault-handling sequence;
completing its safety integration will clarify how this controlled
fail-operational behaviour complements existing safe-state and
degradation strategies in future zonal E/E architectures.

6. RELATED WORK

Research on zonal automotive architectures has led to extensive
studies on fault detection, recovery, and communication fault
tolerance. While hardware redundancy has traditionally
been used to ensure robustness, recent work highlights
the growing importance of software driven reconfiguration
within AUTOSAR environments due to its flexibility and
cost efficiency. Time-aware anomaly detection and reaction
mechanisms, particularly in Time-Sensitive Networking
(TSN), have also been explored to improve communication
dependability under timing constraints [7].

Dynamic reconfiguration frameworks for fail-operational
automotive systems have been investigated through
simulation-based architectures capable of switching
between software tasks or communication routes in response
to faults [9, 8]. More recent efforts formalise redundancy
management and software-based reconfiguration at the E/E
architecture level, demonstrating that multiple communication
paths can be exploited to maintain communication in case of
partial network failure [10]. Other preliminary approaches
rely on dynamic partial reconfiguration (DPR) on FPGAs
to perform protocol switching (e.g. CAN-FlexRay) within
AUTOSAR environments [14]. However, these require
reconfigurable hardware and Complex Device Drivers, limiting
adoption in production-grade automotive ECUs.

In parallel, the avionics domain has developed mature
approaches to network-level reconfiguration in safety-critical
systems. Prior work has examined safe reconfiguration in
Integrated Modular Avionics (IMA) [15], dynamic network
reconfiguration strategies in aeronautical communication
systems [13], redundancy management improvements for
AFDX networks [6], and automated generation of fault
and redundancy management in fly-by-wire architectures [5].
While these studies highlight the importance of dependable
communication and structured fail-operational behaviour,
they rely on architectural assumptions (ARINC 653, AFDX,
IMA partitioning) that fundamentally differ from automotive
AUTOSAR Classic environments.

Across both domains, an identifiable gap remains. Existing
automotive studies do not address a runtime CAN→ Ethernet
switchover relying solely on standard AUTOSAR Classic
modules, with no hardware modification and full application
transparency. The mechanism proposed in this paper fills this
gap by demonstrating a software-only cross-protocol re-routing
strategy that preserves AUTOSAR functional-safety measures
and can be deployed directly on production-like HPC-ZCU
platforms.

7. CONCLUSION

This paper investigated whether communication continuity
can be maintained in centralised automotive E/E architectures
when the primary CAN channel fails, without modifying
the receiving node and while remaining fully compliant
with Classic AUTOSAR. We introduced a cross-protocol
fault-handling mechanism that dynamically reroutes selected
PDUs from CAN to Ethernet using only standard AUTOSAR
modules, relying on a structured sequence of detection,
decision and reconfiguration steps.

The mechanism was implemented on a representative
HPC-ZCU platform and instrumented to characterise its timing
behaviour. The measured worst-case fault-handling time of
3.042 ms demonstrates that a permanent CAN short-circuit
can be detected and compensated within a few milliseconds,
well within the recovery budgets of many time-critical
automotive functions. The reconfiguration itself adds only
tens of microseconds, confirming that the approach provides
a fast, controlled and fully fail-operational transition between
protocols.

The study also showed that the switchover preserves the
receiver's behaviour and the ZCU continues to process
the same logical PDU with identical safety mechanisms,
regardless of the underlying transport path. Finally, a baseline
comparison of CAN and Ethernet timing properties established
the conditions under which the backup channel maintains
predictable behaviour during and after the transition.

Beyond its technical contribution, the proposed mechanism
addresses a fundamental availability concern in future
zonal E/E architectures. For functions whose value
relies on continuity of service such as advanced driver
assistance systems (ADAS), abrupt deactivation following
a communication fault can significantly degrade system
robustness and operational stability. By enabling a controlled
transition to a degraded communication mode through runtime
reconfiguration, the mechanism allows affected functions to
remain operational in a predictable manner until a safe fallback
condition is reached.

Beyond its technical contribution, the proposed mechanism
addresses a fundamental availability concern in future zonal
E/E architectures. For functions whose value relies on
continuity of service over extended operating phases rather
than on instantaneous reaction time, an abrupt deactivation
following a communication fault can significantly degrade
system robustness and operational stability. By enabling
a controlled transition to a degraded communication mode
through runtime reconfiguration, the mechanism allows
affected functions to remain operational in a predictable manner
until a safe fallback condition is reached.

Overall, the results confirm the feasibility of an AUTOSAR
compliant runtime communication switchover mechanism
capable of maintaining service continuity in centralised
automotive architectures. They demonstrate that cross-protocol
redundancy can effectively support fail-operational behaviour
with minimal architectural changes and limited resource
overhead, thus answering the core question raised in the
introduction.

REFERENCES

[1] ISO 26262:2018 - Road vehicles – Functional safety, 2018.

[2] AUTOSAR CP: Functional Safety Measures. Technical report, AUTOSAR, 2022.

[3] ISO 11898-1 - Road vehicles — Controller area network, 2024.

[4] Hadi Askaripoor, Morteza Hashemi Farzaneh, and Alois Knoll. E/E Architecture Synthesis: Challenges and Technologies. *Electronics*, 2022.

[5] Thorben Hoffmann, Robert Wipperfürth, and Reinhard Reichel. Enabling the automated generation of the failure and redundancy management for distributed and integrated fly-by-wire avionics. In *2021 IEEE/AIAA 40th Digital Avionics Systems Conference (DASC)*, pages 1–10. IEEE, 2021.

[6] Meng Li, Guchuan Zhu, Yvon Savaria, and Michaël Lauer. Reliability enhancement of redundancy management in afdx networks. *IEEE Transactions on Industrial Informatics*, 13(5):2118–2129, 2017.

[7] Philipp Meyer, Timo Häckel, Sandra Reider, Franz Korf, and Thomas C Schmidt. Network anomaly detection in cars: A case for time-sensitive stream filtering and policing. *Computer Networks*, 2024.

[8] Florian Oszwald, Jürgen Becker, Philipp Obergfell, and Matthias Traub. Dynamic Reconfiguration for Real-Time Automotive Embedded Systems in Fail-Operational Context. In (IPDPSW). IEEE, 2018.

[9] Florian Oszwald, Philipp Obergfell, Matthias Traub, and Juergen Becker. Using Simulation Techniques within the Design of a Reconfigurable Architecture for Fail-Operational Real-Time Automotive Embedded Systems. In (ISSE). IEEE, 2018.

[10] Florian Oszwald, Philipp Obergfell, Matthias Traub, and Jürgen Becker. Reliable Fail-Operational Automotive E/E-Architectures by Dynamic Redundancy and Reconfiguration. In *2019 32nd IEEE International (SOCC)*. IEEE, 2019.

[11] PEAK-System Technik GmbH. PCAN-View: CAN Bus Monitoring Tool, 2024. URL https://www.peak-system.com/PCAN-View.242.0.html?&L=1. Included with PCAN interfaces.

[12] Patrizio Pelliccione, Eric Knauss, Rogardt Heldal, S. Magnus Ågren, Piergiuseppe Mallozzi, Anders Alminger, and Daniel Borgentun. Automotive Architecture Framework: The experience of Volvo Cars. *Journal of Systems Architecture*, 2017.

[13] Cora Perner, Corinna Schmitt, and Georg Carle. Dynamic network reconfiguration in safety-critical aeronautical systems. In *2020 AIAA/IEEE 39th Digital Avionics Systems Conference (DASC)*, pages 1–8. IEEE, 2020.

[14] Hung-Manh Pham, Sebastien Pillement, and Didier Demigny. Reconfigurable ECU communications in Autosar Environment. In *9th International Conference (ITST)*. IEEE, 2009.

[15] Dajiang Suo, Jinxia An, and Jihong Zhu. A new approach to improve safety of reconfiguration in integrated modular avionics. In *2011 IEEE/AIAA 30th Digital Avionics Systems Conference*, pages 1C4–1. IEEE, 2011.

[16] Wireshark Foundation. Wireshark: Network Protocol Analyzer, 2024. URL https://www.wireshark.org/download.html. Version 4.