A specification for a SCADA or building management system (BMS) that supervises motor control centers must set the layered architecture, the autonomy of controllers when supervision is lost, the interfaces with drives and starters, the point list, the alarm philosophy, cybersecurity and the acceptance procedure. Whatever is not written in the specification gets negotiated later, at a higher price.
Why a specification and not a catalog
A SCADA or building management system (BMS) that supervises pumps, fans, chillers and motor control centers (MCCs) is bought, in most projects, against a specification: a document that describes what the system must do, how it is tested and what is delivered. If that document is vague, each bidder interprets it in their favor, the bids are not comparable, and the differences reappear as extras during construction.
This guide walks through the sections a good specification must cover. It is a general approach that works equally for buildings with HVAC systems, industrial plants and medium- and low-voltage substations with MCCs. SCADA architecture and terminology are explained in more detail in SCADA architecture and tags and in SAS, SCADA, DCS and HMI: differences.
Layered architecture and autonomy
The first section defines the layers and what must keep working when the upper one fails:
- Supervision: server, operator stations, web server if any, firewalls and the historian database.
- Field controllers: direct digital controllers, PLCs or RTUs, distributed near the equipment.
- Field devices: sensors, actuators, drives, starters and motor protection relays.
The specification should require the bid to price and scope the three blocks separately, and require controllers and field devices to operate autonomously if supervision fails. This is a practice seen in building specifications: losing the server must not stop the HVAC or the motors. Controllers keep their program, their pending alarms and the time, and when the server returns, what happened in the meantime is recovered.
It is also worth specifying power for the supervision layer: an uninterruptible supply with enough autonomy for an orderly server shutdown (industrial UPS), and surge protection for all the control equipment.
Communications and open protocols
The specification must name the accepted protocols at each level:
- Between controllers and supervision: an open protocol over Ethernet. In buildings BACnet is common (ASHRAE 135, also ISO 16484-5); in industrial environments, OPC UA or Modbus TCP (what OPC UA is, Modbus RTU and TCP).
- To drives, starters and motor relays: the device’s native protocol, described in drive communication.
- To third-party systems (chillers, fire detection, lighting, meters): read interfaces and, where applicable, write interfaces, with the agreed point list.
Two requirements prevent problems: the bidder must supply all the hardware and software needed for the third-party interfaces, and the points of those systems must be fully integrated into the SCADA screens, trends and time schedules like any other point. A gateway without full integration leaves a parallel system that nobody looks at.
If the network is Ethernet, the usual rules apply: addressing and VLAN plan, segmentation by zones and a common time source, so that the events of all controllers fall on a single timeline.
What is asked of the MCC
Each MCC feeder is a row in the point list. A reasonable set per motor is:
| Type | Typical points |
|---|---|
| Status | Running, stopped, selector in local or remote, available, breaker closed |
| Alarms | General fault, thermal or overload trip, communication failure, start failure |
| Commands | Start, stop, fault reset, and for drives the speed reference |
| Measurements | Current, voltage, power, power factor, energy, output frequency, speed feedback |
| Counters | Running hours, number of starts |
For drives and soft starters, the specification can list explicitly what the system must read and write: start and stop command, speed control and feedback, fault, general alarm, running hours and electrical measurements. Useful references are soft starter versus VFD and selecting a starter by application.
Two principles should be written without ambiguity:
- Safety does not go through SCADA. The emergency stop and the interlocks that protect people or equipment stay hardwired or in certified safety logic. On drive safety functions, see STO and SS1.
- A remote command is accepted only in remote mode. With the selector in local, SCADA reads but does not command. And every command must have feedback: if the motor does not respond within a set time, an alarm is raised.
Alarms, events and history
The specification must require an alarm philosophy, not a chaotic list: defined priorities, clear texts, operator acknowledgment, time-stamped event logging, and a criterion to avoid alarm floods. The reference is ANSI/ISA-18.2, whose international counterpart is IEC 62682. It should also define how much history is kept, at what resolution and how it is backed up, because the server is the part of the system that fills up the most and is the most forgotten.
Cybersecurity
A SCADA connected to the internet or the corporate network needs explicit requirements: firewalls, antivirus compatible with the system, individual accounts with role-based permissions, access logging and a patching procedure. The general criteria are in industrial cybersecurity: IEC 62443 and, for vendor access, in secure remote access.
- Is the point a safety function (emergency stop, protection interlock)?
- Yes: It stays hardwired or in safety logic; SCADA only monitors it
- No: Is it a command (start, stop, setpoint)?
- Yes: Remote mode only, with status feedback and an alarm for no response
- No: Is it a measurement or a counter?
- Yes: Read over communications, with defined scale, unit and period
- No: Status or alarm, with priority and text defined in the alarm philosophy
Documents, testing and acceptance
The specification ends by fixing what is delivered and how it is accepted:
- Before installation: input and output point list, descriptions of the sequence of operation, mounting drawings and datasheets for all components.
- Factory tests: demonstration of the database, the screens and the interfaces before shipment. For the general criteria, see FAT and SAT testing and point-to-point signal testing.
- Commissioning: tuning of each loop, recording of the tuned values, and a demonstration to the owner’s engineer of the complete operation of the system, including loss of communication with supervision.
- Final handover: as-built drawings, operation and maintenance manuals, software licenses, project backups and, when the business case justifies it, a source-code escrow agreement for custom programs.
- Training in stages, with sessions before acceptance and refreshers during the warranty.
- Warranty and spares, with the period and the percentage of spares defined in writing.
Common mistakes
- Asking for “everything open” without naming protocols. Each bidder complies with their own version of “open.”
- Point list at the end. The contract is signed without knowing the number and type of points, and each one is argued over afterwards.
- Not requiring controller autonomy. A server failure stops operation.
- Mixing safety functions with SCADA. A software command does not replace a safety circuit.
- Forgetting common time. Without it, the sequence of events after a fault cannot be reconstructed.
How we help
At Tiza Group we support the drafting and review of control and SCADA specifications, the setup of SCADA and gateway integration, and acceptance testing at the factory and on site. If you are about to tender a supervision system or have bids to compare, we can quote the technical review.
Related guides
- SCADA architecture and tags
- Substation SCADA and HMI system
- Substation signal list
- Drive communication: Modbus, Profinet and EtherNet/IP
- Soft starter
- Predictive maintenance of motors and drives
References
- ASHRAE 135 (ISO 16484-5): data communication protocol for building automation and control networks (BACnet).
- ANSI/ISA-18.2 and IEC 62682: management of alarm systems.
- IEC 62443: security for industrial automation and control systems.
- IEC 61131-3: programming languages for programmable controllers.
- IEC 61439-2: low-voltage switchgear and controlgear assemblies, power switchgear and controlgear assemblies.
Frequently asked questions
What is an MCC and what should SCADA be able to do with it?
A motor control center (MCC) is a lineup that groups the starters, drives and protection of several motors. SCADA should be able to see the status and alarms of each feeder, send start and stop commands when the selector is in remote, and read current, energy and running-hour values. Safety functions such as the emergency stop do not depend on SCADA and remain hardwired.
What should happen to the motors if the SCADA server fails?
Nothing that affects safety or basic service. The specification should require controllers and field devices to run autonomously, with their own sequences and interlocks, and require that when supervision returns, the information is recovered and states are resynchronized. What is lost during the failure is visualization, history and remote commands.
Is Modbus or BACnet better for connecting SCADA to the MCC?
There is no single answer. BACnet is common in building management systems and their controllers; Modbus, along with Profibus, Profinet or industrial Ethernet, is typical in drives, starters and motor protection relays. The specification should name the accepted protocols, require a point list per device, and provide for a gateway when SCADA and devices speak different languages.