IEC61850 createIED.vi parsing inconsistencies

[himre]

Hello!

I have issue with IEC61850 MMS server implementation, with even implementing basic configuration that conforms the standard.
For instance the one below adheres to IEC 61850 conventions without inconsistencies in the `CDC` attributes or type definitions. 

<?xml version="1.0" encoding="UTF-8"?>
<SCL xmlns="http://www.iec.ch/61850/2003/SCL" version="2007" revision="B">
    <Header id="StandardCID" toolID="LabVIEW" nameStructure="IEDxx">
        <History>
            <Hitem version="1.0" revision="1" when="2025-04-04T08:28:00" who="H" />
        </History>
    </Header>
    <IED name="TestIED" manufacturer="Generic" type="MMS Server">
        <AccessPoint name="AP1">
            <Server>
                <LDevice inst="LD1">
                    <LN0 lnClass="LLN0" inst="" lnType="LLN0Type">
                        <DataSet name="DS1">
                            <FCDA ldInst="LD1" lnClass="CFPC" doName="Wfix" daName="setMag" fc="SP" />
                        </DataSet>
                        <ReportControl name="RC1" rptID="Report1" datSet="DS1" confRev="1" buffered="true" />
                    </LN0>
                    <LN lnClass="CFPC" inst="1" lnType="CFPCType">
                        <DOI name="Wfix">
                            <DAI name="setMag">
                                <Val>0</Val>
                            </DAI>
                        </DOI>
                    </LN>
                </LDevice>
            </Server>
        </AccessPoint>
    </IED>
    <DataTypeTemplates>
        <LNodeType id="LLN0Type" lnClass="LLN0">
            <DO name="Health" cdc="INS">
                <DA name="stVal" bType="Enum" fc="ST" />
            </DO>
        </LNodeType>
        <LNodeType id="CFPCType" lnClass="CFPC">
            <DO name="Wfix" cdc="APC">
                <DA name="setMag" bType="FLOAT32" fc="SP" />
            </DO>
        </LNodeType>
    </DataTypeTemplates>
</SCL>

 

The only SCL that works is the IEC61850_example.cid from NI. But even that is unclear how same contents is used as .icd and .cid, leading to suspension that there are hidden logics in the createIED.vi block that handle this. But that cannot be seen given the blocks are password protected.
As a result, I wonder anyone else has similar experience, or does someone know how to deal with it and even there is some template to start working from it (a part from example which is not fully inline with the updated version of IEC61850)?

Many thanks in advance for ay help!🙏  

[rolfk]

It seems you try to define Enum datatypes. Did you check that the toolkit supports that?

As to the password protection of the diagram, I haven't looked at that toolkit yet, but it most likely wouldn't help you to look at that as most VIs for most of their Industrial Communications Toolkit are almost an instant call to a shared library with minimal code on the LabVIEW side.

The OPC UA Toolkit for instance only supports scalars, arrays and 2D arrays of boolean, integers, floating point values, strings and timestamps. No enums, no complex datatypes such as structures or ExtensionObjects as OPC UA calls them. It would suprise me if the IEC 60870 or 61850 Toolkit would support more. It's tricky, although for enums you could always force cast the implementation to go with a normal integer of the right size with a little effort.

[himre]

Hi Rolf,

Thank you very much for your reply. 
Not sure that is the issue, I tried that with many types and it is same. Even if I replace that with:

        <LNodeType id="LLN0Type" lnClass="LLN0">
            <DO name="Health" cdc="INS">
                <DA name="stVal" bType="INT32" fc="ST" />
            </DO>
        </LNodeType>

It doesn't help. It is a good point that you say the logic is implemented in libraries, so we cannot see that. But still I wonder how this standard is implemented, is it updated at all? How can one understand how to deal with it?

Thanks,
Hamidreza

[rolfk]

The LabVIEW IEC 61850 Toolkit was released in 2014 and had one new release in 2015 and since has not been updated. It was most likely based on some C source code that NI licensed from some other 3rd party. The original C source code almost certainly has been updated by that 3rd party in the meantime but NI may not have a license that gives them the right to use such newer versions. Also even if they could use newer source code versions, there still needs to be someone to do the work of compiling the shared library for the various platforms (Windows 32-bit, 64-bit, and NI Linux RT ARM and x64). And of course the VI library needs to be adapted to any changes that may be necessary to adapt to new APIs in the 3rd party library and support new features.

I've been checking with a German company who provides such C source code and for a source code license to their library for a single product, it would be about €10000 with additional yearly costs of about € 1500 as maintenance support contract. That does not include writing a C interface layer to adapt their C oriented API to a more LabVIEW friendly interface nor creation of the entire LabVIEW VI library to access it, testing, debugging and more testing and all the other stuff needed to have a nicely working and documented library. And there would be in fact additional costs to extend the license to also be allowed to distribute this solution for NI Linux RT platforms, LabVIEW for Linux and if we are at it also LabVIEW for Mac.

A commercially taunting exercise for sure. I'm currently busy trying to do that for OPC UA, with the benefit that there exists actual Open Source C code that makes the initial investment for such a library just my own time. It was about half a year of development in my spare time and is almost at the point for a public beta test. But it's not an easy thing to do for any industrial protocols and for most of the others you have to buy a source code developer license or spend one to two years to develop your own.

[himre]

So, literally NI sells a product that is expired. And you cannot see that until you buy and try it. Unfortunately that is also my conclusion, it is all about not being updated with the standard, as the implementation/specification in 2015 is quite outdated.

Thank you very much for explaining, it clarifies how things are done.

Hamidreza

[rolfk]

---

@himre wrote:

So, literally NI sells a product that is expired. And you cannot see that until you buy and try it. Unfortunately that is also my conclusion, it is all about not being updated with the standard, as the implementation/specification in 2015 is quite outdated.

---

Actually, you can download the installer and test it. And you should be able to extend the initial evaluation license for an additional 30 days. So your statement that you can not see it before you buy it is not entirely correct. Also when you download it you can see on the download page that the latest 15.0 version you can download was released in October 2015.

Of course it is not very user friendly but you as a user also have some obligation for due diligence to investigate a software solution before you start building a system based on it.

[himre]

You might say that and I might argue one month among of trial other things isn't enough to learn and also realize the issues you are facing is because of partial implementation of standard.

[rolfk]

---

@himre wrote:

You might say that and I might argue one month among of trial other things isn't enough to learn and also realize the issues you are facing is because of partial implementation of standard.

---

That is always a problem with anything you do in such projects. I agree that NI should try to be more transparent about this but even if I would create such a toolkit based on some 3rd party source code, I could not guarantee to support everything that the standard committee happened to cook up over the years. In fact I could guarantee you that there are some things in the standard that would not be supported! 😁