Abstract

A safety document management system, known as a Permit for Work (PFW) system is used commonly in the power industry to provide appropriate safety conditions for those working on the generating system. This paper investigates how a safety management process (+PFW) can be combined with a safety framework to enhance system effectiveness to ensure the requirements of users and suppliers can be met. While the paper makes some reference to the power industry, the concept is applicable to the management of systems in other domains.

1. Introduction

A safety document management system, known as a Permit for Work (PFW) [1,2] system is used commonly in the power industry to provide safe working conditions for staff and contractors charged with performing repair tasks on the generating system. The PFW system has until relatively recently been a manual system. Although this method is still capable of performing the required tasks satisfactorily more and more users are operating a computerised information management solution to facilitate the issue and control of the required documents. In the power industry, the PFW system is an accepted requirement, but as the Health and Safety Legislation [3] becomes more demanding on other industries, it is also becoming more common in other domains [4].

Research in requirements engineering [5,6] has recognized the need to ensure that systems are developed with safety being considered as an integral part of requirements elicitation. Furthermore, it is generally understood that all stakeholders involved in the requirements process need to be fully conversant with the consequences of their decisions and the potential impact on the domain [7,8].

The power generation industry is not the only sector that has experience of using PFW systems. Oil and gas producers [9] and the mining industry all have similar expertise, although in some instances it is referred to as a “Permit to Work” (PTW) system [10]. Such systems are defined as a formal written approach used to manage certain types of work which are identified as potentially hazardous [9]. As the legal requirements have changed regarding safety, the definition of the term “certain types of work” has been modified. PFW systems are no longer the exclusive domain of the industries that previously were considered dangerous. Rather, they are now a requirement of almost every industrial sector.

Health and safety leglislation is concerned with either eliminating all risks and hazards or at least minimizing them to a level that is considered as low as reasonably practical. When this is not possible, and significant risks still remain, the HSE guidelines clearly state that an alternative method of ensuring the safety of an individual is required. Hence a higher level of control is required and therefore a PFW system is introduced.

When a PFW system is used to provide a safe working environment, a number of reasoned decisions are taken prior to the system being implemented. These revolve around assessing the risks and hazards present in the environment, and also the control measures which are in place. It is when the outcome of these deliberations suggests that the risks cannot be controlled sufficiently that a PFW system is required. Therefore a safety management process needs to be developed to ensure that a level of safety is provided for all stakeholders in the maintenance and repair tasks. This is achieved by means of the +PFW process [1,11].

+PFW is a process that can be applied by either the end user of the preferred solution or the supplier of the system. Its implementation will ensure that the users are capable of operating the solution in a safe and appropriate manner. The supplier can use the process to determine where the user is, in terms of readiness, to install the system. Health and Safety Executive guidelines [12] are very specific about the need to use a PFW system but they are less clear about how the PFW system should be implemented and what is expected of the end user or supplier of the system. If the guidelines are taken in a literal context, it could be argued that having decided that the risk and hazards cannot be controlled adequately a PFW system must then be operated. Furthermore, provided the paper work issued emanates from a PFW solution, the user has conformed with a correct interpretation of the guidelines. In reality this is a very serious misconception.

Both the end user and the supplier are obliged by health and safety legislation and they must both endeavour to meet these statutory requirements. The +PFW process provides a mechanism to achieve this goal. However, on its own the +PFW may not be sufficient to establish all the elements required to satisfy these requirements and this paper is to attempt to enhance the process to ensure these objectives are fully met.

A brief outline of +PFW is discussed in section 2, while section 3 introduces the concept of a framework [1,13] to establish safety requirements. These approaches were derived from different viewpoints of safety but they have the common objective of ensuring that safety is always considered in the development and implementation of a system, particularly a PFW solution. Section 4 investigates combining the +PFW process and the safety framework so that the required outcomes can be achieved for both the supplier and the end user.

2. The +PFW Process

+PFW is an approach which provides a way of ensuring the correct implementation of a PFW system. When a system, which is life safety critical, is implemented and operated, it is important that the users of the solution should be totally conversant with the items addressed by the system [14]. They should be aware of the limitations of the system, understand their responsibilities and know the consequences of any failure to adequately perform the roles and task associated with the system. Figure 1 shows the process diagrammatically.

In following the +PFW process accurately, a situation develops which provides a successful implementation of the chosen solution allowing it to be operated effectively. It also allows systematic reviews and audits to be performed thereby ensuring continued compliance in light of changing circumstances and/or environmental conditions.

The three key stages of +PFW are as follows:

1) Establishment of a maintenance list

The initial concern here is to establish the specific items required and the context in which they are required. The outcome should be a definitive list detailing all equipment and plant in the domain that require the issue of safety documents from the process. The assumptions made and the context of the decisions reached must form an integral part of this list. The maintenance list cannot be considered static throughout the lifecycle of the process, but should be continually reviewed to ensure that it is complete.

2) Development of an equipment list based on the context of the maintenance list

To allow work to be undertaken by an individual, items of equipment needing a safety document are identified. In order to carry out a task, a list of potential energy sources for each item in the maintenance list needs to be established. In this way anything hazardous can be identified and isolated. This new list is an adjunct to the maintenance list described above. The equipment list must be considered as a dynamic document and must reflect the changing environmental conditions of its operating environment.

3) Establishment of specified roles

Potential roles for the process need to be identified and their responsibilities assigned appropriately [15] if the required level of safety is to be achieved. Once established, the roles then need to be allocated to the users of the process.

A full description of the process can be found in [11].

3. Safety Framework

The safety framework [1,13] identified three potential groups of views that are common throughout a variety of domains and industries. The interpretation and application of these view groupings may differ across domains but each can be readily identified in each domain. These provide differing perspectives of a system based on a stakeholder’s concept of the problem. These groups are defined as:

• Operational Group OG. This group contains the views that define the “who” and the “what” of the solution. It identifies what a system is actually required to achieve, who the likely users of a system are, as well as any organisational hierarchy of roles and users that are applicable [16].

• Safety Regulation Group SRG. This group contains the definition of the legislation, standards, policies and procedures applicable in terms of internal and external

stakeholders. It includes existing and proposed legislative requirements as well as the accepted industry standards in force in the chosen environment.

• Requirements Group RG. This group contains the views which detail the requirements of a system under consideration.

The interrelationship and interdependency of these groupings mirrors the safety aspects of a system. Without accurately and faithfully considering all potential views on a system safety cannot be assured.

Therefore to provide the correct level of assuredness about the safety of a system all views must be identified and their requirements addressed in the framework. Figure 2 shows the relationship between these view groups.

A fuller description of the safety framework is given [13].

Each of these identified groups were individually investigated and broken down into their component parts to ensure that all aspects of the requirements elicitation were addressed. The safety framework is shown in Table 1.

All of the views identified in Table 1 are mapped to a column called the “framework methods”. This column shows what might be the most appropriate method or technique to use to accurately represent the identified view.

4. Enhancing the Safety Framework Using +PFW

The safety framework was developed to establish the requirements of a system including its safety aspects. It identified specific areas that need to be included and the models that could be used to represent these requirements.

However, when a system includes a requirement to operate a PFW system this may complicate the process, particularly when the stakeholders involved have little or no concept of a PFW system. Hence the safety framework needs to incorporate a method for dealing with this situation.

4.1. Linking the Safety Framework and +PFW

View OG1 in the safety framework identified the need to have a textual overview of the system. The overview must include all aspects of the system including any specialist information such as the maintenance and equipment list identified in +PFW, while view OG3 established the requirement to identify the roles required to operate a system. Again the roles identified must include all roles including any that may be specific to a PFW system if such an element is part of the overall solution. Thus these two views clearly indicate the need to link the framework and the process. However, unless the stakeholder understands the concept of a PFW system it is not obvious from the safety framework that these items are required.

The need to establish the context of a system and the rationale behind the decision making process are also key components of the safety framework. If a PFW system is an element in the overall system it is vital that the requirements for this system are included in the elicitation process. If it is overlooked or ignored, for any reason, then the accurate modelling of the system will not be achieved. Therefore the safety framework must encourage users to explore the potential need for a PFW system.

The safety framework was established by examining the views that should exist in all systems. The views identified were associated with a set of groupings and the methods and techniques required to capture the required information appropriately were established. It is thus in the context of the views that the concerns over the inclusion of a PFW system needs to be addressed. The validation carried out clearly indicated that the safety framework was sufficiently robust to cope with the inclusion of a PFW system as an element within the overall system, since several of the views discussed included the PFW system and no issues were evident in terms of the framework’s ability to cope with the full system. It would therefore appear appropriate to include the PFW view, and in consequence +PFW as the model for this view, within the framework. However, this assumption

needs to be evaluated further.

The safety framework clearly posses sufficient views to represent all the safety aspects of a system including those covered by a PFW system. If this was not the case it would have been obvious that there is something missing from the safety framework during the verification process. Therefore the requirement to incorporate an additional view to deal specifically with the PFW scenario seems to be superfluous. However, if it is omitted then the issue of the safety framework being used by inexperienced users is not addressed, therefore its inclusion provides a method of dealing with this requirement.

4.2. Including +PFW in the Safety Framework

As already discussed, the need to utilize +PFW will not be a requirement of every system. Rather, it is an adjunct only if the system under consideration requires the incorporation of a PFW system as part of the overall solution. Therefore some method is required that provides the users the ability to utilise +PFW in conjunction with the safety framework when it is required. As a minimum the stakeholder needs to be aware of the potential of requiring a PFW system and they should at least have the opportunity to reject this element. Instead of including the PFW process as a view within the safety framework perhaps a more appropriate solution is to include +PFW as a model in the framework. Several relevant views have been identified within the safety framework which need to incorporate +PFW in order to provide an accurate and appropriate representation of any system being reviewed. These can be identified as views OG4, OG5, OG7, SG2 and RG5.

OG4 is concerned with the interrelationship between roles in the system while OG5 deals with the organisational structure. OG7 represents the changes in state possible in a system. One of these state transitions involves the release of plant for maintenance activities and the return to service of this released plant on completion of the repair tasks. This is obviously a major element in the control of safety using a safety document system and as a result +PFW should be included as a method for this view. View SG2 deals with the safety rules applicable to the system. If these include the operation of a safety document management system then +PFW is a requirement that should be included as a method within this particular view. The final view affected by +PFW is the RG5 view. This view reflects the linkage between the system being considered and any other systems in the environment. This must include any sub-systems such as a PFW solution that may impact on the overall solution. Therefore it is appropriate to include +PFW as a method for this view.

The enhanced safety framework is shown in Table 2, showing the addition of +PFW as an additional method.

5. Enhancing +PFW Using the Safety Framework

+PFW process provides a clear and concise means of implementing a safety document system which is available to use by stakeholders who are aware of their responsibilities and their impact on others. It provides a mechanism to audit the safety document process to ensure compliance with the relevant documentation and procedures. It also facilitates reviews of the operation of the PFW system to comply with changing environmental conditions.

5.1. Linkage of Lists in +PFW to the Safety Framework

+PFW is explicit in the need to develop a maintenance list as the first element in the successful implementation and operation of a safety document management system. It consists of the electrical, mechanical and ancillary devices and equipment items that are considered to have a significant risk factor in the environment in which the maintenance list is considered. Thus the need to create a list, and to record the context in which it is constructed, are key elements in the process.

However, as the safety framework clearly states there is more to the capture of requirements than just knowing that they exist. +PFW is implicit about creating a textual document to record the items that constitute the maintenance list. This is implied by the fact that it is termed a maintenance list and the majority of lists are held in a textual format, but no formal definition of the method of capturing the list is actually provided by the process. The view OG1 identified in the safety framework requires the stakeholders to textually document the overview of the system. This overview should include the establishment of the maintenance and equipment lists. Thus a linkage between +PFW and the safety framework can be established here.

The safety framework highlighted the need to include traceability on the decisions made in the implementation process and the assumptions that underpin these decisions. +PFW does indicate that the context of the system operation is a key issue in the successful implementation and operation of a safety document management system but there is no requirement to document the decisions taken and the assumptions made during the decision making process. +PFW clearly states that a maintenance list and its associated equipment lists are pre-requisites to the successful completion of the process. However, both the maintenance and equipment lists are dynamic living documents. They are not static and must be reviewed on a regular basis. This review can be performed appropriately using +PFW. Thus +PFW would be enhanced if the elements of traceability evident in the safety framework were applied to the process, in this case using OG1.

The context of a maintenance list is influenced by relevant legislation applicable to the client domain. The regulations involved may be internal or external but they must be included when any decision is being made about a maintenance list and its contents. The safety framework addresses issues about legislation using the Safety Regulations viewpoints but once again +PFW is not explicit about the need to include these aspects. Rather it assumes that the individuals charged with preparing the maintenance list will be aware of these requirements and create the list based on this knowledge and experience. This is another potential weakness in +PFW that can be addressed if the safety framework is incorporated. Using the views SG1, SG2, SG3 and SG4 within the safety framework identifies the need to establish the legislative elements using safety cases, the intent specification and soft goals to express these requirements. Each of these elements of the framework allows the reasoning behind the inclusion of a requirement to be established, the intention behind their inclusion and the ultimate goal of the requirement to be identified. Although the concept behind +PFW is quite simplistic, that is to achieve an effective implement of a PFW system, it is important that sight of the ultimate goal of achieving safety is not lost. Using the safety views outlined in the safety framework when developing the maintenance list in the +PFW process will ultimately enhance the process because all of the legislation required will be identified and the context and goals needed will also be established and available for review.

Thus views indicated by OG1, SG1, SG2, SG3 and SG4 within the safety framework allow the first two stages of +PFW to be fully documented providing the correct context and understanding of the rationale behind the decision to either include or exclude an element from the maintenance list.

5.2. Linkage of Roles in +PFW to the Safety Framework

Roles are crucial to the successful implementation and operation of a safety document management system. Without each user understanding and applying their role conscientiously the safety of individuals operating the system may be compromised. +PFW expressly identifies the need to establish the roles associated with the PFW system and its operation. However, it does not indicate how these roles can be established, rather it states simply that they are required. If +PFW is used in isolation to implement a PFW system this key component may not be fully developed and the safety of others could be jeopardised.

The safety framework utilizes use cases and class diagrams to identify the roles evident in a system and if +PFW is used as a standalone system then these items need to be included in its operation otherwise the correct roles and their associated responsibilities may be incorrectly or inappropriately interpreted and applied. Even though +PFW identifies a specific requirement it does not identify a suitable method of establishing this requirement. This stage of the process can be used to identify the readiness or otherwise of a client to operate the solution successfully but there needs to be some method of documenting this. The roles aspects of the requirement elicitation process are dealt with by the safety framework using views OG3 to OG5. The framework suggests a variety of industry standard methods to document these views and establish the roles of individuals and groups to achieve these responsibilities. +PFW is lacking in this level of detail stating merely that it is a requirement to establish the roles and responsibilities without indicating how this could be achieved. Combining the process and the safety framework using the Operational Views OG3 to OG5 allows a much more complete development of the requirement to identify the roles. Thus once again +PFW could be enhanced by the application of the safety framework.

5.3. Including the Safety Framework in +PFW

It is clear from the discussion in the previous sections that although +PFW does address the requirements of implementing and operating a PFW system successfully it does not deal with the entire establishment needs for such an implementation by inexperienced users. In order to improve this, the process elements of the safety framework are required in order to assist the understanding and development of these requirements. Figure 3 and Figure 4 demonstrate how the process is improved by introducing appropriate elements from the safety framework.

Now, these V models shown in Figure 3 and Figure 4 can be combined into a single model to represent the overall process resulting in Figure 5. This therefore shows how the process has been modified to reflect the elements required for enhancement using the appropriate elements from the safety framework.

6. Conclusions

The safety framework, as originally proposed, is capable of producing an accurate model of a system even one utilising a PFW system, provided the stakeholders have a clear and unambiguous understanding of all the proc esses and procedures involved. It provides all the required views to establish an appropriate representation of the required system. However, the introduction of a process enhances the safety framework of a PFW system if inexperienced users are involved in the establishment of the system requirements. This has resulted in the enhanced form of the safety framework which includes +PFW in the appropriate views. Therefore, when the framework is now applied to any system the issues associated with a PFW element are clearly identified. If no PFW system is required then the +PFW method can be discounted.

Conversely, +PFW is a useful approach in the implementation and operation of a PFW system. It identifies the requirements to successfully complete the process of implementing the chosen system and allows it to be operated effectively and safely. Where it fails is in its use, is when it is used as a standalone process. If it is not associated with the safety framework, it is not obvious how the maintenance and equipment lists, the roles required and their responsibilities, are established. These are key elements which must be included. The linkage between +PFW and the safety framework improves the effectiveness of the process and as a result the enhanced +PFW is more effective in providing the required output.

7. References

[1] D. D. Black, “Management of Safety—A Systems Engineering Approach,” Ph.D. Thesis, University of Ulster, Belfast, 2008.

[2] Health and Safety Executive, “Permit-to-Work Systems (IND(G) 98),” 3rd Edition, HSE Books, London, 1997.

[3] Health and Safety Executive, “Essentials of Health and Safety at Work,” HSE Books, London, 2006.

[4] Noble Denton Associates, “ROGS: The Railways and Other Guided Transport Systems (Safety) Regulations 2006–A Guide to ROGS,” July 2009. http://www.rail-reg. gov.uk

[5] P. G. Bishop and R. E. Bloomfield, “The SHIP Safety Case Approach,” Proceedings of International Conference on Computer Safety, Reliability and Security (SAFECOMP’95), Belgirate, 1995, pp 437-445.

[6] N. G. Leveson, “Safeware System Safety and Computers,” Addison-Wesley, White Plains, 2001.

[7] D. Attwood, F. Kahn and B. Veitch, “Occupational Accident Models–Where have We been and Where are We Going?” Journal of Loss Prevention in the Process Industries, Vol. 19, No. 6, 2006, pp. 664-682.

[8] M. E. C. Hull, K. Jackson and A. J. J. Dick, “Requirements Engineering,” 2nd Edition, Springer, Heidelberg, 2005.

[9] Health and Safety Executive, “Guidance on Permit-toWork Systems: A Guide for the Petroleum, Chemical and Allied Industries,” HSE Books, London, 2005.

[10] International Association of Oil & Gas Producers, “Guidelines on Permit to Work (PTW) Systems,” Report No. 6.29/189, January 1993, pp. 1-30.

[11] D. D. Black, M. E. C. Hull and K. Jackson, “+PFW–A Process for System Safety,” 2009, unpublished.

[12] UK Statute Law Database, “Health and Safety at Work (Northern Ireland) Order 1978,” No. 1039(NI9), July 1978, pp. 1-10.

[13] D. D. Black, M. E. C. Hull and K. Jackson, “Systems Engineering and Safety–A Framework,” 2009, unpublished.

[14] A. Mengolini and L. Debarberis, “Safety Culture Enhancement through Implementation of IAKA Guidelines,” Journal of Reliability and Systems Safety, Vol. 92, No. 4, 2007, pp. 520-529.

[15] R. Crook, D. Ince and B. Nuseibeh, “On Modelling Access Policies: Relating Roles to their Organisational Context,” Proceedings of 13th IEEE International Conference on Requirements Engineering, 2005, pp. 157-166.

[16] C. Lowe, “A Human Factors Perspective on Safety Management Systems,” Improvements in System Safety, Springer, Heidelberg, 2008.