CDV61850-6©IEC:2002 -16- 57WG10 contained completely in one voltage level,or preferably outside a voltage level,i.e.within a voltage level with empty designation string and no voltage specified Device an apparatus within the switchyard,e.g.circuit breaker,disconnector,volt- age transformer,power transformer winding etc.The single line diagram of a switchyard shows the electrical connection of these primary devices. Connectivity node objects model these connections.Therefore,each pri- mary device can contain via terminals links to the connectivity nodes to which it is connected.At single line level normally one or two terminals (connections)are sufficient. Subdevice a part of a primary Device,which might especially be a phase of a three- phase device. ConNode the (electrical)connectivity node object connecting different primary de- vices.Typical connectivity node examples are:connecting nodes within a bay(BayNode),bus bars connecting several bays in the same voltage level, lines connecting bays in different substations.See also Device above. Note:observe that the hierarchical structure is mainly used for functional designations.In case that substructures of bays are needed,this can be introduced by appropriate bay names.IF e.g.a bay B1 shall be structured into sub-bays SB1 and SB2,this would in the SCL model lead to two bays named B1.SB1 and B1.SB2.If logical nodes shall be attached also to the B1 structure level,then B1 can be introduced as a third bay. 6.2 The product (IED)model Products consisting of hardware or software implement the functions of the switchyard.The scope of SCL from the product side only covers the hardware devices(called IEDs)that form the substation automation system,and therefore restrict the model to them.Primary devices as products are outside the scope of SCL,only their functional side is modelled by the sub- station structure for functional naming purpose IED a substation automation device performing SA functions by means of LNs.It is normally communicating via a communication system with other IEDs in the SAS.Access point objects form the connection between an IED and subnetworks (communication buses)in the communication system. Server a communication entity within an IED according to part 7 of this standard.It allows access via the communication system and its only access point to the data of the logical devices and logical nodes contained in the server. LDevice a logical device (LD)according to part 7-2 of this standard,that is con- tained in a server of an IED. LNode a logical node (LN)according to parts 5 and 7-2 of this standard contained in a logical device of an IED.The LN contains Data (DO),which other Logi- cal Nodes request,and it may need DOs contained in other LNs to perform its function.The offered DOs (server capability)are described in SCL.The needed DOs (LN client side)are related to the function implementation and therefore determined by the IED configuration tool respective the engineer. SCL allows optionally to describe them,so that a data flow on data level between LNs can be modelled. DO the DATA contained in the LNs according to part 7 of this standard. This part of the standard introduces additionally Version 8CDV,August 2002
CDV 61850-6 © IEC:2002 – 16 – 57/WG10 Version 8CDV, August 2002 contained completely in one voltage level, or preferably outside a voltage level, i.e. within a voltage level with empty designation string and no voltage specified. Device an apparatus within the switchyard, e.g. circuit breaker, disconnector, voltage transformer, power transformer winding etc. The single line diagram of a switchyard shows the electrical connection of these primary devices. Connectivity node objects model these connections. Therefore, each primary device can contain via terminals links to the connectivity nodes to which it is connected. At single line level normally one or two terminals (connections) are sufficient. Subdevice a part of a primary Device, which might especially be a phase of a threephase device. ConNode the (electrical) connectivity node object connecting different primary devices. Typical connectivity node examples are: connecting nodes within a bay (BayNode), bus bars connecting several bays in the same voltage level, lines connecting bays in different substations. See also Device above. Note: observe that the hierarchical structure is mainly used for functional designations. In case that substructures of bays are needed, this can be introduced by appropriate bay names. IF e.g. a bay B1 shall be structured into sub-bays SB1 and SB2, this would in the SCL model lead to two bays named B1.SB1 and B1.SB2. If logical nodes shall be attached also to the B1 structure level, then B1 can be introduced as a third bay. 6.2 The product (IED) model Products consisting of hardware or software implement the functions of the switchyard. The scope of SCL from the product side only covers the hardware devices (called IEDs) that form the substation automation system, and therefore restrict the model to them. Primary devices as products are outside the scope of SCL, only their functional side is modelled by the substation structure for functional naming purpose. IED a substation automation device performing SA functions by means of LNs. It is normally communicating via a communication system with other IEDs in the SAS. Access point objects form the connection between an IED and subnetworks (communication buses) in the communication system. Server a communication entity within an IED according to part 7 of this standard. It allows access via the communication system and its only access point to the data of the logical devices and logical nodes contained in the server. LDevice a logical device (LD) according to part 7-2 of this standard, that is contained in a server of an IED. LNode a logical node (LN) according to parts 5 and 7-2 of this standard contained in a logical device of an IED. The LN contains Data (DO), which other Logical Nodes request, and it may need DOs contained in other LNs to perform its function. The offered DOs (server capability) are described in SCL. The needed DOs (LN client side) are related to the function implementation and therefore determined by the IED configuration tool respective the engineer. SCL allows optionally to describe them, so that a data flow on data level between LNs can be modelled. DO the DATA contained in the LNs according to part 7 of this standard. This part of the standard introduces additionally
CDV61850-6©IEC:2002 -17- 57WG10 a Router function on an IED.This is a function of the communication network,therefore it is described in the next subclause. a Clock function to indicate where a subnetwork master clock is located. 6.3 The Communication system model The communication model is,in contrast to the others,not a hierarchical model.It models the logically possible connections between IEDs at and across subnetworks by means of access points.A subnetwork is seen on this description level only as a connecting node between ac- cess points,not as a physical structure.A logical device of an IED is connected to a subnet- work by means of an access point,which may be a physical port or a logical address(server) of the IED.Client LNs use the address attribute of the access point to build up associations to servers on other IEDs containing logical devices respective to their contained LNs. Although subnetworks only model logically possible connections,a correlation to the physical structure can be built up by appropriate naming of subnetworks and access points,and by the relation of access points to (one or more)physical connection points.The access points are the matching elements (transition objects)of both this communication model and the physical implementation of the communication system.The description and maintenance of the physical structure is out of the scope of the core SCL. Subnetwork a connecting node for direct (link layer)communication between access points.It might contain routing on bridge level,but not on network level.All access points connected to a subnetwork can communicate with all others on the same subnetwork with the same protocol.SCSMs may define re- strictions to this e.g.if the stack implements a master-slave bus.The sub- network as used here is a logical concept.Several logical subnetworks with different higher layer protocol could e.g.be used on the same physical bus to allow mixing of higher level protocols on the same physical (lower) layer(s). Access point a communication access point of the logical device(s)of an IED to a sub- network.There is at most one connection between a logical device and a subnetwork on this logical modelling level.An access point may,however, serve several logical devices,and the logical nodes contained in a logical device may,as clients,use several access points to connect to different subnetworks.Typically a switch controller LN may get data as a client from a process bus(part 9-x of this standard),and provide data as a server to the inter bay bus(part 8-1 of this standard).In the terminology of part 7 an access point may be used by a server,a client,or by both.Further the same (logical)access point might support different physical access ports, e.g.an Ethernet connection and a serial PPP based connection to the same higher level(TCP/IP)access point and same server. Router Normally Clients connected to a subnetwork have only access to servers connected to that subnetwork.The router function extends access to serv- ers connected to another subnetwork at another access point of that IED which hosts the router function.However,a router restricts the access to those services which use a networking layer,all other services like GSE, sampled values and time synchronisation messages are not allowed to cross it. Clock a master clock at this subnetwork,which is used to synchronize the internal clocks of all (other)IEDs connected to this subnetwork. Version 8CDV,August 2002
CDV 61850-6 © IEC:2002 – 17 – 57/WG10 Version 8CDV, August 2002 • a Router function on an IED. This is a function of the communication network, therefore it is described in the next subclause. • a Clock function to indicate where a subnetwork master clock is located. 6.3 The Communication system model The communication model is, in contrast to the others, not a hierarchical model. It models the logically possible connections between IEDs at and across subnetworks by means of access points. A subnetwork is seen on this description level only as a connecting node between access points, not as a physical structure. A logical device of an IED is connected to a subnetwork by means of an access point, which may be a physical port or a logical address (server) of the IED. Client LNs use the address attribute of the access point to build up associations to servers on other IEDs containing logical devices respective to their contained LNs. Although subnetworks only model logically possible connections, a correlation to the physical structure can be built up by appropriate naming of subnetworks and access points, and by the relation of access points to (one or more) physical connection points. The access points are the matching elements (transition objects) of both this communication model and the physical implementation of the communication system. The description and maintenance of the physical structure is out of the scope of the core SCL. Subnetwork a connecting node for direct (link layer) communication between access points. It might contain routing on bridge level, but not on network level. All access points connected to a subnetwork can communicate with all others on the same subnetwork with the same protocol. SCSMs may define restrictions to this e.g. if the stack implements a master-slave bus. The subnetwork as used here is a logical concept. Several logical subnetworks with different higher layer protocol could e.g. be used on the same physical bus to allow mixing of higher level protocols on the same physical (lower) layer(s). Access point a communication access point of the logical device(s) of an IED to a subnetwork. There is at most one connection between a logical device and a subnetwork on this logical modelling level. An access point may, however, serve several logical devices, and the logical nodes contained in a logical device may, as clients, use several access points to connect to different subnetworks. Typically a switch controller LN may get data as a client from a process bus (part 9-x of this standard), and provide data as a server to the inter bay bus (part 8-1 of this standard). In the terminology of part 7 an access point may be used by a server, a client, or by both. Further the same (logical) access point might support different physical access ports, e.g. an Ethernet connection and a serial PPP based connection to the same higher level (TCP/IP) access point and same server. Router Normally Clients connected to a subnetwork have only access to servers connected to that subnetwork. The router function extends access to servers connected to another subnetwork at another access point of that IED which hosts the router function. However, a router restricts the access to those services which use a networking layer, all other services like GSE, sampled values and time synchronisation messages are not allowed to cross it. Clock a master clock at this subnetwork, which is used to synchronize the internal clocks of all (other) IEDs connected to this subnetwork
CDV61850-6©1EC:2002 -18- 57WG10 7 Configuration Description Files Configuration description files are used to exchange the configuration data between different tools. possibly from different manufacturers.As already mentioned in section 5(see also figure 2),there are at least two kinds of configuration files to be distinguished for the data exchange between tools.This is done by means of different file extensions.Nevertheless the contents of each file shall obey the rules of the Substation Configuration Language SCL defined in the next section.Each file should contain a version and revision number to distinguish different versions of the same file.This means that each tool has to keep the version and revision number information of the last file exported,or read back the last existing file to find out its version. Note:The version identifies versions of the SCL file,not versions of the data models used within the tools.This is a private issue of the tools. The following types of SCL files are distinguished: Data exchange from the IED configurator tool to the system tool (corresponding to points 1 and 2 of clause 5).This file describes the capabilities of an IED.It shall contain exactly one IED section for the IED whose capabilities are described.Further it shall contain the needed logical node type definition,and may contain an optional substation section. The file extension shall be .ICD for IED Configuration Description. Data exchange from the system configurator tool to IED configurator tools(corresponding to points 3 and 4 of clause 5).This file contains all IEDs,a communication configuration section and a substation description section. The file extension shall be .SCD for Substation Configuration Description. The IED Configuration Description file again may be used in different ways. If the name of the IED (Ref attribute,see next clause)is left blank,then this is a file for a device type,i.e.it describes the capabilities of a certain device type,and can be used as a start of engi- neering for each device of this type.This file does not contain a communication system section, but may contain an optional substation section that has the substation and voltage level names (Ref attributes)undefined,i.e.set to an empty string. If the name of the IED is given,this refers to an instantiated IED within a project.In this case the communication section contains the current address of the IED.The substation section related to this IED may be present and have name values assigned according to the project specific names. Version 8CDV,August 2002
CDV 61850-6 © IEC:2002 – 18 – 57/WG10 Version 8CDV, August 2002 7 Configuration Description Files Configuration description files are used to exchange the configuration data between different tools, possibly from different manufacturers. As already mentioned in section 5 (see also figure 2), there are at least two kinds of configuration files to be distinguished for the data exchange between tools. This is done by means of different file extensions. Nevertheless the contents of each file shall obey the rules of the Substation Configuration Language SCL defined in the next section. Each file should contain a version and revision number to distinguish different versions of the same file. This means that each tool has to keep the version and revision number information of the last file exported, or read back the last existing file to find out its version. Note: The version identifies versions of the SCL file, not versions of the data models used within the tools. This is a private issue of the tools. The following types of SCL files are distinguished: • Data exchange from the IED configurator tool to the system tool (corresponding to points 1 and 2 of clause 5). This file describes the capabilities of an IED. It shall contain exactly one IED section for the IED whose capabilities are described. Further it shall contain the needed logical node type definition, and may contain an optional substation section. The file extension shall be .ICD for IED Configuration Description. • Data exchange from the system configurator tool to IED configurator tools (corresponding to points 3 and 4 of clause 5). This file contains all IEDs, a communication configuration section and a substation description section. The file extension shall be .SCD for Substation Configuration Description. The IED Configuration Description file again may be used in different ways. • If the name of the IED (Ref attribute, see next clause) is left blank, then this is a file for a device type, i.e. it describes the capabilities of a certain device type, and can be used as a start of engineering for each device of this type. This file does not contain a communication system section, but may contain an optional substation section that has the substation and voltage level names (Ref attributes) undefined, i.e. set to an empty string. • If the name of the IED is given, this refers to an instantiated IED within a project. In this case the communication section contains the current address of the IED. The substation section related to this IED may be present and have name values assigned according to the project specific names
CDV61850-6©1EC:2002 -19- 57WG10 8 The SCL language The SCL language is based on XML(see normative references). 8.1 Specification method The XML language contains a method to define the allowed vocabulary of XML document types,the Document Type Definition (DTD).The later developed XML Schema is an en- hancement to DTD which additionally allows to define data types and data type dependent value coding.The XML Schema language can express more details syntactically,and is therefore used here for the normative syntax definition of SCL.The appropriate XML Schema definition is enhanced by appropriate (incomplete)examples illustrating the use of the spe- cific feature defined,and additional written requirements,restrictions,and relations to the object model,which shall be used or checked by the application reading or building an SCL file.The complete normative XML schema definition is contained in the appendix. In the following schema definition parts it is assumed that the SCL Schema definition file starts as follows: <?xml version="1.0"encoding="UTF-8"?> <!--W3C Schema for IEC61850-6 (SCL)--> <xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema" elementFormDe- fault="qualified"> and then ends with </xs:schema> The basic XML syntax is itself specified in a special form of extended Backus -Naur form (EBNF).In certain cases reference is taken to elements defined there,by indicating them as XML-EBNF elements. In some cases the data format of values is important.Wherever possible,here the data type coding (lexical presentations)of the XML Schema shall be used.If not explicitly said,all ele- ment values are XML Schema strings,and all attribute values are of the XML Schema type normalizedString,i.e.they are not allowed to contain tab,carriage return and line feed char- acters.Further restrictions may be stated either in this document or in other parts of this standard,mostly parts 7,8 and 9.If any XML schema data type is used,it is referenced with the prefix xs:,e.g.xs:decimal for decimal number coding.For convenience an overview about coding of the most types used in SCL is given in Table 2 Data type mapping 8.2 Private Data Private data entities appear on several levels of the SCL.The contents of these XML ele- ments is,as seen from the SCL,transparent text (XML format CDATA).If the Private part shall contain XML data,then this has to be bracketed with <![CDATA[at the start,and ]]at the end. Private data for different purpose can be distinguished by the value of its Type attribute The handling within tools shall be as follows: The private data is owned by a tooltool category.The owner is allowed to modify its con- tents,and normally is the only one able to interpret the data.All other tools which read pri- vate data have to preserve (store)its contents on SCL import,and regenerate it if an SCL file containing this part is produced exported. Version 8CDV,August 2002
CDV 61850-6 © IEC:2002 – 19 – 57/WG10 Version 8CDV, August 2002 8 The SCL language The SCL language is based on XML (see normative references). 8.1 Specification method The XML language contains a method to define the allowed vocabulary of XML document types, the Document Type Definition (DTD). The later developed XML Schema is an enhancement to DTD which additionally allows to define data types and data type dependent value coding. The XML Schema language can express more details syntactically, and is therefore used here for the normative syntax definition of SCL. The appropriate XML Schema definition is enhanced by appropriate (incomplete) examples illustrating the use of the specific feature defined, and additional written requirements, restrictions, and relations to the object model, which shall be used or checked by the application reading or building an SCL file. The complete normative XML schema definition is contained in the appendix. In the following schema definition parts it is assumed that the SCL Schema definition file starts as follows: <?xml version="1.0" encoding="UTF-8"?> <!--W3C Schema for IEC61850-6 (SCL)--> <xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema" elementFormDefault="qualified"> and then ends with </xs:schema> The basic XML syntax is itself specified in a special form of extended Backus - Naur form (EBNF). In certain cases reference is taken to elements defined there, by indicating them as XML-EBNF elements. In some cases the data format of values is important. Wherever possible, here the data type coding (lexical presentations) of the XML Schema shall be used. If not explicitly said, all element values are XML Schema strings, and all attribute values are of the XML Schema type normalizedString, i.e. they are not allowed to contain tab, carriage return and line feed characters. Further restrictions may be stated either in this document or in other parts of this standard, mostly parts 7, 8 and 9. If any XML schema data type is used, it is referenced with the prefix xs:, e.g. xs:decimal for decimal number coding. For convenience an overview about coding of the most types used in SCL is given in Table 2 Data type mapping 8.2 Private Data Private data entities appear on several levels of the SCL. The contents of these XML elements is, as seen from the SCL, transparent text (XML format CDATA). If the Private part shall contain XML data, then this has to be bracketed with <![CDATA[ at the start, and ]]> at the end. Private data for different purpose can be distinguished by the value of its Type attribute. The handling within tools shall be as follows: The private data is owned by a tool / tool category. The owner is allowed to modify its contents, and normally is the only one able to interpret the data. All other tools which read private data have to preserve (store) its contents on SCL import, and regenerate it if an SCL file containing this part is produced / exported
CDV61850-6©1EC:2002 -20- 57WG10 The appropriate IED Configurator tool owns all private data within IED sections.The System configurator tool owns all other private data (on top level,within the substation part,and within the communication part).Only the LNodeType section might contain Private data from the IED tool to which it belongs,as well as from the system configurator tool.Therefore Pri- vate data for different purpose here shall be distinguished by the value of its Type attribute.If manufacturers use it,this Type attribute value should start with a manufacturer specific string part. 8.3 SCL Language extensions Extensions of the data model with semantically new LNs and DOs are covered by the rules stated in part 7-x for extensions,and by the SCL approach as a meta language to the data model,i.e.data model element identifications do not appear in the language syntax itself. The name scope of logical node classes,DATA and CDC attributes are described in SCL by stating the appropriate name space values within the appropriate DATA attributes The core SCL as defined here is designed for a specific purpose described in clause 5.It can however be used with smaller or bigger extensions like additional attributes for additional (engineering)tasks.Further it leaves some communication stack dependent definitions to the SCSMs.Therefore the following describes SCL extension possibilities. 8.3.1 Additional semantics to existing syntax elements Some language elements of SCL like Desc have a weakly defined semantic,some like the parameter P have purposely been left open.An SCSM shall or a further standard can define (additional)semantics to these elements.This can be done e.g.by defining a Type value for a P parameter with an own semantic. 8.3.2 Data type constraints The usage of XML schema based data types allows already on the syntactic level to further restrict the range of some values.A restriction shall use one of the allowed subtypes of the types defined in this core language. 8.3.3 XML name spaces For all tag elements(sub-)tags and attributes can be added.These shall however belong to a defined XML name space with a defined semantics for all these elements.The used name spaces shall be defined at the main tag (SCL).For private name spaces the used internal name space abbreviation shall start with the character e.An example of a standard extension for single line or communication diagram layouts is given in the appendix.The name space URI of this version of the core SCL (which is normally used as default name space in case additional elements are used in an SCD or ICD file)is xmlns:scl http://www.iec.ch/61850/scl001 All tools compliant to this standard shall be able to import an SCL file with name space defi- nitions,at least for the core SCL as the default name space.Name spaces other than the SCL core,which are not understood by the tool,shall be ignored by it.This means especially, that an IED tool which exports data in its own name space to an ICD file,can NOT expect that this information is contained resp.preserved in a SCD file coming from the system con- figurator tool. 8.3.4 Private parts For small manufacturer or project specific extensions the Private parts can be used (see 8.2) The advantage of private parts is that the data content is preserved at data exchange be- tween tools. Version 8CDV,August 2002
CDV 61850-6 © IEC:2002 – 20 – 57/WG10 Version 8CDV, August 2002 The appropriate IED Configurator tool owns all private data within IED sections. The System configurator tool owns all other private data (on top level, within the substation part, and within the communication part). Only the LNodeType section might contain Private data from the IED tool to which it belongs, as well as from the system configurator tool. Therefore Private data for different purpose here shall be distinguished by the value of its Type attribute. If manufacturers use it, this Type attribute value should start with a manufacturer specific string part. 8.3 SCL Language extensions Extensions of the data model with semantically new LNs and DOs are covered by the rules stated in part 7-x for extensions, and by the SCL approach as a meta language to the data model, i.e. data model element identifications do not appear in the language syntax itself. The name scope of logical node classes, DATA and CDC attributes are described in SCL by stating the appropriate name space values within the appropriate DATA attributes. The core SCL as defined here is designed for a specific purpose described in clause 5. It can however be used with smaller or bigger extensions like additional attributes for additional (engineering) tasks. Further it leaves some communication stack dependent definitions to the SCSMs. Therefore the following describes SCL extension possibilities. 8.3.1 Additional semantics to existing syntax elements Some language elements of SCL like Desc have a weakly defined semantic, some like the parameter P have purposely been left open. An SCSM shall or a further standard can define (additional) semantics to these elements. This can be done e.g. by defining a Type value for a P parameter with an own semantic. 8.3.2 Data type constraints The usage of XML schema based data types allows already on the syntactic level to further restrict the range of some values. A restriction shall use one of the allowed subtypes of the types defined in this core language. 8.3.3 XML name spaces For all tag elements (sub-)tags and attributes can be added. These shall however belong to a defined XML name space with a defined semantics for all these elements. The used name spaces shall be defined at the main tag (SCL). For private name spaces the used internal name space abbreviation shall start with the character e. An example of a standard extension for single line or communication diagram layouts is given in the appendix. The name space URI of this version of the core SCL (which is normally used as default name space in case additional elements are used in an SCD or ICD file) is xmlns:scl = http://www.iec.ch/61850/scl001. All tools compliant to this standard shall be able to import an SCL file with name space definitions, at least for the core SCL as the default name space. Name spaces other than the SCL core, which are not understood by the tool, shall be ignored by it. This means especially, that an IED tool which exports data in its own name space to an ICD file, can NOT expect that this information is contained resp. preserved in a SCD file coming from the system configurator tool. 8.3.4 Private parts For small manufacturer or project specific extensions the Private parts can be used (see 8.2). The advantage of private parts is that the data content is preserved at data exchange between tools