I'm at a company that works with electrical products and we have a raspberry pi based system which tests the products we manufacture.
When it was being designed, my old line manager decided that it should include a system (a relay) which switches off power to the device as a backup. I queried whether that was wise, as despite being labelled by him as a backup system, where the expectation was the user would always unplug the device from the socket, if a feature exists then it eventually is relied upon.
Skip a few years later, I've implemented a calibration script that's run by this system, and modified some of the scripts that it runs so it works with our latest product. And my old line manager left.
My new line manager decided that the system is too slow, and asked the company that implemented the system originally, to remove a lot of what it was doing. After this, a new employee wrote a guide instructing the factory workers to operate it, where instead of unplugging the device, you use a switch on an MCB to turn it off, before opening the device to unplug the power cables.
While I was updating the calibration routine, I noticed that the system was able to arbitrarily turn power on to the device, when a user wouldn't expect it to. If they were relying on the system to switch the power off, then they would certainly electrocute themselves. When I discovered this, another employee pointed out that the MCB switch couldn't be relied upon because the contacts in it could become welded.
I imagine it's making an asynchronous call to switch the power on, which should be cancelled but isn't. It probably shouldn't have a asynchronous call to turn power on, that's cancelable by the user.
We asked the company that developed the system to fix the issue, and while they had an attempt to fix it, they weren't able to fix it and they don't have a system to test the fix against.
The MD has declared that users always need to unplug devices before they're opened up, but as this feature still partly exists, I can't help but think that it'll essentially be relied upon again. Particularly if this particular case is fixed.
There now appears to be some expectation from members of staff that I should fix it. The member of staff that wrote the guide I mentioned earlier, asked if I had fixed the issue, an hour after I discovered that it hadn't been fixed, and specifically asked whether I couldn't be bothered to fix it. I guess this is because I've developed scripts for it in the past. However, while the framework around the scripts is open source python, I've not had to update the framework itself and I have reservations about touching it. Particularly if the implementing person isn't able to fix the issue.
I can't help but think that I should try to steer clear of this. This is in effect a safety critical system, that's been implemented in a language that's inappropriate for that purpose. In addition, the company has the usual issues where, outside of this device, I'm also expected to tackle ambitious projects with tight deadlines, limiting my ability to give it the attention it deserves.
While my line manager has stated that the MD is ultimately responsible and liable for safety in the company. I'm not sure I want to potentially be responsible for an incomplete fix that may mean that someone is electrocuted in the future, even if I'm not legally liable. It's likely that the issue has always been there, and no one noticed.
Does anyone have suggestions on how I should handle this situation? Should I fix it?
