If you read my last blog, I took you through how Functional Safety is actually a subset of Product Safety, and I told you I would show you how a robust Functional Safety Process, if employed across your design, development and production processes for ALL safety requirements, will assist your organization in meeting the Product Safety requirements of IATF 16949:2016.
Since there is quite a bit of information, we will look at the Product Safety requirements included in IATF 16949:2016 in two parts. Check back for the second half in a few weeks!
A) Identification by the Organization of Statutory and Regulatory Product-Safety Requirements;
When developing the Item Definition, one of the inputs required from ISO 26262:2011-3:2011, 5.4.1 is “(c) legal requirements (especially laws and regulations), national and international standards”. With this information, all statutory or regulatory requirements should be defined. If your organization does not perform an Item Definition, you will also need this information in order to perform your DFMEA, so you should ask your customer for this information (at the very least they will need to provide you the markets in which the vehicle will be sold, and your organization would be required to research applicable statutory and regulatory requirements). I also recommend that you confirm that you have identified the same requirements as your customer.
B) Customer Notification of Requirements in Item A);
Your customer should specify what is required for customer notification requirements. At the very least, as mentioned above, you should check with the customer that the statutory and regulatory requirements you have identified are consistent.
C) Special Approvals for Design FMEA;
According to ISO 26262:2011, safety analyses must be verified. If the requirements for verification are followed, it is my experience that this meets the requirements of IATF 16949:2016 for this item. It has also been my experience that customers agree with this process; however, it is common that the customer will still perform a review of the results of the DFMEAs and provide an approval as well. It should be noted that there may be failure modes that result in a Severity rating of 9 or 10 that may not have been assigned as Functional Safety related. These are still considered Product Safety related and should be verified with the same diligence as Functional Safety related failure modes.
As a note, since the DFMEA should be used as a tool to ensure that appropriate safety requirements throughout all levels of the project (both for product and functional safety) have been identified, these special approvals should be very comprehensive.
D) Identification of Product Safety-Related Characteristics;
By properly maintaining requirements traceability, safety-related characteristics will need to be defined (e.g. safety-critical special characteristics on drawings are design requirements that would be provided for the manufacture of a product). If all safety requirements are properly included in the requirement traceability, product safety-related characteristics will be identified.
E) Identification and Controls of Safety-Related Characteristics of Product and at the Point of Manufacture;
Any product safety-related characteristics should also be included in the specification of requirements related to production, operation, service and decommissioning. Again, all safety requirements must be included, not only Functional Safety requirements. The documentation of these aspects may prove a bit cumbersome; however, depending on how the RMS is set, there are various ways that this can be accomplished.
F) Special approval of control plans and process FMEAs;
I have to say, I think that Part 7 is a little soft when it comes to clearly specifying the requirements relating to production of Functional Safety items.
Let’s trace the PFMEA requirements identified:
- Part 7 states: “Reasonably foreseeable process failures and their effects on functional safety shall be identified and the appropriate measures implemented to address the relevant process failures”. I would contend that this can be evaluated using a PFMEA.
- Part 9 identifies process FMEAs as a qualitative safety analysis method (see above).
- Part 2 identifies that verification is required of safety analyses. Therefore, the verification of the PFMEA should cover the special approval requirement (as long as all safety requirements are included, not just Functional Safety).
As identified in the section on DFMEAs, these special approvals should be very comprehensive.
For Control Plans, I don’t have as strong of an argument; however, I think it is prudent to perform a verification on the Control Plan. At the very least, Part 7 identifies: “The controls shall be performed in accordance with the production control plan. The related control report shall include the following information: the control date, the identification of controlled object, and the control results.” I would argue that if results in the control report pass for all safety requirements, this will constitute a verification of the Control Plan, and be sufficient to provide special approval. However, I would still recommend performing a verification on the Control Plan prior to running the control report activity.
G) Reaction plans;
ISO 26262:2011 states the following related to Reaction Plans:
- From Part 7: “Process failures occurring during production (including deviation of safety-related special characteristics from their authorised range) and their potential effects on functional safety shall be analysed, the appropriate measures shall be taken and their ability to maintain functional safety shall be verified.”
IATF 16949:2016 states:
- From 18.104.22.168: “The organization shall institute a reaction plan indicated on the control plan and evaluated for impact on compliance to specifications for characteristics that are either not statistically capable or are unstable.”
Since Product as well as Functional Safety items should be identified as Safety Critical Special Characteristics, the Reaction Plans should be developed to include ALL Safety items. I think this is inherently covered within IATF 16949:2016 as long as all safety items are identified with Safety Critical Special Characteristics.
H) Defined Responsibilities, Definition of Escalation Process and Flow of Information, Including Top Management, and Customer Notification
ISO 26262:2011 states the following related to Escalation:
From Part 2: “The organization shall institute, execute and maintain processes to ensure that identified functional safety anomalies are explicitly communicated to the applicable safety manager(s) and the other responsible persons.” Note that this includes the customer safety manager as applicable. Further in Part 2, ISO 26262:2011 states the organization shall have an operational quality management system (calling out IATF 16949 in the 2018 revision).
From Part 8: “The supplier shall report to the customer each anomaly which occurs during the development activities in their area of responsibility or in that of their subcontractors.” and after release for production “Each party that becomes aware of a safety-related event shall report this in a timely manner”.
If all safety related anomalies and safety-related events are included in this process, the Product Safety requirement in IATF 16949:2016 is met.
As you can see from the discussion above, if all safety requirements are included in the above processes, the requirements of IATF 16949:2016 are easily adhered to.
Keep in mind that as we look at meeting the Product Safety aspects of IATF 16949 by using your processes already in place for Functional Safety, doing so may require a slight change in the thinking of your organization. As I have said previously, if you consider that Functional Safety is a subset of Product Safety, then management of Safety should be carried out for ALL safety related aspects of the project. In that management, Functional Safety related aspects will have additional requirements that are addressed in ISO 26262, but Product Safety requirements will apply to ALL safety aspects of the project.
**Note, this blog is written based on ISO 26262:2011. Updates, if necessary, based on ISO 26262:2018 will be included in additional information this year. **