A SCADA point list is an executable engineering contract, not a tag-name spreadsheet. It must identify the physical source, information semantics, address, value encoding, quality, timestamp, alarm behavior, control authority, interlocks and acceptance test for every MV switchgear signal. If any of those fields is ambiguous, the HMI may display a plausible but unsafe state.
This guide gives a complete database structure and workflow for IEC 61850 station data with IEC 60870-5-104, DNP3 or Modbus northbound mapping. It focuses on traceability from primary equipment to control center and through FAT/SAT to the final as-built baseline.
1. Define scope and ownership first
- Protection engineer: function indications, trips, starts, blocks, settings groups and fault records.
- Switchgear/control engineer: positions, local/remote, interlocks, mechanism and auxiliary supervision.
- SCADA engineer: addresses, reporting, alarms, control workflow, HMI and gateway mapping.
- Network/IEC 61850 engineer: data model, SCL, clients, RCBs, time and communication quality.
- Operations: point necessity, alarm priority/text, normal state, response and authority.
- Cybersecurity: roles, control permissions, audit, secure protocols and change control.
Appoint one database owner and one controlled source of truth. Discipline reviews approve fields but should not maintain competing copies.
2. Minimum database fields
| Field group | Required entries |
|---|---|
| Identity | Unique point ID, project, station, voltage, bay, equipment, function |
| Source | IED/RTU, physical input or internal logic, terminal/contact, LD/LN/DO/DA |
| Value | Class, encoding, states, normal state, units, scale, signedness, resolution |
| Protocol | IEC 61850 reference/FC; IEC 104 CA/IOA/type/COT; DNP object/variation/index/class; Modbus function/register/bit/word order |
| Event | Trigger, timestamp source/class, deadband, SOE requirement, buffer/replay |
| Quality | Source flags, target mapping, stale timeout and communication-loss behavior |
| Alarm | Text, priority, category, delay, latching, acknowledgment/shelving and operator action |
| Control | Model, command value/pulse, select/execute timeout, authority, interlock, feedback |
| Test | FAT/SAT case, stimulus, expected value/quality/time/alarm/control result |
| Lifecycle | Requirement/source reference, revision, approval, implementation and test status |
3. Use a stable naming convention
A tag should be readable but not carry every semantic in a fragile string. Use separate structured fields for station, voltage, bay, equipment and signal. The unique ID must remain stable when display text changes. Define allowed abbreviations, case, separators, maximum lengths and how duplicated equipment is distinguished.
- Match the single-line/bay designations and physical labels.
- Separate point ID, operator text and protocol address.
- Distinguish command, indication and calculated state.
- Avoid vendor-specific relay menu names as the fleet-wide semantic name.
- Include phase and stage where meaningful: 50/51 stage, L1/L2/L3, trip circuit A/B.
- Store language translations in controlled columns, not in separate unmanaged files.
4. Core MV switchgear point groups
| Group | Examples |
|---|---|
| Primary position | CB open/closed/intermediate, disconnector, earthing switch, truck service/test/withdrawn |
| Protection | General trip, phase/earth stage starts/operates, breaker failure, arc, differential, lockout |
| Measurements | Phase/residual current, voltage, frequency, P/Q/S, power factor, energy, demand |
| Breaker/mechanism | Spring charged, trip/close circuit supervision, coil/drive alarm, operations count, timing/condition alarm |
| IED/system health | Self-supervision, settings group, time sync, communication A/B, test/simulation/block |
| Panel auxiliaries | DC supply, AC heater, temperature, pressure/density where applicable, door/security alarm |
| Authority/control | Local/station/remote, control enable, interlock/synchrocheck status, close/open command and result |
Do not transmit every internal relay bit. Each point needs an operator, automation or maintenance use case; otherwise it adds alarm load, bandwidth and lifecycle testing without value.
5. Model breaker and switch position correctly
- Prefer both 52a and 52b (or equivalent) for a double-point state where the design supports it.
- Define open, closed, intermediate and invalid/contact-disagreement states.
- Set transition time before raising a discrepancy alarm; keep the intermediate state visible during travel.
- Separate primary position from “command accepted” or output relay operation.
- Define communication-loss quality without changing the last physical value into a false position.
- For withdrawable breakers, model truck position separately from main-contact position.
- For earthing switches, apply stricter alarm/control visibility and authority because consequence is high.
6. Measurements, scaling and deadband
- Record primary/secondary reference, CT/VT ratio ownership and engineering units.
- Specify instantaneous, demand, min/max, integrated energy or calculated quantity.
- Define raw format, sign, multiplier/offset and target protocol representation.
- Check overflow/clipping across maximum fault or operational range as appropriate.
- Set deadband from operational purpose, resolution and reporting capacity—not a universal percentage.
- Record where deadband is applied: IED data object, MMS report, gateway or control-center database.
- Verify phase order, P/Q sign convention, import/export energy and power-factor convention.
7. Quality mapping
Quality is part of the point, not a separate optional alarm. Build a mapping table from source flags to HMI and northbound flags. If the destination cannot represent every source state, define precedence and retain diagnostic detail elsewhere.
- Validity: good, invalid, reserved/questionable as applicable.
- Detail: overflow, out of range, bad reference, oscillatory, failure and old data where modeled.
- Source state: substituted, test, operator blocked and derived/calculated.
- Communication state: source IED offline versus gateway/master link failure.
- Stale rule: how a static but healthy point is distinguished from a frozen communication path.
- Restoration: whether last value is revalidated by integrity/interrogation before quality returns good.
8. Timestamp and sequence-of-events fields
- Identify timestamp origin: physical input/IED logic, RTU/gateway receipt or control-center receipt.
- State UTC/local display handling, daylight-saving policy and time-quality flags.
- Define required resolution and end-to-end accuracy by use case.
- Preserve source time through protocol conversion; record when receipt time must be used.
- Classify SOE-critical points such as trips, breaker contacts, breaker failure and bus/arc operation.
- Specify event buffer capacity, overflow indication, reconnection replay and ordering rules.
- Test simultaneous contact transitions and time-source loss, step and recovery.
9. Alarm rationalization fields
| Alarm field | Engineering question |
|---|---|
| Consequence/priority | What happens if the operator does not respond and how soon? |
| Text | Does it identify equipment, condition and actionable meaning? |
| Normal state | Is alarm active on 1, 0, transition or quality condition? |
| Delay/debounce | Is delay needed to suppress contact chatter without hiding a critical event? |
| Grouping/suppression | Which parent condition explains secondary alarms? |
| Response | Who acts, what is checked and what escalation applies? |
| Lifecycle | Can standing/chattering frequency be measured and reviewed? |
10. Control-object fields
- Exact controllable equipment and open/close or raise/lower value.
- Direct versus select-before-operate and normal versus enhanced security.
- Pulse duration/latched output, select timeout, execute timeout and command cancellation.
- Permitted origin: bay, station HMI, remote SCADA, automatic scheme or maintenance tool.
- Authority mode and required fresh position/quality.
- Interlock, synchrocheck, earthing/truck conditions and any approved bypass path.
- Positive/negative command termination, rejection reason and independent final feedback.
- Audit fields: user/client/origin, time, command, result and final equipment state.
11. Protocol-specific mapping columns
- IEC 61850: IED, access point, LD/LN/DO/DA, functional constraint, data set/RCB, trigger, control model and SCL source.
- IEC 104: common address, IOA, type identification, cause behavior, time-tag type, quality mapping, select/execute qualifier and interrogation group.
- DNP3: group/variation, index, class, static/event relationship, flags, unsolicited support and command mode.
- Modbus: unit ID, function code, zero/one-based convention, register/bit, data type, word/byte order, scale and communication-failure rule.
- Never reuse one opaque “address” column for all protocols; validation cannot detect collisions or semantic errors.
12. Database quality checks
- Unique point IDs and no duplicate target addresses within scope.
- All required fields populated by point class; controlled null values with reason.
- Allowed enumeration values for state, priority, protocol types and test status.
- Units/scales/data types consistent with range and destination capability.
- Every control has feedback, authority, interlock and rejection behavior.
- Every alarm has normal state, priority and operator responsibility.
- Every event-critical point has timestamp origin and accuracy requirement.
- Cross-check against SCD, IED signal matrix, drawings, HMI graphics and gateway database.
- Automated diff report between revisions with semantic impact classification.
13. FAT/SAT traceability
- Freeze a uniquely identified database release and all generated/imported files.
- Use the database to generate test sheets; do not retype points manually.
- Stimulate the physical input/IED logic and verify all intermediate and destination layers.
- Test value, state sequence, quality, timestamp, alarm text/priority and acknowledgment.
- For analogs, test zero, nominal, negative/sign case, upper range, deadband and bad quality.
- For controls, test success plus every block/rejection/timeout and feedback discrepancy.
- Interrupt IED, LAN, gateway, WAN and time; verify each quality/recovery rule.
- Record measured results, tester, date, evidence and defect/retest against point ID.
- At SAT, repeat risk-based end-to-end cases with installed wiring and actual breaker/switch.
- Reconcile redlines into one as-built database; no unresolved “site-only” copies.
14. Change and version management
- Use immutable release identifiers, approval status, authorship and checksums.
- Classify changes: text-only, HMI behavior, address/mapping, alarm, control or source-model change.
- Generate dependent SCL, IED, gateway, HMI and control-center files from or reconcile them to the same release.
- Require regression scope proportional to semantic risk.
- Retain previous release and tested rollback package.
- Audit field/database drift against live IED and gateway configurations.
- Keep point retirement history so old event records remain interpretable.
15. Final acceptance checklist
- Every point has a justified operational/maintenance function.
- Primary equipment, drawings, IED model, SCD, gateway, HMI and control-center address trace end-to-end.
- Bad quality and time failure are visible and cannot masquerade as healthy process state.
- Controls have exclusive authority, interlock, result and independent feedback.
- Alarm load, event capacity and reconnect behavior have been stress-tested.
- FAT/SAT results and defects link to stable point IDs.
- Operations receives the as-built database, change method and readable exports.
References and further reading
- IEC 61850-6 edition 2.2 — SCL configuration exchange
- IEC 61850-7-2 consolidated edition — ACSI services
- IEC 61850-7-3 consolidated edition — Common data classes
- IEC 61850-7-4 consolidated edition — Logical nodes and data objects
- IEC 60870-5-104 consolidated edition — Telecontrol mapping context
- IEC 60870-5-5:1995 — Basic telecontrol application functions
- Modbus Organization — Official protocol specifications
Engineering note: The point database is complete only when an independent tester can start from one row, find the physical source, predict the value/quality/time/control behavior and prove the same result at every destination.