Currently v0.0.2
© 2023. All rights reserved.
Currently v0.0.2
© 2023. All rights reserved.
This page describes the functional architecture of CoMPAS. CoMPAS provides software components related to IEC 61850 model implementation, specifically for power system profile management and configuration of a power system Protection Automation and Control System (PACS). It describes the logical decomposition.
The IEC61850 series are standards and documents describing the communication protocol between different equipments in a substation. It provides services and requirements for designing and deploying substation automation. It improves power quality, operation cost and maintenance activities within a substation.
| Process | Description |
|---|---|
| Specify IED | With this process the Utility specifies the required IED in an ISD file. This profile is input for the manufacturer to deliver the required IED |
| Specify Substation System | With this process the Utility specifies the substation system in an SSD file. For example, this specification may be done based on CIM data existing with the Utility |
| Configuration Substation System | With this process the Utility configures the substation. This results in the SCD file. Additional inputs for this process are the IID file (IED configuration) and SED file (interfacing with other projects) |
| Configure IED | The process of configuring the IED. This results in an instantiated IED IID file. The process is manufacturer specific. It results in either an ICD file or IID file. It is used to convert the SCD to a manufacturer specific CID file to be sent to the IED |
| Test | The fully configured IED can be tested against the SCD and SSD files |
| Convert CIM/GIS to IEC61850 SLD | CIM or GIS can be used to convert to 61850 configuration files |
Refer to the Glossary for the abbreviations and various 61850 file types.
The green indicated process are in scope for CoMPAS.
The diagram shows the context of CoMPAS. CoMPAS offers a set of IEC61850 services disclosed by a REST API that can be used to create tooling for specification, configuration, deployment and testing of substations.
This diagram shows the services within CoMPAS. Currently following (micro)services are provisioned:
| Service | Description |
|---|---|
| CIM to SSD Mapper | A service that maps a CIM representation of a substation to an IEC61850 System Specification Description (SSD) file |
| CoMPAS Configuration Manager | Example configuration tool, as web page, based on OpenSCD. CoMPAS microservices can be used to create own configuration tooling. CoMPASS Configuration Manager serves as an example of such a tool. |
| CoMPAS SCL Data Service | A service handling the storage of SCL files, hosted on Github. Besides hosting SCL files, it also offers APIs for storing and retrieving these SCL files. |
More services to be added
CoMPAS will consist of a number of microservices that can be used to build substation configuration tools according to IEC61850. In this situation a microservice architecture is chosen because of
The diagram shows the generic structure of a microservice. It consists of following layers:
| Layer | Description |
|---|---|
| Resources | Implements the REST API |
| Service | Implements the business logic of the service |
| Service Entities | Business entities within the service |
| Data | Data layer is responsible for access to storage or other services |
| Data Entities | Entities corresponding to the data storage of external services |
We adhere to the microservice architecture by applying following rules:
This section describes a number of design decisions
REST APIs: The microservice offers a REST API that presents the service. The IEC61850 services consists of various data conversions that may take time. The conversion is executed within the scope of the REST call. This means a REST call may take time.
REST Security: Https will be used for the REST calls. Data transferred by the calls must be regarded as confidential and therefore must be protected against data disclosure. Microservices must therefore be provided with a certificate. When all microservices and the Configuration Tool are deployed within the same namespace, it is allowed to use http.
OAuth 2.0 Code grant flow will be used for authentication and authorization. The user logs in on the Configuration Tool and obtains a code and token (preferably a Java Web Token (JWT)). The token is used to access the microservices as a resource. This requires an OAuth server.
Deployment: Microservices will be deployed as docker container
Scalability and redundancy: It must be possible to deploy multiple instances of a microservice. We won’t expect that scalability will be an issue. Availability might be an issue requiring redundant instances.