IEC 61850 defines Device Models for the exchange of information between any two or more entities. The Models are structured as unique branches of a tree.That means:
The signals are composed of an access reference (LDName/LNName.DOI. ...) and the value that corresponds with the path.
Example of two leaves:
LDName/Tran1STMP1.Tmp.mag.f = 23.5 (Temperature value)
LDName/Tran1STMP1.Tmp.units.SIUnit = °C (Temperature engineering units)
These are key-value pairs that could easily map to JSON Objects:
"LDName/Tran1STMP1.Tmp.mag.f " : "23.5"
"LDName/Tran1STMP1.Tmp.units.SIUnit" : °C
These JSON objects are
Lesson learned: Controller in inverter could easily provide an http/JSON interface.
The Device Model is a virtual model that could be configured using the SCL (System Configuration Language, IEC 61850-6). The Device Model is implemented in an IED and could be accessed to get the self-description, read, write, send/receive reports, publish/subscribe, ...
An IEC 61850 Server hosted by an IED could easily map the model to JSON objects that may be communicated with MQTT, HTTP, ...
The mapping to JSON is quite easy. It could be implemented by a simple automatic process that parses the model (SCL/XML), searches for the paths and concatenates the names from the root to the leaves to get the reference! AND: the mapping preserves the semantic - the meaning represented by the path name.
The mappings of IEC 61850 Models to IEC 60870-5-104, DNP3 or Modbus would result in messages that have lost the semantic of the signals. These solutions have mainly numbers as reference - these numbers have no meaning in the communication.
Each path from the Device (Root) to
any node or leave of the trees is unique
The signals are composed of an access reference (LDName/LNName.DOI. ...) and the value that corresponds with the path.
Example of two leaves:
LDName/Tran1STMP1.Tmp.mag.f = 23.5 (Temperature value)
LDName/Tran1STMP1.Tmp.units.SIUnit = °C (Temperature engineering units)
These are key-value pairs that could easily map to JSON Objects:
"LDName/Tran1STMP1.Tmp.mag.f " : "23.5"
"LDName/Tran1STMP1.Tmp.units.SIUnit" : °C
These JSON objects are
- Light-weight
- Language independent
- Easy to process with Python, ...
- Text based and human readable
- JSON Schemas could support automatic (syntax and semantic) checks
- JSON is supported by many controllers
Lesson learned: Controller in inverter could easily provide an http/JSON interface.
The Device Model is a virtual model that could be configured using the SCL (System Configuration Language, IEC 61850-6). The Device Model is implemented in an IED and could be accessed to get the self-description, read, write, send/receive reports, publish/subscribe, ...
An IEC 61850 Server hosted by an IED could easily map the model to JSON objects that may be communicated with MQTT, HTTP, ...
The mapping to JSON is quite easy. It could be implemented by a simple automatic process that parses the model (SCL/XML), searches for the paths and concatenates the names from the root to the leaves to get the reference! AND: the mapping preserves the semantic - the meaning represented by the path name.
The mappings of IEC 61850 Models to IEC 60870-5-104, DNP3 or Modbus would result in messages that have lost the semantic of the signals. These solutions have mainly numbers as reference - these numbers have no meaning in the communication.
Posts
No comments:
Post a Comment