Author: Scott Turner
This is the fourth part of my five part series on how to write an effective User Requirements Specification. The topic for this part is the ‘Control Philosophy’. The first three in the series include Considerations for Your User Requirement Specification, Process Overview for Your User Requirement Specification and Scoping Your User Requirement Specification. The fifth and final part to be written soon will be about hardware.
If you would like to comment and add to the contents of this post, please do so. It will make it a more rounded and complete guide.
I recommend that authors of Control Philosophies consider the following points:
- Within this section, describe if the plant is a continuous or semi continuous plant. If the plant is operated continuously, are start-up and shutdown routines required?
- For batch plants or plants which include batch functionality, explain how the interface between batch and continuous parts is managed? For example, are there buffer tanks?
- If there are any naming conventions for database elements or instruments, please explain them. This will allow the designers of the control system to understand the duty of instrumentation and ensure they are consistent.
- Where non-standard control modules or strategies are required, include a detailed description. Examples of non-standard control modules and strategies include AGA compensation modules, fuzzy logic and anti-surge control.
- State if any advanced control applications are required. Are there any complex PID loops? If so, describe them.
- For each equipment unit consider describing the principal forms of control including control module tags where available.
- For batch projects, describe any inter-stage cleaning requirements as these can be particularly complex. Is a recipe management facility required? Are batch analytics required? Do you use golden batches?
- Explain how many operators will use the system and how many operator consoles are required.
- If any operations or tasks are carried out manually, please describe them. How does the operator interact with the system for that task?
- If any alarm management functionality is required, ensure that it is fully described. Examples of this may be automated suppression logic or the creation of general alarms based on bit patterns.
- Describe how the sequential logic is arranged and how much of it there is. How complex are they? It is useful to include an indication of the number of steps in a typical sequence.
- A lot of the configuration effort around procedural logic is associated with failures. It is typically more than half of the effort. Describe how sequences can fail and what should happen on failure. This includes failures of instruments which impact the sequences. It is important to consider as many failures as possible so that the system is more robust.
- State how a sequence can be restarted or recovered when it has failed. Is it manually? Does the system need to repeat certain functions on restart?
- Ensure that you describe to what graphics conventions the project should adhere. How many are there? How are they organised and navigated? Do they need to be similar to an existing system?
- Describe what reports are required and what type of information they should contain.
Include as much information in the control philosophy as you can and pay particular attention to how the system responds to failures. This is an area of the philosophy which is often not considered but is immensely important to the person who configures the control system. The system will be much more robust if it can respond to failures in a controlled manner and not get into a situation where the logic locks up.
Please feel free to let me know your thoughts on the control philosophy in the comments section below.
From Jim: You can also connect and interact with other project experts in the Plan & Design group in the Emerson Exchange 365 community.