Functional Control Description Format

  • Thread starter Robert G. Cook, Jr.
  • Start date

Thread Starter

Robert G. Cook, Jr.

I write many functional control descriptions which, for those of you who are not aware, are detailed descriptions of the control functionality of process equipment, commonly used as a reference by PLC programmers to generate the ladder logic code.

My question to you gurus out there is this. What is the best format and structure of this type of document? Are there any standards on how to define it anywhere? My industry is the chemical process and wastewater and I am looking for ways to improve upon our existing methods. Any ideas or sample documents would be greatly appreciated.

Bruce Durdle

A good list of what should be in a Functional Specification, based on the UK IEE "Guidelines for the documentation of ciomputer software for realtime and interactive systems" is set out below. This is for a safety-related system, but can be relatively easily adapted to other uses.
Process Description -
This should give an overview of the process, so that someone who is not familiar with the details of the proposed operation has some understanding of what is required. It effectively provides the context for the protective system. The overview should include P&I Diagrams or similar methods of
representing the process operation. Another element of the process description that needs to be recorded is a list of materials involved, complete with any properties that may affect
safety or reliability, such as corrosion, plugging or coating properties, excessive temperatures, and so on. This needs to take into account not only the main process materials, but also those used for chemical cleaning, for
example. Where a process is covered by government or local regulations or Codes of
Practice, these need to be referred to in the Safety Requirements Specification.
Hazards -
The starting point for the Safety Requirements Specification is the list of hazards identified during the initial Safety Review. This will identify the safety functions required, and all layers of protection intended to cope with each hazard. The Safety Integrity requirements for each hazard also need to be given.
For each hazard, there is other information needed that is pertinent to the design of the protective system. How much time have we got to cope with the hazard? With a tank that will take 20 minutes to reach the overflow from the alarm point, when the inflow is at maximum, there are many more options for protection than in a boiler where an explosive mixture can be reached
in 5 seconds.
Field Devices -
For each hazard, there will be sensors and final control elements. These are part of the protective system, but also part of the process - we have limited scope to choose these, and their operation will also affect how quickly the protective system can take effective control action. There may be other implications on sensors or final control elements that
have to be considered - for example, drift in a sensor or coating of a valve will have an impact on the reliability of the element and therefore
on the overall system PFD.
With field sensors, there is also a need to have a list of all instruments involved, and their calibration ranges or setpoints. This is needed to
review the actual operating settings in an overview. The capacity of final control elements, such as valve design and maximum flows, also needs to be listed. It should be noted that in some applications excessive valve or pump capacity can contribute to a hazard - for instance, if a boiler discharge flow control valve is grossly oversized the speed at which level will fall will be much greater than with a correctly-sized valve. With some manufacturer's valves, only limited size ranges are available and it may be necessary to mechanically restrict valve stroke to avoid excessive flow.
The Operating Cycle and Safe States
In this section we define the intended operation mode, and the actions to be taken for each hazard. It will summarise the overall actions to be taken in the system, and provides the reference point for the discussion of functions to be executed for each protective function.
Safety Functions
For each hazard listed, we need to define the operation of the safety system. In many cases, this will be straightforward, but in others the
safety actions needed will depend on the state of the system.
As we have already discussed, this part of the specification needs to be unambiguous and complete. For each hazard, it should include:
The relevant process sensors and details of the measurement connections to the process
The process outputs involved, and how they affect the process
The functional relationships between inputs and outputs, with any necessary logic or calculations set out in detail.
Any factors such as disabling or modification of protective functions during different steps
Any time constraints or limits on performance
The Safety Requirements Specification should also identify any requirements for testing and monitoring of particular safety functions, where these are set by statutory requirements or similar.
Operator Interface
In any system where an operator is required to take some sort of action, we need to define the actions to be taken and the locations of various
interface elements such as manual shutdown switches or indicators. We also
need to define the format to be used for alarms.
Any areas where operator action is essential to a particular layer must have this explicitly defined, and any limits on time for this action set out. Operator actions can be related to the operating cycle, as many of the transitions such as starting will involve an operator. Monitoring of the operation may also be included.
Maintenance and Testing
Specific consideration must be given to maintenance and testing. These activities are essential in most applications, and if possible specific provision has to be included in the Safety Requirements Specification to cover them. In particular, where testing is likely to reduce the safety or integrity, it is worth while making specific provision to keep control of the methods used and make sure safety is not compromised by leaving jumpers in place, for example.
Testing frequency may also be taken into account to achieve a given SIL. If this is the case, it needs to be stated explicitly in the Safety
Requirements Specification.

Hope this helps,