Receive selected changes efficiently
Use reports when the IED should deliver events and value changes without polling every object at the same interval.
Practical tutorial · DataSet · BRCB · URCB · visible fallback
Stop guessing whether updates came from reports or polling.
Smart Reporting turns selected IED signals into a visible acquisition plan. ARSAS starts with usable reads, inspects configured DataSets and Report Control Blocks, proves exact coverage, uses approved recovery only when permitted, and keeps polling visible for anything still uncovered or unverified.
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
A DataSet chooses the signals. An RCB controls their delivery.
IEC 61850 Reporting lets the IED push selected changes instead of waiting for the client to read every point repeatedly. A BRCB can buffer report entries across a temporary client interruption; a URCB delivers while the association is active without buffered continuity. ARSAS shows whether each update came from a report or polling and does not hide gaps behind a generic “live” label.
When to use Smart Reporting
Use it after MMS discovery and one trustworthy read.
Reporting depends on a known IED, known object references and an acquisition requirement that can be checked against actual DataSet membership.
Prove how each point was acquired
Keep report, polling and fallback evidence explicit while validating indications, measurements and sequence behavior.
Separate connection success from report success
An association can work while the DataSet is empty, the RCB is occupied, triggers are wrong or no report is delivered.
Keep each acquisition lifecycle independent
Reporting state, ownership and degradation for one IED must not silently change the behavior of another session.
Confirm the reporting prerequisites.
- The correct IED is associated and discovered
- Selected object references and Functional Constraints are known
- At least one direct read has understandable quality and timestamp
- The required update behavior is defined
- Any DataSet or RCB write is explicitly authorized
Prefer configured reports before considering writes.
ARSAS should first inspect existing DataSets, BRCBs and URCBs. Dynamic DataSet or RCB recovery is conditional, device-dependent and only appropriate when the IED capability and approved procedure permit modification.
Core concepts
Know what each reporting object is responsible for.
DataSet
The ordered list of data members attached to a report. A convincing name is not proof that the required points are present.
Report Control Block
The control object that references a DataSet and governs enablement, trigger options, integrity period, optional fields and delivery behavior.
BRCB
A Buffered Report Control Block can retain report entries for later delivery when buffering is supported, correctly configured and the client resumes within the applicable continuity limits.
URCB
An Unbuffered Report Control Block delivers while the association is active. Events that occur during disconnection are not recovered as buffered history.
GI and integrity
General Interrogation requests a current image. Integrity reporting can periodically refresh the DataSet. Neither alone proves spontaneous change triggers work.
Trigger options
Data change, quality change and data update triggers determine which changes can produce reports. The expected event must match the configured trigger behavior.
Step-by-step in ARSAS
Build a defensible acquisition path per IED.
The workflow starts with evidence that works now, then improves report coverage without turning unavailable reports into invisible data loss.
Confirm discovery and trustworthy reads
Start only after the intended IED model is known and selected points can be read with understandable identity, quality and timestamp.
Select the required signals
Define the points needed for monitoring or test evidence. Keep their full object references and Functional Constraints.
Inspect configured DataSets and RCBs
Read DataSet members, BRCB and URCB references, reservation or ownership state, trigger options, optional fields and enablement conditions.
Validate exact coverage
Compare every selected signal with actual DataSet membership and order. Do not infer coverage from a DataSet or RCB name.
Use the approved report path
Prefer suitable configured reporting. Consider temporary DataSet or RCB recovery only when writes are permitted, the target is available and rollback is defined.
Verify delivery and retain visible fallback
Change a known test point, confirm report reason and source where available, and keep uncovered, rejected or degraded points in bounded polling.
No hidden report dead end.An empty DataSet, occupied RCB, rejected write or silent stream must remain visible in diagnostics while usable polling continues within an explicit bound.Open the silent-reporting guide →
Success criteria
A reporting workflow is successful when coverage and source are explainable.
Known coverageEvery selected point is reported, polled or explicitly unresolved
Known sourceEach update identifies report, polling or another acquisition path
Known contextIED, reference, value, quality and time remain attached
Known degradationAssociation loss or silent delivery changes the visible state
How to read the result
Three acquisition outcomes are valid when they are explicit.
The selected point is covered and delivery is verified.
The update carries attributable IED context, report source and supporting quality and time evidence. BRCB or URCB behavior remains specific to the actual IED configuration.
The point remains observable without pretending Reporting works.
Polling can be a deliberate bounded fallback for uncovered, occupied, rejected or degraded report paths. Its source and interval must remain visible.
The required evidence is not available yet.
Invalid quality, unknown ownership, incomplete coverage or ambiguous delivery should remain unresolved rather than being promoted to a false pass.
If Reporting is silent
Check the acquisition chain in order.
Association or discovery is unstable
Confirm the IED session and direct reads before changing report configuration.
The DataSet is empty or incomplete
Read the actual member list and compare it with the selected points.
The RCB is reserved or occupied
Inspect ownership and reservation without forcing takeover from another client.
GI works but spontaneous reports do not
Check trigger options, data-change behavior, report enablement and whether the test stimulus changes the correct attribute.
Coverage appears correct but updates are missing
Inspect report reason, sequence, entry state, optional fields, association continuity and diagnostics before trusting the stream.
The report path degrades after reconnect
Re-evaluate ownership, enablement, BRCB continuity and fallback state. Do not reuse stale acquisition claims from the previous association.
Real application evidence
Every live value keeps its acquisition origin.
The same workspace can show selected values from independent IED sessions while preserving device, reference, quality, timestamp, recent-change evidence and report or polling source.
EvidenceAttributable live-value workspace
Selected signals retain IED identity, value, quality, time, recent-change state and acquisition source instead of collapsing all updates into one generic live state.
A visible acquisition plan and its current evidence
ARSAS can show configured report objects, exact selected-point coverage, current delivery source, fallback state and negative diagnostics for the active IED session.
Automation does not create universal interoperability.
Successful Reporting on one IED, DataSet or RCB does not prove all vendor implementations, triggers, buffered continuity or receiving systems behave the same. Configuration writes and active test stimuli still require approval.
What is the difference between a DataSet and an RCB?
A DataSet defines which data members belong together. A Report Control Block defines how and when changes from that DataSet are delivered.
Does a successful General Interrogation prove spontaneous Reporting works?
No. GI can provide an initial image while spontaneous data-change delivery remains absent, misconfigured or blocked.
Is polling always a failure?
No. Bounded polling is a valid visible fallback when report coverage is unavailable, incomplete, occupied, rejected or not yet verified.
Next lesson
Use the same evidence discipline for GOOSE and project testing.
After report delivery is attributable, continue to GOOSE sequence analysis, IO List FAT or broader FAT workflows without losing device identity, quality, time and source.
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 →