AJapps

Configuration Version Log — SCD, CID, Switch & RTU Files

Keep a record of which version of every configuration file is approved and which is in each device — SCD and CID files, switch, RTU, gateway and PLC configurations, HMI projects and firmware — identified by its SHA-256 fingerprint, with who changed it, when and why. Then check any file to see whether it is a recorded, approved version.

Add a version

Check files against the log

    Read the file back from the device (or take the switch's configuration backup) and check it here before and after every change.

    The log is empty. Add a version or load the sample log.

    Tool guide · know before you use

    What this tool is, how it works and how far to trust it

    A configuration version log that identifies every SCD, CID, switch, RTU, PLC, HMI and firmware file by its SHA-256 fingerprint, with device, version, status, author and reason.

    Read this before relying on a result. Every method, formula, assumption and limit is stated here, so you can check the answer yourself instead of accepting it blindly.

    What it can do

    • Fingerprint files in the browser and fill version, revision, date, author and reason from the SCL Header and History.
    • Check any file (for example a CID read back from a relay) against the log: approved or installed, superseded, draft, recorded for another device, or unknown.
    • Flag several Installed versions for one device, approved versions not yet installed, missing reasons and one file under two versions.
    • Export the log as JSON (to reopen) and CSV.

    Why you need it

    • Years after commissioning nobody is sure which file is the approved one; a fingerprint gives a definite answer.
    • Configuration control is required by IEC 62443 and is the basis of fault investigation after an incident.

    Understand this first

    • Any change to a file — even a space — changes its SHA-256. Two files with the same fingerprint are identical.
    • The same configuration exported twice by a tool may differ (for example a time stamp in the file); record the file that was actually loaded into the device.
    • The log in the browser is a convenience; the downloaded JSON file is the record.

    What you need before you start

    • The configuration files (from the engineering tools, or read back from the devices).
    • Device names, versions and the change request or reason.
    • A current browser (Chrome, Edge, Firefox or Safari). Nothing is installed and your data is never uploaded; it is processed on your own computer.

    How to use it

    • Load the sample log, or start a new one with the site name.
    • Add a version: choose the file, complete device, type, version, status and reason, and add it.
    • When a version is loaded into the device, set its status to Installed and the previous one to Superseded.
    • Check files read back from devices; download the log after every change.

    What you get

    • The log grouped by device, log checks, file check results, JSON and CSV exports.

    How to read the results

    • OK: the file is the recorded approved or installed version.
    • Not a recorded version: find out what changed before using the file.
    • Superseded or draft: an old or unapproved version is in use.

    Technical basis

    • SHA-256 (FIPS 180-4) computed with the browser's Web Crypto API; SCL Header and Hitem attributes per IEC 61850-6.

    Limits: when not to rely on it

    • It cannot read files from devices itself; use the manufacturer's tool to read back the configuration.
    • It does not judge the content of the configuration.

    Sample files for this tool

    Download, open and compare with what the guide says you should see.

    All sample files and what to expect →

    For preliminary engineering use. Results must be checked by a qualified engineer against the project's standards. How results are checked · Terms & disclaimer · Build 61a41bc · 2026-11-14