Measurement and Application of Fault Latency
IEEE Transactions on Computers - The MIT Press scientific computation series
Fault Injection Experiments Using FIAT
IEEE Transactions on Computers
FERRARI: A Flexible Software-Based Fault and Error Injection System
IEEE Transactions on Computers - Special issue on fault-tolerant computing
The Exception Handling Effectiveness of POSIX Operating Systems
IEEE Transactions on Software Engineering
Xception: A Technique for the Experimental Evaluation of Dependability in Modern Computers
IEEE Transactions on Software Engineering
Preliminary guidelines for empirical research in software engineering
IEEE Transactions on Software Engineering
A Fault Injection Approach Based on Reflective Programming
DSN '00 Proceedings of the 2000 International Conference on Dependable Systems and Networks (formerly FTCS-30 and DCCA-8)
Jaca: A Reflective Fault Injection Tool Based on Patterns
DSN '02 Proceedings of the 2002 International Conference on Dependable Systems and Networks
Automated Robustness Testing of Off-the-Shelf Software Components
FTCS '98 Proceedings of the The Twenty-Eighth Annual International Symposium on Fault-Tolerant Computing
Comparing Operating Systems Using Robustness Benchmarks
SRDS '97 Proceedings of the 16th Symposium on Reliable Distributed Systems
Automatic Failure-Path Inference: A Generic Introspection Technique for Internet Applications
WIAPP '03 Proceedings of the The Third IEEE Workshop on Internet Applications
DOCTOR: an integrated software fault injection environment for distributed real-time systems
IPDS '95 Proceedings of the International Computer Performance and Dependability Symposium on Computer Performance and Dependability Symposium
Comparison of Physical and Software-Implemented Fault Injection Techniques
IEEE Transactions on Computers
Basic Concepts and Taxonomy of Dependable and Secure Computing
IEEE Transactions on Dependable and Secure Computing
Understanding The Linux Kernel
Understanding The Linux Kernel
Software Testing, Verification & Reliability
Injection of faults at component interfaces and inside the component code: are they equivalent?
EDCC '06 Proceedings of the Sixth European Dependable Computing Conference
Mutation Testing of Protocol Messages Based on Extended TTCN-3
AINA '08 Proceedings of the 22nd International Conference on Advanced Information Networking and Applications
SystemC-Based Minimum Intrusive Fault Injection Technique with Improved Fault Representation
IOLTS '08 Proceedings of the 2008 14th IEEE International On-Line Testing Symposium
Towards understanding the effects of intermittent hardware faults on programs
DSNW '10 Proceedings of the 2010 International Conference on Dependable Systems and Networks Workshops (DSN-W)
Model-Implemented Fault Injection for Hardware Fault Simulation
MODEVVA '10 Proceedings of the 2010 Workshop on Model-Driven Engineering, Verification, and Validation
Comparing the effects of intermittent and transient hardware faults on programs
DSNW '11 Proceedings of the 2011 IEEE/IFIP 41st International Conference on Dependable Systems and Networks Workshops
| Hi-index | 0.00 |
It is more important to properly handle exceptions, than to prevent exceptions from occurring, because they arise from so many different causes. In embedded systems, a vast number of exceptions are caused by hardware devices. In such cases, numerous software components are involved in these hardware device-originated exceptions, ranging from the device itself to the device driver, the kernel, and applications. Therefore, it takes a lot of time to debug software that fails to handle exceptions. This paper proposes a lightweight device exception testing method, and a related automation tool, AMOS v3.0. The proposed method artificially triggers more realistic device exceptions in runtime, and monitors how software components handle exceptions in detail. AMOS v3.0 has been applied to the exception testing of car-infotainment systems in an automobile company. The results based on this industrial field study have revealed that 39.13% of the failures in exception handling were caused by applications, 36.23% of the failures were caused by device drivers, and 24.64% were derived from the kernel. We conclude that the proposed method is highly effective, in that it can allow developers to identify the root cause of failure for exception handling.