Fault Collection and Control Unit (FCCU)
Overview
The Fault Collection and Control Unit (FCCU) is a centralized hardware block responsible for collecting, classifying, and reacting to faults across the system.
It acts as the safety arbiter, ensuring that any detected anomaly—whether from sensors, peripherals, power management, clocking, or internal logic—triggers the appropriate response.
The FCCU enforces deterministic fault handling, supports configurable reaction strategies, and ensures that the system transitions into a safe state when required.
FCCU in the Safety Architecture
The FCCU aggregates faults from multiple sources, classifies them, and triggers deterministic reactions that lead the system into a safe state.
Role in a Safety Architecture
The FCCU is a cornerstone of functional safety because it:
- aggregates fault signals from multiple subsystems
- classifies faults based on severity and safety relevance
- enforces deterministic and time‑bounded reactions
- coordinates safe‑state transitions across domains
- ensures that no single fault can bypass safety mechanisms
- provides visibility to software through status registers and interrupts
The FCCU is the central decision point for hardware‑level safety enforcement.
Fault Sources
The FCCU typically receives fault inputs from:
Clocking
- loss of clock
- frequency drift
- PLL unlock
Power and Voltage
- undervoltage
- overvoltage
- brown‑out
Memory Protection
- ECC errors
- parity faults
- address violations
CPU and Processing
- lockstep comparator mismatches
- illegal states
- watchdog failures
I/O and Peripherals
- stuck‑at faults
- short‑to‑battery / short‑to‑ground
- protocol violations
Safety Peripherals
- ADC self‑tests
- sensor plausibility checks
- CRC monitors
External Devices
- PMIC fault lines
- external watchdogs
- board‑level fault signals
The FCCU is the convergence point for all safety‑relevant diagnostics.
Fault Classification
The FCCU typically distinguishes between:
Critical faults
Require immediate safe‑state transition
(e.g., CPU lockstep mismatch, clock failure).
Non‑critical faults
Require logging, notification, or controlled degradation.
Recoverable faults
Can be cleared by software after diagnosis.
Latent faults
Detected during periodic self‑tests or BIST routines.
Classification determines the reaction path and timing constraints.
Reaction Mechanisms
The FCCU supports multiple reaction strategies, often configurable per fault:
- interrupt generation — notify software for controlled handling
- reset assertion — system‑wide or domain‑specific reset
- safe‑state activation — drive pins or actuators to predefined values
- clock or power gating — isolate faulty domains
- error signaling — propagate fault information to external devices (e.g., PMIC)
- escalation logic — increase severity if faults persist or accumulate
These mechanisms ensure deterministic and timely fault handling.
Configuration and Protection
FCCU configuration is safety‑critical and must be protected:
- write‑once or lockable registers — prevent accidental or malicious reconfiguration
- startup configuration — FCCU initialized early during boot
- redundant configuration checks — CRC or mirrored registers
- secure integration — prevent access from non‑safety software
Incorrect FCCU configuration can compromise the entire safety architecture.
Interaction with Software
Software interacts with the FCCU through:
- fault status registers — read fault causes and timestamps
- clear mechanisms — acknowledge recoverable faults
- diagnostic routines — periodic checks for latent faults
- safety manager — coordinate system‑level reactions and recovery
Software must follow strict timing and sequencing rules to maintain safety integrity.
Relationship with Security
Although the FCCU is a Safety component, it intersects with Security:
- fault injection attacks (voltage, clock, EMFI) can trigger FCCU reactions
- secure boot ensures FCCU configuration cannot be altered
- lifecycle states protect FCCU registers from unauthorized modification
- board‑level fault lines must be protected from spoofing
Safety and security must be co‑designed to avoid conflicting behaviors.
