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?

  • 4
    You need an EE knowledgable about safety interlocks (it's not an exotic skill). If you are primarily a developer, don't touch it. If you are an EE make a judgment call about whether it is properly fixable, err on the side of caution. Safety interlocks are routine and required by law in most countries, there's no reason to skip it. People do defeat them fairly often, but there's a world of difference between that and not having it. This one calls for maximally simple and blunt communication. – Pete W Mar 28 at 20:27
  • 2
    We have another product tester that uses a non-contact switch on the cables before power is applied, which googling safety interlock appears to be the same thing. I suggested that and the MD said he just wanted power pulling from it. Problem is, I'm still getting pressure to fix the software side. I think I'll double down and say that it's something that requires this, and I'm not planning on touching the software. – ThrowAway8654321 Mar 28 at 21:22
  • @ThrowAway8654321, Don't just say it. Write it down. Print it out. Send it out to everyone involved (including your company's legal counsel). Email it as well. Keep proof of those records at your home. And drop those letters in a mailbox before you send out the email. CYA. – Stephan Branczyk Mar 29 at 7:34
  • Email sent indicating that I don't plan on fixing this and that it should be fixed via a safety interlock. I BCC'd myself a copy to my personal email address. – ThrowAway8654321 Mar 29 at 8:49
  • I'm not sure what jurisdiction you are in, but is there some designated person responsible for health and safety at your place of work? You almost certainly have a legal responsibility to inform them (or the MD/CEO) of a risk, and they then have a responsibility to act on that risk. If you don't do that, then you could be liable in the event of an accident. – Stuart F Mar 29 at 10:17

There now appears to be some expectation from members of staff that I should fix it.

State clearly that it is not in your purview.

[someone] asked if I had fixed the issue ... and specifically asked whether I couldn't be bothered to fix it.

State clearly,

  1. Please don't be rude

  2. I am not able to fix it.

  3. Only the supplier can fix this.

  4. It is a serious safety issue.

  5. Please note that I already pointed out this serious safety issue some months ago.

If they continue to flapgum, Just endlessly repeat the phrase

Only the supplier can fix this.

If in the past you have not clearly said this, unfortunately that is a mistake by yourself. All you can do is be clear from now on.

Does anyone have suggestions on how I should handle this situation?

For me I would print out a physical letter cc'd to everyone, saying:

There is a serious safety issue with the XYZ. I pointed this out some months ago. This can only be fixed by Supplier ABC. Today's date is Mmm XX. I hagve personally handed this note to < list of first and last names >. Thanks, Fattie.


Should I fix it?

If you "fix" this, you will likely be a murderer. So "no".

If someone came on here and said "Someone wants me to do a shoddy fix on this nuclear bomb stuff wee work on" what would the response be? Obviously "do not do that".

  • Thanks for your Frank comments Fattie. – ThrowAway8654321 Mar 28 at 21:26
  • Truly my pleasure. Thank God someone like yourself with a brain is in that situation. Some idiot - through plain dumbness, not even malice - in a similar situation could let a dangerous item out in the wild. – Fattie Mar 28 at 23:00
  • @Fattie isn't the saying something along the lines of ignorance before malice? Unfortunately most don't think far enough ahead... – morbo Mar 29 at 0:11
  • The inner conflict that I had was that; I could potentially fix this particular problem. And maybe doing something about it, is better than nothing. But I think it's right not to get involved with it. – ThrowAway8654321 Mar 29 at 8:48
  • 2
    @ThrowAway8654321 Don't fool yourself. If you're trained and certified to fix it, you would be legally backed with certification and be paid the respective $$$. The fact that you don't hold those certification means that you're setting yourself up to be thrown under the bus if shit hits the fan. If my involvement in Home Improvement SE taught me anything, is that you never f*k around with electrical safety. It'll kill you long before you know what happened. Do not do this with residential electricity. Definitely do not do this with industrial electricity. – Nelson Mar 30 at 5:16

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .