System safety terms, defined

The ANSI/ISA-84.00.01-2004 (lEC 61511) standard (Ref. 1) defines a safety instrumented system (SIS) as an "instrumented system used to implement one or more safety instrumented functions. A SIS is composed of any combination of sensor(s), logic solver(s), and final element(s)." lEC 61508 (Ref. 2) does not use the term SIS but instead uses the term "safety-related system." That term defines the same concept but uses language that can be broadly applied to many industries. 

Many of the equipment vendors have developed cost of ownership (COO) models, some traceable, at lease in part, to SEMATECH. These COO models may be used to account for all aspects of amortized costs and provide a user with a highly accurate anticipated cost schedule. At a minimum a COO model should include the cost of the system, utilities, facilitization, mean-time-between-failures, mean-time-to-repair, preventative maintenance, personnel, all consumable safety costs (including that of required support equipment), reactant, and substrate costs. Each of these parameters" should be well defined and guaranteed, and the user of such models should precisely understand how up-time, mean-time-to-repair, and other terms are defined. A 90% uptime schedule is useless if the system is routinely defined to be out of service, for maintenance, 25 % of the time. 

When this term is capitalized in this book, it denotes the specific form of safety engineering developed originally by the Defense Department and its contractors for the early ICBM systems and defined by MIL-STD-882. System safety (uncapitalized) or safety engineering denotes all the approaches to engineering for safety. 

Definitions of basic terms differ greatly among industries and engineering disciplines. A set of basic definitions is used in this book (see appendix A) that reflect common usage in System Safety. An accident is defined as ... 

The term hazard has been used in different ways. For example, in aviation, a hazard is often used to denote something in the environment of the system, for example a mountain, that is in the path of the aircraft. In contrast, in System Safety, a hazard is defined as within the system being designed (or its relationship to an environmental object) and not just in its environment. For example, an aircraft flying too close to a mountain would be a hazard. 

The Polish Standard PN lEC/ISO-TR 13335-1 (Polish Standard 1999) defines the term IT security as all activities related to confidentiality, integrity, reh-ability, availability, etc of a computer system. The term safety of a computer system is defined as the lack of negative impacts on surrounding environment computer operating system. 

One of the major problems confronting the system safety community is a lack of standardization or commonality. (This problem is discussed in detail in Chapter 4.) Presenting universally accepted definitions to even basic terms is therefore difficult because, by and large, they do not exist. The following terms are defined in nontechnical language to ensure the reader understands each term as used in this book. Specific definitions from documents widely used in the system safety effort are contained in the glossary, and definitions used by specific organizations are included in Chapter 3. 

This section has chapters devoted to process safety management, and in those chapters we will provide an overview of U.S. and Canadian requirements for process safety, define terms, provide some examples, and show the value of system safety philosophy when addressing the safety of processes related to the chemical industry. 

The term SMS is a relatively new term. As defined earlier, the concept of system safety is to merge the engineering with the management of the systan development and operation into the concept of system safety. Over the last 20 years or so, the term SMS has been coined. Chapter 4 is dedicated to discussing SMSs. Briefly an SMS is a... 

A fundamental challenge is then to ensure that safety requirements are satisfied despite the increased system complexity and the uncertainties introduced by the operation in open and not well defined environments. In general, the problem might be equated in terms of achieving system safety for potentially mass consumer products. From an application perspective, the workshop focuses on distributed and cooperative safety-critical systems. So far, the existing solutions are still insufficient or inadequate and therefore these systems are not allowed to operate in the public air space or on public roads because the risk of causing severe damage or even threaten human lives cannot be excluded with sufficient certainty. This justifies the importance of research in this area, and explains the interest on the subject by the academia and the industry. 

The first step is to analyze the technical process or system in terms of safety and define the so-called safe situation. The safe situation is a situation which, by definition, is equally or even more safe than the actual situation and can be achieved immediately out of the actual situation by taking simple action. 

A nonfunctional requirement is a requirement that specifies criteria that can be used to judge the operation of a system, rather than specific behaviors. This should be contrasted with functional requirements that define specific behavior or functions. In general, functional requirements define what a system is supposed to do whereas nonfunctional requirements define how a system is supposed to be. Nonfunctional requirements are often called qualities of a system. Other terms for nonfunctional requirements are constraints, quality attributes, quality goals and quality of service requirements, and nonbehavioral requirements. Nonfunctional requirements address the hidden areas of the system that are important but not always immediately obvious to the user. They do not deal with functionality they tend to be fuzzy and global factors necessary for system success. They tend to be ility -type requirements, such as safety, reliability, maintainability, and scalability. 

Note that the term SCL goes by different names, such as SHRI, SL, DAL, or SIL, depending on the guidance documentation used. These alternate terms and similar SwS processes are defined in M1L-STD-882C, the DoD Joint Software Systems Safety Engineering Handbook and RTCA/DO-178B. 

In this section safety engineering is discussed in its broadest sense, so the term system can be defined as equqnnent, working practices, organisation, etc.,... 

---