Recently I've encountered an interesting situation onboard with our AMCS (Alarm, Monitoring and Control System).
Normally, the alarm in AMCS can be cleared once the alarm condition that caused the alarm is cleared.
For example, High Level alarm in a tank can't be reset as long as the sensor detecting high level is activated/energized and the alarm will stay present in the AMCS Active alarms list.
Only once the sensor detecting high level is deactivated/deenergized, can the alarm be cleared and then it is automatically removed from the AMCS Active Alarms list.
Of course, the system can be set up so that deactivated/deenergized sensor triggers the alarm and vice versa.
What happened to me was the following:
A port main engine temperature alarm (I believe it was FW cooling, if I remember correctly) occurred and it was present on the engine’s local panel as well as in AMCS.
However, after clearing the alarm from the local panel, the alarm wouldn’t clear from the AMCS.
As mentioned, once the alarm is cleared locally, the alarm can be cleared in AMCS as well.
Chief Engineer called me to check the situation and mentioned that rebooting the engine’s local panel is not an option since the reboot of the starboard engine’s local panel a few months ago caused the panel to completely fail.
I was thinking what might have happened.
For some reason, AMCS was still “thinking” the alarm was present and was refusing to clear it.
There are 2 AMCS servers and 1 client and it was not possible to clear the alarm on any of them.
Main Engine’s local panel was cleared, there was no fault present but is it really not sending any info to AMCS.
Who is to blame? Local panel, AMCS, wiring issues??
To be honest, I would have been the happiest if I could have rebooted main engine’s local panel and eliminate it definitely as a cause of the problem but, as mentioned previously, this was not an option.
I checked the drawing to see how the AMCS gets the alarm from the main engine and saw that all the main engine alarms are sent from the main engine’s local panel to one of the AMCS cabinets via CAN bus.
Could I have read what was being sent via that CAN bus and detect if the alarm was present? Yeah, if I had the tools and the knowledge to do so– of the two, I had none.
Next thought that occurred to me was that it was problem on the AMCS side and that it could have been a server processing issue? But how to test this? By rebooting a server? I didn’t want to do that because we had guests onboard even though I felt comfortable doing it as I did it few times in the past when we were troubleshooting AMCS issues with the shore support.
To keep the story short, after ruling out local panel or the AMCS server(s) reboots as viable options, I decided to disconnect the CAN bus cable between the Main Engine’s local panel and the AMCS cabinet for few seconds and connect it back in hopes that this might help the AMCS “see” there is no more alarm present. And guess what? It really did work! I was one happy guy!
What if this move didn’t work?
Well, I would probably shoot a mail to the AMCS support team to check if they can sort it out.
If I had took more time, maybe I would have come up with some other good solutions but as many of my colleagues will attest, time is often not and a perk you get to enjoy when doing this job.