A model is a more formal way of defining your detailed functional requirements than just text. And the S88 standard provides a good basis for modeling requirements. Functional Requirements Analysis is the process of finding out and then describing the detailed functional requirements – what the 'objects' are and how they should be controlled. The process by which the model develops is important.
The process should ensure that:
End users have the opportunity to input and can make sure that their requirements are considered.
Design is carried out in a rational and documented way
Important design decisions are not made by programmers whilst coding (which can be a recipe for problems)
The process includes
The decomposition of the process equipment and recipes into the S88 physical and procedural objects
The detailed design of each of these objects
Mapping these into the standard system functions. During the system independent stage the mapping is done into generic standard modules.
The resulting design is contained in a Functional Requirements Model, hereafter just called the model.
The process uses the Models and Terminology defined in the ISA standard S88.01. There are however many interpretations of S88. Different understandings of operations versus phases are common and the same sometimes applies to Equipment Modules versus Control Modules. Unless the standard is narrowed down, there is still a lot of room for inconsistencies and misunderstanding. Furthermore, the standard does not proscribe detailed design architectures such as Unit Centric versus Equipment Module centric choices. The standard in fact clearly states that there are many different ways to proceed – or choices.
For this a Design Principles document should be written to clarify the extent to which the choices that are allowed in S88 apply to the particular project. It should also shows the way Units, Equipment Modules, Operations are defined. The Design Principles document also provides a description of generic control mechanisms that are common to the entire process, and describes in general terms how the diagrams and tables define the required Control and Operational activities.
Generic control requirements for both normal operation and exception handling.
The structure of the model.
The use of diagrams.
The use of matrices.
The use of tables and lists of data.
How various control objects (items such as units, equipment modules, control modules, recipe procedures etc) are defined.
HMI aspects of the model
Standard module designs
There is an example for producing such a document on the ControlDraw web site, called the Requirement Principles Template
State Based Control is another technique that helps with defining control functionality
This web is funded by advertising, but the advertisers have no influence on the web site. Please visit them.