Roberth Jonsson
- 10 sep 2019
- 8 min läsning

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.

Schematics analysis

The schematics analysis is where you look at you schematics from a functional safety perspective. You do this by performing a FMEA (Failure Mode Effect Analysis) on the product. Start with your “O” and work you way back. What faults on the component can lead to that the safety function is no longer fulfilled? Can you detect it? Can you alter the design to remove the risk?

Analysis of user manual and maintenance manual

One must make sure that the safety functions of the product is properly described in the user documentation. For instance or example would be described as: Safety function category 1 PL d: As long as the switch is not pressed no movement of the cylinder is allowed.

In the maintenance manual there may be a requirement to exchange certain components in due time. For instance, in our example we have a relay and if calculations would show that this relay is not durable enough to handle the entire life time (with good enough margin) one could describe here that that specific component is to be replaced in say 5 years.

End report

When you finally have produced all documents and made all of the tests that you need and they have been vetted and reviewed you will use the look up table in the standard to see that we indeed have reached the correct PL. Hopefully the result is satisfactory and you can now see that you indeed have fulfilled the requirements of the standard! If not, well then it is time to go back and see what could be changed in order to get through.

Roberth Jonsson

Consultant and founder, Zatisfy AB in Umeå. Roberth is passionate about helping companies make their CE marking a natural part of their working day. As an expert in EN 13849 he is working to develop the standard in the swedish standardization association SIS.

Find out more about Roberth here

English

182 visningar0 kommentarer