News About John X. Wang

Defining Safety Requirements During New Product Development (NPD)

  • Jul 27, 2019 |

    Based on Industrial Design Engineering: Inventive Problem Solving, a systematic method for human safety integration early in the design process has been developed. Called Industrial Risk Engineering Design (IRED), this method facilitates the generation of safety requirements through past experience analysis and design choices analysis all along the design process. Design parameters thus result simultaneously from technical and safety functional requirements. This CRC Press News deals with the problem of defining safety objectives and flow down requirements early in the product design process. It highlights the mechanism offered by IRED for generating non-technical design objectives when preparing the requirements and constraints list. It shows that there are different typologies of safety objectives depending on the evolution of the product. In fact, there is a specific type of safety objective/requirements to be taken into account in a specific design stage. Finally, the applicability of the method is demonstrated through the application to a water faucet case study and mechanical person-machine interfaces.

    The question that we tried to answer in this CRC Press News is:

    • what is a safety requirement?

    Consideration of this question is based on the definition of design objectives (functional requirements and constraints).

    Based on IRED, we can convert the defined risks into functional safety requirements, integrated into the specification document and taken into account in the design stages. These requirements are enhanced and specified throughout the design process through risk analysis related to the design choices and are considered as evolving simultaneously with the product development. Safety requirements are defined throughout design and added to the specification documents. Consequently, the specification document is enhanced through the possible undesirable events and serves for verification and validation. Integrating the safety functional requirements into the technical product design, all along the product development, constitutes the risk reduction process. These operations of design synthesis, analysis, risk and safety requirements identification correspond to the conceptual model of the IRED approach.

    As the design parameters' characteristics typology depend on the design stage, the potential risks depend on the considered design stage as well. This observation leads us to consider that there is a mapping process between design and risk describing the compatibility between the design and the human characteristics. Therefore, the design process communicates with a "risk process" which is divided similarly into three steps according to the abstraction level of the solution. Thus, we noticed the Human-Principle Interaction (HPI), Human-System Interaction (HSI) and the Human- Machine Interaction (HMI). The HPI corresponds to the interaction between the human and the design solution in the conceptual design stage. The HSI corresponds to the interaction between the human and the design solution in the embodiment design stage. Finally, the HMI corresponds to the interaction between the human and the design solution in the detailed design stage. This "risk process describes the safety requirements generation and the risks identification processes.

    The Human-Principal Interaction (HPI)

    The HPI corresponds with the conceptual design stage. From the design point of view, at this level the overall functional requirements are decomposed into sub-requirements less abstract and one or more working principles are selected. Therefore, the potential interaction with human could be related either to the environment of the product or to the chosen working principle. From this interaction safety requirements related to the environment and to the solution's principle will result.

    The Human-System Interaction (HSI)

    The HSI corresponds with the embodiment design stage. The conceptual design working principles are structured and the occupied as well as available spaces are defined. In addition, the way in which the product will function is also specified. The dangerous zones and the intervention zones of the user are defined. The user location is related to functional and physical structures. At this step, the interaction with human is related either to the human activity or to the nature of the structuring parameters.


    The HMI corresponds with the detail design stage. From the design viewpoint, the product components, layouts, etc. are defined. Notice that traditionally, at the end of this stage, risks are analyzed and corrective actions are implemented. Normally, in IRED approach, potential accidents and ergonomics are handled systematically. Here, less important risks related to components, final forms, etc. are studied. At this stage, potential interaction mainly involves the design technical choices.

    Ecosystem Requirements (ESRs)

    We call the elements in interaction with the product in a given lifecycle situation "ecosystems". They may correspond to physical, human, environmental, etc., components. This context outlines safety requirements related to the use context of the product. These requirements are deduced from risks arisen in ground (experience feedbacks) due to the use of the same or similar products. At the associated design phase, the product is described through its desirable functionalities (mainly technical), design constraints, characteristics and super-systems. The context of ESRs completes these technical requirements with others ensuring the minimization of risks generated by the super-systems. This kind of risk exists and is totally independent of the design choices. In this regard, this type of safety requirements is expressed by an infinitive verb connecting two or more super-systems that belong to the considered use situation. In this context, safety requirements are input requirements and are specific to the overall design goals. Here, safety imposes the designer to take specific actions that could be well specified.


    System Requirements (SRs)

    We call the product's structure and architecture the "system". This structure is based on the solutions' principles organization and structuring. This context describes the safety requirements leading to the product's structure identification. From the human point of view, this structure induces a procedure resulting from the product functioning mode. A procedure is a set of activities cooperating in a chronological way in order to reach a specific goal. Therefore, we consider a procedure as the succession in time and space of the multiple tasks that a user must do. At this stage, design consists in functions allocation between the solution and the human in an ordered way. Functions' allocation is directly affected by the working principle chosen at the phase which defines the nature of the activity (automated or manual) as well as the human intervention degree and its frequency. This will set constraints to point out the better product's structure. Here, human safety is characterized by the human spatial position, his activity temporisation and his anthropometric data. In addition, the nature of the human activity is involved by his physical efforts limitations. These physical limitations will involve product functioning mode as well as dimensioning and materials choices. At this design stage, human characteristics are input constraints defined at the beginning of the design process. These constraints may result from either the experience feedback or the standards. The main characteristic of this context is to describe spatial and temporal separation between the product and the human. Besides these constraints, this context contains system safety requirements. These requirements consist of input constraints specification according to the physical design choices.

    Sub-System Requirements (SSRs)

    We call the product's components that allow finishing the product at the detail design level the "sub-system". This context describes safety requirements involving the components choices. A large number of these components constitute the human-machine interface. The human-machine describes the interaction between the user and the product in the use phase. This interface results from the nature of the human activity. More precisely, this context describes the safety requirement that leads to the product's final components choice according to the required human characteristics (vulnerability and ergonomic). The difference with the previous types of interaction is that here, safety requirements have minor effects on the global product safety. At this level, safety is expressed as functional requirements induced by the previous levels. These requirements result from the risk remaining in the previous levels.

    Safety Objectives Typology

    System safety objectives are defined during design and are true for a specific design and are the consequence of the design choices. Risks related to the design parameters choices are converted into safety requirements and are to be taken into account in the following design stages. System safety objectives are functional requirements. This type of functional requirement is created during the design process when some constraints are not satisfied. More precisely, it consists of unsatisfied constraints that are converted into safety requirements to be taken into account in the design stages. In fact, unsatisfied constraints are specified when progressing in design and necessitate design parameters.

    Case Study 1: Dual Knob Faucet

    The most common injuries from using domestic hot water are skin burns. Accidents affect mainly children and older people because of their limited mobility. Hot water can reach the 60°C, exceeding the 38°C the legal safety temperature. In addition, over 50°C, hot water causes serious burns.

    The technical functional requirements of dual knobs faucet are:

    • FR1: Control the temperature of water;

    • FR2: Control the flow of water.

    Definition of Water Faucet Input Safety Objectives

    This requirement is then integrated to the requirements list and is measured by:

    Functional requirements Measures

    • FR1 : Control the temperature of water 0 ≤ Tm ≤60°C

    • FR2 : Control the flow of water 1,5 ≤ Pm ≤ 4 bars

    • SR3 : Maintain a safe temperature 0 ≤ Tm ≤38°C

    Tm and Pm are respectively the temperature and the pressure of the outlet water. In addition, limited mobility is an ergonomic problem. This risk generates a “safety constraint” «Take into account the mobility of the users» to be taken into account during the embodiment design stage. The consideration of the experience has lead to a new FR noted SR3.

    Definition of The Water Faucet System Safety Requirement

    Here, we will consider that the conceptual design of the water faucet is validated. The system safety requirement thus results from design parameters analysis. The analysis of the design parameters shows that the outlet water temperature may reach the 60°C and thus exceeds the legal safety temperature. If the conceptual design is validated, this risk is converted into a system safety requirement at the embodiment design.

    Physical domain

    Accident Tm>38°C -> burning

    Functional domain

    System requirements

    SR2.1: Minimize the intervention of the user to assess the outlet water temperature

    The little consideration of the experience at the conceptual design (HPI) stage has lead to this new “system FR” in the “embodiment design stage” (HSI). In addition, Considering the interaction between the temperature limiting device and FR1 to control the temperature, the designer’s task is to decouple the functional requirements. This could be accomplished by selecting alternative DPs. In the absence of FR3 (maintain a safe temperature), the solution would be driven to a lower triangular. It would be better to first control the temperature and then control the flow. The presence of FR3 to limit the temperature could remove the risk of burning. The presence of a coupling between FR1 and FR3 indicates an expected interaction between the temperature control and the device to maintain a safe temperature.

    Case Study 2: Alpine Ski Bindings As Special Human-Machine Interfaces

    Mechanical human-machine interfaces, such as an alpine ski bindings, hand power tools or vehicle steering columns, need to transmit control loads from the user to the machine. The potential to transmit injurious loads to the user should be avoided. The top FRs is to transmit control loads and the top SR is to filter injurious loads. Steering columns filter injurious loads by collapsing under impact in a collision. The collision and normal driving loads are different enough so that there is no mistaking one for the other and there is no inadvertent collapsing of steering columns. It is known from experience that ski bindings however suffer from inadvertent release, i.e., mistaking non-injurious loads for injurious loads. In the “conceptual design stage (HPI)” in the context “Ecosystem requirements” one or two safety requirements can be defined.

    • SR1 is “to avoid transmission of injurious loads”.

    This is common to all such mechanical interfaces. In the case where SR1 is satisfied by a release system, whereby control might be lost, such as, a conventional releasable ski binding with explosive bolts, or an ejection seat, then

    • SR2 would be “to avoid inadvertent release”

    At this point, the design is similar in some ways to the previous case study on the faucets. It is necessary to separate FR1 and 2. At the HSI stage, two sub-systems could be envisioned based on the magnitude of the loads, provided that there is a clear difference in the control and injurious loads. Experience shows however that high loads, even potentially injurious loads, can be sustained without injury for short durations. If the binding releases in these situations, then loss of control and serious injury from collisions can result. In the HSI stage this calls for a method to systematically discriminate between actual injurious situations and non-injurious, high-level, short-duration load spikes.

    Two system level approaches have been developed to avoid inadvertent release. One is impulse-based and has been developed at the detailed level electrically. It tests that the load is of sufficient duration to approach injury potential before release. The other is work-based and has been developed at the detailed stage using preloaded springs to transmit control loads below the preload without significant displacement until the preload has been exceeded. It assures that work is done on the mechanism at sub-injurious loads adsorbing energy that would have caused injury or release. The preloaded spring mechanism filters injurious loads while faithfully transmitting control loads and adsorbs energy that could cause inadvertent release.


    This CRC Press News deals with a method for the definition of safety objectives early in the design process. Based on Industrial Design Engineering: Inventive Problem Solving, the Industrial Risk Engineering Design (IRED) method gives the typology of safety objectives at each stage of design. When the design process is started, safety objectives are contextual requirements and ergonomics constraints. In this paper, it is shown that safety requirements generated during design are functional requirements. These requirements are the specification of safety constraints initially defined in design. Like technical objectives, safety objectives consist of input and system objectives and are described in terms of functional requirements and constraints. The application of the method to the water faucet and the ski bindings has been presented.

    See More
    Engineering - General, Engineering - Industrial & Manufacturing, Engineering - Mechanical, Ergonomics & Human Factors, Occupational Health & Safety