IEC 61850 Protection

Basic Application Profiles

By Maud Merley. RTE, France and Camille Bloch, Schneider Electric, France

Power utility automation application implementations varies from users, regions, and operational philosophies. IEC 61850 based automation systems are bound to a variety of implementations, which causes users to look for templates to improve the interoperability in projects along the entire lifecycle (Figure 1) of a system.  With integration of the different systems participating in the Smart Grid on all levels in the domain of power utility automation, interoperability is the key element to enable the power system transformation. Information exchange between different actors in the market like TSOs, DSOs, Aggregators, Energy markets, Power Generation, Prosumers and Energy Users demands a system-to-system approach with well-defined interfaces, roles, and responsibilities.

To achieve interoperability on all types of application functions, a common understanding and interpretation of all necessary layers will be necessary which could be ensured by the use of profiles – a subset of elements from a standard required in a given environment. IEC Technical Committee 57 therefore decided to work on a guideline for building Basic Application Profiles (BAP). 

This guideline aims to provide a constrained framework to model typical and often used automation functions for substation automation systems in the context of IEC 61850 in order to increase functional interoperability in practical applications and follows the approach of the framework document IEC TR 62361-103 (Edition 1, published in 2018) as shown in Figure 2.

The IEC TR 61850-7-6 (Edition1, published in 2019) focuses on the description of the typical information exchange including the data and communication services and related engineering conventions to provide the functional behavior definition of a specific application function.

The technical report itself does not intend to provide standardized description of some applications. A BAP in accordance with the technical report shall provide a fully defined (no option) and autonomous description of an application function with all required data as an interface to the rest of the system and shall be independent from any implementation and any real IED.

From a user point of view, the system specification might be realized by aggregating different BAPs to answer to his requirements. From an engineering process, the selected BAPs will have to be machine processable to be easily merged. The purpose of the future edition of the IEC TR 61850-7-6 is to describe a new kind of SCL file, supporting additional rules to adapt the BAP to a real system needs.

Content of BAP Technical Report (IEC 61850-7-6 ED1)

The concept of BAP comes from the need to standardize applications in the context of specific kind of users to simplify the implementation and reusability of well tested components of systems. This is the notion of profile applied to IEC 61850 to express a subset of data from the standard, integrated together to create a functional application.  The IEC 61850-7-6 ED1 has defined a development process and implementation requirements to express such a standardized IEC 61850 application profile by means of BAP, independent of any users. This TR also gives advice for user groups to manage these profiles in a central repository.  But the document does not define itself standardized BAPs.

The IEC 61850-7-6 allows to describe BAP in editorial tools (Word, Excel), which is an easy way to appropriate, use and share BAP between users. This method is also well adapted to describe data in tables (such quality management) and to include some “user-friendly” schemas and descriptions.

Then the document also defines the notion of BAP interoperability and testing, with real examples coming from users, and proposes a high level process of BAP integration into systems, as shown in Figure 3.

On-Going Work about BAP at IEC

Having started to describe the concept of BAP, utilities and suppliers have quickly faced some new challenges and questions: Is it possible to describe BAP using SCL?; How can we link BAP with general substation requirements?; Which tools can manage and process BAP? and How to include this in the engineering process?. The on-going work about function modelling and BAP, as we will see below, tries to and hopefully will succeed in solving these issues.

Function and Basic Application Profile Modelling in SCL: More and more, configuration of IEC 61850 PACS is based on a top-down engineering process, where a system tool aggregates all specifications (single line diagram…), as requirements for the whole configuration of the substation and its IEDs. In such specifications, utilities want to be able to describe, in SCL, functional requirements (IEC-61850-6-100), or BAP (future IEC 61850-7-6 ED2).

Evolution of the specification process is also subject of the previous article “From Specification to the Substation – The OSMOSE Project Contribution to Improve the IEC 61850 Engineering Process” published in Issue 054 of December 2020.

IEC TR 61850-6-100 Function Modelling in SCL: The technical report IEC TR 61850-6-100 under development is looking at improvement of the functional description of systems and brings the concept of application scheme description. The global engineering process is not changed, but this technical report proposes additional SCL elements to improve the specification with inclusion of new requirements from users.

Figure 4 gives an overview of changes proposed by the technical report. The first evolution is the creation of the concept of SourceRef which allows to model at specification level independently from any implementation the data exchange required between Logical Nodes. In the SCL Substation section, it will be possible to define SourceRef for each LNode, describing the data expected by the function to operate properly. It is similar to the ExtRef concept for the IEDs, but at functional level. (black arrows in Figure 4.)

The second concept represented in the figure is the Application Scheme, which is the definition of a real application, composed of different functions. A typical example is a breaker failure application. The concept of application scheme (or simply application) is the heart of the BAP which will be described later.

Then the IEC TR 61850-6-100 is also defining the possibility to specify values for different data of the specified functions (configuration or settings), in a similar way as it is done for implementation values with DOI/DAI SCL elements.

Another important evolution proposed by the Technical report is the new concept of Virtual Device which allows a user to allocate its specification functions to non-real devices, to start to work on the system architecture, dataflow, and communication specifications. Then, this virtual device will have a new exchange SCL format called .ISD (IED Specification Description), allowing to specify the expected real device to be provided for the system.

As seen in the above mentioned Osmose project, a full process based on these evolutions will allow to specify and configure the system.

The capacity to to define reusable pieces of specification without prior selection of the IED to be used, is now required, and this is where edition 2 of IEC TR 61850-7-6 will help.

IEC TR 61850-7-6 ED2 BAP modelling in SCL: Since 2018, a new WG10 Task Force is working on a new edition of the TR 61850-7-6 to describe the integration of BAP in the SCL engineering cycle.

The first point the TF has to deal with is to identify the new object models needed to describe BAP in SCL. Based on the extensions proposed by the IEC 61850-6-100 Task Force, the SCL basic application profile shall represent all elements described in the textual BAP of IEC TR 61850-7-6 ED1: the functions used by each actor or role of the application, the input signals of these functions, the logical architecture (LN used), or the variants of the application for instance. In this proposal (Figure 6), several concepts are introduced.

  • An Application Object is used to describe, at Substation Level or Voltage Level, an application scheme as defined in IEC TR 61850-6-100
  • The Role object represents an actor of the basic Application. It allows to group the functions needed to perform the Application under a semantically coherent entity, relying on the IEC TR 61850-6-100 concept of FunctionRef (references to Function instances in the Substation). Depending on the implementation on real projects, the function references contained in the Role could be instantiated once or more. This ability is represented by a specific attribute of the Role, “multi”, which could take values from “one”, “one to n” etc. in template files
  • The SignalRole object represents the incoming signal of the function used in a specific Role. Associated with the IEC 61850-6-100 SourceRef concept, it aims to specify the data exchange and kind of service (GOOSE…) required for the Application
  • The ApplicationVariant object may be the trickiest new concept. The idea is to cover all variants of an application in a unique template, to prevent having as many BAP SCL template as variants. As variants of application are user specific, they shall be defined in an open way (standardized the “way to do” but not the data). The proposal that has emerged in the IEC 61850-7-6 ED2 Task Force is, first, to allow users to define criteria (Voltage Level, topology of substation,…) and then to give the existing conditions of each object of the Application, based on an equation of criteria defined at first step. ApplicationVariant is only stated in template file, as in a specific project, only one variant is chosen (by the user at least, and automatically if possible) and applied. See the example, in the “Utility use case.”

Once the model is defined, one other important point is to define how the BAP SCL template should be integrated in the engineering process (Figure 5). Existing files as SSD could not be used as they are project specific, and BAP template should express all implementations options (application variants, multiplicity of Role as instance). The idea of the TF is to add a new input in the engineering process for the building of a SSD file: the .ASD file (Application Specification Description) which represents the BAP Template. Each .ASD file contains the template of a basic application (collection of roles and functions), which could be instantiated by a system specification tool (SST) in a project specific application as needed.

Thus, the TF still has to address some issues, regarding the SCL engineering process (merging of .ASD files in existing SSD project…), the verification of SSD compliance against ASD and so on.

Further work is in our mind (Figure 7), for utilities that may want to use machine-processable BAP (as UML for example) to get more advanced features: deal with BAP evolution management, be able to create “packages” of several BAP… Auto-generation of BAP textual description or SCL BAP template should be made available from this machine-processable BAP format. An ED3 of TR IEC 61850-7-6 will for sure follow the SCL work on BAP!

On-Going Work in TC95-WG2:  Not only IEC Technical Committee 57 and WG10 is dealing with profiles, and we will now have a look on the work in progress within the IEC Technical Committee 95 – WG2 (Protection functions with Digital input/outputs).

Process bus based on IEC 61850 is being introduced widely in the substation automation systems. There are standards for digitally interfacing instrument transformers (IEC 61869-9).

In order to ensure functional interoperability, the standards of protections have to be adapted. The aim of TR IEC 60255-216-1 ED1″Guidelines for requirements and tests for protection functions with digital inputs and output”, currently under development by IEC TC95 WG2 (Protection functions with Digital input/outputs), is to establish recommendations for protections functions with digital inputs and outputs, including

  • Subscription to streams of digital Sampled Values (SV) representing energizing inputs
  • Subscription to GOOSE (e.g. circuit breaker position, circuit breaker failure)
  • Publication of GOOSE messages (e.g. trip orders)
  • Subscription to time synchronization messages

This Technical Report will describe the global framework for digital interface protection functions (Figure 8), namely the relevant features in IEC 61850 and the properties of the Sampled Values defined in IEC 61869-6 and -9 subscribed by protection functions. This is done at the beginning of the Technical Report, covering in, particular SV published by SAMU (IEC 61869-13:2021) or LPIT (future IEC 61869-7 and -8). Specific requirements for protection functions are defined on this base for protection functions. In some cases, this concerns an extension or a specific profile of IEC 61850 (e.g. label some requirements as “mandatory” for protection functions instead of “optional” in base IEC 61850 standards). This can be understood as a profile of IEC 61850 to be used for protection functions. New requirements specific for digitally interfaced protection functions are formulated and the associated tests are discussed. Recommendations for standard developments associated to protection functions, but also for digitally interfaced Instrument Transformers (TC38) and for identified needs related to protection functions in IEC 61850 series are given at the end of the TR.

After its completion, the Technical Report is intended to be used as a base for TC95 standards for digitally interfaced protection functions. The following roadmap has been discussed for WG2:

  • Define the mandatory requirements and tests for a number of general features, possibly in a new part of IEC 60255 (IEC 60255-1xx series) giving general requirements for protection IED with digital interfaces. This includes accuracy, requirements for the IEC 61850 interface and test features, generic definition and methodology for criteria for publishing of output data with non-nominal quality and the expected behavior of a protection function in case of SV with non-nominal time synchronization and associated tests
  • For each functional part of IEC 60255, add the relevant requirements and tests for protection functions. This will be done in collaboration with TC95/MT4 at the same time as an existing standard is revised or a new standard is developed
  • Create a new part of IEC 60255 for IED interfacing binary I/O (BIED)     
  • Investigate if a part of IEC 60255 describing additional requirements for multifunctional IED interfaced with digital secondary system is necessary. This should cover minimal requirements for making functions independent from each other in order to be testable, e.g. using one separate LD per function

In addition to requirements for protections, the use of IEC 61850 based settings, and the requirements for their implementation, import and life-time management should also be addressed in standardization working groups.

Utility Use Case Example

To illustrate what we have just explained, we are now going thought the profiling experience of the French TSO, RTE, and the example of the BAP of line Distance Protection application.

At the beginning, in 2015, to model requirements for IEC 61850 Distance Protection Application, RTE relied on what was available: specifications for each application, standard fascicules, and general principles to meet (especially not to be dependent of vendor’s implementations, not consider allocation in IED).

The solution that emerged quickly was to model each application in a specific Logical Device. In addition to meet the expected principles, this allowed us the benefit of domain Logical Node (LLN0, LPHD…) to independently manage each application. The list of LNs needed to perform the application is then deduced from the specification and the standard fascicules. Sometimes, happily not so often, no standard LN can be mapped to the specification requirements. In that case, RTE uses pre-standardized LNs from Task Force works, or as a last resort defines some private LNs.

This is not sufficient to provide interoperability, and some additional information as to be specified, as for instance Data Object or Data Attribute to be used, or application and variants specificities to be taken into account. In relation with the method provided in the TR IEC 61850-7-6 ED1, RTE collected all this profiling information in a Word document. In this document, each function is described in its own chapter structured as follows:

  • General: a short textual description of the function
  • Used LN: list of LNs used to model the function
  • Specificities: more details needed to understand the function
  • Static description: lists all DO and DA needed, and maps, where it is possible, with utility tool entries, signals and settings
  • Interface description: also called “dynamic” description, shows the expected exchange between one application and its input or output linked to other applications

The full profiling of IEC 61850 application profiles of RTE is regularly updated and publicly available: https://www.rte-france.com/fournisseurs/network-together#LeprojetRSPACE

Annex C of the IEC 61850-7-6 TR ED1, also contains a textual description of line Distance Protection, with a functional description, the roles and actors involved, and some typical interactions. Other requirements could be described in such textual BAP, as the dynamic data model, some variants of the application, and performance requirements.

An IEC 61850 profile can be used as specification for the IEDs of the substation. Yet, for complete interoperability, it is also necessary to deal with quality of inputs signals.

As explained earlier, RTE adds input management tables to each application, to have predictable behavior in the PACS.

For each input, the expected behavior of the application (process as valid, ignore, block the application) is specified for the manufacturer. After sending all information about the profile, input signal, but also functional, communication, configuration or cyber-security requirements to suppliers, this can, at least allows to begin the engineering process, as represented by Figure 9.

Suppliers are expected to provide ICD files compliant to the RTE profile, however, at that time, there was no way to automatically verify it. Yet, textual description takes the risk of misinterpretations. For this reason, RTE strongly supports on-going work about machine processable BAP, in order to enforce our engineering workflow.

Inside the Task Force IEC 61850-7-6 ED2, some applications, such as the line Distance protection are used as examples to accompany this transition from text to automatism, and this is the point that we are at now (Figure 10). There is still a lot to do on this topic, and RTE is going to adapt its profile and engineering process over the course of future developments on BAP.

Conclusion: The Basic Application Profiles were created a few years ago, to answer a need to standardize (at different levels: international, user groups, users or manufacturers) application description to improve integration, testing, and interoperability between the different actors of an IEC 61850 system, by reducing the standard flexibility to a specific use case with less choices.

It has been identified from the beginning as not enough to have BAPs described only in a “paper” format as it is not exchangeable between tools. Users are still bound to human interaction. Since the first edition of TR IEC 61850-7-6, the standard has evolved, proposing a new concept related to machine processing and improvement of top down engineering process which has released the capability to describe an IEC 61850 application in SCL. In parallel, other standards are looking at the BAP usage for their own domain (like DER). This has been seen as the appropriate time to work on the machine-readable representation of BAP.

This is the next step for user to industrialize their engineering process, moving from a paper document exchange process between customer and provider to a machine to machine exchange. This will bring different advantages like the non-exhaustive list of:

  • Reducing human interactions and human errors
  • Improving interoperability at functional level in addition to communication level
  • Reducing time of engineering with an increase in quality
  • Improving quality of vendors delivery by giving interpretable specification to build their devices and systems
  • Easing of the commissioning of systems by giving source of comparison with implemented system

This kind of requirements are already a reality as it is shown by different users’ requirements, funded multi-party R&D project, and published papers.

This current work is a new step in digitalization of Power utility automation applications, opening other possibilities in virtualization, digital twins, or distributed protection systems.

It will now be the time to discover the new possibilities released by BAP expressed in a machine-processable format.

Biographies:

Maud Merley works as expert and test engineer of Protection Automation and Control System at RTE, the French TSO, since 2008.
Recently involved in standardization, Maud MERLEY is member of IEC TC57 WG10 and the French national mirror committee. She leads the Task Force in charge of the new edition of TR IEC 61850-7-6 about machine processable Basic Application Profile.

Camille Bloch is IEC 61850 System Experienced Principal Technical Expert of Relay Application Center of Excellence at Schneider Electric Energy Management Business after multiple carrier steps within R&D at ALSTOM and AREVA. He is member of international standardization body IEC TC57 WG10 and the French national mirror committee. As member of IEC TC57 WG10, he is specialized in IEC 61850 process, and editor of standards IEC 61850-6 and IEC 61850-7-7. He is convenor of the new CIGRE WG B5.68 and member of Linux Foundation for Energy (LFEnergy) CoMPAS project (Configuration Modules for Power industry Automation Systems).