com-pas / compas-core Goto Github PK

As developer

I need to know how to store different database files in baseX

So I can integrate with openSCD

Background:

Is this way we want to store the the diffenent SCL files?

Acceptance criteria

-How to handle different file extensions?

-What are the relations and how to handle them?

-Document in the CoMPAS architecture including the requirements

As end-user

I want to be able to store the provernance of SCL files

So I check the provernance in case of issues

Background

If the generation of substation fails, if would be nice of we can check what the history/provernance of the files is. W3C prov can be used for this:

PROV-Overview (w3.org)

Acceptance criteria

• Document the place where is information can be stored

Some new CoMPAS extensions are added in the coming time and we decide that the names of the current two type are not what we want.
The types should be changed from tSclName/tSclFileType to tCompasSclName/tCompasSclFileType.
Looking at the current code, this shouldn't have any impact, because the type names are only used in the XSD.

This issue was automatically created by Allstar.

Security Policy Violation
Security policy not enabled.
A SECURITY.md file can give users information about what constitutes a vulnerability and how to report one securely so that information about a bug is not publicly visible. Examples of secure reporting methods include using an issue tracker with private issue support, or encrypted email with a published key.

To fix this, add a SECURITY.md file that explains how to handle vulnerabilities found in your repository. Go to https://github.com/com-pas/compas-core/security/policy to enable.

For more information, see https://docs.github.com/en/code-security/getting-started/adding-a-security-policy-to-your-repository.

This issue will auto resolve when the policy is in compliance.

Issue created by Allstar. See https://github.com/ossf/allstar/ for more information. For questions specific to the repository, please contact the owner or maintainer.

As a developer
I want to remove the dependency on the Jandex Maven Plugin
So that there are less dependencies to manage (and problem to occur with upgrades)

Background:
Jandex is used to indicates which components there are in a JAR File. (Classes Annotated)
But with the upgrade to 1.2.0 of Jandex something changed causing the old version not to work with the new version.
This means that all dependent repositories (SCL Data Service and CIM Mapping) also need to be synced at the same time.

This can be solved in a different way. Remove Jandex and the Annotations can also be removed.
And in the dependent repositories (SCL Data Service and CIM Mapping) initialize the beans in a Application Configuration.
This is already done for example the JAXB Marshaller.
This way the JAR file can be used also in other ways for example in Spring with RestEASY.

As a risk manager

I would like to sign the SCL config files

so I can be sure that receiving parties can check the file on authenticity

Background

Signing SCL config files is part of the CoMPAS security measures.

compas-architecture/security_requirements_workshop.pdf at master · com-pas/compas-architecture (github.com)

Acceptance criteria:

• Identify related IEC document related to XML signing
• Document the storage location of the signing

For automatic releasing, we should setup release-please GH Action.

We're currently waiting for V4 of release-please (https://github.com/google-github-actions/release-please-action/pull/883) to be released, since we're making use of a develop/main branch.

Steps to take:

Create release-please.yaml with release-please@v4
Should be triggered on push to main.
Target branch should be main.

This is the current workflow:

gitGraph LR:
    commit
    branch "Develop"
    branch "Feature1"
    commit
    checkout "Develop"
    commit
    merge "Feature1"
    branch "Feature2"
    commit
    commit
    checkout "Develop"
    merge "Feature2"
    checkout "main"
    merge "Develop"
    branch "Release PR"
    commit id: "Auto generated by Release Please"
    checkout "main"
    merge "Release PR" tag: "Release"

Once Release-please is setup correctly and releasing works, we can remove the GH Action release-project.yml and move it into release-please.yml

The US purpose is to update the new COMPAS XSD file in attachement into COMPAS Core: compas-core/scl-extension/src/main/resources/xsd at develop · com-pas/compas-core · GitHub

Impacts:

compas-core/scl-extension/src/main/bindings/scl-extensions.xjb => tSclFileType type to be updated

SCL_CoMPAS_20221021.zip

The following changes are made:

• Add extra values and changed 1 value of tCompasIEDType

 <xs:simpleType name="tCompasIEDType">
        <xs:annotation>
            <xs:documentation xml:lang="en">
                IED type to be used to identity the set of LDevice.inst handled by the IED
            </xs:documentation>
        </xs:annotation>
        <xs:restriction base="xs:string">
           <xs:enumeration value="SCU"/>
           <xs:enumeration value="SCU-MCB"/>
           <xs:enumeration value="SCU-TG"/>
           <xs:enumeration value="SCU-ORG"/>
           <xs:enumeration value="BCU"/>
           <xs:enumeration value="BCU-LIGNE"/>
           <xs:enumeration value="BCU-CBO"/>
           <xs:enumeration value="BPU"/>
           <xs:enumeration value="MU"/>
           <xs:enumeration value="SAMU"/>
           <xs:enumeration value="PROT"/>
           <xs:enumeration value="TAC"/>
           <xs:enumeration value="PX"/>
           <xs:enumeration value="PDIS"/>
           <xs:enumeration value="PDB"/>
           <xs:enumeration value="AUT"/>
           <xs:enumeration value="PDIF"/>
           <xs:enumeration value="GRP"/>
           <xs:enumeration value="GW"/>
           <xs:enumeration value="TG"/>
           <xs:enumeration value="TOPO"/>
           <xs:enumeration value="ADEFINIR"/>
           <xs:enumeration value="IEDTEST"/>
        </xs:restriction>
    </xs:simpleType>

• Add extra attribute BusBarSectionOrder to tCompasTopo

    <xs:complexType name="tCompasTopo">
      <xs:annotation>
        <xs:documentation xml:lang="en">
            Describe the connectivity node and layout order for a given Bay;can be multiple instanciated in case of bay which is connected to multiple nodes
        </xs:documentation>
      </xs:annotation>
      <xs:attribute name="Node" type="xs:string" use="required"/>
      <xs:attribute name="NodeOrder" type="xs:integer" use="required"/>
      <xs:attribute name="BusBarSectionOrder" type="xs:integer" use="optional"/>
      <xs:attribute name="Direction" type="tCompasTopoNodeDirection" use="required"/>
    </xs:complexType>

• Add extra attribute MainLongLabel to tCompasBay

    <xs:complexType name="tCompasBay">
        <xs:annotation>
            <xs:documentation xml:lang="en">
                Define the specific Compas attributes linked to the Bay. The Main and Second Labels are label of the bay specific to each user. MainLabel and Version identify uniquely the instanciated Bay as the UUID
                The BayCodif is specific to each user to identify the bay kind.
            </xs:documentation>
        </xs:annotation>
        <xs:attribute name="UUID" type="xs:string" use="optional"/>
        <xs:attribute name="Indice" type="xs:string" use="optional"/>
        <xs:attribute name="Version" type="xs:string" use="optional"/>
        <xs:attribute name="MainShortLabel" type="xs:string" use="optional"/>
        <xs:attribute name="MainLongLabel" type="xs:string" use="optional"/>
        <xs:attribute name="SecondLabel" type="xs:string" use="optional"/>
        <xs:attribute name="BayCodif" type="xs:string" use="optional"/>
        <xs:attribute name="NumBay" type="xs:integer" use="optional"/>
        <xs:attribute name="BayCount" type="xs:integer" use="optional"/>
    </xs:complexType>

User Story

As a PO

I want to update COMPAS_SCL.xsd file by adding 2 attributes in TCompasFlow (FlowSourceVoltageLevel and FlowSourceBayNodeOrder) and 1 enumerated value on tCompasIEDType ("ASLD")

So that new file contain updated data

This issue was automatically created by Allstar.

Security Policy Violation
Project is out of compliance with Binary Artifacts policy: binaries present in source code

Rule Description
Binary Artifacts are an increased security risk in your repository. Binary artifacts cannot be reviewed, allowing the introduction of possibly obsolete or maliciously subverted executables. For more information see the Security Scorecards Documentation for Binary Artifacts.

Remediation Steps
To remediate, remove the generated executable artifacts from the repository.

Artifacts Found

• .mvn/wrapper/maven-wrapper.jar

Additional Information
This policy is drawn from Security Scorecards, which is a tool that scores a project's adherence to security best practices. You may wish to run a Scorecards scan directly on this repository for more details.

This issue will auto resolve when the policy is in compliance.

Issue created by Allstar. See https://github.com/ossf/allstar/ for more information. For questions specific to the repository, please contact the owner or maintainer.

As a developer

I need to know how to handle versioning of SCL files

So I can implement it the database

Acceptance criteria:

• Make a design: how to do versioning
• Document the design

To make easier releases, we should set up the GitHub Action Release please.
See OpenSCD Release-please for more info

Testing new GitHub Action to update Board

As a developer
I want support for all SCL versions of IEC61850
So I use all verions and make convertions between versions (where possible)

Background:
We want to support new verions and older verions.

Acceptance criteria:
-Use the CoMPAS XSD repository
-Store the generated java classes in a packege (per version) with 3 different package names
-re-use the naming scheme of the 61850 SCL standard

As a COMPAS user service, this US purpose is to create a service to add a new Private object in current SCD file.

 
As service user, I would like to have a service in order to create a new Private object in current SCD file by defining where to create the Private, its type, its source and its value or its namespace:node with the XSD file to check the Private syntax.
 

Prerequisites: 
None
 

The inputs of this service are:

• A previous existing SCD file (Mandatory) defined by Header.id, Header.version and Header.revision.
• XPath where to create the Private in current SCD file (Required)
• Private type (Required) (String)
• Private source (Optional), it is the URL of the source
• Private value or XML fragment (Optional) (String). It may contain:
• the value of the Private
• OR an XML fragment such as a set of: <namespace:node xmlns:namespace=URL attributes/>
• XSD file of the Private to validate the Private section syntax (Required). This input refers to a folder path containing the XSD

US process

SCD file create Private section UseCase:

The following steps have to be considered to add Private section into current SCD file :

Step 1:

• Check the presence of required inputs and the validity of inputs:

• Check that XPath where to create the Private section is provided as input else an error message is returned: "XPath where to create the Private section is missing"

• Check that XPath where to create the Private section exists in current SCD file else an error message is returned: "XPath where to create the Private section doesn't exist in current SCD file"

• Check that Private type is provided as input else an error message is returned: "Private type is missing"

• Check that XSD file to validate the Private section syntax is provided as input else an error message is returned: "The XSD file to validate the Private section syntax is missing"

• If Private source is provided as input, check that URL is valid else an error message is returned: "The Private source is invalid"

• Check that Private section syntax is valid by using the XSD file else an error message is returned: "Private section syntax is invalid"

• Check that the new Private XML section doesn't already exist in current SCD file else an error message is returned: "This Private XML section already exists in current SCD file". Two Private XML sections are identical when they have:

• same XPath

• same type

• same hash code for the XML section

 
Note : the norm doesn't define the uniqueness of a Private but we have chosen to define the uniqueness of the Private thanks to following attributes.

• XPath
• and Type
• and hash code of the XML section

Step 2:

If no error has occurred during the inputs checking, then create the Private section at the specified place into the SCD file
 

Output:

The Private section is created at the specified place into the SCD file and its syntax is validated by XSD file of the Private.

Error messages:

See error messages provided all along step 1 

User Story
Add a CoMPAS Extension to store labels for a SCL File to make filtering easier if a lot of SCL Files are stored in the SCL Data Service.

Additional information
The idea is the add a extra Element 'Labels' to the CoMPAS SCL Extension. This Element will be added to the private section of the SCL Element (beside the SclName and SclFileType)

    <xs:simpleType name="tCompasLabel">
        <xs:annotation>
            <xs:documentation>Label added to the SCL File to filter on</xs:documentation>
        </xs:annotation>
        <xs:restriction base="xs:normalizedString">
            <xs:minLength value="1"/>
            <xs:pattern value="[A-Za-z][0-9A-Za-z_-]*"/>
        </xs:restriction>
    </xs:simpleType>

    <xs:complexType name="tCompasLabels">
        <xs:annotation>
            <xs:documentation>List of Labels belonging to the SCL File to filter on with a maximum number of labels</xs:documentation>
        </xs:annotation>
        <xs:sequence>
            <xs:element name="Label" type="tCompasLabel" minOccurs="0" maxOccurs="20"/>
        </xs:sequence>
    </xs:complexType>

    <xs:element name="Labels" type="tCompasLabels"/>

Example of Private Section in SCL XML File

<SCL xmlns="http://www.iec.ch/61850/2003/SCL" xmlns:compas="https://www.lfenergy.org/compas/extension/v1" 
          release="4" revision="B" version="2007">
  <Private type="compas_scl">
    <compas:SclName>MiniGrid</compas:SclName>
    <compas:SclFileType>CID</compas:SclFileType>
    <compas:Labels>
     <compas:Label>Label1</compas:Label>
     <compas:Label>Label2</compas:Label>
    </compas:Labels>
  </Private>
  ...
</SCL>

As a Application admin

I want to set privilages to users

So I set the userrights: read-only, write and tailored XML acces (e.g. masking the IP adresses).

Background

Due to possible sensible data in CoMPAS it is needed to set userrights and management.

Acceptance criteria:

• Where do you set the user privelages?
• How do you connect them with a central user rights repository? or other microservices can acces the services.
• Is direct database access allowed for a microservices architecture?
• Documented on the architecture pages

User story

As a developer I want to have external pull requests and issues on the overview boards, so that there is 1 overview of all the open issues and pull requests.

Acceptance criteria

Issues and pull request from external sources need to be shown in these boards:
https://github.com/orgs/com-pas/projects/2
https://github.com/orgs/com-pas/projects/1

The US purpose is to update the new COMPAS XSD file in attachement into COMPAS Core: compas-core/scl-extension/src/main/resources/xsd at develop · com-pas/compas-core · GitHub

Impacts:

compas-core/scl-extension/src/main/bindings/scl-extensions.xjb => tSclFileType type to be updated

Companies need some way to add their own specific extions to the SCL files.

Questions:
Where to store the XSD extensions?
How to validate the XSD extsions?
How to use them?

as suggested here

As a CoMPAS sysadmin

I need to know where the (database) runs including to define: what micro serivces do we seperate

So I deploy CoMPAS and understand the workings

Background:

Microservices define the how the databases works. The databases needed for CoMPAS can split up in multiple microservices. This are choices

Acceptance criteria:

Document on the architecture page

Dependabot is used to monitor new versions of dependencies, but now we have often issue that a new version can't be used because of the EE8/EE9 incompatible upgrade. So as long Quarkus stays on EE8 we can't upgrade some of these dependencies. Spring will probably have the same issues.

Quarkus defines a lot of version for the dependencies we use in the core repository. So by only importing the BOM from Quarkus we stay in sync with these versions. This way dependabot only monitors the Quarkus version. Quarkus is also updating his dependencies regularly when possible, so we won't stay behind a lot.

As a risk owner
I want to fix the small LFx security scanner issues
So I know that known vulnerabilities are addressed

Background:
The security issues can be found in the LFx security scanner:
https://security.lfx.linuxfoundation.org/#/e8b6fdf9-2686-44c5-bbaa-6965d04ad3e1/issues

Acceptance criteria:
Start with the critical issues
Critical/High/Medium issues to be adressed
Quick fixes can be fixed directly
Major/complex issues require a seperate Github issue

User Story
As a PO

I want to update COMPAS_SCL.xsd file by adding a new attribute to the Private Compas Flow
The new attribute is FlowIEDSystemVersioninstance.

So that new file contains this new attribute.

There are now 2 repositories in which there is code that depends on classes from core-commons from compas-core repository. After pull requests are merged the artifact should be available for other parts of compas to be used.

Where are think about https://docs.github.com/en/packages or maybe Maven Central to store there artifacts.

User Story
As a PO

I want to update COMPAS_SCL.xsd file by adding new Ied types to tCompasIEDType

So that new file contain updated data

User Story

As a developer
I want to upgrade to Java 17
So that I can use the latest features and we keep up with Java releases (for security updated)

Acceptance criteria
The project is build with Java 17 and the containers are using Java 17 to run.
Convert some Request/Response/Model Classes to Records and check if it works.