Switchgear SCADA Signal List: Define Points Before Ordering a Gateway

Medium Voltage Switchgear Guides

Published 2026-09-07 | Updated 2026-09-07

Published by Jinxing Electric. This buyer guide supports specification discussions; confirm the final configuration and document scope for your project.

KYN28-12 Metal-Clad Switchgear

Short Answer

A switchgear SCADA specification needs a point list with meaning, source, scaling, quality and command behaviour, plus the communications boundary. Naming a protocol or buying a gateway does not define the complete integration scope.

Get a Project-Specific Recommendation

Send your single-line diagram, voltage, capacity or feeder schedule, destination country, quantity, and required standard. Jinxing will review the closest product configuration and return the missing technical questions before quotation.

Send Project Requirements

Quick answer

Prepare the SCADA signal list before ordering the gateway and finalising control wiring. Each point needs an agreed meaning, source and receiving destination; commands also need authority, permissives and feedback. A protocol name describes part of the communications arrangement, not the complete integration deliverable.

Separate functions from the communications product

An RTU can combine monitoring, control and multiple protocol options. ABB's NETCON 200 product information illustrates this range of functions in a specific device. The buyer still has to define which functions and interfaces the project requires, and whether the selected equipment includes them. ABB NETCON 200 product information.

Begin with operational decisions: which states must operators see, which measurements support decisions, and which actions may be initiated remotely? Then trace each requirement to a field device, panel terminal, relay or communications source.

Give each point a complete definition

The following worksheet uses illustrative point descriptions. It is not a claim about signals included in any standard Jinxing panel.

Point typeFields to defineAcceptance question
Breaker positionSource contacts, open/closed meaning and invalid stateCan the receiver distinguish a valid state from a wiring or data problem?
Current measurementSource, phase, unit, ratio, scaling and update behaviourDoes the displayed value correspond to the approved input?
Protection alarmExact event, persistence and reset behaviourIs the alarm meaning consistent at panel and control centre?
Remote commandAuthority, permissives, command method and feedbackDoes the accepted or rejected command produce the agreed indication?
Communications statusDetection source, time basis and recovery behaviourIs unavailable information clearly represented?

Add unique point identifiers and revisions. Use them in the wiring schedule, gateway database and control-centre list so that the same requirement remains traceable across suppliers.

Resolve quality and timing expectations

A displayed value without its validity condition can mislead an operator. Define how stale, unavailable or invalid information is represented, and which system determines that state. Agree timestamp origin, time synchronisation responsibility and event ordering requirements where they matter to the project.

Avoid requiring every available device point simply because it can be exported. Ask the owner to identify the decision supported by each point. This keeps the interface review manageable and helps distinguish essential alarms from optional diagnostic data.

Example: the same “open” point means two things

Consider a hypothetical integration in which one team interprets an absent closed indication as “open,” while another expects independent open and closed inputs with an invalid combination. The protocol connection can operate correctly while the operational meaning remains inconsistent.

A point definition resolves the ambiguity by stating the actual input source, state mapping and invalid-state response. The acceptance test can then verify all agreed states using a suitable approved test method, rather than checking only that a label changes on a screen.

Similarly, a remote command should have an agreed acceptance or rejection response. Receiving a network message does not by itself demonstrate that the intended equipment action occurred.

Divide factory and site acceptance

Allocate panel wiring checks, relay data mapping, gateway configuration, network provision and control-centre configuration separately. Define where factory testing ends and which external interfaces require site testing. If a simulator is used, record what it represents and what remains to be verified against the actual receiving system.

Retain the accepted point database and configuration versions with the final drawings. Future firmware, relay or panel changes should trigger review of affected points instead of relying on an undocumented copy of the original mapping.

Inputs for a connected switchgear enquiry

For medium-voltage switchgear configurations, provide the owner-approved point list, protocol and network requirements, command philosophy and control-centre contact responsibilities.

Use the project enquiry page to request a clear panel-to-SCADA scope for the proposed KYN28-12 equipment. Available signals, gateway hardware and integration services need confirmation against the order.

References

FAQ

1. Is specifying IEC 60870-5-104 enough for a SCADA quotation?

No. The protocol must be accompanied by the required points, mappings, control behaviour, network boundary and acceptance responsibilities for the selected system.

2. Should every available relay point be sent to SCADA?

Use the owner’s operating requirements to select useful points. Record the meaning and acceptance criteria of each selected point rather than exporting an unreviewed database.