IEC60870-5-104 Settings for redundancy with Sicam AK3

<div>Hello</div><div>I have one standalone Zenon runtime PC, Communication via IEC60870-5-104 with one redundant Sicam AK3 system, (consisting of tho AK3 with internal voter logic).<br>My settings on the Zenon driver are these: Redundancy according to Edition 2.0.</div><div>Communication is working, the driver is establish Connection with both AK3, but if the system Changes Active CPU, the driver still listening on the primary.<br>If I make a manual switchover via driver command 104_MANUAL_SWITCH it starts to work again.</div><div>What are the conditions that makes the driver shift to secondary Connection ?<br>I only have spontaniously signals, shouldnt it be som kind of polling or internal watchdog in the driver that handles this desicion.</div><div>On the sicam side I have some options to make when the CPU is passive.</div><div>Stop send time setting TI103<br>Stop send test command TI107<br>Shutdown the ethernetport</div><div>If I select the last one, it works, but leave an alarm on the RTU.</div><br><br><br><br>

In IEC 60870 standard the periodical watchdog of the Data Layer connection is called 'test procedure'. These are not ASDU TI107 frames but small APCI U-frames; the period is the T3 timeout (default 20s).

The driver switches connection (primary <-> secondary) when on current Data Layer the slave is not responding. Or slave closes the TCP socket. In the background the driver process the 'test procedure', but in currently released zenon versions, when socket is kept alive but slave does not react on APCI frames, the driver has issue blocking the switch for quite long (at least T0 timeout * 2); or much longer, depends situation. We fixed it in the IEC870 driver but only for future versions - as there is a workaround working faster as the 'test procedure' could.

The IEC 60870 standard defines that the connection is lost when there is no response T1 timeout long (default 15s). And this T1 timeout (value recommended by the standard) is anyway longer as it would be to force the switch by an applicative solution:
-> link with the variable representing the active CPU a reaction matrix detecting the switch of CPU and then calling the zenon driver command 104_MANUAL_SWITCH.

If this is not the solution in your case, then please contact your local COPA-DATA Support officially - to request the merge down of the driver fix.

Ok, thanks for Quick response.<br>I have done som wiresharking on the Connections, and the passive CPU answers U-frames, but sends no other spont. signals.<br>The problem for me happends when the CPU switches from Active to Passive, the Connection in Zenon just freeze, no "invalid" or "not topical" flags are set, so I never get the signalupdate on the variable that says Active CPU has changed. I tried to make a copy of the Active/passive variable, and checked the "Read from standby Server only" but that variable is Always marked as invalid, I suppose its not the same thing as, read from secondary driver Connection.<br>Is there a possibility to read some variables from secondary Connection, in that case I could trigger a function and switch Connection.<br>Another option could be to read "CPU Clock seconds" to a variable, if the variable has not Changed within 5 seconds or so, I could try to switch Connection, in this way it is possible to detect the switch with a "stalled" variable.<br>

The variable setting 'Read from Standby Server only' is not relevant for the primary/secondary IP of the connection.

If passive CPU still responds U-frames then the only way is to link a variable which regularly changes the value (like this "CPU clock seconds") with a 'multi numeric' Reaction Matrix detecting any value change with the 'Delay' 5-20s (depends performance and traffic). And in this rema - to call the zenon function with manual driver connection switch.
Thus, if value will not change for N seconds the rema will call the function.

Ok thanks, now it works at least, but for some strange reason it takes 35 seconds before the function executes, not 5 as I have set in the rema.<br>See attached rema config, where could that 30s extra com from?<br><img class="previewthumb" id="vbattach_2568" alt="" src="https://forum.copadata.com/attachment.php?attachmentid=2568&amp;stc=1" attachmentid="2568"><br>/Tobias<br>

Solved, time was not synched on the PC, now its working as expected.<br>/Best Regards Tobias<br>

In&nbsp;the rema I would add also a state detecting the INVALID status bit. For the case that&nbsp;a connection loss happens while the variable "CPU clock seconds" has value 0 (probability 1:60 <img title="Lächeln" class="inlineimg" alt="" src="images/smilies/smile.png" border="0" smilieid="1">).&nbsp;

Ok, thanks for the tip.

After weeks of testing this function, I have found one problem.<br>If I Start Zenon Runtime while the primary CPU is passive, (the secodary cpu/connection is running normal) nothing happends.<br>The status of the watchdog variable is "nothing" in variable diagnosis, the rema is not triggered.<br>If I trigger the function "switch connection" manually the processvalues starts to update and the driver works.&nbsp;<br>How can I prevent this, my guess is that I have missed some settings of the statusbits in my rema.<br><img src="https://forum.copadata.com/attachment.php?attachmentid=2656&amp;stc=1" attachmentid="2656" alt="" id="vbattach_2656" class="previewthumb"><br><img src="https://forum.copadata.com/attachment.php?attachmentid=2657&amp;stc=1" attachmentid="2657" alt="" id="vbattach_2657" class="previewthumb">

If the Variable Diagnosis screen is not displaying timestamp and status of variables, then it has nothing to do with settings in reaction matrix. There can be only 2 reasons:

• - screen Variable Diagnosis is open by function where option 'refresh actual values on' is not activated and user has not pressed the button 'refresh on'.

Then all variables are affected, also internal variables are displayed without time, status etc. although they always have it.

• - the PLC is not delivering these variables.

In case of iec870 variables of 'driver object type' = "PLC marker" this can only happen when the slave device (Sicam) is not delivering these variables in reaction on General Interrogation (ASDU<100>).

Screenshot from my project with iec870 redundant ed.2 Data Layer connection while only secondary is available while Runtime start:
Attachment 2660
note: on the screenshot you can see that driver is testing the connection each 5s - this is according the driver setting 'T3' ("test procedure" on APCI frames TESTFR).

I have an experience with Sicam AK systems claiming to be redundant Ed.2 where passive CPU are not fully passive - they still are responding GI requests (sending acknowledge for ASDU<100>, but no data). Thus, are then not compliant with the IEC 60870-5-104 Standard Ed.2.0. When the passive CPU (slave) confirms GI request, the driver (master) has no chance to detect that it has to use another IP for the Data Layer.

I’m attaching 4 XML files exported from my project - you can import in yours. Import those files in the order according the number in file name (else remas and functions etc will be not linked correctly).