A functional specification can better define a control system’s requirements
Picture this: Your brand new desalinization plant takes up to four hours to start, and that is if the one operator who has a piecemeal understanding of the controls is available.
The following is a true story: Over the course of two weeks, a newly hired principal engineer at this agency spent two weeks with operators through trial and error to determine how the controls worked. They conceived a custom startup sequence, using 20 screen changes and manual interventions, to bring the plant online in 20 minutes. Even with the plant running, they did not trust the data.
Stories like this are not unique, but they do not have to be yours. One of the best ways to work well with a systems integrator (SI) after vetting qualifications is to ensure the SI’s scope includes developing a clear, consistent and complete functional specification in partnership with the owner (end-user). This means defining what the control system is required to do, in terms unmistakable to the owner, before anything is built.
An Explanation for Specification
Why develop a functional specification? Control systems have a disproportionate impact on the systems they serve. No matter how well the infrastructure and process designs are implemented, a poorly functioning control system can overwhelm an organization with problems, including poor reliability; increased staffing; manual interventions; training difficulties; prolonged troubleshooting; and reduced ability to optimize operations.
Unlike other industrial engineering disciplines, developing control systems is not regulated, and disciplined project methodology is not common practice. Solutions are crafted in virtual spaces where core decisions can be implemented on a whim; visibility to stakeholders is low; and technology and terminologies pose barriers to stakeholder understanding. Imagine a contractor constructing a tank and changing the bottom shell plate thickness by half in the middle of the build without notifying anyone. Preposterous—but in the SI industry, the equivalent is normal.
Developing a functional specification forces the SI to actually design the software (e.g., PLC program, HMI). Through the written word, the operational structure of your process, big or small, can be rapidly outlined, followed by filling in detailed requirements for the behavior and operator controls of every sequence, control loop, pump, valve, safety switch, trend, alarm, user security, etc.
Let’s say an owner reviews a functional specification from his or her SI and discovers fatal flaws or omissions. Excellent—it is only paper, it is early in the project, and the redlined functional specification provides a medium to communicate the gaps to the SI so the required changes are mutually understood.
By reworking sentences on paper, the control system architecture can be optimized in minutes or hours. A customary alternative is “design as you code” which, regardless of a programmer’s perceived skill, yields disjointed program structures that are subsequently difficult to correct and expand upon.
What does a functional specification look like? A functional specification should be written in plain English, describing the required behavior of the system in the equipment and process terminology of the owner. References to programming syntax are rarely necessary. The accessibility of the document dictates how effectively stakeholders can provide feedback during design, and how well it will support operations as reference material. If an operator, technician or manager cannot understand it, it is not written well enough.
A well organized document structure builds the reader’s understanding of the physical process, introducing key concepts and intent prior to control strategy details.
A table of contents could read as follows:
While better than nothing, control strategies written as standalone flow charts or diagrams leave countless gaps in requirements (e.g., How are critical alarms conveyed? Is the PID loop tunable from the HMI? When the user presses the “Auto” button, what sequence unfolds? How long is data stored? What permissions are required?). Proper functional specifications provide the basis for programming, testing, startup, acceptance and operations. Both the SI and the owner can use them to measure progress and compliance.
Who writes a functional specification, and how does he or she write it? Ideally, SIs should write the functional specification, because they are best suited for ensuring requirements are thoroughly defined. However, the highest value is attained when stakeholders from the owner are engaged in the process.
“Control strategy workshops” are an effective format to engage stakeholders in helping to define control system requirements. During a workshop, the SI can discuss and diagram (whiteboard) what the equipment and process will do to frame the requirements gathering in terms relevant to operations. The SI can subsequently develop and submit a draft functional specification and, upon approval, start programming. This may seem more expensive and drawn out; however, short- and long-term savings from the benefits are substantial. The fastest and lowest cost project methodology? Do it right the first time.
A functional specification developed in this manner allows the owner to confirm the process control system he or she will receive and provides value throughout the life of the system. A functional specification is a principal as-built document, offering clarity that informs training, troubleshooting, optimization, new feature requests, system expansion and system replacement/retrofitting. Without one, a SI will inevitably be hired to reverse-engineer the legacy system at some point to support the owner. This cost is never represented in the original project budget.
Programming without a functional specification typically is born from an optimism and lack of awareness common to software development. Projects executed without finishing functional specifications tend to encounter budget and schedule duress. Processes can provide fundamental necessities to communities—engineers want to build them better, and they can.
The desalinization plant from the introduction is being doubled in capacity, including a new control system. The functional specification has been approved and the owner confidently predicts a 10-minute, fully automated startup without changing screens.
Enterprise Automation is a member of the Control System Integrators Assn. (CSIA) specializing in the water and wastewater industry. Headquartered in Irvine, Calif., Enterprise Automation’s expertise includes design consultation, specification development, panel design, virtualization, communications optimization, PLC programming, and SCADA configuration. For more on Enterprise Automation, visit the company profile on the Industrial Automation Exchange.