Project

General

Profile

Issues #649

Should vendors be required to provide a vendor specific NSD instead of MICS

Added by Herbert Falk about 3 years ago. Updated over 2 years ago.

Status:
Closed
Priority:
Normal
Assignee:
-
Due date:
Discuss in Upcoming Meeting:
No
Clause Reference:
61850 Standard:
Triggering Tissue:
Final Decision:
Initial Test Document:
Updated Test Document:
Test Case ID:
Closed Reason:
No Action Taken
Triggering Tissue 2:
Triggering Tissue 3:

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

Related to Server - Issues #648: Is MICS to be deprecatedClosedActions
#1

Updated by Herbert Falk about 3 years ago

  • Related to Issues #648: Is MICS to be deprecated added
#2

Updated by Herbert Falk about 3 years ago

  • Status changed from New to Resolved
#3

Updated by Herbert Falk about 3 years ago

  • Status changed from Resolved to In Progress
#4

Updated by Herbert Falk about 3 years ago

  • Status changed from In Progress to New
#5

Updated by Thierry Dufaure about 3 years ago

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.

#6

Updated by Bruce Muschlitz about 3 years ago

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.

#7

Updated by Thierry Dufaure about 3 years ago

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.

#8

Updated by Richard Schimmel over 2 years ago

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).

#9

Updated by Richard Schimmel over 2 years ago

  • Status changed from New to In Progress
#10

Updated by Bruce Muschlitz over 2 years ago

  • Status changed from In Progress to Closed
  • Closed Reason No Action Taken added

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.

Also available in: Atom PDF