Added by Herbert Falk about 3 years ago. Updated over 2 years ago.
Description
Are vendors required to provide vendor specific NSDs including their object extensions.
Files
| custom2.nsd | custom2.nsd | 1.54 KB | Example vendor extension NSD file | Bruce Muschlitz, 04/11/2021 08:40 PM |
Related issues
I am not in favour for such a modification.
Since Ed2, the ICD/IID file can be used as mics. This is a tool issue to expose the model implementation conformanc statement based on the IID file Descriptions @DOs are available for the docuementation purpose.
There is no valid use case for introducing the necessity of NSD here.
61850-7-7 Clause 5.4 (Use case 4) is named "Definition of private data model extensions by following the rules of the standard" which is exactly the usage of the MICS files except the NSD files are machine-readable (compare to free-form text of the MICS document without machine-readability).
Clause 5.4.3 specifies: "A private namespace is allowed only to extend existing LNClass or create new LNClass (with a different name than existing LNclass) and add DataObject to them".
NSD files allow semantic information for be attached to LN/DO in exactly same way as the object definitions in the core standard.
Additionally, any required enums and object abbreviations can be documented in the NSD file.
The results would be a machine-readable version of the definition of the non-standard extensions to the model which would simplify any future permanent changes to the code model.
An example of a NSD file is attached and a XSLT could be easily generated to convert this into an HTML rendering of the file.
What would be the purpose to introduce the manufaturer NSD from a certification perspective?
We already have the IID file that exposes the model. What additional use case would be covered?
An iid file may include additional user defined model extensions for the purpose of the test. Those extensions would not be part of the NSD, but are visible in the IID.
I am still not in favor for a NSD representation.
The purpose of the MICS is to provide a human readable information on the data model. NSD and SCL files are targeted for software applications. Secondly the NSD defines only classes not instances. As such an NSD can never replace a MICS. I disagree with the proposal (no change).
TPWG decided 20210824 to continue use of MICS and not use private NSD file.
However, additional requirements on MICS should be considered to make it simpler to locate proprietary Logical Nodes and Data Objects within the MICS. For now, it is up to the reader of the MICS to find this information.