Showing results 1 to 5 of 5

Thread: IEC 61850 MMS Connection Problems with Schneider C264

  1. #1
    Join Date
    02.09.2016
    Posts
    5

    Ausrufezeichen IEC 61850 MMS Connection Problems with Schneider C264

    Hi all;





    1. I have a problem about MMS connection with Schneider C264. Current system has 6 C264, 10 Micom P44x and 2 Zenon Runtime (redundant).



    System has work perfectly like a day, then suddenly, all my signals appear invalid. I cannot connect again. I must shutdown whole system then turn it up and start working again. Everytime, one or more BCU(C264) drop connections (Randomly). I also tried to use IED Scout. Samething happens and says "MMS request canceled because of timeout"



    My driver settings are at default. This can create issue, because of RCB settings?



    Anyone know what is the problem or experince similiar problem?



    2. Do Zenon give .scd, .cid, .icd or .iid? SCE (Schneider configuration program) needs .icd for adding SCADA.



    Thank you.

  2. #
    Join Date
    01.07.2008
    Location
    Salzburg, AT
    Posts
    809
    Best Answer

    Default Re: IEC 61850 MMS Connection Problems with Schneider C264

    ad.1
    Do you see in Wireshark that the driver (iec850 client) is polling periodically the affected IED? There should be MMS.Read in period of 'polling rate' setting in driver.

    I'm not 100% sure, but your description looks like a block of outstanding PDUs (frames) on MMS.

    In MMS all request and response PDUs are numerated - in field InvokeID (visible in Wireshark sniff by MMS Read and Write requests). An IED is obligated to respond all requested PDUs, but if the IED is faulty and does not respond some InvokeIDs - these numbers keep to be outstanding and are blocking the sending queue of 850-client. Unfortunately the IEC61850 Standard does not define any method for 850-clients to go out of such situation. There is no timeout (no definition how long maximally an IED has to respond an InvokeID) but the Standard defines that a client cannot send new requests when the negotiated quantity of outstanding PDUs is reached. Thus actually a client is obligated to wait on these missing responses forever and cannot do anything.
    From your description i'm guessing that the IED Scout has some internal timeout and if it is elapsed - informs "MMS request canceled because of timeout" and probably treats InvokeID as free again. But IED Scout is the testing tool, so is not obligated to follow the Standard so strictly like a 850-client in a SCADA system must do.

    If block of outstanding PDU queue is here really the case - if some of your IEDs are never responding some MMS request PDUs, then this is very severe bug in IEDs. The only solution is to contact the manufacturer of the IED and demand the fix.
    When outstanding queue is blocked then in Wireshark you will see that IED maybe still is sending MMS.InformationReports, but client is not sending any MMS.Read nor MMS.Write requests.

    In zenon the only thing you could do would be to abort the communication - e.g. by zenon function 'driver command' to stop the iec850 driver (or exit the zenon Runtime). You would probably also have to reset the IED and then start the driver in zenon again.

    Last months we get signals from our customers about faulty IEDs on market (but not Schneider). Thus, in future, coming next year version of zenon - 8.0 - we will anyway introduce the protection in iec850 driver against such blocks in MMS. The iec850 driver will abort the association with IED when its MMS requests queue is blocked for longer as 50s (and will log errors). It will not solve the problem but help to find the reason - faulty IEDs - faster, hopefully already before system acceptance tests.

    Ad. 2.
    The ICD file of a client would be almost identical for any client, contains typically one logical node class - ITCI. The only interesting information in such file would be the client's IED name (can be used to preconfigure in IEDs the reports with ClientLNName). This name is a string you can define like you want. I'm attaching an example we have used by latest certification. In this file the client's IED name is "zenon_iec850Client".
    Attached Files Attached Files
    Last edited by ursulak : 25th July 2017 at 10:22 Reason: typo

  3. #2
    Join Date
    13.08.2013
    Posts
    57

    Default Re: IEC 61850 MMS Connection Problems with Schneider C264

    Hi,
    it is hard to analyse without further information.
    What I suggest you to do would be, log the communiction with the Diagviewer(Manual->Drivers-> IEC850 -> Reporting -> RCB activation - verification possibilities)
    ) and wireshark (with an appropriate iec61850 dissector).
    Also create  !ConnectionState variables for the connection to analyse, as described in IEC850 -> IEC850 client functions -> Establishment of a connection and detection of a connection failure

    For the Reports:
    Make sure that diffrent clients don't use the same report, this includes all clients including IEDScout.
    As an example
    Depending on ReportEnabled flag of the Report, there might be 1-16 instances of a Report.
    Server A would use  Z1_P6A_TF2LD0/LLN0/urcbST01[RP]
    Server B would use  Z1_P6A_TF2LD0/LLN0/urcbST02[RP]
    IEDScout would use     Z1_P6A_TF2LD0/LLN0/urcbST03[RP]
    Of course if the IED supports ClientLNName you should work with this.

    Check the Reportsettings of your .cid/.icd/.scd files, they should look something like this.
    <ReportSettings cbName="Fix" datSet="Dyn" rptID="Dyn" optFields="Dyn" bufTime="Dyn" trgOps="Dyn" intgPd="Dyn" resvTms="true" />
    IF optFields,bufTime,trgOps,intgPd, are ALL set to "Dyn" you must NOT use "Use preconfigured scl options"

    Make sure the TriggerOptions are sane, which means don't use data-update and data-change at the same time, which could cause problems,
    best is to check the triggeroptions in your .cid/.icd/.scd files and validate with the settings in the zenon configuration

    Best regards
    Sigi

  4. #3
    Join Date
    01.07.2008
    Location
    Salzburg, AT
    Posts
    809
    Best Answer

    Default Re: IEC 61850 MMS Connection Problems with Schneider C264

    ad.1
    Do you see in Wireshark that the driver (iec850 client) is polling periodically the affected IED? There should be MMS.Read in period of 'polling rate' setting in driver.

    I'm not 100% sure, but your description looks like a block of outstanding PDUs (frames) on MMS.

    In MMS all request and response PDUs are numerated - in field InvokeID (visible in Wireshark sniff by MMS Read and Write requests). An IED is obligated to respond all requested PDUs, but if the IED is faulty and does not respond some InvokeIDs - these numbers keep to be outstanding and are blocking the sending queue of 850-client. Unfortunately the IEC61850 Standard does not define any method for 850-clients to go out of such situation. There is no timeout (no definition how long maximally an IED has to respond an InvokeID) but the Standard defines that a client cannot send new requests when the negotiated quantity of outstanding PDUs is reached. Thus actually a client is obligated to wait on these missing responses forever and cannot do anything.
    From your description i'm guessing that the IED Scout has some internal timeout and if it is elapsed - informs "MMS request canceled because of timeout" and probably treats InvokeID as free again. But IED Scout is the testing tool, so is not obligated to follow the Standard so strictly like a 850-client in a SCADA system must do.

    If block of outstanding PDU queue is here really the case - if some of your IEDs are never responding some MMS request PDUs, then this is very severe bug in IEDs. The only solution is to contact the manufacturer of the IED and demand the fix.
    When outstanding queue is blocked then in Wireshark you will see that IED maybe still is sending MMS.InformationReports, but client is not sending any MMS.Read nor MMS.Write requests.

    In zenon the only thing you could do would be to abort the communication - e.g. by zenon function 'driver command' to stop the iec850 driver (or exit the zenon Runtime). You would probably also have to reset the IED and then start the driver in zenon again.

    Last months we get signals from our customers about faulty IEDs on market (but not Schneider). Thus, in future, coming next year version of zenon - 8.0 - we will anyway introduce the protection in iec850 driver against such blocks in MMS. The iec850 driver will abort the association with IED when its MMS requests queue is blocked for longer as 50s (and will log errors). It will not solve the problem but help to find the reason - faulty IEDs - faster, hopefully already before system acceptance tests.

    Ad. 2.
    The ICD file of a client would be almost identical for any client, contains typically one logical node class - ITCI. The only interesting information in such file would be the client's IED name (can be used to preconfigure in IEDs the reports with ClientLNName). This name is a string you can define like you want. I'm attaching an example we have used by latest certification. In this file the client's IED name is "zenon_iec850Client".
    Attached Files Attached Files
    Last edited by ursulak : 25th July 2017 at 10:22 Reason: typo

  5. #4
    Join Date
    02.09.2016
    Posts
    5

    Default Re: IEC 61850 MMS Connection Problems with Schneider C264

    Thank you for your replies .

    I will try those you mention and give you a feedback. If it possible to catch disconnection with Diagviewer and Wireshark, i will share logs.





  6. #5
    Join Date
    02.04.2017
    Posts
    6

    Default Re: IEC 61850 MMS Connection Problems with Schneider C264

    I faced this problem before with C264
    The my solution was to define your zenon servers in C264 database (using SCE) also import the 61850 Var (lphd1.proxy.stval) in zenon database

Similar Threads

  1. IEC 61850 Edition 2
    By altera in forum zenon Energy Edition
    Replies: 4
    Last Post: 26th April 2016, 11:27
  2. SBO in iec 61850
    By nikabena in forum zenon Energy Edition
    Replies: 1
    Last Post: 22nd May 2015, 08:10
  3. Iec 61850
    By nikabena in forum zenon Energy Edition
    Replies: 10
    Last Post: 2nd March 2015, 10:29
  4. Iec 61850
    By nikabena in forum Drivers
    Replies: 10
    Last Post: 2nd March 2015, 10:29
  5. SNMP connection problems
    By kicker in forum zenon Network
    Replies: 2
    Last Post: 29th July 2014, 15:44

Posting Rules

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