Despite the seemingly logical conclusion that an IEC 61850 device supporting say disturbance recording should provide RDRE and the individual channel RABR and RBDR, the Standard does not mandate the modelling chosen by the manufacturer must include these Logical Nodes.

Nor does the Standard mandate that a distance relay has to use a PDIS, and a differential relay is not mandated to have a PDIF.  It is totally up to the vendor to decide what and how to implement IEC 61850 so if they want to have a distance relay but want to exclude the distance function from the scope of the IEC 61850 model, they can do that - perhaps ridiculous to make a conscious decision to do that but it is possible and permit-able.

• I know of one utility who called for samples of IEC 61850 conforming line differential relays for tender evaluation - one vendor supplied a sample relay with LOTS of LN of all sorts EXCEPT PDIF - none at all!  The IED however has a valid Conformance Certificate issued by KEMA
• I also know of a university as specialists in teaching of IEC 61850 who obtained various relays "compliant to IEC 61850" in order that they do some research of sampled values - however the relays they obtained did not provide IEC 61850 - 9-2 nor 9-2LE either in subscribing to or publishing Sampled Values
• I also know of a utility investigating some new products on the market which ONLY had LLN0 implemented in the device - but of course still had a Conformance Certificate.

That is probably a big epiphany for many.

LNs are MODELS of functions.

If a supplier CHOOSES to model a function with IEC 61850, then that model must conform to the LN structure defined in Part 7-4.

i.e. which LNs they provide is TOTALLY OPTIONAL.

Furthermore, within the LN Model itself there are Mandatory, Optional and Conditional Data Objects and Attributes according to the vendor's chosen 'depth' of modelling - hence for example they don't necessarily have to provide any setting Data Objects for a PDIS - they are ALL Optional Data Objects.  The only PDIS Mandatory Data Objects for PDIS are .Str and .Op

Many Procurement specifications for relays and/or systems often end up not being of any practical benefit towards getting what you need:
(refer these 3 real specification examples - click to enlarge)

:

These specifications are akin to buying a car based on the sole requirement  "all cars shall be drivable on tarred roads".

Lets suppose (from a real life example) that you are an asset owner writing a specification for an iED period contract - i..e teh IEDs will go into stock and then at some point a Project Manager will requisition them for a specific project.

Example:

Lets suppose the SCADA system needs certain information to be displayed on the Master Station screens - lets pick two - specifically the C phase Amps and the 3phase Watts

We know that metering values are contained in an MMXU.
Is it good enough for the asset owner to have a specification that just says "the IED shall have an MMXU LN"?
No, because the Standard is flexible as to what that actually means because obviously an IED that only has current input cannot possibly calculate Watts.

When we look at the Data Objects for an MMXU in IEC 61850-7-4, we find that MMXU.A and MMXU.TotW are both Optional.
Therefore if it is imperative that you have these values, you must specify them for your procurement as being Mandatory

But that is not the end of it.
If we now look at the Common Data Class for MMXU.A in IEC 61850-7-4, it is referenced as WYE.
Now looking at WYE in IEC 61850-7-3 we see that the phases are each separate Data Attributes as MMXU.A.phsA, MMXU.A.phsB, MMXU.A.phsC and MMXU.A.neut. 

Perhaps it is "obvious" that in specifying "MMXU.A shall be provided" that you mean all phase Data Attributes shall be available.  Perhaps not!
But certainly, if we want our Systems Integrator, who may even be a third party, to use specifically the C phase current, then we had better make sure that they use precisely MMXU.A.phsC.

Conclusion: 

You only can expect to get what you specify - that requires to the DETAIL of:

1. Which TYPE of LNs
2. How MANY of each type of LN
3. Which Optional and Conditional DATA OBJECTS to be provided as Mandatory for your application
4. Which Optional and Conditional DATA ATTRIBUTES to be provided as Mandatory for your application

This does represent a lot of work defining how many instances and what DO/DA are to be provided - a multifunction IED needs a very large spreadsheet to capture all the information.
Therefore there is work being finalised to define a new seventh IEC 61850-6 SCL file as the ISD: IED Specification Description file.  This is an asset owners version of their ideal ICD file in order that all the required LN/DO/DA can be specified.  This also then simplifies the procurement evaluation of the vendor's offered IEDs by simply comparing the required ISD against the offered ICD.

What do Conformance Certificates actually certify

There is much controversy - rather misunderstanding - of what Certification means, especially the wording of the Certificates.

The wording of the Certificates seems a bit confusing: "NOT BEEN SHOWN TO BE NON-COMPLIANT"
This means that the certification laboratory has undertaken the prescribed testing of the IED and it did not fail. 

This is a correct 'legal' statement of what was done.

The IEC 61850 Certification process is defined in IEC 61850 Part 10.

A vendor must declare what they want certified.  

The Certification Laboratory will then test the things the vendor has requested to be certified that whatever has been implemented has NOT BEEN SHOWN TO BE NON-COMPLIANT
Hence the above example of a Certified IED only having a LLN0 which was "not implemented incorrectly".

Certification does not include proving that the vendors chosen functions and modelling thereof makes any sense from an application or usage point of view.
This, as always, is the responsibility of the purchaser to specify and verify they get the "things" they need for their application.

Extra Notes: