Initial use cases for comparison plugin

comparison_use_cases.adoc

Use Cases for Comparison

Introduction

Warning

VERY DRAFT!

What follows is some initial use cases for comparison functionality. They are somewhat hypothetical since most of them apply after an initial green-field substation is deployed and further changes are made. However they also apply to situations associated with standard designs, use of manufacturer ICT tools, firmware upgrades and tracking changes during design.

Use cases associated with specification activities are largely ignored here although are likely of particular interest to European utilities.

1. Standard Design Use Cases

1.1. UC-1 Reviewing ICD Changes

Actor

Setting Designer

Primary actor

Setting Designer

Stakeholders

Manufacturers, Risk management reviewer, Quality Assurance process auditors

Pre-conditions

Change made to ICD file, often in ICT software.

Triggers

1. Change made in ICD file, impact on SCD file not clear or ICT software doesn’t provide sufficient information to identify full extent of change

   For instance adding functionality in DIGSI 5 typically addings LNodes and LDevices and introduces new types. These are not immediately obvious.

2. Additionally the changes may affect the file in multiple places including the DataTypeTemplates and the user often wants to see an easy assessment of the differences.

Basic flow

1. Setting file changes and user exports corresponding changed ICD file.

2. Actor wants to understand all changes made. This may include changes in Private elements or custom namespaces.

3. Actor compares ICD files.

4. Comparison can be "deep" and should be by default with a single IED as this is not expected to be computationally expensive.

5. Use is then able to focus on particular elements or areas of interest by looking at the change summary/filter drop down.

Implementation comment

Affected SCL Elements	All
Exclusions	None
IEDS	one
Performance Issues	Not expected

1.2. UC-2 Understanding Improved Device Models

Tip	Almost identical to UC-1 Reviewing ICD Changes

Actor

Setting Designer

Primary actor

Setting Designer

Stakeholders

Manufacturers

Pre-conditions

Manufacturer releases new device model or upgrade to ICD

Triggers

1. Manufacturers release notes often inadequate. Unclear what new capabilities or changes are included in ICD file.

2. This is for manufacturers where the superset of capabilities are provided in a single file.

Basic flow

1. Designer compares ICD files.

2. Comparison can be "deep" and should be by default with a single IED as this is not expected to be computationally expensive.

3. Use is then able to focus on particular elements or areas of interest by looking at the change summary/filter drop down.

Implementation comment

Affected SCL Elements	All
Exclusions	None
IEDS	one

1.3. UC-3 Upgrading an ICD file

Tip	Future use case for merge requirements. Not developed here.

2. Project Use Cases

2.1. Networking Use Cases

2.1.1. UC-4 Identification that network reconfiguration required

Actor

Network Engineer

Primary actor

Network Engineer

Stakeholders

Setting Designers, Site Technicians

Pre-conditions

Change made to SCD file

Triggers

1. Change made to SCD file.

2. To avoid designers being required to log and list changes it should be a procedural step once a new configuration is completed to identify the required network changes.

3. In Transpower’s network this will mainly impact on GOOSE and SV traffic which requires explicit network configuration of:

   • VLANs on a per port basis

   • MAC address filtering for devices involved in SV publishing and subscriptions

Basic flow

1. SCD file changes made.

2. Network engineer assess whether changes required using comparison tool (possibly could be done by the designer and flagged to the Network Engineer, ideally would be done automatically between revisions of the SCD file and flagged to the network engineer for action as part of a work package management system).

3. Network engineering is only interested in configuring new ports, VLANs and MAC address filtering for SV traffic. In principle they may be interested in carrying out network bandwidth calculations and may be interested in calculating changes of this but this is not a target for the MVP of the comparison tool.

   • All IED elements

   • All ReportControl elements with a name beginning/containing a certain string (or perhaps with a DataSet name beginning with a certain string)

4. Comparison can be shallow for the initial use case (e.g. where we are not calculating bandwidth) and identify changes in the Communication section:

   • New ConnectedAP elements for IP traffic

   • New or changed GSE or SMV elements

Note	In SEL devices typically the esel:datasrc attribute included within the db DAI is important for calculating the overall deadband.

1. Use is then able to focus on particular elements or areas of interest by looking at the change summary or able to drill down.

Implementation comment

Affected SCL Elements (provisional)	Communication > SubNetwork > ConnectedAP > Address[contains P type="IP" && has(P type='OSI-TSEL') && has(P type='OSI-SSEL') && has(P type='OSI-PSEL')] (all children, no referencing) Communication > SubNetwork > ConnectedAP > GSE (all children, no referencing) Communication > SubNetwork > ConnectedAP > SMV (all children, no referencing) User may wish to be able to scope to particular IEDs or do a wild card filter on results (?).
Exclusions	None
Namespace	SCL only
Include Descriptions	No
IEDs	All
Performance Issues	Unlikely to be slow as no referencing required.

2.2. Protection & Automation Use Cases

2.2.1. UC-5 Project Comparison

Actor

Protection & Automation Reviewer, EC Design Reviewer, EC Designer

Primary actor

Protection & Automation Reviewer

Stakeholders

Setting Designers, Site Technicians, Auditors

Pre-conditions

Change made to SCD file between one project and the next

Triggers

1. Change made to SCD file. Typically a project has been and produced an SCD file. A new SCD file has been prepared as part of the new project.

Basic flow

1. Comparison is done of whole SCD file.

2. The SCD is now critical to substation function and must be maintained in a high fidelity way across time without loss of data. No unexpected changes of any kind are permitted. The designer’s reviewer should ensure this as part of their contracted deliverables and ISO 9001 QA process. Transpower’s project engineer is also likely to review changes in the SCD as part of ensuring (at a high level) that the changes are consistent with the delivery scope and the changes are in the expected places (broadly).

3. This comparison would typically be done only a few times during each project:

   • At key points in the design process to check/demonstrate that no unexpected changes or corruptions have occurred.

   • At completion of design deliverables for particular components (e.g. transformer protection, line protection, a whole bus)

   • At completion of all design deliverables before delivery to the client (could be very many changes)

4. Because these checks are only done infrequently if they are more time consuming it is acceptable.

Implementation comment

Affected SCL Elements (provisional)	All and All references
Exclusions	None
Namespace	All or Selected Namespaces
Include Descriptions	No or Yes
IEDs	All
Performance Issues	Will be very slow. Server implementation likely required for adequate performance.

2.2.2. UC-6 Comparison to Standard Package

Important

We have not discussed this use case previously and while it seems somewhat straightforward it may be out of scope for the initial MVP for the project.

Note	This may be quite similar to the kinds of comparisons required for the specification process (e.g. that Burak Tahincioglu from Omicron is interested in)

Actor

Protection & Automation Reviewer, EC Design Reviewer, EC Designer

Primary actor

Protection & Automation Reviewer

Stakeholders

Setting Designers, Site Technicians, Auditors

Pre-conditions

Change made to SCD file between one project and the next or a new SCD file.

Triggers

1. Change made to SCD file. Typically a project has been and produced an SCD file. A new SCD file has been prepared as part of the new project. It contains one or more new IEDs.

Basic flow

1. The premise is that it is useful to ensure the new IEDs match the standard package and that deviations from the standard package are of interest.

2. The standard might be a comparison with an ICD file but could also be a comparison with a reference design in which devices are instantiated and configured with communications between them. It would also be useful to be able to compare the communications configuration for GOOSE and SV traffic between a reference design and actual design.

3. The user opens an SCD file and a comparison standard design ICD or SCD file.

4. The user "matches" the IED named TEMPLATE with the instantiated IED with a different name or perhaps matches multiple IEDs between the site SCD file and the standard design SCD file.

   From an implementation point of view, this might mean that the IEDs are renamed between the standard design and site SCD file using the appropriate scl-lib function prior to the comparison being made.

5. The user may wish to then carry out some of the comparisons mentioned in other sections to answer the question:

   • Has the GOOSE or SV communications changed?

   • Has the SCADA configuration changed from the standard design? "Is this application of the standard design actually standard?"

Implementation comment

Affected SCL Elements (provisional)	All and All references (or qualified by other use cases, e.g. UC-8 Identification of SCADA relevant changes or UC-5 Project Comparison)
Exclusions	None
Namespace	All or Selected Namespaces
Include Descriptions	No or Yes
IEDs	Selected number for a scheme
Performance Issues	Will be somewhat slow. Server implementation likely required for adequate performance.

2.2.3. UC-7 Comparison for GOOSE and SMV Communications

Actor

Protection & Automation Reviewer, EC Design Reviewer, EC Designer

Primary actor

Protection & Automation Reviewer

Stakeholders

Setting Designers, Site Technicians, Auditors

Pre-conditions

Change made to SCD file between one project and the next or a new SCD file.

Triggers

1. Change made to SCD file. Typically a project has been and produced an SCD file. A new SCD file has been prepared as part of the new project. It contains one or more new IEDs or changes to existing IEDs.

Basic flow

1. New IEDs have been added or existing IEDs have been modified.

2. The protection designer wants to run a narrowly scoped query, "Are all my Protection & Control functions the same or what new functions are there?" and treats the GOOSE and SMV functions as a proxy for this. The remainder of the data model is of little concern (SCADA is someone elses problem and even if it is imperfect as long as protection functions correctly the protection designer would consider it to be a win)

3. The designer wants to know that:

   • All network communications are configured correctly

   • All subscriptions are configured correctly and have not changed for GOOSE and SMV traffic

   • All new GOOSE and SMV traffic and its addressing can readily be examined

Implementation comment

Affected SCL Elements (provisional)	Communication > SubNetwork > ConnectedAP > GSE (all children, referencing to GSEControl > DataSet, no further referencing by default but perhaps on demand) Communication > SubNetwork > ConnectedAP > SMV (all children, referencing to SampledValueControl > DataSet, no further referencing by default but perhaps on demand) IED LN/LN0 > Inputs > ExtRef[serviceType="GOOSE"||"SMV"] (all children, referenced to DataSet > FCDA) These capture published information (ConnectedAPs) and subscribed (ExtRefs) information. However if ExtRef elements are referenced via both control block and ConnectedAP then the only communication which matters is the subscriptions. We haven’t discussed this referencing previously.
Exclusions	Private/Text (?), desc or description attributes
Namespace	SCL
Include Descriptions	Yes
IEDs	All
Performance Issues	May scale poorly for very large files but should generally be performant where we are doing little referencing. Server implementation may be helpful.

2.3. SCADA Use Cases

2.3.1. UC-8 Identification of SCADA relevant changes

Actor

RTS (Real Time Systems) Engineer

Primary actor

RTS (Real Time Systems) Engineer

Stakeholders

Setting Designers, Site Technicians

Pre-conditions

Change made to SCD file

Triggers

1. Change made to SCD file. Typically SCADA gateway changes may be delivered before all protection and control (read: GOOSE and SV) communications is completed.

2. If no changes are made to ReportControl elements or the corresponding Communication sections, then there is no change required or need to generate a new SCADA gateway configuration. However without doing a comparison there is currently no way for a designer to know if a change or even inadvertent change has occurred.

Basic flow

1. SCD file changes during project delivery process and possibly after initial SCADA gateway configuration generation.

2. RTS engineer wants to understand if changes made should generate a new gateway configuration. RTS engineer fundamentally is not concerned with changes to Substation section or GOOSE/SMV changes (typically).

3. RTS engineer compares SCD files, seeking to look at:

   • All IED elements

   • All ReportControl elements with a name beginning/containing a certain string (or perhaps with a DataSet name beginning with a certain string)

4. Comparison should be deep (fully dereferencing if possible) to cover some particular known cases but presumed to be many possible cases (illustrative only):

   • control model (ctlModel) changes

   • potentially originator category (orCat) changes

   • to include analogue deadband (sometimes relevant information is included within a namespaced element for instance on SEL devices) and relevant parameters, e.g. include:

     • DAI: SIUnit

     • DAI: multiplier

     • DAI: db (deadband)

       Note	In SEL devices typically the esel:datasrc attribute included within the db DAI is important for calculating the overall deadband.

5. User is then able to focus on particular elements or areas of interest by looking at the change summary or able to drill down.

Implementation comment

Affected SCL Elements (provisional)	Communication > SubNetwork > ConnectedAP > Address[contains P type="IP" && has(P type='OSI-TSEL') && has(P type='OSI-SSEL') && has(P type='OSI-PSEL')] > IED[name === ConnectedAP['iedName']] > AccessPoint[name === ConnectedAP['name']] > ReportControl[name === 'user specified match?'] > DataSet[name === 'user specified match?']
Exclusions	Private/Text (?), desc or description attributes
Namespace	All or Selected Namespaces
Include Descriptions	No
IEDs	All
Performance Issues	May be slower on large files. Server implementation helpful.

2.4. Technician Use Cases

2.4.1. UC-9 Identifying Changed GOOSE and SV Traffic

See UC-7 Comparison for GOOSE and SMV Communications.