During your risk analysis, hazardous situations that can occur due to a software failure are given a probability of 100%. Since risk is a combination of the severity of the hazard and the probability of occurrence, a given hazard has a higher risk if it is due to software rather than hardware.
Plus, developing software with a process that complies with IEC 62304 can be hard. And expensive. It can take a lot of time and effort.
Naturally, some companies start to wonder:
Hey, we can move all of our software to an FPGA, and it will count as hardware! What a great loophole!
So, can you get out of complying with IEC 62304 if you implement all your software functionality in an FPGA?
My answer is: “Almost certainly not.”
Here’s why:
-
It’s disingenuous.
To be frank, are you in the business of finding loopholes in safety standards? Remember the safety critical mindset. Think of your device being used by your child or your spouse. Still want to cut corners in your safety process? -
Your risk analysis shouldn’t allow it.
If you’re doing your risk analysis properly, then a bug in your FPGA code should absolutely be considered as a failure mode, which may lead to a hazardous situation. This is no different than the software risk analysis procedure that you’d have to perform with your software. Any mitigation of that risk should require just as much rigor as that required to develop software. Hey, there’s already an accepted standard for developing software! Maybe, just use that! -
It probably won’t pass FDA. The FDA is wise to this practice. They are looking for it. Prepare to face some awkward questions during your review that you won’t have good answers to, because, let’s face it, you tried to find a loophole and got caught.
Now, am I advocating that all FPGA code, without exception, qualifies as software?
Not quite. The rule I use (and I unfortunately do not know where I first saw this, or I’d happily give credit) is that if the logic implemented in an FPGA can be tested by brute-force, it can reasonably be classified as hardware. In other words, the algorithm has to have few enough states that you can exhaustively test every single possible state, with every possible input, and verify that the output in every case is as expected. As you can imagine, only the very simplest logic algorithms meet this definition.
In short, if you have an FPGA in your device, it’s almost certain that you must develop the code for that FPGA according to IEC 62304, just like you would any other software.
Happy developing!