Interested in contributing? Please read carefully the CONTRIBUTING guidelines.  Refer to GLOSSARY for technical terms and acronyms. 

This page contains an overview overview of the ComPAS architecture. More details can be found on the ComPAS architecture website:

https://com-pas.github.io/compas-architecture/

Principles for Overall Architecture

The project will adopt the following principles for the overall software architecture:

Architecture Overview

Functional architecture

Overall functional block diagram

CoMPAS functional block diagram

The diagram below shows the functional block diagram structure and their interactions with the deployment requirements. It is composed of two packages: sct-core and sct-common (which could be replaced by compas-core depending on the choice of code hosting)

The requirements are constructed into ease of implementation, deployment, integration and adaptability with respect to the tools.

System Configuration Tool (SCT) functional diagram

SCT functional diagram

System Configuration Tool (SCT) is part of CoMPAS open source project. It goal is to bring a flexible and adaptative tool for configuring PACS (Power Automation and power Control System). It's an n-tiers architecture which combine reliability, flexibility, modularity and adaptability to allows users to choose their own database to implement the SCT.

The following architecture (package diagram) is divided in 3 major parts :


Compas SCT (System Configuration Tool) is dedicated to manage automatization of binding signals for 61850 standard. It allows third parts to realize their system configuration. This tool plays a capital role on managing devices configuration and communication on power systems.

The architecture of the SCT is oriented microservices and present advanced abstraction level in order to facilitate usage by third parties.

It's design choice is to allow every user to re-implement the tool  (data access part) according to his own needs. This architecture simplify usage and decrease contraints on database type to use and service aor controller re-adaptation for each need.

The component diagram shows two parts : sct-core and sct-common.

This model diagram describes the n-tiers architecture chosen for SCT implementation. It is composed by 2 parts : sct-core and sct-common. The sct-core part is devided into 3 layers : sct-app (controller), sct-service (service) and sct-data (data access abstract layer).

sct-app or controller layer and sct-service are concrete in opposite of sct-data which is abstract in order to allow it's re-implementation by concrete methods for user purpose and context.

The source code is in Java, Spring Boot and hosts in compas space on GitHub. The build process and IC/DC are realized with Github Actions and allows contributor to construct a valuable product. 

The component/package diagram allows to see the high modularity of the SCT architecture which gives a choice to build all components at the same time or build them one by one which may contribute off smart managing off package versions.



Data Architecture

Conceptual Overview of Data Architecture Repositories and Semantics



Tools

Fossoly is used by LF energy to scan on license compliance.

LFX security is used for security scanning in the code.