Connect to the intended IED
Use the relay IP on an authorized test, FAT, SAT or commissioning network. Keep the first session read-only.
Live discovery · SCL generator · ICD · CID · IID · SCD
Start from an IED IP or SCL file. Build a traceable engineering baseline.
ARSAS can discover the running IED model from a reachable device on an authorized engineering network, or open an existing SCL source. Keep observed live evidence separate from configured project intent, then prepare bounded IID, ICD or CID output for the next engineering system.
Evidence contract
Keep the observation together with the context that makes it reviewable.
ARSAS treats engineering data as evidence, not just screen output. The exact fields depend on the workflow, but the source and acquisition context should remain visible whenever they exist.
What?Signal, event, packet, file, model or command result
Which IED?Device identity, endpoint and project context
When?IED time, protocol time or ARSAS receive/capture time when available
Quality / state?IEC quality, event state, sequence state or result status when the source provides it
How acquired?Discovery, MMS read, Reporting, GOOSE/SMV capture, file service or control workflow
No invented certainty.Not every workflow exposes every field. ARSAS should preserve what is actually available, identify the acquisition path and keep missing context explicit rather than synthesizing proof.Review field interoperability evidence →Review engineering boundaries →
30-second takeaway
SCL is the engineering description that connects device capability, project configuration and system integration.
ICD commonly describes what an IED can support. CID commonly describes the configuration delivered to one IED. SCD represents the integrated substation project. IID is commonly used for an instantiated IED description exchanged during engineering updates. These are practical roles, not permission to ignore edition, schema, project-profile or vendor rules.
From IP to SCL in four steps
Discovery builds observed device evidence before export begins.
You do not need a vendor SCL file to start a read-only live discovery. ARSAS first identifies what the running server exposes; export is a later engineering decision with an explicit receiving-system target.
Discover the running model
Build physical identity, MMS hierarchy, typed data, DataSets, RCB inventory and available-service evidence from the live server.
Review what the next system actually needs
Choose whether the task needs monitoring only, a full bounded device baseline, or one selected reporting path.
Prepare bounded engineering output
Generate IID Edition 2 or ICD Edition 1 from complete live discovery where appropriate, or prepare a selected-RCB CID baseline when that is the receiving contract.
SCL file types in plain language
Choose the file by its job, not only its extension.
ICD — IED Capability Description
A capability-oriented description supplied for system engineering. It commonly represents the functions, data and communication features an IED family or configuration can offer.
CID — Configured IED Description
A device-focused configured description intended for one IED. It may include communication, DataSets, reports, GOOSE and project-specific settings.
SCD — Substation Configuration Description
The wider integrated system model produced by system configuration engineering, including multiple IEDs, communication relationships and substation context.
IID — Instantiated IED Description
An instantiated IED description used in supported engineering exchange or update workflows, especially where Edition 2-oriented tooling expects device-specific system context.
SSD — System Specification Description
A specification-oriented view of substation functions and topology before all IED implementation details are assigned.
Edition and profile matter
The same extension does not guarantee identical schema edition, namespace, optional content or importer behavior. Confirm the receiving contract.
When to use SCL Workspace
Use it when configured intent and live evidence must be compared or exchanged.
Build a typed baseline from live discovery
Use the intended IED endpoint on an authorized engineering network when the available vendor file is missing, outdated or cannot explain the online server model.
Reduce the input to a bounded device scope
Preserve exact identity, model, DataSet and RCB evidence while avoiding an oversized multi-IED project file for a limited receiver.
Compare live model and configured intent
Keep differences visible instead of silently replacing the source file or assuming the running IED exactly matches the project SCL.
Export one verified RCB path
Prepare a selected-RCB CID baseline when the receiving SAS or gateway needs one explicit reporting path.
Ask what the receiving system actually accepts.
- Required file type and IEC 61850 edition
- Expected physical IED name and AccessPoint identity
- Allowed namespace, schema and vendor profile
- Required DataSets, RCBs, GOOSE or communication sections
- Whether a full project, one IED or one selected RCB is required
Configured intent and live evidence are different sources.
An SCL file can be stale or incomplete. A live IED model can omit wider project relationships. Preserve both, record provenance and make differences reviewable rather than declaring either source universally correct.
Step-by-step in ARSAS
Create a bounded SCL baseline without losing the source context.
Define the receiving-system requirement
Record the target tool, edition, expected IED identity, required services and whether it needs IID, ICD, CID or another approved SCL scope.
Choose live discovery or an existing SCL source
Connect to the intended IED on an authorized engineering network for complete MMS discovery, or open the available SCD, CID, ICD, IID, SSD or compatible XML. Keep the original file unchanged.
Verify physical identity and model hierarchy
Separate the physical IED name from MMS domains and Logical Devices. Review Logical Nodes, Data Objects, Data Attributes, types and Functional Constraints.
Review DataSets, RCBs and communication context
Check member order, exact runtime RCB names, trigger options, optional fields, report IDs, configuration revision, endpoint and available GOOSE or communication identity.
Choose the bounded target output
Generate Edition 2 IID or Edition 1 ICD from complete live discovery where appropriate, normalize a single-IED source, or select one verified RCB for a bounded CID baseline.
Validate the output in the receiving system
Review SCL, companion evidence and findings, then import into the intended SAS, gateway or engineering tool. Record every rejection or modification instead of editing identity by trial and error.
Success criteria
A useful SCL handover is traceable before it is accepted.
Known sourceLive discovery or original file provenance is preserved
Correct identityIED, AccessPoint, domains and references are not conflated
Bounded scopeThe output contains the intended device or reporting path
Receiver verifiedThe target tool imports and its resulting model is reviewed
What the running server exposes now
- Online physical and MMS identity evidence
- Logical hierarchy and available typed data
- DataSets and concrete runtime RCB instances
- Current service availability and read diagnostics
What the engineering project says should exist
- Substation and multi-IED relationships
- Communication and subscriber configuration
- Configured DataSets, reports, GOOSE and Sampled Values
- Project naming, edition and revision context
Selected-RCB output
Prepare one explicit reporting path for a bounded receiver.
Run a read-only availability audit, choose one usable RCB, preserve its verified DataSet membership and available configuration evidence, then export the approved Edition 1 or Edition 2 CID baseline.
CIDSelect the RCB and target edition
Keep the exact runtime RCB name, verified DataSet directory, trigger options, optional fields, buffer time, integrity period, report ID and configuration revision where available.
If the file is rejected
Diagnose the contract mismatch before rewriting the model.
Edition or namespace mismatch
Confirm the expected IEC 61850 edition, namespace, schema location and receiving-tool profile.
IED identity mismatch
Check physical IED name, AccessPoint, IP address, MMS domains and Logical Device names. Do not substitute one identity level for another.
DataSet or FCDA problem
Verify member references, Functional Constraints, ordering and whether the receiver requires a specific reporting scope.
RCB naming or configuration problem
Preserve concrete runtime names and check report ID, configuration revision, trigger options, optional fields and reservation expectations.
The file is too broad
Use a bounded single-IED or selected-RCB output instead of passing a complete project to a receiver with limited scope.
XML imports but the resulting model is wrong
Compare the receiver's imported tree, DataSets, RCBs and communication settings with the source evidence. XML validity alone is not success.
A traceable, bounded SCL baseline and its evidence
ARSAS can preserve source identity, live discovery, model relationships, selected reporting evidence, output findings and provenance for engineering review.
Schema-aware output is not universal importer certification.
The receiving tool may enforce proprietary rules beyond the standard. Generated output does not prove project-wide SCL correctness, GOOSE/subscriber behavior, Reporting interoperability or IEC 61850 conformance.
What is the difference between ICD, CID, SCD and IID?
ICD commonly describes IED capability, CID one configured IED, SCD the integrated substation project and IID an instantiated IED exchange or update description. Verify the exact edition and project profile.
Can a live IED model replace the project SCD?
No. Live discovery shows what one server exposes now. The SCD can contain wider system, subscriber and communication relationships that one IED cannot reveal.
Does valid XML guarantee the SCL will import correctly?
No. The receiver may apply identity, edition, namespace, DataSet, RCB and proprietary profile rules. Review the resulting imported model.
Next lesson
Compare the configured stream with observed GOOSE traffic.
Use GOOSE Analyzer to verify publisher identity, sequence, TAL and payload order, while keeping subscriber operation and end-to-end protection acceptance as separate tests.
Verified stable · ARSAS 1.6.41
Ready for an approved Windows workstation?
Installer and portable packages share the same application scope. Verify the published SHA-256 and review the release boundary before field use.
Release notes, limitations and signing status →