Flight elements: Advanced avionics systems architectures

Space transportation objectives are associated with transporting material from Earth to orbit, interplanetary travel, and planetary landing. The objectives considered herein are associated with Earth to orbit transportation. Many good avionics architectural features will support all phases of space transportation, but interplanetary transportation poses significantly different problems such as long mission time with high reliability, unattended operation, and many different opportunities such as long nonoperational flight segments that can be used for equipment fault diagnosis and repair. Fault tolerance can be used to permit continued operation with faulty units, not only during launch but also, and perhaps with more impact, during prelaunch activities. Avionics systems are entering a phase of development where the traditional approaches to satisfactory systems based on engineering judgement and thorough testing will alone no longer be adequate to assure that the required system performance can be obtained. A deeper understanding will be required to make the effects of obscure design decisions clear at a level where their impact can be properly judged

Fault tolerance via diversity for off-the-shelf products: A study with SQL database servers

If an off-the-shelf software product exhibits poor dependability due to design faults, then software fault tolerance is often the only way available to users and system integrators to alleviate the problem. Thanks to low acquisition costs, even using multiple versions of software in a parallel architecture, which is a scheme formerly reserved for few and highly critical applications, may become viable for many applications. We have studied the potential dependability gains from these solutions for off-the-shelf database servers. We based the study on the bug reports available for four off-the-shelf SQL servers plus later releases of two of them. We found that many of these faults cause systematic noncrash failures, which is a category ignored by most studies and standard implementations of fault tolerance for databases. Our observations suggest that diverse redundancy would be effective for tolerating design faults in this category of products. Only in very few cases would demands that triggered a bug in one server cause failures in another one, and there were no coincident failures in more than two of the servers. Use of different releases of the same product would also tolerate a significant fraction of the faults. We report our results and discuss their implications, the architectural options available for exploiting them, and the difficulties that they may present