Showing results 1 to 3 of 3

Thread: redundant iec 104 gateway standby server disconnects

  1. #1
    Join Date

    Default redundant iec 104 gateway standby server disconnects

    Our system is built around 2 scada servers. Both servers have a gateway function built in (they function as clients).

    The idee is that different iec104 server paires can connect to our system and  get data from us. The servers of our employer works on the principle that only 1 of the redundant communication path is active at the time. During testing the takeover between this redundant pairs was working fine when we where looking in detail we saw that the communication was establish to both of our servers .  So far so good. But after 2 minutes the standby server was disconnected  en reconnect some time later.
    Is this normal behavior?

  2. #2
    Join Date
    Salzburg, AT

    Default Re: redundant iec 104 gateway standby server disconnects

    I'm confused by the terminology you are using because in IEC60870 protocol there are "master (monitoring/controlling station)", "slaves (controlled station/outstation)", but no "servers". So you are probably asking about the IEC60870 communication in combination with zenon Network servers?
    And when you write "2 scada servers" - do you mean zenon or some other system - communicating then with zenon? Then, if on the zenon side you are using for this communication zenon Process Gateway IEC870 Slave, then in other system this must be via some IEC104 masters, not servers, not slaves.
    I’m also not sure about what redundancy you are talking - zenon Network redundancy, or the IEC60870-5-104 Edition 2.0 redundancy, or maybe both? And they are totally independent.

    I will try anyway to write something useful, and maybe on topic :-)

    For an IEC60870-5-104 slave device (so also for zenon Process Gateway in this protocol) the normal behavior is to force the restart of the connection if master is not sending the General Interrogation command. This GI - a C_IC_NA_1 (ASDU<100>) - command is a mandatory beginning of data exchange session (Application Layer). The remote IEC104 master has about T0 (30s) timeout to send the GI, else the Data Layer connection is not valid for Application Layer, and must be restarted. And when connection is broken, a slave is not allowed to initiate the DL connection, only master can do this, so the slave waits...
    If zenPG closes connection, then if writes in LOG the reason. The existing log files you can open using DiagViewer; by default the log files are in directory C:\ProgramData\COPA-DATA\LOG.

    Some masters are sending GI command first when slave sends the 'end of initialization' frame - ASDU<70>. The zenPG IEC870Slave can do this optionally - controlled by variable linked with T70 information object (more info in manual).

    The zenPG IEC870 Slave is not supporting the IEC60870-5-104 Edition 2.0 redundancy; only the zenon driver IEC870 (master) does it.
    So, if the remote system with some 870-master expects a redundant slave, it will have to communicate and handle the data from two identical slaves - made in zenon as two zenPG started on the same or 2 different PCs in zenon Network. These 2 zenPGs, when started with identical XML configuration, will deliver perfectly same data to remote master(s). As in zenon Network all Runtimes (or PCs) have the same data. Also the zenon Standby server delivers for operator, gateways, etc. the same data - the data from zenon Network process server (on standby server, the standby data is kept in internal buffer, not visible as long process servers is available in the network). But both zenPGs are expecting the GI from 870-master, else - connection break.

    I’m recommending to start zenPG not on zenon Network servers, but on zenon Network clients. The PCs with network servers have anyway already more work. The process data on network clients (available then via zenPG) is exactly the same like on network servers, so zenPG on zenon client will deliver to remote master the right information. And while zenon network redundancy switch, the zenon Client will automatically reconnect to Standby, as soon Standby takes over. Thus, zenPG running on client will get again the current process data automatically.
    Last edited by ursulak : 1st August 2019 at 10:34 Reason: completed

  3. #3
    Join Date

    Default Re: redundant iec 104 gateway standby server disconnects

    thanks for the quick response.

    Your interpretation is spot on of the problem. I 'm responsible for the configuration of 2 zenon (7.60) server with  a gateway on the same vm. they act as controlled stations. My employer connects with 2 pairs of redundant servers (brand "kisters") and a single pi server who act as controlling station.

    Is it correct that this disconnecting is a normal behavior of the process gateway due to the fact that there is no general interrogation?
    So we can leave this like it is and this isn't a symptom of a underlying problem.

    I going to leave the  the process gateway on the zenon gateway server. This architecture was design together with Mark Clements and we are know in a stage of the project that we can't easy do this quant of changes.If we see in the future that the server have processor capacity problems we can do the changes then.

    best regards and have a nice day

Similar Threads

  1. Process gateway in redundant mode
    By henrixon in forum zenon Energy Edition
    Replies: 1
    Last Post: 28th May 2018, 13:42
  2. Redundant Proccess Gateway
    By yara in forum zenon Energy Edition
    Replies: 5
    Last Post: 2nd February 2015, 14:22
  3. Redundant Proccess Gateway
    By yara in forum Drivers
    Replies: 5
    Last Post: 2nd February 2015, 14:22
  4. Redundant Process Gateway
    By talal in forum zenon Network
    Replies: 1
    Last Post: 23rd October 2014, 15:45
  5. M-Bus Fehler am StandBy-Server
    By herrmoartl in forum zenon Network
    Replies: 2
    Last Post: 30th April 2014, 13:50

Posting Rules

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts