New Paradigms in System Safety

by Dev Raheja, Laurel, Maryland, and
Brian Moriarty, Woodbridge, Virginia

Pages 1 | 2 | 3

Introduction

This article is based on our long experience in system safety as practitioners, trainers and consultants. Some of our suggestions may appear to be impractical, but don't judge until you have tried them. All of these paradigms have worked.

The impact of system safety extends far beyond safety itself. It establishes the cost of risk and the indirect costs of risk to management credibility. This article presents a view of paradigms that have yielded extraordinary return on investment (ROI), making safety an excellent business case.

The Current State of the Art

Some companies have built up a strong and long-lasting reputation for safety. But, in our opinion, there are flaws in the field of system safety itself. These include:

1. A lack of productive debate on system specification. Without a cross-functional and productively challenged debate, many system functions are overlooked. That is why many engineering changes often increase the risk after the change is inserted. An incomplete specification is always prone to sneak accidents.

2. A lack of attention paid to hazards that are initiated in manufacturing, such as variations in components or, for example, production employees not putting enough torque on fasteners or leaving out a seal.

3. While everyone has a view for their subsystem in the system, rarely is there a true owner for the system of systems. Paying attention to parts only kills the connectedness among systems — the most dangerous inaction.

4. A lack of observance of the transition hazards when components are placed into subsystems, and subsystems are placed into a total system and tested. The build-up of subsystems and their integration into a total system justify examination of the transition hazards as the subsystems are joined together to eventually qualify a total system.

5. A lack of adequate safety training that addresses the total system. Major attention to only subsystems training can lead to potential safety problems by overloading the operator or maintainer of the system.

The New Paradigms

Paradigm 1: System Safety Must Extend to System-of-Systems Safety

Systems today are connected directly and indirectly with many other systems. A typical weapon system is linked to other systems, vehicles, soldiers and satellites in almost unlimited interactions. Tweaking in one place is bound to create some change in another place. As a result, an environment risk is impossible to predict with high confidence. Therefore, organizations following good processes and doing the right things need to rethink how to deal with such enormous complexity. Even the familiar Internet has so many interactions that an intruder can easily take advantage. Someone can be reading your Social Security number while you are typing it on a secure network. It is hard enough to do the right things, but it is even harder to know what the right things are.

So what can we do to control complexity? System safety needs to pay more attention to hazard analysis on the structure and architecture of the system-of-systems. The architecture must have traceability to safety-related interactions. Unfortunately, by the time system safety is involved, the structure and architecture are already chosen.

Paradigm 2: Spend Plenty of Worthwhile Time on Requirements Analysis

Here, we are talking about the functions of the system, not the safety functions that come later. Experience shows, and data supports, that the source of about 60 percent of mishaps is incomplete, ambiguous or poorly defined requirements. If the specification overlooks so many system details, how can one even think of system safety? Safety is not possible without accurate performance specifications. Areas such as human factors, reduction of No-Faults-Found (NFF), prognostics, cognitive requirements and prevention of warranty failures are vague in the specifications. These are all intertwined with system safety. Very few specifications address even obvious requirements for robust internal and external interfaces, as well as robust human interfaces. Requirements should include how the system should behave when a sneak failure occurs. A good specification will also address what the system shall not do. Those who are trying to build safety around a faulty specification should only expect an unsafe system. There should be a big contingency budget for making robust design changes that should have been included during the concept phase.

next page »