Object-oriented Functional Specs are Key to Surprise-free Automation

KEY WORDS

Process control and instrumentation

Object technology

Specifications

Sidebars: Using functional specifications to solicit bids How to develope control module objects

Functional specifications have two key purposes, to enhance the information presented on process and instrumentation drawings (P&IDs) in such a way as to meet user expectations, and to reduce the total installed cost of a process automation system.

Failure to develop a comprehensive functional specification can make project management a very difficult assignment, can keep engineers on a project much longer than anticipated, and can deliver an unsafe process automation implementation.

A 1988 survey conducted by the United Kingdom’s Health & Safety Executive (Bootle, U.K.) of 34 “reportable” accidents in the chemical process industry revealed that inadequate specifications could be linked to 20% (the #1 cause) of these accidents.

Functional specification development has often been avoided because of the belief it is time consuming and unable to capture sufficient details of automation requirements to ensure project success. Such notions may be true for projects where the functional specification starts with a clean sheet of paper each time. Now it is refreshing to see many process control manufacturers embracing object-oriented configuration tools as an integral part of their products; refreshing because process control has always been about objects.

A look at any P&ID reveals a collection of objects…motors, valves, vessels, sensors…all connected together by lines representing the piping. Adopting object-based modeling techniques for functional specification development encourages the creation of standard process object libraries, and a tighter integration between the functional specification and the development tools manufacturers are providing in their products. These libraries become an ever-growing collection of predeveloped, pretested, reusable process control objects that need only be referenced in the functional specification. This further enhances productivity and encourages consistency across the enterprise.

Two significant features of object-based modeling techniques are the objects and their associated attributes , and the methods or operations applied to objects. Objects are defined as something with a crisp boundary, while methods are defined as functions or transformations that may be applied to an object. By applying those definitions to P&IDs, objects appear in the form of pumps, valves, vessels, etc. What’s missing on standard P&IDs are the object attributes and the methods describing how the objects are to be orchestrated to produce the desired product. These missing object attributes and method descriptions are details the functional specification must provide.

Models, terminology can help

ANSI/ISA-S88.01-1995, Batch Control Part 1: “Models and Terminology” standard closely approximates the significant features of object-based modeling. S88 defines a physical model, equal to objects, and it describes a procedural model, which is analogous to the methods used in object-oriented techniques. Do not allow the reference to “batch” cause you to dismiss S88 as a worthwhile tool in developing efficient and effective functional specifications for continuous processes. S88 has been successfully adopted to define continuous processes in a large number of industries.

The reality of developing a process design is that some portions are easier to define and thus progress through design more quickly.

Often P&IDs of different parts of the process are at different levels of development. A key benefit of developing functional specifications using the models, methods, and terminology of S88 is the ability to match the development progress of the functional specification to the pace of the process development. Project management especially appreciates the ability to develop modular functional specifications because resources can be assigned to work on the portions where design has been completed.

A functional specification structured to follow the S88 models can evolve to address many additional requirements of the project, including detailed design, system architecture, communication requirements, and information system interface requirements. While functional specifications generally do not include testing procedures, meeting its requirements is what testing is all about. Also, in many regulated industries, functional specifications are a key document for completing the validation effort.

The functional specification can:

Help compare quotations from various vendors;

Ease the impact on the project from unexpected changes in personnel;

Ensure proposed solutions will deliver the required interface to other systems;

Help establish expansion or modifications to meet future requirements;

Define a stable platform for change-management; and

Make startups quicker.

Clarity, accuracy required

It is important that information provided on P&IDs and in functional specifications is accurate and clear. Errors in the functional specification have been estimated to be 10 times more costly to remove during testing and 100 times more costly once the application software has been installed and startup is in progress. Not included in these estimates is the potential hardware impact of finding application software errors. For example, misjudging the amount of detail necessary for operator screens may result in overwhelming the communication through-put requirements, forcing an unexpected system upgrade. A functional specification which lacks detail, relies on “buzz” words, acronyms, and mnemonics, produces an overly generalized and incomplete document.

A functional specification requires a commitment of time and expertise to develop, but it is the foundation for building a surprise-free automated control system. If development expertise is unavailable in-house, look to a consultant or system integrator who has proven experience in developing object-based functional specifications.h

Using functional specifications to solicit bids

One way to evaluate the capability of consultant or system integrator is to determine the level of documentation and standardization it has available to guide preparation of the functional specification.

A user should obtain a detailed proposal from prospective consultants and system integrators to develop the desired functional specification. The proposal should define what is to be done, provide a guide as to how the task will be met, identify the expertise level of the person who will be leading the development effort, present a milestone-based schedule, and suggest an approximate cost to develop the functional specification. Such a detailed proposal is important in evaluating and selecting a consultant or system integrator. Upon completion of the functional specification, it may be used to seek bids for the implementation and start-up activities. The ability and willingness of a consultant or system integrator to develop a detailed proposal usually is indicative of the developer’s expertise and commitment to ensure an on-time, cost-effective, quality functional specification.

How to develope control module objects

Development of control module objects requires a generic definition with sufficient detail to ensure clear understanding of the attributes and methods of the control module. The following is a partial sample list of control module attributes:

“Module name” should describe the control module and a few of its key attributes (i.e., “PUMP 2-1”).

“Module description” explains how the control module is to perform. Each PUMP 2-1 control module includes two discrete outputs and one discrete status input. When an interlock condition becomes true, the pump is stopped and remains stopped until the operator issues a start command.

“Command&status words” define the commands the operator uses to manipulate the control module and the status words indicate the current status of the module (i.e., Command words = Stop and Start, Status words = Stopped and Running).

“Module template” defines a standard I/O channel assignment for the control module (i.e., Stop command: Discrete output #1 = 1, Discrete output #2 = 0, Discrete status input = 0. Start command: Discrete output #1 = 0, Discrete output #2 = 1, Discrete status input = 1).

“Module symbol” defines the symbol placed on graphic screens to represent the control module. Since many control system manufacturers include a library of graphic symbols with their product, it may be appropriate to indicate only a typical symbol and select the suitable symbol during implementation.

“Wait time” defines the time to wait between an issued command and when the status input should be read, thus preventing nuisance alarms. When modules utilize sensors (i.e., speed switches) to indicate device status, several seconds may elapse between the command to start and when the sensor actually indicates running.

“Module symbol normal colors” defines the stopped and running colors of the module (i.e., Stopped = green, Running = red).

“Module symbol alarm colors” define the graphic symbol colors when the command and the status do not match after the wait time has expired (i.e., Red-blink).

Depending on the control module type, the attribute list will vary. However, because a reusable control module library is being developed the time and attention to detail is worth the effort.

Do you have experience and expertise with the topics mentioned in this content? You should consider contributing to our WTWH Media editorial team and getting the recognition you and your company deserve. Click here to start this process.