I wonder how many readers have had the benefits of a well-automated production system that just operated seamlessly when recovering from power outages or operator mistakes? Maybe there is another segment that has had to suffer the problems caused by a poorly designed control system. Maybe some have experienced both. Is it just luck or is there some science involved?
INFORMATION GATHERING & PLANNING
At the very start, it is important to work at gathering all the data you reasonably can to deliver a proposal that fits the end-user’s needs and expectations. This deliberate, up-front communication with stakeholders allows us to determine the client’s process and how that process relates to the client’s business and project goals. From this collection of information, the Control System Integrator (CSI) can develop a Design Specification Document that can be reviewed and agreed upon by all the stakeholders before even starting the Design Phase of the project.
Having nailed down the core of the deliverables for the project, it’s time to consider what potential contingencies need to be incorporated into the design. Unlike database programming where the programmer controls every step of the transaction (and should), the real-time control program can only do what the field data will allow. As an example, the next step is to add some liquid to a vessel, but the vessel isn’t ready. What should happen? Should that be accounted for in advance of starting or is that practical? How long can the process stay in that suspended state and still make a good product? Such conditions should be identified and a plan or set of plans incorporated into the design of the system. Simply getting stalled in the process isn’t a desirable feature of a well-designed system.
WHY A DESIGN SPECIFICATION DOCUMENT?
One of the additional benefits of a Design Specification Document is the ability to layout the programming modules in a very specific way before producing the program code. Using this style, the programmer doesn’t have to think about what they want the system to do or how to lay it out while writing the syntax (code). The programmer can concentrate on writing good, clean, well-documented code to execute what they planned.
A good methodology will call for unit testing as the system goes through the Development Phase. At the completion of the Development Phase, a full integrated test to validate the performance of the system to include the recovery from abnormal exits. (See BCI blog posts.) It is important during the Testing Phase to have a documented testing protocol to ensure that all aspects mentioned in the Design Specification Document perform as expected. If additional tests come to mind during testing, the team should ensure those tests are documented and the desirable outcome stated before starting the test to observe the reaction of the system.
Some ways to reduce the cost of development is to skip parts of the above described methodology. Perhaps Contingency Management is only given a cursory look. Perhaps not so much time is given to up front planning and information gathering from stakeholders which can result in a reduction of valuable features for the end-user. Perhaps a Design Specification Document is bypassed which will likely result in more fragmented programming code and leads to something that isn’t as easily supported or modified.
This methodology will produce the best long-term benefit to the end user. It will come on line faster; hence, both reducing commissioning costs and producing good product sooner. This will not be the lowest up-front cost when purchasing the system but will be the best value for the end-user and best Total Cost of Ownership.
As in many things, there are ways to reduce cost of a control system, but is the corresponding loss of value worth it? I suggest finding out whether the CSI is CSIA Certified. CSIA certification requires an audit to verify the CSI’s quality program.
A structured, disciplined methodology produces quality and value.
BCI’s goal is to be the best value through start-up!!