Change and Configuration Management for Substation Automation and SCADA

The baseline is the set of records that describe the approved system: the SCD, the CID of every IED, switch configurations, the IP and asset registers, the SCADA tag database, firewall rules, the installed software and patch level of each computer. Take it at the end of commissioning and store it with the as-built documents.

Every later change is described as a difference from the baseline, and once approved and tested, becomes part of the next baseline.

File names and dates are not reliable: 'S13_final_v3_rev2.scd' says nothing certain. A SHA-256 fingerprint is calculated from the content; any change, even one character, gives a different value. Recording the fingerprint of each approved file makes it possible to prove later that a file in use is — or is not — the approved one.

Read files back from devices (CID from the relay, configuration backup from the switch) and compare their fingerprints with the log before and after each intervention.

Before a change, compare the proposed revision with the baseline so that every difference is seen and assessed; after the change, compare what is actually installed with what was approved. Unexpected differences in either comparison are the warning signs.

The impact of a difference depends on its kind. An IP address change touches the register, the SCD, firewall rules and the SCADA connection. A data set change requires a new confRev and a reload of the publisher and every subscriber. A firewall change needs security review. A firmware change needs the tests the release notes require.

Large point lists are built by copying rows, and copy errors load without complaint: two points on one address, a description not edited, alarm limits in the wrong order, an analog value placed in the wrong data table. Validating the list before loading finds them in minutes, instead of during point-to-point testing or in operation.

SCADA vendors test operating-system updates against their software and publish approval lists. Installing an untested update can break drivers, OPC DA or redundancy; not installing approved security updates leaves known vulnerabilities open. Redundant servers should always run the same patch level, so that a failover behaves as tested.

Collect the installed updates from each computer, compare them with the vendor's list and between redundant pairs, and plan the differences into maintenance windows.

The design says which VLANs each switch port carries, which device is on it and which multicast filters it has; the installed switches say what was really configured and connected. Compare the configuration exported from every switch with the plan, trace every GOOSE and sampled-value stream from publisher to subscriber through the configured ports, and compare the LLDP neighbours and MAC address tables with the planned port map. A missing VLAN on one port silently stops a trip or interlock; a swapped cable or an unknown laptop shows up only this way.

Then scan the subnets (with permission) and compare what answers with the IP register: devices nobody registered, a replaced device with a new MAC address, a device at the wrong address, and services such as Telnet or HTTP that should be disabled.

At handover, the client should receive the records needed to operate and maintain the system: the network design and IP plan, GOOSE/SV addressing, switch port and cable schedules with test results, the asset register with firmware and lifecycle, firewall rules, the configuration log with fingerprints, and the open items. Signed and dated, they are the first baseline.