Locked-Step Architecture for Hardware Error Detection
Find Innovative SolutionsGenerate Solutions
Solution Overview
Problem
Embedded systems face challenges in detecting and addressing random and transient hardware errors, such as soft errors caused by cosmic rays and electromagnetic interference, which can lead to undetected faults that propagate and cause unpredictable failures, including heisenbugs, due to the complexity and unreliability of modern hardware.
Innovation Solution
A loosely-coupled locked-step architecture that utilizes replication and diversification through virtual synchrony to provide resilience against hardware and software errors, allowing for dynamic adjustment of resiliency levels and automatic isolation or reboot of failing components, ensuring 'fail-operational' behavior and compliance with safety standards like ISO 26262.
Engineering Contradictions & Design Principles
Engineering Contradiction Analysis
1Adaptability or versatility
If hardware size is reduced to increase integration, then device complexity and functionality improve, but reliability deteriorates due to increased susceptibility to soft errors from cosmic rays and electromagnetic interference
Solution Approach 1:
The system divides computation into multiple independent instances (primary and secondary computation engines) that operate in parallel. Each engine processes the same input data independently, and their outputs are compared to detect errors. This segmentation allows the system to maintain high functionality while improving reliability through error detection and correction mechanisms.
Solution Approach 2:
The patent applies different quality levels to different parts of the system. Critical safety functions use locked-step dual redundant architecture with highest reliability, while non-critical functions can use standard single-engine architecture. This local quality approach optimizes the balance between functionality and reliability based on specific system requirements.
2Reliability
If hardware error detection mechanisms are added, then reliability improves, but device complexity and cost increase
Solution Approach 1:
The system creates a secondary copy of the computation engine that replicates the primary engine's computation. Instead of adding complex error detection hardware, the patent uses software-based replication where the secondary engine copies the primary's logic and data processing. This copying approach provides error detection capability while keeping hardware complexity minimal.
Solution Approach 2:
The patent replaces mechanical/hardware error detection mechanisms with software-based detection. Instead of using additional physical sensors or hardware monitoring circuits, the system uses software processes (virtual machines, monitoring threads) to detect and respond to errors. This substitution reduces hardware complexity while maintaining reliability.
3Reliability
If locked-step dual redundant architecture is implemented, then reliability and safety compliance improve, but processing speed and productivity decrease
Solution Approach 1:
The system dynamically adjusts its operational mode based on safety requirements and system state. During normal operation, the primary computation engine runs at full speed while the secondary engine operates in a lighter monitoring mode. When safety-critical operations are detected, the system transitions to full locked-step mode where both engines execute simultaneously. This dynamic approach maintains high productivity during non-critical operations while ensuring safety integrity when needed.
Solution Approach 2:
The patent implements periodic verification where the secondary computation engine periodically checks the primary engine's outputs rather than continuously monitoring every operation. This periodic action reduces the overhead on processing speed while still providing adequate safety verification. The system performs full locked-step execution at key decision points and uses lighter monitoring between these points.
Data Source
Figure 1
Figure 2
Figure 3
AI summary
A system and method that detects hardware and software errors in an embedded system that includes detecting or measuring an operating state; causing one or more computation engines to operates in group synchrony; causing one or more active monitors that monitor the computation engines to an automotive integrity level to operate in group synchrony; synchronizing the communication between and from the plurality of computation engines and the plurality of active monitors, respectively; and arbitrating the output generated by the computation engines and the active monitors.