· CoMPAS Architecture

Functional architecture

Introduction

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 standard

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. CoMPAS functional block diagram

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.

CoMPAS architecture

Context

CoMPAS context diagram

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.

First level of decomposition

CoMPAS context diagram

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

Microservice architecture

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

CoMPAS will provide reusable components
The development will be open source, therefore by multiple development teams. Since microservices are loosely coupled and independent this will fit.
Microservices are independently deployable and testable

Microservice architecture

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:

Microservices are developed independently
If a microservice requires storage (e.g. a database), it will be part of the microservice
If some central data store is required, it must be disclosed by a microservice that can be used by the other microservices.

Design decisions

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.