Supporting multiple levels of criticality

Éric Totel, J.-P. Blanquart, Yves Deswarte, David Powell

2002 · 39 citations · 6 references

Concepts

TL;DR

Current safety‑critical embedded systems support diverse tasks with varying criticality levels, so validating all software to the highest confidence is inefficient; instead, validation focuses on the most critical components while ensuring low‑criticality faults cannot corrupt high‑criticality ones. The paper defines an object‑oriented integrity policy to enforce that low‑criticality faults cannot corrupt high‑criticality components. The policy assigns each object an integrity level tied to its criticality and specifies method‑access rules that prevent lower‑integrity components from corrupting higher‑integrity objects, supporting multiple object types for flexible safety‑critical design. A prototype implementing the policy was demonstrated on a CORBA‑compliant distributed system.

Abstract

Current safety-critical embedded systems provide support for increasingly diverse and complex tasks, whose levels of criticality can be extremely different. Rather than validating all software to the highest level of confidence, it is more efficient to focus the validation effort on the most critical components. Consequently, it must be ensured that residual design faults in low criticality software cannot corrupt high criticality components. This paper defines an object-oriented integrity policy which ensures that such a property is enforced. Each object is assigned an integrity level related to its criticality. The policy defines rules to access the object methods so that no object can be corrupted by a lower integrity component. Several sorts of objects are accommodated, enabling safety-critical applications to be designed with great flexibility. This is illustrated by a prototype which is implemented on a CORBA-compliant distributed system.

References

6