P2 controlling medical device
ManAtWork
Posts: 2,216
A customer asked me if I could develop some sort of smart power supply for a medical device. It has to deliver high energy electrical pulses to a magnetic coil according to commands received over a serial communication. I think the P2 would at least technically be a well suited candidate for this because of it's ability to generate high speed PWM and do real time control loops.
But are there any objections against the use of the P2 in a medical environment? It's no life support device and even a complete failure would not cause any thread to the life or health of the patient. But of course there will be a lot of paperwork to be done. This exceeds my knowledge and I have to get help from a consultant, anyway.
But before I start something that turns out to be impossible, eventually, I'd better ask in advance... I've found CE and UK certificates on the P2 docs page but no UL certificate. I think I'll need that if my customer wants to sel to the US market. Does anybody have any experience if this has a chance to succeed?
Comments
The P2 is a microcontroller. Microcontrollers are used in complex electronic circuits that would generally be independently certified at the product level. You will find a similar case for the ARM Cortex controller or any other micro I can think of. The last chip I KNOW had independent UL certification for the actual IC was the PIC, and that was thirty years ago. This is not engineering advice, this is just a statement of fact as I know it.
FDA or other medical certification paperwork definitely needs an expert. "Do what the lawyers tell you to do" is the best advice I can give you on that one. Technically speaking I don't see why not, we're using it in aviation for similar reasons. This is not legal advice this is a recommendation to follow legal advice. If you want a turnkey industrial design expert who can help you out on the IP, regulatory, and industrial design parts of the project I can recommend Tarlow Design (https://www.tarlowdesign.com/) we've worked with Ken Tarlow for 10+ years, he knows the prop, he knows us, and he has good lawyers. Just tell him we sent ya.
Ok, thanks, I've already asked Ken and he also sees no general show-stopper.
The Propeller is a bit special because it is designed for "hackers" who normally don't care much about safety (look for all those discussions about overclocking...). The P1 and P2 both don't have any kind of code protection and they can only execute programs from RAM. This means a random software bug can overwrite instructions so anything can happen. I've experienced this once when a faulty network switch emitted "impossible" network packets that had a correct CRC but invalid content. This triggered a bug in the ENC28J60 ethernet controller which happened to report a negative packet length which in turn triggered a bug in my software which lead to a buffer overrun. The result was that all cogs of the Propeller ran amok and wildly toggled all IO pins. Fortunatelly, I was able to fix this with remote updates before any customer noticed.
There are special microcontrollers for safety sensitive applications which offer features like register protection, memory protection and so on. This doesn't mean you can't use the Propeller for those things. It's just much harder to proove that your software is correct. If it is you can build very reliable systems.
For our medical device we just put all electronics in an armored steel box. A fuse and a hardware watchdog limits the energy that can go into and out of the box. So no matter what the software does and even if everything melts and explodes the patient is still safe.
Think the debug area of ram can be write protected. Also, if code is in a cog only , somewhat safer from mischief…
There is no such thing as "somewhat safer". A single cog out of control can cause all sorts of misbehaviour. Overwritten code can lead to coginit commands being executed which renders any kind of protection useless.
But general programming wisdom applies...
Yup. Maybe this project and some of the stuff we're doing should result in a linter for spin2? I'd be happy to chip in.
Sounds like a PEMF device. I think any old microcontroller would work here. P2 would be overkill.
Having built a power converter with the P2, the ADCs aren't great for high speed control loops. Say you want 100ksps, that is 1600-3200 clock cycles. That's about 10 effective bits from the ADC. At 1MSPS, it would be 8 bits at best. I looked at STM32F031C6 and saw 12 bits 1MSPS.
The P2 certifications are just for RoHS. I think UL is mostly "it won't catch fire."
I've thought about using a sparse bytecode as a way to mitigate bit flips and other corruption. Perhaps there would only be 64 valid bytecodes out of 256. Thus accidentally corrupted data would likely be detected as invalid. (This is inspired by the Shannon limit.) Code in the cog ram is somewhat protected after the cog starts. The standard convention of any non-zero value being true seems like a bad idea. In my code I use 1 for true and everything else is false.
ManAtWork,
You should do a FMEA (Failure Mode and Effects Analysis) which documents what item could fail, the effect that failure will occur, the likely-hood of that failure occurring, and how the patient would be affected.
Anything that is likely to occur or would severely affect the patient needs to be mitigated against.
It's also common to do Hi-Pot testing when a device handles a considerable amount of energy.
The number one rule in medical devices is patient and user safety so make there are plenty of fail-safes for any possible condition that may occur.
Don't forget about Brown-Out and Black-Out power conditions.
Yes, it is kind of PEMF (pulsed electromagnetic field therapy) device. But not one of those yoga-mats with helmhotz coils that only achieves magnetic flux densities in the milli-Tesla range. It has a rather high energy. A HV capacitor is charged to 1300V and discharged through a coil. You can feel it heating up the keyring in your pocket (if you don't obey the warning "no metal objects allowed"
) It is designed to cause muscle contraction similar to the NMES (neuromuscular electrical stimulation) devices but without the pain from the current flowing through the skin.
The predecessor had a really heavy 50Hz transformer. The new design will use a software controlled SMPS.
It's also important to assign the high-state of an output pin to the safe state and low to the active/dangerous state. That's because the DIR (output enables) and OUT registers in the propeller are OR-wired. So a false output from another cog can override the low-state and turn it into a high-state but not vice versa.
Yes, though you could invert it at the very end with the CIO bits of the pin config
ManAtWork,
Also consider that in this day and age Cyber-Security is a very big concern so any potential attack vectors should also be investigated.
Does the main device use wireless or internet that an attacker could use to take control of the system?
And how would your P2 handle a software bug on the device end where it's continually being pummeled with commands and inquiries?
Of course, the device has no connection to the internet and field updates are also a no-go. Commands are revived over an RS485 line running MODBUS protocol.
A typical PC software application is never really finished, these days. So it needs constant updates and improvements. But I hate that, anyway. A good engineer should develop his product until it's really matured and then release it. Thereafter, "never change a running system" is the slogan.
Yerp! That's why I still have shelf space for BASICON parts... and 20 different antique MODICON chassis... (Looks a little like Warehouse 13 back there..) for internal stuff, just replace 'really matured' with 'sufficiently functional'
So in the UK railway signalling world, safety critical applications involve dual or triple redundant systems. Each processor runs different code, but they all perform the same function. They check each others results. If a dual system detects a mismatch it shuts down. If a triple processor system detects one CPU at odds, that is shut down and the signalman warned of the degradation in safety. The now dual system continues. It would normally be replaced as soon as convenient.
With 8 CPUs to go at, might the above be adapted? Before diving into coding, a failure mode and effects analysis needs doing on all the basic functionality, to see how often an unsafe condition is to expected - and whether that is acceptable to the application. This might answer the question as to whether a P2 is applicable to safety critical applications or whether it is inherently unsafe.
Cheers, Bob
A redundant system makes sense only if the 3 systems are completely isolated from each other, e.g. the crash of one CPU can't disturb the others. That's not true for the cogs of a propeller.
BTW, to decide if there's a fault and which of the CPUs has to be shut down some sort of "voter" is required, e.g. a 4th CPU or some hardwired logic. That could also fail. You can integrate the comperator logic into the 3 CPUs themselves but what should be done if they disagree?
But that's all overkill and only required if the consequences of a fault can be really catastrophic. Remember the "airplane rule": a plane with 3 engines has 3 times more engine failures than a single engine plane. Unless you plan to cross the ocean you better invest the money in one really reliable engine.