Mark-V Diagnostic Alarms

We have a Gas turbine
TG-702 S.No. : 281817 with Speedtronic control mark-5, with DOS based I.

Following Alram appeared on the alarm display.
16-AUF-2008 08:14:15.000 T2 1* Q 0000 DIAGNOSTIC ALARM <C> <Q>

In the Diagnostic Alarm display following alarms were present.

16-AUG-2008 08:14:14.000 T2 0* R 0009 DCC DPM:INVALID DESTINATION ADDRESS
16-AUG-2008 08:14:14.000 T2 0* R 0005 DCC NO queue server for distination
16-AUG-2008 08:14:09.000 T2 0* C 0009 DCC DPM:INVALID DESTINATION ADDRESS
16-AUG-2008 08:14:09.000 T2 0* C 0005 DCC NO queue server for distination

When these alarms were ACKed and Reset they disappeared.

What might be the reason behind these alarms.
What steps can be taken to stop recurrence of these alarms.

Can these alarms cause the Gas Turbine to Shutdown.

First of all it might be helpful to understand the acronyms in the alarm text messages.

DCC (Drive Control Card) - The main card with the microprocessor, RAM, & EEPROM chips on it DPM (Dual-Ported Memory) - An area of RAM where signal values are placed and can be accessed by other processors

So, it would seem that something is asking for either a signal value for which there is no signal, or the signal type being requested is not valid. Another, less likely, possibility would be that there is a problem with the dual-ported memory. DCC cards were the first cards used in the early production of Mark Vs. It could be the card components are getting "old" and have been exposed to excessive heat and/or humidity. But I would expect lots of these alarms which couldn't be acknowledged and reset.

How long have these alarms persisted? If they just started recently, was it after someone was making some kind of changes to the <I>, possibly running the Total Job Compiler (MK5MAKE), or making changes to a MODBUS.DAT file? Or to some the DCS or other system which might be communicating with the Mark V through the <I> via MODBUS? Was the processor recently re-booted or was it downloaded to, and the same information was not downloaded to the other processors, or vice versa, nothing was downloaded to this processor but only to the other processors?

Unless these alarms increase in quantity and frequency and cannot be reset, they should not cause a turbine shutdown/forced outage.

No compilation or reboot was in progress.
Nothing was downloaded to any processor.
Just before the alarm the Monitor of Local <I> was turned OFF and then again ON. Only the monitor not the I processor.

These alarms did not persist for long, and their state changed from 1 to 0 automatically.
After being Acked and reset they have not appeared again so far.