Real-time Euclid: a language for reliable real-time systems
IEEE Transactions on Software Engineering - Special issue on reliability and safety in real-time process control
Analysis of Faults in an N-Version Software Experiment
IEEE Transactions on Software Engineering
Guest Editorial: A Review of Worst-Case Execution-TimeAnalysis
Real-Time Systems - Special issue on worst-case execution-time analysis
Using Simplicity to Control Complexity
IEEE Software
The worst-case execution-time problem—overview of methods and survey of tools
ACM Transactions on Embedded Computing Systems (TECS)
A Modular Worst-case Execution Time Analysis Tool for Java Processors
RTAS '08 Proceedings of the 2008 IEEE Real-Time and Embedded Technology and Applications Symposium
Worst-case execution time analysis for a Java processor
Software—Practice & Experience
| Hi-index | 0.00 |
Worst-case execution time (WCET) analysis is safe in theory, but it may not truly be safe in practice. Even if a particular analysis algorithm is sound, its implementation may contain bugs that result in unsafe WCET estimation. This potential for error is serious, given that the usual purpose of WCET analysis is to verify the correctness of hard real-time systems--software on which entire missions and even human lives may depend. A possible solution lies in N-version programming, where N teams of developers work independently on N unique but equivalent implementations. Although this fault-tolerance technique has been criticized for its statistical assumptions and high cost, it may be perfectly suited to address the inherent risks in implementing WCET analysis tools. This paper argues that N-version programming still has merit and cites an example of how the technique improved the quality of two WCET analysis tools at relatively low cost.