5.2.1 Definition of Safety

The word “safety” is used with different connotations in different domains, and even in the domain of automotive producers. Sometimes safety has been discussed as absolutely no harm to people or even no accidents whether there is harm to people or not. This definition can lead to useful analysis and results [1]. Since there are accidents, the products today would not be described as safe using this definition. Despite the efforts of producers, the driver can still cause an accident. Producers strive to prevent this.

Another approach is to define safety as freedom from unacceptable risk [2]. In this definition safety is not absolute. The concept of risk is introduced. Risk may be subjective, but for purposes of determining safety, the level of risk is assessed with rules or efforts to quantify the risk. The severity of the mishap is quantified, usually based on the extent of the potential loss. This loss may be restricted to harm to people. Then the frequency of the event that may cause the mishap is considered. To be safe the risk must be tolerable. This depends on the norms of society. Context is taken into account.

A now common definition will be used in this chapter. It is to define safety as the absence of unreasonable risk [3]. This definition also introduces the concept of risk and is similar to the previous definition from which it was derived. The probability of some level of harm resulting from a mishap, the ability to avoid that harm, and the exposure to situations that may result in the mishap are all taken into account. A judgment about acceptability is left to others. That the risk involved is reasonable may be determined by the measures taken to prevent the mishap. Many of these measures are discussed in Ref. [3]. Other measures may be taken. This results in “no unreasonable risk” and safety, in the above sense of the word, is achieved.

5.2.2 Safety Life Cycle of the Product

Every product has a life cycle, a beginning and an end. However the safety life cycle of products varies from product to product. Consider a utility plant as a product. Safety may be achieved by the plant in the end, but the plant matures over time to become safe. First the plant is designed and built. Then safety mechanisms are added to mitigate risks and ensure safety. The plant then starts operation.

Automotive products have a different safety life cycle. The business activity itself requires differentiation, to distinguish its product and attract buyers, so different concepts are developed. The product must be safe in concept. After an initial product concept is achieved, the design activity is performed. This design also must take into account safety measures. The product must be safe in design. The design is then manufactured and must be safe in manufacture. How the consumer will use the product is taken into account. The product must be safe in use. All automotive products are exposed to the possible need for maintenance. The product must be safe in maintenance. Finally the product’s life comes to an end. It must be safe in disposal.

5.2.3 Evaluating Risk

To determine safety, the risk must be determined. The risk being considered here is the risk of harm to people. The authority of the product is considered when determining the role the product may have in causing harm to people. If the product is a system, this determination can start by analyzing what actuation of any of the product’s functions, included in the system as a whole, can do. Frequently guidewords are used to systematically determine what harm actuation of system function can bring with it when it exhibits what is called malfunctioning behavior. For example, we consider whether harm can result for each of the functions if it has the following potential malfunctions:

This malfunction, of the given system function, is then cascaded up to the vehicle level to determine if harm may result. To illustrate this, consider a steering actuator in an automobile. If the steering actuator provides steering assistance in error (guideword 4), when not requested by the driver or inappropriately in the case of automated steering function, such as steering in the “wrong direction,” this may cause the vehicle itself to turn in the wrong direction and lead to the vehicle departing from its lane of travel. A lane departure could result in a wide variety of types of accident, such as sideswiping a neighboring vehicle, a head-on collision, or a rear-end collision. This has potential for serious harm. This reasoning is then repeated for each of the guidewords in the list.

To further determine risk, system communications are also considered, including communications between the subsystems of the vehicle as well as between vehicle and driver and, in future connected vehicles, between the vehicle system and other vehicles or infrastructure. This includes messages sent and received. Again these are systematically analyzed. For example, consider if harm can result for each of the following communication malfunctions:

Again this is cascaded up to the vehicle level. To illustrate, again consider a steering system providing a steering angle signal that may be used by a stability control system. Depending on the diagnostic capability of the receiving system, the ability to assess the “health” of the sending system for error or fault, this could lead to an intervention by the stability control system that could lead to a lane departure at the vehicle level. The same evaluation as above for this actuation may result. This again has potential for harm. As in the previous example, this reasoning is then repeated for each of the communication malfunctions guidewords.

5.2.4 Exposure to Risk

The potential for harm is evaluated in different driving situations. Such situations include highway driving, country road driving, parking, and other situations. These situations and other considerations are described in Ref. [4]. The quantification of this potential for harm may be determined using traffic statistics from various sources. Both Refs. [3,4] refer to this. This helps quantify risk by relating it to the likelihood of being exposed to it.

Not all risks are discussed in Refs. [3,4]. It is also important to consider harm that may result from fire, smoke, and toxicity. Often toxicity is considered in the choice of materials for the product. Fire and smoke are considered for the case when the vehicle is occupied and also for the case when the vehicle is not occupied. In the case when it is occupied, the ability to control the vehicle is considered. This will vary if the system is in or out of the passenger compartment. When the vehicle is not occupied, the potential for harm due to fire and smoke is controlled by the ability of the system to be supplied with energy. External switching may reduce this probability to a reasonable level without further consideration within the system. Otherwise further consideration may be warranted. The harm could be catastrophic.

In determining risk, we also consider the duration or frequency of exposure to the situations that provide an opportunity for harm caused by the product. For example, if each exposure may be a trigger for harm due to a latent product malfunction, then frequency is important. Otherwise duration, such as driving in rain, is considered. This is further discussed in Ref. [4]. Then the risks can be prioritized. This can be done for malfunctions, for example, using the automotive safety integrity level (ASIL) of a system function found in Ref. [3]. For other cases that are out of scope of Ref. [3], a similar prioritization can be done. It should be done systematically. The same principles apply.

5.2.5 Reducing the Risk

To reduce the risk to an acceptable level, the safety requirements for each life cycle phase are determined. For example, to have safety of the concept, the requirements for the concept to be safe are determined. This is repeated for each phase. The requirements are then verified.

5.2.6 Concept

To determine the requirements for a concept, the concept is expressed as an architecture in which the functional requirements are understood for each functional block. Then this architecture can be systematically analyzed to determine the safety requirements. A systematic analysis gives confidence that the requirements are complete. Such systematic analyses include the following:

Requirements from all other systems are always considered. An FTA is especially useful at the block level for determining what type of failure combinations may lead to a hazard. If a single failure may lead to a hazard, then it must be determined if the probability of such a failure is sufficiently remote, such as a mechanical failure where there is adequate design margin in a well-understood technology. For example, consider the strength of the rack in a rack-and-pinion steering system. If a single failure is not sufficiently remote, requirements may be elicited to create redundancies.

An ETA is particularly useful in determining the effect of functional failures. Each function of each block may be evaluated considering, for example, if it fails to execute, executes incorrectly or with the wrong timing. If a hazard may result, then there is a requirement for a safety mechanism to independently prevent the hazard. The independence is required so that this failure fault does not also disable the safety mechanism.

Diagnostic coverage is similar. If a fault can lead to an unsafe or a hazardous failure, then a specific diagnostic needs to be implemented to detect the fault and prevent the unsafe failure by implementing a safe state of operation. The diagnostic type provides the required coverage. This leads to specific requirements.

There is confidence that these safety requirements are complete when the systematic analyses are complete. This requires review of the analyses. It may be by an independent peer review. Another means of performing the review is through simulation of the requirements and the response to inserted faults to determine if the faults are properly managed.

The safety requirements are then assigned to architectural blocks. These are the same architectural blocks that represent system functional requirements. Each safety requirement is uniquely identified, atomic, and verifiable. To avoid complexity, the safety requirements and architecture are hierarchical. Lower level safety requirements satisfy the parent safety requirements. These safety requirements are split between hardware and software safety requirements. In addition, safety requirements are assigned to other systems to document assumptions concerning the behavior of these systems to achieve safety. This supports subsequent verification.

5.2.7 Design

The design is made consistent to the architecture. This allows the design to be created to satisfy the safety requirements directly. Then traceable hardware safety requirements can be derived from the architectural requirements to enable requirements-based detailed hardware design. Further hardware safety analyses may be performed to derive further safety requirements that may emerge from the design chosen. Such analyses may include analyses of single point failures and dual point failures. Such analyses are described in Ref. [3].

In a similar manner, traceable software safety requirements can be derived from the architectural requirements to enable requirements-based detailed hardware design. Further software safety analyses may be performed to derive further safety requirements that may emerge from the design chosen. A potential analysis useful for this is an ETA as described in the concept discussion earlier. This is useful to elicit safety requirements to cope with the software reaction to the exception of a hardware failure. The design may be improved to meet these safety requirements. Systematic software errors can be controlled by following a mature software process. This is not discussed here. Sometimes diverse software is used.

After the design is complete, it is verified to meet the safety requirements. Appropriate methods are chosen for verification. For example, if Ref. [3] has been used, then methods may be chosen based on ASIL. The actual verification detail, such as the test case, is identified for each safety requirement. The verification method is executed. Verification is performed hierarchically from bottom to top. The result of each executed verification method is reviewed to determine if the pass criteria have been met, and the result of this review is recorded. All nonconformances are resolved. To ensure completeness of verification, a systematic review of the status of all requirements and verification is implemented. Sometimes automation may help determine status. This simplifies the review process.

5.2.8 Manufacturing

The intent of safety in manufacturing is to retain the safety designed, throughout component production and assembly and into the product when it is manufactured. To elicit the complete set of safety requirements to ensure this, systematic analyses are performed. These include the design failure modes and effects analysis (dFMEA) and the process failure modes and effects analysis (pFMEA). The dFMEA can elicit critical characteristics to be controlled in manufacturing. Appropriate process controls are implemented to achieve the critical characteristics. The pFMEA elicits safety requirements to mitigate any process errors that may affect safety. Again, process controls are mitigated. The manufacturing organization provides feedback to the product design organization if these requirements cannot be met. Appropriate changes are implemented.

The manufacturing safety requirements are documented and traced to the process. This includes any configurable software, for example. When a manufacturing process change is proposed, these safety requirements are taken into account. Thus it can be ensured that the improved process is as safe as the process it replaces. No unreasonable risk is introduced.

5.2.9 Maintenance

When considering safety in maintenance, the user’s manual is also considered as well as the maintenance manual. Warnings are included about potential misuse as well as expected maintenance. For example, for a convenience system such as adaptive cruise control, any limitations such as weather or stationary object detection are explained. This calibrates the user’s expectations or sets user expectations appropriately. This calibration can be further reinforced through the message center in the automobile. Then the appropriate message is repeatedly presented at the appropriate time to support the user’s understanding.

The maintenance instructions take into account safety in installation. For some systems, misalignment may lead to potential hazards. A warning and instructions may be included. Likewise, for example, torque applied to bolts in the steering intermediate shaft may be critical. A warning and specification may be included. As needed, information concerning diagnostic tests or messages is included. If replacement is necessary for safety instead of repair, then this is made clear. Likewise, instructions may be needed for some foreseeable maintenance anomalies, for example, instructions on what to do if the system is accidently dropped. Is it possible to check for damage? May it be used?

In addition to maintaining safety of the system, safety of the maintenance personnel is also taken into account. Any kind of stored energy may require measures to ensure that the maintenance personnel are not injured by its release, for example. Warning labels and maintenance manual warnings may be appropriate. Also, inadvertent motion may be considered, such as movement of an electric steering system connected to a battery while on a hoist. Disconnection may be recommended.

For continuous improvement, field data from performed maintenance may be helpful. This may be especially important for new systems during its initial introduction. Instructions on what data to record and return may be included. In this way, improvement of the instructions and product is supported.

5.2.10 Disposal

Disposal is normally the final phase of the product’s life cycle. Many of the comments made above for maintenance are also appropriate for disposal. In the case of stored energy, it may be appropriate to discharge this energy when disposed. Airbags may be discharged when the vehicle is disposed. If there is a possibility that a system may be salvaged for reuse as used equipment, any safety requirements may be considered such as requirements to prevent an inappropriate installation due to calibration for another vehicle. Design measures may be possible. In addition the useful lifetime may be specified. A warning may be included.

5.3.1 Purpose

To ensure that safety is properly considered throughout the product, life cycle requires diligence. Therefore a systematic process is established for this purpose. Then this process can be managed; the tasks identified, resourced, and executed. The process creates evidence, such as work products, that this systematic process is followed. This evidence together with a safety argument becomes the safety case: evidence that the safety requirements have been elicited and evidence of compliance. With no evidence, there is no case.

5.3.2 Pillars of a Safety Process

A safety process can have 3 pillars: policy, audit and assessment, and implementation. These can be established independently. For example, independence of the assessment activity from the implementation activity can help ensure diligence. Such independence is recommended in Ref. [3].

An overall organizational policy helps ensure consistency, helps ensure uniform diligence, and helps ensure that best practices for safety are adapted across the organization. These best practices may include both analysis methods to elicit safety requirements and methods to trace these requirements. Also the overall organizational safety policy can set forth the strategy of how the organization will integrate a safety process into the organization’s development process. This integration is important to the developers. At the end of the development life cycle, the developers will have completed whatever process they were following. It is important that all considerations were taken into account, because closing gaps at the end may not be possible. This may be especially true for safety. Safety considerations start in the concept phase. Then they are implemented.

Audit and assessment are independent of the developers implementing the process. In Ref. [3] this is to include independence from the organization responsible to release the product. The audit is to ensure that the developers follow the process in the overall organizational safety policy. Nonconformances to this policy can then be independently escalated to executive management for action. Such audits ensure diligence.

Assessment is performed on the evidence that the process is being followed, such as work products. These work products are to show that the safety requirements have been systematically elicited. An example may be the single point fault metric of Ref. [3]. It is intended to contain all the safety-related hardware and have diagnostic measures appropriate for the ASIL. Again, independent assessment ensures diligence.

To control that the process is followed, it helps to measure what is expected. It is expected that the process delivers artifacts that demonstrate that the safety requirements have been elicited for each phase of the safety life cycle. It is also expected that compliance is demonstrated during each phase of the safety life cycle. For those requirements that fall within the scope of Ref. [3], the safety work products for each phase are defined in Ref. [3]. The requirements for these work products, and other safety requirements not in the scope of Ref. [3], can be satisfied by the work products of the organization’s development process. Metrics can be developed to indicate that this is achieved when it needs to be achieved to follow the safety process. Then there is confidence or assurance that the resulting products will be safe. It should be noted that failure to follow the process does not mean that the product is defective. In this case the evidence may be missing. Favorable metrics improve the confidence. Diligence is demonstrated.

To implement the safety process, each project that will release a product to the general public, includes plans to implement the safety process. The tasks to produce meaningful artifacts required by the safety process are identified for each phase of the safety life cycle. These tasks are then resourced adequately and planned to be executed on time. This requires that the scope of work is identified, for example, using a change impact analysis to determine what is planned to be changed from a baseline product and if product safety could be affected. Then the tasks are planned for those phases that may have a safety impact. A supportive environment for carrying out these changes is established. This includes change control and documentation. Requirements management is supported.

The analysis planned to elicit the safety requirements for these affected life cycle phases is performed. For example, if potentially safety-related changes to software are planned, then an ETA may be performed on those software modules involved in the change. An independent assessment is performed of this analysis. The analysis may be improved if necessary for acceptance. Safety requirements may be identified for these software modules, other software modules, or safety requirements may be identified for hardware, the system, or other systems. These requirements are captured so that they may be included in the design. Then the design tasks are executed. Verification tasks are executed to ensure compliance of the design to the identified safety requirements. The report of this verification is reviewed. Any noncompliance is resolved. The results are recorded.

To implement a project in this way, a safety culture in needed. The importance of safety in the product development process is recognized throughout the organization. This includes executive management to approve resources, project management to plan and allocate resources, and the development personnel. To obtain this recognition requires the support of management. When this support is evident, then training is offered and this training will be embraced. The training also includes training for management. Expectations become consistent.

5.3.3 Organization

There are 5 key requirements for a successful safety organization:

There are different organizational implementations to satisfy these 5 requirements for a successful safety organization. Each different organizational implementation has advantages and disadvantages. Consider a central organization. In this implementation the Head of Safety either manages or may be the safety auditor. The safety auditor checks each project to determine if the safety process is being followed. The safety assessors may report to the safety auditor. The safety assessors determine if the artifacts generated by the safety process are adequate for their purpose, and timely in their creation. This puts the safety assessors in a position to collect the data necessary for the metrics used to measure safety process conformance. The safety managers and engineers may report to the safety assessors. The safety managers and engineers are deployed to engineering projects where they participate in the product development process, plan, and help create the safety artifacts, such as a hazard and risk analysis.

There are advantages for a central organization. Each level of management is skilled in safety. This helps to foster technical competence. There is a clear career path to retain safety personnel in a safety role. It can include management or may be structured to also include a purely technical path. Because it is central, there is a structural foundation to support consistency in implementation of the safety process across different products the organization is developing. This can be encouraged by job rotation. There can also be load leveling across products. This also helps consistency.

There can also be disadvantages to a central safety organization. Even though the resources are deployed to support engineering, the rest of engineering may tend to take less responsibility for implementation of the safety process. There are many tasks necessary to launch a product. Product engineering may prioritize those not perceived to have support from the central safety organization. Also, because there are different organizations, the communication paths may not be well established. This is important so that safety-related changes are evaluated promptly. Also, safety requirements need to be communicated. Effective communication is needed.

A decentralized organization may also implement the 5 requirements for a successful safety organization. In a decentralized organization the safety auditor and assessor are organized separately from product development engineering. This is needed to achieve the required independence. The safety managers and engineers are assigned and managed by product engineering. They report directly into product engineering. The decentralized organization has the advantage that safety personnel are integrated directly into product engineering organization without “deployment.” Domain knowledge of the product is increased through normal maturing due to focused engineering experience. Organizational communication may be established.

There are also disadvantages in this case. A career path needs to be established to retain personnel in a safety role or turnover will result. This may be established by a technical career path or ladder for safety, a product engineering safety management path, or a combination. The management in product engineering that is responsible for the safety personnel may not be as skilled in safety management and analyses as the personnel being managed. Measures may need to be established for continuous training of the management and safety personnel. This may be from internal assessors or externally. An independent review and escalation path needs to be established. This may use internal or external assessors. Executives should always be included.