2
Safety Organizations

The Need for a System Safety Organization

Meeting consumer expectations for system safety in automotive products requires diligence to ensure that no unreasonable risk occurs after consumers purchase a product. There must be no unreasonable risk to either the consumer or to others exposed to the product's use throughout the product's life. The intended use and foreseeable misuse of the product must not cause unreasonable risk, and there also must be no unreasonable risk imposed on the consumer or others as a result of a failure of the product. This diligence must be driven consistently throughout the product organization at the vehicle level and at the supplier. Consumers expect a very intense effort to ensure their safety and the safety of their families by all who are involved in developing, manufacturing, delivering, and repairing the product. This includes executive management and functional management in both engineering and operations, including support functions.

Figure 1.1 shows what must be fulfilled in order to achieve what is expected for safety. As discussed in Chapter 1, these expectations can be easily overlooked. Thousands of engineering and operations personnel are involved in the launch of an automotive product, and diligence is required from all of these personnel to fulfill customer expectations for safety. Considering the large consumption of resources required to launch a road vehicle, as well as resources consumed developing and launching each of the vehicle's systems, a systematic approach to diligence with respect to safety is appropriate. To deploy this systematic approach across the enterprise requires technical support for execution. It requires management of the process, which also requires resources.

Consider a global tier 1 safety system supplier that supplies advanced driver assistance systems; braking, steering, and passive restraint systems, as well as other products with safety requirements. Such a supplier has multiple engineering development centers around the world. These development centers can support collaboration with local and regional vehicle manufacturers as well as global vehicle manufacturers VMs that have local development centers in the region.

There are cultural differences from development center to development center as well as multiple engineering organizations within each development center. The cultural differences may be due to different languages and practices for everyday living and social interactions, as well as differences in business practices. Customer expectations are communicated by the customer in a more formal or less formal way from one technical center location to another. Schedules and content for the vehicle launch may be more carefully planned in advance or modified in an almost ad hoc manner throughout the launch cycle.

The engineering organization at a technical center may be organized by engineering specialty, such as software engineering, electrical hardware engineering, mechanical engineering, and system engineering; or by product function, such as applications engineering or advanced product development independent of the particular application. Both applications engineering and advanced development engineering may also be organized by engineering discipline. There may be an engineering quality organization that checks a sample of the projects to determine if the process steps are performed on time. A global quality standard process can be instantiated on each project being supported by the engineering quality department in order to ensure compliance with the engineering quality standard and to standardize on a global engineering process for the enterprise.

Each of these engineering specialties has particular capabilities for design and analyses. System engineering provides the concept and high-level requirements for the system, hardware, and software. Software engineering derives software requirements for the software architecture, software modules, and software units. Hardware engineering develops requirements and design for electrical circuits. However, none of these engineering specialties is system safety. The specialized elicitation and derivation of safety requirements is not the specific domain of system, hardware, and software engineers; nor is the establishment and execution of a safety process included in the domain of engineering quality. How are system safety tasks managed? How are they executed diligently?

Many - perhaps most - automotive suppliers and VMs have safety organizations. The need to establish, support, and execute a safety process is universally accepted across the automotive industry. This goes beyond what is legally required by the regulations of each country, or the performance requirements in safety system regulations. These safety organizations may be separated into product safety and functional safety, or they may be combined into a system safety organization.

The differences in these approaches are somewhat regional: for example, in the United States, it is common to see system safety organizations that include the safety of systems in case of failure and also consider the safety of the systems' intended functions without any failures. For example, such an organization considers the safety of an automatic emergency braking system in the case of a false detection of an object while the automatic emergency braking system is operating within its specification. In Germany, the safety of the intended function is addressed by the product safety organization, and the safety of systems in case of failure is addressed by the functional safety organization. System safety versus functional safety in automotive applications will be discussed in Chapter 3.

Functions of a Safety Organization

These safety organizations support the achievement of system safety throughout the safety life cycle of the product. This life cycle includes the concept phase, when the overall functional concept of the product is established and analyzed for potential hazards; the design phase; the verification phase; release for production; use; repair; and disposal. Activities include:

1. Determining or recommending a global safety policy for the supplier or VM. Such a safety policy directs the enterprise's general goals with respect to safety and references where process documentation responsivity may be found, or the policy may include specific responsibilities for safety-related tasks.
2. Developing and maintaining a system safety process. The safety process will detail the specific safety-related tasks, management of execution of these tasks, and responsibilities for execution, assessment, and auditing.
3. Executing systematic analyses of the system, hardware, and software. Many of these systematic analyses take the form of a HAZOP, such as a hazard and risk assessment of the system functions. Other analyses include a software architectural analysis, hardware failure modes and effects analysis (FMEA), and single-point fault analysis.
4. Training system, hardware, and software engineers as well as management, operations, and supporting functions concerning their roles in achieving system safety. This training may include basic online process training, specialized training for each engineering domain, operations training including background for interaction with outside auditors, overall priorities, expectations of management, how achievement of these expectations will be reported to executive management, and executive actions that are required.
5. Assessing work products. This includes what level of independence is required for assessment of each potential work product, what tools are available for performing these assessments, communication between the author and the assessor, how long it may take, what should be included in the assessment, required actions on assessment findings, storage of the assessment, release of the document, and what may be shared with the customer or outside parties.
6. Auditing projects and reporting. This includes periodic audits of all projects by a specified auditor, actions and follow-up on all actions, reporting the audit report, actions still outstanding, and any escalations to senior management for urgent resolution.

To perform these activities efficiently, a safety organization is established and staffed. The staff must include the necessary talent to execute each of activities just described. Assessments and auditing need to be performed by staff that is independent of the release organization. The safety analyses need to be performed by individuals with domain knowledge and associated with the release authority.

This organization may be located anywhere in the automotive supplier's or VM's organizational structure, as long as the necessary independence is maintained for assessment and auditing. Staff for other activities, such as training and performance of analyses, may also be independent but are not required to be. However, there are advantages and disadvantages in how the safety organization is organized and where it is placed. There are critical success factors to consider, which will be discussed next.

Critical Criteria for Organizational Success

There are five critical success factors to consider for a system safety organization [5]:

1. The organization must have the talent to perform the safety tasks.
2. System safety must be integral to product engineering.
3. There must be a career path for safety...