In the previous section, I introduced the basic architecture of the K-Chief 600 cargo monitoring system, including the functions of each module and how they are connected. By understanding this structure, most problems onboard can be handled and troubleshooted without much difficulty.

Even if the issue cannot be solved immediately, you’ll be able to identify the cause more clearly and report the problem accurately.

On one of the ships I sailed on, we had to carry out maintenance on the LT cooler system, which required the ship to go into a blackout condition. During the blackout, the emergency generator started automatically, as expected. All systems, including the Kongsberg OS PC in the CCR (Central Control Room), performed a safe shutdown.

After powering the PCs back on following the completion of maintenance, some alarms needed to be reset. During this process, CMS_M Fail and CMS_R Fail alarms appeared on the Engine Room AMS and could not be cleared. The ER AMS was part of the Hyundai ACONIS system. In this system, “M” stands for Master, and “R” stands for Redundancy. These alarms indicate a failure in communication between the Master and Redundant CMS units, likely due to an unstable or disconnected communication link.

The ACONIS software user interface is very clear and easy to understand. On the Network Status Page, the communication status of each module in the system can be easily checked. If any module has an error, or if a communication cable is not functioning, it will clearly show up there.

For example, in Figure 13, if a PC or communication line is not working, or if a link is disconnected, it can be quickly identified and tested through the live status display.

When I checked the communication status, I found that everything was in normal condition. So, I had to find out what CMS actually means in the alarm. To do that, I referred to the ACONIS manual to understand the purpose of the CMS unit.

According to the ACONIS manual, the CMS is responsible for data exchange between the IGG (Inert Gas Generator) and other control systems. This is clearly shown in Figure 14.

At first, I was quite confused because the cargo system and the Engine Room AMS were supplied by different makers. The cargo system was the K-Chief 600, while the Engine Room AMS was the ACONIS system. There was no clear drawing or documentation available onboard that showed how these two systems were connected.

According to the manual, the CMS (Cargo Monitoring System) is monitored from the Kongsberg OS located in the CCR (Central Control Room). All sensor data and tank parameters from the deck are displayed there.

On the other hand, data from the Engine Room, such as generator power status, valve remote control, trim and list, etc., are not shown on that system.

This clearly showed that there was a communication loss between the ACONIS system and the Kongsberg system. Since no drawings were available, I had to trace the wire tags manually. I found that two SCU modules—DPU 1000 and DPU 6000—located in the CCR were connected to the HiSCM (Hyundai Intelligent Smart Control Module) of the ACONIS system through LAN communication.

The HiSCM module acts as the interface between the ACONIS system and various AMS (Alarm Monitoring System) subsystems. In this setup, systems like IGG, BWTS, and SCR are connected to the ACONIS alarm monitoring system through the HiSCM.

These systems communicate via MODBUS protocol into the ACONIS system through the HiSCM. Additionally, the Auxiliary Engine Control System is also connected to the HiSCM using the RS-485 communication standard.

To explain briefly, the main engine’s exhaust gas temperature sensor thermocouple is connected to a 4-20 mA converter, which then sends its signal to analog input module and finally to the ACONIS AMS.

For the auxiliary engine, the exhaust gas thermocouple sensor is connected directly to the engine controller, which communicates with the ACONIS system via a single RS-485 communication line.

The data can be read in the ACONIS system, but not in the Kongsberg system, so the problem lies with Kongsberg.

First, I checked all the LAN cables carefully to make sure they were connected properly. Then, I restarted the affected SCU module to try to fix the problem. However, the issue continued, which indicated that the SCU modules themselves were malfunctioning.

Because the SCU modules play a key role in communication between systems, their failure caused loss of data and communication errors.

On some ships, LAN ports in the network switch can be swapped to check if the ports are working properly. But on this ship, it was not possible because the network ports were preconfigured.

When checking the network status on the Kongsberg OS , I noticed communication issues with the SCU 1000 and 6000 modules. The AMS Ethernet status showed some problems, which can be seen in Figure 15 as red warning indicators.

Because of this problem, the K-Chief system could not get information from ACONIS. Compared to ACONIS, the user interface of K-Chief is a bit more complicated. Since I was not familiar with the K-Chief UI at the time, it took me a while to find the network status page in the Kongsberg OS.

After thoroughly checking the system, I ran the system backup file provided by the Kongsberg supplier and rebooted the SCU module. After that, everything worked smoothly.

For those who have just started working as an ETO, note that for this problem, what I did was only check the power status and cable connections. Once I understood how the K-Chief system works and its structure, I was able to find the cause and report it correctly to the company. This way, the company could provide exactly what was needed without spending too much time solving the issue.

One important thing to always remember is to note down the position of the port and the LAN cable when disconnecting. Otherwise, if you forget and reconnect to the wrong port, you will face another problem.