Do you really need a specification document?
A well written design specification that has been thoroughly reviewed and discussed can greatly minimize the startup headaches and number of changes.
“The most common specification for a distributed control system (DCS) is an IO list written on a paper napkin.”
This is an old joke, but it is more true than someone may realize. Many initial DCS requests for quote (RFQ) are based simply on an approximate IO list and the number of operator stations required. While this can result in a reasonable“ball park” first pass estimate, the accuracy of that first pass will depend on how close the initial IO count was to the actual IO required to complete the system. A specification is something that tells people what they should build. Without a specification they don’t know what to build. A well written design specification that has been thoroughly reviewed and discussed can greatly minimize the startup headaches and number of changes. So think back to the paper napkin specification. Isn’t that a pretty big risk to take with something a company will own for 20 years to venture into a complex project without a written understanding of the functional requirements?
As we have experienced, there is benefit and value to a specification for complex controls projects. In our controls world there are two basic types of specifications: Functional design specifications and detailed design specifications. These specifications help address two critical objectives of a project: Setting and staying on budget and setting and maintaining the schedule.
Functional design specification
A functional design specification defines the overall design and functions that the system needs in order to perform the operations required to execute a successful project. It is typically used to help develop a budget plan for the project or plant. It describes how the plant or unit will operate and allows the user to obtain budgetary bids based on a more detailed set of criteria than just basing the bids purely on a list of inputs and outputs.
If a specific platform has already been standardized, the initial development of a specification may be a bit easier to develop. It also narrows the number of integrators that you can choose, provided that you utilize integrators who have demonstrated experience on the chosen platform.
If there is no specific platform selected, having a functional design specification will help ensure that the process of selecting a platform is based on a defined set of criteria. If you request bids based on your paper napkin, you will get you a wide range of bids. Some may provide you with a “Cadillac” system, while others will quote an “economy car” and they may hope to upsell you later on features that you may actually need.
The functional design specification helps you identify, in writing, the product you are making, how you make it, the plant areas and units, if the process is batch or continuous, PLC or a DCS, remote racks or a central rack room, if you will have remote viewing capabilities, and your reporting requirements. In addition, the specification can help you plan the actual testing methods and conversion strategy to include downtime requirements and critical components.
By having these and other items listed in the specification, you will create a solid basis for you to receive reasonably similar bids back from your request for proposal that takes into account all aspects of the project. I have 2 examples of customers with regards to functional specifications. One good and one not so good.
Two case studies
I recently worked with a customer that needed to upgrade a unit’s control system that has been in place since the mid 1980’s. They had been using the equivalent of EBay for a decade to keep the system running. They also had several key personnel retire, taking with them a vast knowledge base that has kept the system running for the past 30 years. Most DCS systems are designed to be in place for 20 years, but are rarely designed to actually run for 30 years without major upgrades in technology.
The customer decided to purchase a FEED (front end engineering and design) study, which is another name for a functional design study. This study was to help identify exactly what was needed on the new system and to develop a document that would allow them to go to vendors and obtain bids for the replacement system. For the FEED study we had 4 companies spend a week onsite pouring through the original documentation for the system and going through the updates that had been made on the documentation, as well as walking the plant to assess the electrical and mechanical requirements for the new system.
Fortunately they had done a reasonably good job of updating the information, but as it was in paper form, there was no electronic documentation that could easily be pulled into a database. After the site visit there was about a 2-3 week effort to produce the final FEED Study document. The document allowed them to set a good budget for the project and make a realistic assessment of downtime and implementation time required to work with production for the upgrade.
I worked with another customer, several years back, who was building a grassroots plant with a completely new design. They opted not to develop a Functional Design Specification as they wanted to quickly get the plant up and running. By omitting this step they suffered. Neither of the two project objectives that were identified earlier were achieved.
They ran over budget as they were designing the system on the fly and were constantly reworking configuration. This added cost to the project. Because of the lack of a clear design and the resulting tinkering, the project schedule slipped and they did not meet the startup date. In an effort to bring the project back on schedule, some shortcuts were taken and, while they did help the schedule, they caused support issues for the long term.
In the end the customer had a working system but it was over budget and late. This scenario could have easily been improved by simply taking the time and making an investment at the beginning of the project to develop a proper specification. The additional cost that they incurred were substantially more than the cost of a Design Study.
Detailed design specifications
The detailed design specification is typically divided into two sections, hardware design and software design.
The hardware design deals with elements like system architecture, cabinet requirements, cabinet distribution, cabinet design, PC requirements, fieldbus or traditional IO, and network requirements. The system architecture determines what level of redundancy should be used and whether a safety system is required or a basic process control system will suffice.
- Cabinet requirements include environmental requirements (indoor or outdoor) and whether they may need cooling to keep the equipment within required heat and humidity tolerances.
- Cabinet distribution deals with whether the plant will have centralized IO using homerun cabling or a distributed IO cabinet layout in which a bus is used between areas and shorter instrument wires are required.
- Cabinet design deals with how the equipment is laid out within the cabinet, power distribution and defines typical wiring for different types of inputs and outputs.
- PC requirements can be with regards to standard or industrially hardened PC’s. Whether you plan to utilize a thick client architecture in which each operator and engineering station is a full PC with its own licenses residing locally or you go with a virtualized system, which uses thin clients at each location.
The software design deals with how the process will work. It defines how individual elements in the process act and react. The software document will define the device and functions of each specific device and each area of the plant. The devices are defined as control modules (CM). The functions are defined as equipment modules (EM).
By developing and signing off on the software design, before you begin the software configuration, you will provide your integrator with a solid basis from which to configure the system. This should eliminate confusion on how the system is designed to operate. The software design also becomes a test document that can be used, during the factory acceptance testing, as a checklist to confirm that the system performs as it was intended to work.
In addition, we have seen time after time that multiple departments in the same facility do not actually agree on the actual procedure the plant is currently using on a particular application. The process of going through the discussions to create the design specifications forces the plant production, management, maintenance and engineering to realize true discrepancies in their understanding of plant operation so they can discuss and agree on how they will handle particular operations.
I am currently working with a customer for which we are configuring their chosen DCS system. They are building a new plant that is an entirely new facility near their existing plant and, working with them, we developed a software design specification (SDS). Their engineering team had never built a plant from scratch, which presented some issues as they determined what new technologies to use and what strategies to keep from the existing plant.
They decided that, even though they have perfected the process in the existing plant, they did not want to simply copy it exactly without taking advantage of new technologies. In deciding to utilize new technologies, there was a need to accurately communicate how it needs to operate to our engineers.
This is a medium sized DCS and lot of time was spent to jointly develop the Software Design Specification. The software design has been a key part of the project and has helped to reduce confusion on how specific elements of the system operate. Some of the initial ideas on how elements work have changed during the life of the project.
Making changes after the project is configured is sometime necessary regardless of the planning and adds time to the project. However, since we have the SDS in place, it helped to quickly identify what the ripple effect of the required changes would be on the entire system, thus allowing the customer to determine whether the changes are worth the additional time. This document has not only acted as a test document during hardware and software checkout, it will remain as a major part of the system documentation after the project is complete.
The paper napkin
Looking back to the beginning of this article, do you really want to start with the paper napkin approach? Most control systems will be in place for greater than 20 years and you may not want to risk a mistake, on the front end, that you will live with for a generation. For a nominal investment, at the beginning of a project, you can save yourself and your company on not only the project budget but also on the lifecycle cost of the system.
For more on specification documents, read "Specification documents: Pay now or pay later."
John Walker is an account manager with the Cross Company, Integrated Systems Group based in Nashville, TN. John has over 20 years of experience in the process control industries in both sales and sales management roles. He has successfully implemented projects in the chemical, pulp & paper, power, defense and food & beverage industries. Cross Company Integrated Systems Group is a CFE Media content partner.
Cross Company is a CSIA member as of 7/6/2015
Do you have experience and expertise with the topics mentioned in this content? You should consider contributing to our CFE Media editorial team and getting the recognition you and your company deserve. Click here to start this process.