by Christoph Brunner, it4power, Switzerland
You may be aware that there exists a part IEC 61850-7-6 with the title “Guideline for definition of Basic Application Profiles (BAPs) using IEC 61850.” As IEC 61850 covers a wide range of applications, specific usages of IEC 61850 typically only require a subset of the full functionality. For a subset of a standard, the term “profile” is commonly used.
While depending on the scope and objective, different types of profiles exist, the focus here is on application profiles, where the profile specifies what is required to implement a specific application. An application like as an example “breaker failure protection” is realized through the interaction of various functions (e.g. breaker interface, protection tripping, breaker failure detection etc). These functions exchange data (e.g. breaker position, current measurement, initiate function, etc) to achieve the purpose of the application.
The part 7-6 of the IEC 61850 series defines a methodology to define what is called Basic Application Profile (BAP). A basic application profile is a selection from the standard for a specific application that then can be used as a building block for e.g., a project specification.
According to the template to describe a BAP as introduced by IEC 61850-7-6, the description of a BAP starts with a functional description to explain the expected behavior of the application function. This is followed by a use case description with actors, roles and sequence diagrams for the typical interactions.
Next follows the logical architecture described with IEC 61850 Logical Nodes (LN) and the interactions between those. The interactions are defined using the data objects from the LNs. Optionally function allocation and functional variants may be discussed as well as performance requirements.
Then, based on the previous, the data model per actor / LN as well as the required communication services is identified. From that, device related requirements may be derived. Finally, the BAP includes requirement related to engineering tools, naming rules and capabilities for testing.
While the guideline is part of the IEC 61850 standard, it is not foreseen to develop BAPs as part of the standard. It is rather the role of user organizations or of individual users to develop the BAPs for their specific requirements. So, a utility may define BAPs for the different applications they use in their substations. As mentioned above, a BAP identifies the data model and the requirements on communication for a specific application.
By combining all the BAPs for a specific context like as an example the feeders in a transmission substation, a superset of the data model and the requirements on the communication services can be created. Considering function allocation, a utility or user organization can then derive device profiles for e.g. feeder protection units and bay controllers that will be suitable to be used in the feeders of the transmission substations of the utility.
Supporting interoperability between different devices was always one of the goals of IEC 61850. As profiling reduces options, it reduces configuration effort to achieve interoperability. Interoperability is not only relevant for protection, automation and control systems in substations. Interoperability is as well relevant for integration of Distributed Energy Resources (DER) in the grid. DERs play an important role in the SmartGrid and need to exchange information with multiple actors. Interoperability is key here.
NIST (US National Institute of Standards and Technology) has identified the need for an interoperability profile for DER controllers and is partnering with SEPA (US Smart Electric Power Alliance) to develop such a profile.
The approach to develop such a profile is to create in a first step BAPs for the applications that the DER controller shall support. In this first step, those BAPs are kept standard neutral, which means the data model requirements as well as the communication requirements are expressed in a generic way and not as IEC 61850 data.
A DER interoperability profile – which is a device profile for a DER controller– can then be created as a superset of the BAPs. That still generic profile can then be mapped on IEC 61850. The profile can as well be mapped on other protocols, however as most protocols do not support semantic data but only data points that are identified with numbers, a model needs to be created by mapping the identified data on specific points.
While according to this first Edition of IEC 61850-7-6, the BAP is only described as a text document, IEC TC57, WG 10 is now preparing a second Edition that will include an extension to describe, how it will be possible to describe a BAP using the System Configuration Language (SCL). Once this is available, system specification and design can be further automated.
A user can create a library of the BAPs for his use cases, or he may rely on a collection of BAPs defined by a user organization like as an example ENTSO-E, the organization of the European Transmission System Operators. With a system specification tool, he may then apply the required BAPs to a specific project. The tool can then automatically derive the data model and the required data flow from the BAP.
Biography:
Christoph Brunner is the President of his own independent consulting company it4power LLC based in Switzerland. He has over 25 years of experience with knowledge across several areas within the Utility Industry and of technologies from the Automation Industry. He has worked as a project manager at ABB Switzerland Ltd in the area of Power Technology Products in Zurich / Switzerland where he was responsible for the process close communication architecture of the automation system. He is Convener of WG 10 of the IEC TC57 and is a member of WG 17, 18 and 19 of IEC TC 57. He is member of IEEE-PES and IEEE-SA. He is an IEEE Fellow and is active in several working groups of the IEEE-PSRC and a member of the PSRC main committee and the subcommittee H. He is advisor to the board of the UCA international users’ group.
