One-sentence Summary

This paper introduces a formal model and deployment calculation approach for a fault-tolerant electric vehicle architecture that computes valid placements and redeployments of mixed-critical software components to execution nodes, isolating faulty hardware to maintain fail-operational behavior and formally analyze feature availability as execution resources decrease.

Key Contributions

• Introduces a formal model of a fault-tolerant software and hardware architecture for electric vehicles that explicitly represents mixed-critical software components and their fail-operational safety requirements.
• Presents a constraint-based approach to calculate valid initial deployments and fault-driven redeployments that automatically deactivate lower-priority components when execution resources decrease following execution node isolations.
• Establishes a formal design-time analysis framework to quantify system degradation and determine the exact subset of features that remain operational after hardware failures, with applicability demonstrated through an automotive domain case study.

Introduction

Modern automotive systems increasingly rely on software to deliver safety-critical features that must maintain fail-operational behavior even when random hardware failures occur. Traditional vehicle architectures struggle with this requirement because dedicated electronic control units and rigid communication buses prevent system-wide reconfiguration, while existing fault-tolerance methods often assume fail-silent models, fixed hardware setups, or limited replication without addressing mixed-criticality constraints. The authors leverage a formal system model and SMT-based constraint solving to automate the deployment and redeployment of mixed-criticality software components across execution nodes. Their approach ensures fail-operational features by redundantly allocating software and automatically downgrading lower-priority functions when hardware nodes fail, enabling designers to formally verify system degradation and feature availability at design time.

Method

The authors leverage a modular and scalable system architecture designed for automotive hardware and software integration, centered around a redundant and fault-tolerant execution framework. The overall system is composed of a Central Platform Computer (CPC), which aggregates multiple central execution nodes known as Duplex Control Computers (DCCs), and a set of peripheral Smart-Aggregates responsible for physical sensing and actuation. The DCCs are interconnected via redundant switched Ethernet links, forming a robust communication backbone. The Smart-Aggregates, which include integrated mechatronics such as wheel hub motors with steering, braking, and damping, are directly connected to the DCCs. This architecture enables a simplified hardware and network structure with a scalable set of execution nodes, supporting a homogeneous communication system based on industrial standards like Ethernet. The system is designed to support a runtime environment (RTE) capable of executing both safety-critical and non-safety-critical software side-by-side, ensuring a plug-and-play capability for retrofitting new software and sensors post-purchase.

The deployment model is structured around a formal definition of the vehicle system, which includes functional features, an application software architecture, an execution hardware architecture, and a configuration. The application software architecture is composed of Application Software Components (ASWCs) grouped into ASWC-Clusters, where each cluster contains ASWCs with the same Automotive Safety Integrity Level (ASIL) and fail-operational requirements. The execution hardware architecture consists of central execution nodes (DCCs) and peripheral Smart-Aggregate nodes. The configuration defines how ASWC-Clusters are deployed to execution nodes, either actively (executed) or passively (in memory). The deployment approach is designed to reduce complexity by focusing on clusters rather than individual ASWCs, as clusters exhibit stronger binding due to shared requirements such as data-transport delay.

The deployment process is governed by a set of constraints that ensure valid configurations, including time-budget limits, power-supply diversity for redundancy, and fail-operational requirements. Each ASWC is defined by properties such as Worst-Case Execution Time (WCET), ASIL, fail-operational level, and minimum fault-tolerance time (minFTT). The fault-recovery time (FRT) of the vehicle determines whether slaves are deployed as hot-standby or cold-standby, based on the comparison between minFTT and FRT. The deployment calculation is formulated as an arithmetic model, which can be solved using an SMT-Solver like Z3. This model ensures that all constraints are satisfied, such as no time-budget exceeding and the proper allocation of master and slave instances to different power-supplies.

In the event of an isolation, the system reconfigures its deployment to maintain functionality. A Platform-Availability-Graph (PAG) is used to model transitions between states of alive central execution nodes. The validity of deployments after a transition is ensured by arithmetic constraints that maintain the mapping of ASWCs to clusters and prevent unnecessary changes to previous allocations. Each ASWC-Cluster has properties indicating the requirement and presence of a hot-standby slave and the presence of a master. The deactivation order for ASWC-Clusters is determined by maximizing the sum of priorities of active instances, with clusters having the lowest priority being deactivated first. The priorities are derived from the ASIL and fail-operational level of the clusters. This ensures that critical features are preserved while non-critical features are sacrificed in the event of resource constraints.