60.1 60.2 60.3 60.4 60.5 60.6 Chapter 60 User Requirements Process Description The P&I Diagrams Control Philosophy Particular Requirements General Considerations Golden Rules Assuming that the outcome of the costs and benefits analysis has impressed senior management, the next step is to generate a user requirements specification (URS). The end-user writes the URS. Its function is to articulate what functionality is required of the control system. The purpose of the URS is to provide a clear basis for tendering and for making a meaningful quotation. It should therefore be correct, as complete as is practicable, and consistent. The URS must be in a form that can be understood by a system supplier or integrator.Also, it should enable the end-user to judge whether the supplier has understood the requirements. The amount of detail required in an URS varies considerably depending on the extent of automation and the functionality required. In particular, it depends on who is going to develop the application software. Is the supplier expected to provide hardware and system software only or a turnkey solution? This chapter addresses the turnkey scenario. There are essentially four parts to an URS: the process description, the P&I diagrams, the control philosophy and the particular requirements. This chapter outlines the factors to be taken into account in formulating an URS. There are various industry guides on the formulation of specifications and for more detailed information the reader is referred to the STARTS handbook (1989),the IEE guidelines (1990) and the GAMP guide (2002). The text by Lee (1998) also provides an introduction to the subject. 60.1 Process Description This provides a basis for the supplier to understand and interpret the user’s process objectives. The point of providing a process description is that it enables the supplier to make informed judgements about the requirements for control. An overview of the process should be provided in sufficient detail for a process engineer to develop a feel for the plant and its automation needs. This should, for example, include: • An outline process flow diagram • An explanation of the function of each major unit and equipment item • Information about the nature of the process carried out in each unit, e.g. exothermic or endothermic, under reflux, pressure or vacuum operation, precipitation of solids, evolution of gases, agitated, etc. • A description of each stream, e.g. continuous or intermittent, liquid or gaseous, clear or slurry, viscous or otherwise • For a multi-products/stream batch plant, typical production schedules indicating the number and frequency of products, number of stages 480 60 User Requirements involved, permissible parallel operations, critical ordering of batches, inter-stage cleaning requirements, etc. • An indication of any unusual features about the operating conditions, such as very slow ramp rates or small difference measurements, and any particularly stringent criteria such as very tight tolerances on error signals • Nature of any constraints, e.g. maximum temperature differences, minimum flows, etc. The more information that can be provided, the less scope there is for the supplier to claim a lack of understanding later on. Remember, though, that this is only the URS. It is not necessary for the end-user to give away commercially sensitive information. For example, the detailed chemistry of the process, the capacity of the plant and precise operating conditions need not be divulged. Once the project has progressed beyond tendering and a contract for supply has been placed, it will be necessary to provide more detailed information. At that stage, if appropriate, confidentiality agreements can be signed. 60.2 The P&I Diagrams The P&I diagrams are key working documents for the supplier.As stated in Chapter 59, they are based upon and reflect the control philosophy. Availability of the P&I diagrams is fundamental to an understanding of the control philosophy. Indeed, the P&I diagrams are a pictorial representation of much of the control philosophy. They will probably be available in a more detailed form than was available at the costs and benefits analysis stage of project, but are still unlikely to be fully detailed. Again, the more information that can be provided, the less scope there is for the supplier to claim a lack of understanding later on. 60.3 Control Philosophy The control philosophy document is essentially a collation of statements about design policy and the principles underlying key decisions relating to the control system. Those key decisions and the operational intent are themselves part of the control philosophy. The point is that the control philosophy enables the supplier to understand the basis on which the control system is being specified. As such, it provides an informed basis for interpreting the user’s requirements. Note that the principles established in the preliminary CHAZOP study, as discussed in Chapter 54, must feed into (and indeed become part of) the formulation of the control philosophy. Note also the distinction between the principles which are the control philosophy and the details which form the particular requirements. A clear indication is required of: a. Scope of project. The end-user needs to state unambiguously what is expected of the supplier in terms of: • The supply of hardware and standard system software only,or provision of turnkey system including application software, or other variants. • Requirements by end-user for involvement in software development, witnessing of tests and acceptance. • Involvement of supplier in provision and/or integration of the control system with third party packages and systems as, for example, with MIS. • Involvement of supplier during installation and commissioning. • Documentation expected. • Timescale for deliverables and deadlines. • Any BS, IEC or ISA standards and guides such as GAMP (2002) which have to be complied with. • Statutory requirements, such as FDA approval. • Quality assurance, such as ISO 9000 approval for development procedures and documentation, for which a quality plan should be requested. b. Scope of automation. The project needs to be ring fenced as indicated in Chapter 59. It is particularly important to identify parts of the plant: 60.3 Control Philosophy • Shown on the P&I diagrams but which are not to be automated. • Not shown on the P&I diagrams which are to be automated. c. Continuous operations. For continuous plant, the key policy decisions concern continuity of operations: • Is the plant to be operated continuously or intermittently? • Is all the plant operated continuously, or are there are parts of it that are operated batch-wise? If so, are they semi-automatic or manual? • How will any batch or semi-batch parts of the plant be brought on or taken off stream? • Is automatic start-up required and, if so, what is the strategy? Units may be brought on stream one at a time, in process order, or all started up simultaneously, or some combination thereof. Start-up from empty may well require a different strategy to start-up following a shut-down. • If automatic start-up is provided, it is usual to have automatic shut-down too. Again, what is the strategy? Remember that automatic shut down is very different from emergency shutdown (ESD). d. Control schemes and strategies. The approach to tag numbering needs to be specified to ensure consistency throughout the system. On a unit by unit basis, the principal control schemes and strategies such as cascade, ratio and feedforward control need to be identified, as outlined in Chapter 30. Any non-standard requirements for control algorithms or associated features should be identified. Any requirements for advanced process control (APC) techniques, such as model predictive control (MPC) or real-time optimisation (RTO) must be made explicit. e. Batch operations. The general requirements for the control of batch operations need to be articulated. Key policy decisions here include: 481 • Whether all batches are to be produced under sequence control. If not, what are the criteria? • Are inter batch/stage cleaning operations to be handled by sequencing? • If a recipe management facility is required, to what extent are recipes likely to have to be created, modified and deleted? • Will recipes have to be modified on-line for batches during processing? • Will different products be made simultaneously in parallel streams? • In the event of failed batches, is there a requirement to be able to go back in the sequence structure to repeat phases and/or steps, or to go forward and omit them? • Is there a requirement to organise batches into campaigns? If so, how are campaigns defined and initiated, and how is production switched between campaigns? • Is any form of dynamic scheduling of batches, units and recipes required? • Does any provision need to be made for anticipated plant expansion? f. Operator involvement. There needs to be some policy on operator involvement, covering the nature and scope of operator activity, as this determines the extent of automation. It is important that: • Some indication of manning levels is given as this provides a feel for the extent of automation. • Types of operation to be carried out manually, such as additions, sampling and visual checks, are identified. • The range of manual actions for areas of plant that are to be semi-automated is clearly understood. • Decisions to be made by operators are identified, such as when to start, continue, stop or abort a batch. • Information to be entered into the system by operators,supervisors, etc. is categorised according to activity type. • Policy exists regarding access to information and levels of authority for changing it. 482 60 User Requirements g. Sequence design. The user needs to explain what approach to sequence development is acceptable. For example: • Are sequences to be generic with parameter lists, as in Chapter 29,rather than being of a dedicated nature? • Is the operations approach to sequence design, based upon plant units (MEIs), as explained in Chapter 37 to be adopted. • Do operations need to be established by configuration of phases from a library of pre-defined phases? • Is it a requirement that the plant be capable of being put into a safe hold-state at the end of each operation? • In the event of an instrumentation, plant or process failure being detected by the sequence logic, is sequence flow forced into a safe hold-state? • To what extent are recovery options to be built into sequences? • Are parallel sequences to be used for application diagnostics? h. Failure philosophy. The central issues here is consequence of failure, which may be of a hazardous or economic nature, or both. Policy decisions are therefore required about: • The minimum levels of system reliability. This enables the requirements for duality to be determined, if at all. • Power supply redundancy and standby power failure arrangements. • Action on system hardware failure, e.g. are outputs forced to predefined values, activate the ESD, or what? • On reinitialising after failure, should loops restart in manual, with their normal set points and zero outputs, or what? • In the event of instrumentation or plant failure, should the outputs of control loops and schemes fail shut, open or stay put? Note that these options are not always available for configuration within DDC packages. • Action to be taken in the event of failure of third party systems and/or packages to which the control system is interfaced. i. Human factors. The user needs to explain what approach to the development of standard displays is acceptable,and to develop an alarm management policy as explained in Chapter 43. For example: • The organisation and numbering of standard displays to maximise the operators ability to navigate the display system. • Guidelines for the amount of detail to be included on standard displays. For example, one MEI per mimic display, or all loops associated with an MEI in a single group display. • Conventions on colour codes, symbols and visual effects to ensure consistency throughout the display system. • The basis for prioritising and grouping of alarms. • The scope for suppression of alarms and provision of diagnostics. j. Approach to layout. The general layout of the control system can affect its cost and functionality. Policy decisions need to be made with regard to: • Relative positions of the rooms and/or buildings in which the operator stations, engineers terminals, I/O card racks, marshalling cabinets, motor control centre,field termination cabinets, etc. are to be situated. • Locations of field stations for remote input of information by operators. • Routing of instrumentation and power cables to a level of detail appropriate to the project scope. • The clustering of units (MEIs) into cells such that units between which there is significant interaction can be handled within the same node of a DCS. This will allow the capacity of the nodes to be sized correctly. k. Management information. Inevitably, there will be interfaces between the control system and other systems and/or packages for MIS purposes. 60.4 Particular Requirements Whether the MIS is provided by the supplier or is of third party origin, the essential functionality required and the nature of the interface need to be specified.To a large extent,the approach to specifying an MIS is much the same as that for the control system itself. Chapter 100 provides more detail. It is useful at the URS stage to identify any key performance indicators (KPI) that are likely to be required. KPIs can seldom be measured directly and invariably require calculation. That is typically done either in real-time by the DCS or off-line within the MIS.It is important to think through the nature of the calculations involved, to identify any necessary measurements, and to understand the data requirements. Typical KPIs are: • • • • • • • • • • • Volumetric throughput Plant/unit efficiency Process yield Energy consumed per unit throughput Raw materials consumed per unit of product Emissions/discharges, etc. Variation in product quality Batch cycle times Plant utilisation Profitability Bonus rates, etc. 60.4 Particular Requirements This part of the URS provides further, more detailed information to supplement the control philosophy document. Some of the more obvious examples of such information are categorised below. Note that the particular requirements identified in the preliminary CHAZOP study, as discussed in Chapter 54, must feed into (and indeed become part of) the formulation of the control philosophy. a. System hardware. The URS does not normally cover system hardware. However, whether the scope of supply includes installation or not, the environment within which the system is to be installed should be articulated. Of particular im- 483 portance is the space available for the proposed system layout, and any constraints on physical access to that space. Likewise for the provision of power, normally a 110 V a.c. supply, and earthing arrangements. Details and functionality of the interfaces to other systems and their peripherals should be provided. This includes serial links to other control systems, such as PLCs and packaged equipment, as well as links to other computers for MIS and APC purposes. b. Plant interface. The point count must be specified as accurately as possible to enable the number of I/O cards to be determined. Remember to distinguish between static and fleeting contacts for discrete I/O. Requirements for segregation of I/O signals must be specified, especially of IS and non-IS signals, since such constraints can have a significant effect on the numbers of I/O cards. Expansion and spares requirements in each I/O category should be identified. Requirements for serial links to intelligent instruments must be specified to enable the number and type of gateways required to be determined. c. Operator interface (hardware). Information needs to be provided about likely manning levels in each control room to enable decisions about appropriate numbers of operator and engineer stations, workstations and peripherals. The manning levels need breaking down on the basis of operators, supervisors and engineers, together with levels of access as appropriate. Provision must be made for redundancy of OCPs. This enables simultaneous and/or multiple displays and allows for failure. Make allowance for both emergency and commissioning situations when access to OCPs becomes a bottleneck. The requirements for any remote, field based, operator stations need to be detailed. Any non-standard features, such as an interface to a hard wired mimic diagrams, need to be detailed. 484 60 User Requirements d. System software. Any unusual requirements should be specified in full: if in doubt, specify it. The supplier’s responsibility is to identify any additional system software that is necessary to provide the functionality required to meet the users’ requirements. Areas for which system software may be required include: • Special input conversion routines, control algorithms and device types. • Implementation of the action on failure philosophy. • Drivers for gateways to intelligent instrumentation to support, for example, HART or fieldbus protocols. • Integration of I/O states in external devices with, for example, those in the DCS or PLC database. • Special display and data entry requirements, e.g. to support any remote operator station functionality. • Abnormal archiving requirements: the numbers, types of point and time scale for archiving should be defined. For example, time scales of a year, not uncommon in the water industry, may well not be within the scope of a typical DCS. • Non-standard event recording: define what constitutes an event and what information must be recorded with it. The associated data is likely to be extensive to satisfy FDA requirements. e. Configurable software. Simple control loop details can be determined from the P&I diagrams but any complex schemes should be specified in detail. Typical I/O channel sampling frequencies should be identified, especially if high frequencies are necessary. This can have a significant effect on control processor loading and it is the supplier’s responsibility to ensure that the equipment quoted has the necessary capacity. Note that the contractor doing the plant design may be using a CAD package which allows instrument data to be ported into another system. If this is the case, include its details: the system supplier should interface to it if possible as this will save a great deal of database configuration and testing time. Publication of ISO 10303, a standard for the exchange of product model data (STEP), has focused attention on the potential for data storage and portability across the various project phases. An extension to this is being developed by the process industries STEP consortium (PISTEP). f. Display system. If the turnkey effort includes configuration of standard displays of the type described in Chapter 42, the number and extent of each type involved must be defined. g. Sequence software. Assessing the volume of turnkey sequence software is difficult: if the effort is initially underestimated, the chance is that it will lead to contractual problems during the project. The following guidelines apply to a multi product / stream plant which is the worst case scenario. The best approach is based on a two-stage analysis as follows: First stage: quantify the total extent of the sequences: • Identify all the products to be made and categorise them into generically similar groups on the basis that within any one group batches of each product could be made by the same procedure but with different parameter lists. • Establish what products are to be made in which stream and hence identify the number of MEIs required for each product. • Consider any inter batch cleaning operations on the same basis of sequences and parameter lists. • Analyse each of the procedures and identify all the operations to be carried out on each of those MEIs for each of the products. Hence determine the commonality of operations between products. Second stage: qualify the detail using representative sequences: • Select three products,whose procedures are representative of all the others,that can be classified as being simple, typical or complex according to the complexity of sequencing involved. 60.4 Particular Requirements 485 • For each of these three products, based on a selection of the MEIs involved, break down their operations into phases and steps. Details for a mix of typical phases and steps should be articulated in the form of sequential function charts, or otherwise. quired, a combination of messages and events will be required to be held for each batch of each campaign on a vessel by vessel basis. Some suppliers’ reporting functions are more comprehensive than others so it is best to be cautious. The cost of the procedures is estimated from the total amount of code and the effort involved. The amount of code is calculated from the number of procedures, their classification, the number of operations involved, the number of phases anticipated and the size of typical steps. The greater the commonality of operations and/or phases, the less the overall cost. The above two-stage analysis is non-trivial and requires experience. If the end-user requires the supplier or some third party to carry it out,relevant information in sufficient detail must be provided. Of particular importance are the P&I diagrams for MEIs such as reactors, filters, dryers, etc. If some of the products were previously manufactured manually, the process instruction sheets are extremely useful, expurgated if necessary. The supplier should be asked to program one of the operations and include it with the quotation as a worked example. i. Higher level packages. These are generally required for calculations for which the amount of processing is beyond the scope of normal control processors.Typically,for management information type applications, the package will provide a frontend to a relational database in another computer, the package handling both access and communications. Or, for advanced control type applications, packages are often of a third party proprietary nature, usually running in a separate processor. h. Batch software. In addition to the requirements for sequencing, further information for batch purposes needs to be provided: • Estimates of the minimum, average and maximum number of products to be manufactured simultaneously • The expected length of a typical campaign • The maximum number of batches in a campaign This information allows the supplier to establish that the functionality of the batch process control package (BPC) can accommodate the requirements for recipe handling and campaign definition. Specify any complex or non-standard logging and/or reporting requirements in detail, including any requirements for access to RDB or MIS for such.Note that if FDA or GAMP conformance is re- For MIS applications, it is of particular important to establish: • Which variables are to be read into the database, RDB or otherwise,from the PLC,SCADA or DCS, and how often they are to be read. It is likely to be a large number of variables but only read occasionally. • What levels of access to those variables exist within the MIS, given that the whole point of an MIS is to provide access to such information. • That security exists to prevent values being written from the MIS into the control system database. If not, on what basis can writing occur? • That the MIS and control system data types are consistent, both for tag numbers and numerical values. • What protocols are in use and that the necessary drivers are available. • That the MIS proposed has the required functionality. The nature of RDB and MIS are covered in detail in Chapters 99 and 100. It is sufficient to say that establishing RDB and MIS links with control systems is not well standardised so the requirements should be specified in some detail. For APC applications, such as SPC, MPC and RTO, key issues to establish are: 486 60 User Requirements • Which variables are to be read into the database from the PLC, SCADA or DCS, and how often they are to be read. It is likely to be relatively few variables which are read often. • Which variables are to be written from the APC package into the control system database. These are likely to be either set points for control loops or output values. If not, on what basis can writing occur? • Any requirements for complex calculations or development of process models, etc. • If the APC is model based, say for predictive control or optimisation purposes, how often the model runs and how it is initialised. Can operation of the model be suspended and, if so, how is it resumed? Are there additional variables required for any of these activities? • The ways in which the APC package can fail. What happens if the packages loses its synchronisation with real time? How does the package handle out of range inputs? Are out of range outputs limited? What happens if there is a calculation failure? • The extent to which the control system is robust to failure of the APC package. Does control revert to pre-determined set points in AUTO and/or outputs in MAN control? The action on failure philosophy may require significant design effort and must be carefully specified. • The form of the operator interface to the control system. This clearly has to be consistent with other aspects of the operator interface. • That the APC package and control system data types are consistent, both for tag numbers and numerical values. • What protocols are in use and that the necessary drivers are available. • That the APC package proposed has the required functionality. If the supplier provides packages for APC, some negotiation over the model may well be required. In general, the process model will be developed by the end-user or some third party and will be highly confidential. However, there is no reason why an overview of its functionality cannot be provided. Likewise, if the software already exists, the language and number of lines of code it occupies can be given. Further discussion with potential suppliers prior to their quotations can examine the possibility of porting existing programs. 60.5 General Considerations As should be obvious, writing a good quality URS is a major task. So too is interpreting it. For this reason it is important that the document is well written. The following general considerations are worth noting: • The user requirements should be as complete, concise, consistent and correct as possible. They should neither be duplicated nor contradicted. Take care to avoid vagueness and ambiguity. Avoid verbosity. Only use terminology and acronyms as defined in standards and texts. Avoid unnecessary jargon and technobabble. • Only provide information that is relevant and reliable. Information whose quality is uncertain is best left out altogether: it is easier to provide supplementary information at a later stage than to correct misinformation. • Where relevant, a distinction should be drawn between essential requirements and things that “would be nice to have”. • Each requirement statement should be uniquely numbered to enable cross referencing by the supplier. • Each requirement must be testable in that there should be some means of deciding whether the solution proposed satisfies the requirement. • A list of contact names for queries should be included in the URS. • Specify a return date for quotations and give the suppliers enough time to respond in detail. Reference should be made to contract terms and a copy of the user’s Conditions of Contract appended. For large contracts, the best terms are ones that support a mixture of lump sum and reimbursable payments for different parts of the project. Of particular importance are arrange- 60.6 Golden Rules ments for stage payments: if these are not available,that should be out in the open at the tendering stage. It should be stated when flexibility is allowable, rather than attempting to force the supplier to comply with fixed terms, often at additional cost. 60.6 Golden Rules It is important for the end-user to specify requirements rather than solutions. The URS is a requirements specification. It is up to the supplier to interpret those requirements and tender a solution utilising the functionality of the system being offered. The URS is invariably and inevitably incomplete.The supplier therefore has to interpret the requirements and interpolate between them. In general,the better the quality of information provided, and the better the understanding so obtained, the less likely it is that the project will go wrong. Encourage the suppliers to visit the plant and discuss specification queries. Much can be learnt on both sides with such a meeting. 487 Different suppliers’ systems and packages may well have different functionality, but still be able to meet the requirements specification. Care should be taken not to generate detailed specifications for packages which the supplier provides as standard. Do not be tempted to develop the URS by working backwards from the detailed description of a particular supplier’s system or package: it will be difficult for other suppliers to satisfy such an URS. Also, it is obvious when this has been done and suggests that the key decision about the choice of supplier, system and/or package has already been made. The tendering process is reduced to a charade. A good quotation is one which enables the supplier to meet fully the user’s specified requirements, subject to agreed quality procedures. It must be cheap enough to be accepted by the enduser but at the same time provide enough profit to support the viability of the supplier’s business.
