Chapter 2 – Control System Requirements and
This chapter is in two sections. The first speaks to the specifications for the control system, both in terms of enforcing safety protocols and of operating the facility, and proposes solutions to satisfy them. The second section is largely background information on the methods, materials, and technologies with which the control system is built. It is included in hope of furthering the broader educational purpose of the high-power lab.
Lab Operational Requirements
The High Power Lab equipment is impressively large and potent, beyond the scale of what most people deal with regularly. How then does one construct the lab so it is appropriate for an academic environment? So that it is safe, yet not so restricted as to be unusable? All the equipment needs to be interlocked for safety purposes and integrated in terms of control and data collection, so useful work can be done. As is evident from the physical layout and electrical distribution topology presented in the previous chapter, doing so will require simultaneous operation and monitoring of widely distributed equipment.From these general considerations, we derive the following list of specifications for the control system. It must:
• Communicate data and commands from remote, dangerous locations to a safe,centralized one.
• Guide the operators in taking correct actions and react automatically to dangerous situations.
• Facilitate data collection.
Additionally, by virtue of being a university facility, the control system will have to be reconfigured periodically to host new experimental equipment. The system must be flexible in
• It must be scalable and modular, able to accommodate new needs.
• It must depend as little as possible on components that will become obsolete and hard to maintain.
• Interfaces must be “open” and intuitive to minimize the user learning curve. System security is also an issue:
• Supervisory constraints and system interlocks must be reasonably robust and readily verifiable.
• Communications must be private and secure.
To address the above specifications, the author proposes the following:
• Use a system of distributed I/O devices, connected by a digital data network for the bulk of control and data communications. Safety-critical signals will be carried by discrete, hardwired circuits.
• Logical elements in the system will continuously evaluate the state of the system and permit or prohibit the power distribution equipment from feeding power to the load. Animated, graphical status displays will indicate the state of the facility, and illustrate the necessary conditions to operate the power system.
• A system monitor will periodically poll the system internal states and log them. It will be possible to trigger external data collection devices in a coordinated way.
• Use a commercially available system of small, inexpensive, network to I/O transducer modules designed to be mounted near to their loads. The individual transducers can be added or replaced as required. Design enclosures with spare capacity for future needs, and place them to minimize wire runs to I/O devices.
• Wherever possible, “name brand” equipment will be used so that the OEMs are more likely to offer future product support. Preference will be given to products that are not tied to a particular generation of hardware or operating system and that have a large installed base.
• Selection will also favor tools and protocols that are well documented, have technical support available, and are industry standards (if not open-source).
• “Safety” and “user” functions will be segregated so that the users can not compromise the safety functions. This may require physical separation of the I/O and control platforms, lockable circuit enclosures, and reference code templates. Potentially dangerous actions will require a “man in the loop.”
• The system network(s) will either be isolated or reside behind a router/firewall. Additionally, the lab is expected to be a high-EMI environment so all circuit enclosures and wiring will have to be shielded. This also leads us to favor I/O devices which do not rely on field effects.
Chapter 1 – Introduction
1.1 Our Motivations
1.3 The prior art – other testing facilities
1.3.1 Static, dissipative loads
1.3.2 Dynamic systems
1.3.3 Static, regenerative systems
1.4 The VT HIGH-POWER LAB – available facilities
1.5 Objectives of this thesis
Chapter 2 – Control System Requirements and Background
2.1 Lab Operational Requirements
2.2 Proposed solutions.
2.3 SCADA, what it means and why it satisfies our needs
2.4 Elements of a SCADA system
2.4.1 Sensors and Actuators
2.4.2 Operator Interface
220.127.116.11 Graphic design
18.104.22.168 Organization and navigation
22.214.171.124 Messages and Alarms
126.96.36.199 Direct wiring.
188.8.131.52 Networking – the modern marvel.
184.108.40.206.1 Serial networks
220.127.116.11 The Role of the Control System vs. the Role of the Operator.
18.104.22.168 The Administrative Role
2.4.5 Data Processing
2.5 Redundancy and fail-safe
2.5.1 Fault detection – the fail-safe principle
2.5.2 Protective actions
2.6 A case study.
2.7 Summary of design goals
Chapter 3 – Design and Implementation
3.1 Automation design
3.2 I/O system
3.2.1 What I/O?
3.2.2 Sensor hardware
3.3 Communications systems
3.4.1 Safing the room
3.4.2 Energizing 480VAC wall outlets
3.4.3 Energizing MV supply-
Chapter 4 – Testing and Verification.
4.1 Hardware commissioning
4.1.1 I/O, field device to module
22.214.171.124 Discrete inputs
126.96.36.199 Discrete outputs
188.8.131.52 Analog signals
4.1.2 I/O, network connectivity
4.2 Software commissioning
4.2.1 Variable assignments.
4.2.2 Logical tests
Chapter 5 – Results, Conclusions, and Guidance
5.1 Weaknesses in the design
Appendix A – Ladder Program
Appendix B – VT High-Power Lab User’s Guide
Appendix C – E-stop Interlock
Appendix D – Design Schedule
Appendix E – High-Voltage Grounding