Developing products according to EN ISO 13849 - the basics
Have you have realized that your product needs to fulfil the safety standard EN 13849? Without prior training or experience it may feel like a daunting task. You may well feel that you have great difficulty to understand where to start and also how to find the most natural track from A to B, if there even is one. Many customers feel just that and to be honest I understand them. The standard is tricky and compared to a C-standard, where you have very clear requirements, the requirements in EN ISO 13849 can be very generic in nature and hard to grasp. In this blog series I will show a way to tackle the standard, even though there are other ways as well, and this is the way I use and teach my customers.
Revision of EN ISO 13849
The standard EN ISO 13849 is on the verge of getting revised and the new version will be released in spring 2020. I intend to inform in due time what the new revision will mean when it comes to developing products but this blog post will focus on the current standard. No need to talk in detail of what the new revision will mean yet, as it changes so rapidly, but in general a goal is to make it easier to grasp which is of course a very good thing!
What is the purpose of this blog post?
As I have already mentioned the standard is very broad in its scope and as such writing a blog post about it is a feat. What I am thinking is that we should take a fairly narrow example and walk through the steps. My plan is to describe how to create a safety function PL c with category 1* meaning we will not have any software involved and quite small amount of components: a switch, a relay and a hydraulic valve. If my audience wants one could dive into other categories in the future, including software development, in later blog posts.
The purpose of this blog post is not to be exhaustive in information on how to develop according to EN 13819 but rather to give a glimpse into what it means. Please feel free to contact me if you have any questions!
*There are 5 different categories in EN ISO 13849, Cat b and 1-4, where b is the "lowest" and 4 is the "highest". The requirements increase rapidly when you increase the categories. I assume hence forth that the reader has a general understanding of the terminology. If you do not understand something in the post, please contact me. Maybe I can explain it in a better way in the post.
Where to start?
At this point it is also a good idea to create a document overview of all of the documents you need to have in your project (you can download a template for that document here). This is to enable a reader to quickly get an overview of the status of the documents. This, together with the system description, could be the input for the risk assessment which is the next step.
When developing a safety related product one should focus a lot on the risk assessment. In our example we have a hydraulic valve that we want to activate. The valve activates a cylinder which in turn is attached to something “dangerous” and the flow is similar to this:
The generic risk assessment according to EN12100 has found that this is a hazard that needs to be handled by a safety function according to EN 13489.
In the risk assessment method described in EN 13849 (see figure below) we follow the tree and realize that we end up with S=1 (you cannot severe your hand but it can hurt), F=2 (you are working close to the function) and P=2 (it is unlikely that you will be able to react quickly enough if something goes awry). The result is thereby PLr=c.
The actual risk assessment is of course something that one should not do singlehandedly but rather a team of experienced people. Try to gather a team that can span across all of the products life cycles for best result. As an input to the risk assessment, write a system description explaining all aspects of the machine.
SRS (Safety requirement specification)
This is probably the most important document in the bunch (and there will be a bunch of documents) as it sets the tone for the entire project. The document describes the safety function in detail and works as an input to all the succeeding documents. If one aims too high, well the final cost of the product will be too high, and if one aims too low you may later realize that you need to do (expensive) changes to the product.
The idea is to describe the safety function that we have found in the risk assessment. You will describe the safety function in terms of:
What is the required reaction time.
What is the trigger,
What is the usage frequency,
how is it supposed to behave after the safety function has been triggered.
System architecture
etc
It is really good to discuss the SRS with someone with experience who can tell what the implications are of the requirements that you have put in. As I just said, it is important to get this just right. Our example is quite simple but you will still need to put in the effort here. So back to our example. The generic category 1 architecture looks like this:
And for our example it looks as such:
Note that we do not use a L in the example which is fine.
SVP – Safety Validation Plan
A very important part of EN ISO 13849 is the validation process. What has been found to be important in the SRS should be validated and in this document one writes what should be done. Each requirement should have their own test even though a lot of them can probably be tested together. This document basically will tell us how to handle each requirement that is placed on the product.
SVR - Safety validation report
The result from the tests described in the SVP is documented in a report.
Hardware component summary
Basically what you put in here is the components that you use. In our case the switch, relay and hydraulic valve. It should contain a list of the MTTFd values. This does not really need to be a specific document but could actually just as well be a BOM (Bill Of Material).
Calculations
You would here calcuate MTTFd (mean time to dangerous failure) according to a specific method described in the standard.
Systematic failures
In the standard there is a term called systematic failure. This means that you need to take appropriate actions to make sure that you do not design errors into the system. It does come down to methodology in how you actually develop the system and that you for instance use "good" components for the application.
Environmental influence
The product should of course be able to handle the environment it is used in. So for instance this document should refer to EMC test reports, shock and vibration test reports, climate tests etc.
Basic safety principles
In the standard EN 13849-2 there are a number of requirements that needs to be commented upon. An example of a basic safety principle is:
Well tried safety principles
Quote similar to basic safety principles so you would tackle this in the same way. An example of a well tried safety principle is:
Use of suitable material
Proper fastening
Simplification, i.e. keep the safety core as small as possible, do not use more components than necessary.
Well tried components
Not all components can be considered well tried, for instance one cannot use a PLC or microprocessor and call them well tried. Well tried components are only relevant for category 1 solutions. So what you do is to make sure that the components you use are a part of the lists in table A.3 and D.3 in EN 13849-2 and that you fulfil the requirements for it.
Faults considered and excluded
It is important to look at all relevant faults that you may encounter. Sometimes you will need to exclude a certain fault and this is made by having a much lower usage rate than the actual life time of the component plus making sure that the fault is actually okay to be excluded according to EN13849-2.