13849-1;4.6.2;"confidence from use"

[uwe_]

What does the standard mean when it says "use of suitable programming languages and computer-based tools with confidence from use"? How would I demonstrate confidence in the tools?

To make a concrete example - for the test of a safety function I would like to use a USB-CAN adapter to send test CAN frames to a safety ECU to verify it's function. Potentially this adapter could lose messages, duplicate them ect. (all the potential errors mentioned in IEC61508-2 7.4.11) and therefore mess up test results.

I could now do some previous tests with the CAN-Adapter first to see if it causes any problems - but would that suffice even thought it cann't be tested exhaustively? Would tests need to be run for a time compareable to the required performance level of the tested safey function or could I set up a set of test cases that, when it passes, seems to be a reasonable sample of all possible CAN messages and therefore all other are expected to work?

 

[BrianPetersen]

Who built the "safety ECU", and who built the "USB-CAN adapter", and who is taking responsibility for what? Which parts of this system have a declaration of conformity, and what do those declarations say? Where's the risk assessment, where's the FMEA? Are you on the end-user side of this, or are you proposing to build one of the components involved, or is someone else building it and it's your responsibility to test it?

ISO 13849-1 is enough of a nightmare on the end-user side (me). I don't know how safety-component manufacturers do it, especially when network-communication is involved. We rely on the declaration of conformity provided by others. There's no other realistic choice for a simple end-user like me.

I believe you're going to find that the safety PLC and the components that it's meant to interface with, are sending packets back and forth between each other to confirm that they are each awake. If you disconnect the network cable, you sure find out about it in a hurry.

 

[uwe_]

Who built the "safety ECU", and who built the "USB-CAN adapter", and who is taking responsibility for what? Which parts of this system have a declaration of conformity, and what do those declarations say? Where's the risk assessment, where's the FMEA? Are you on the end-user side of this, or are you proposing to build one of the components involved, or is someone else building it and it's your responsibility to test it?

The safety ECU is something the company I work for may begin to develop soon. For that I try to figure out the parts of the norm that I don't yet fully understand. The USB-CAN adapter is a off the shelf product without any safety guarantees but we used it in some projects in the past for development and debugging and as I stated I would just like to continue using it for the tests and verification of the system. The problem with arguing with the past use is that we didn't do any systematic data collection on the development tools which could help with a Route 2 argument.

The FMEA for the CAN-Adapter is rather simple - for all it's potential failure modes at worst it would result in an undetected error in the product.