150 likes | 373 Views
Regulatory Documents - Canada. Policy DocumentsP-119 Policy on Human FactorsGuidance DocumentsG-276 Human Factors Engineering Program PlansG-278 Human Factors Verification and Validation Plans. Other Programmatic Documents. NUREG-0711 (US NRC)
E N D
1. Human Factors Integration Considerations in Technical Upgrades
October 2007 Good Morning. My name is Kira Berntson, and I am one of the site Human Factors Specialists at Bruce Power. Bruce Power has developed an overall Human Factors program that applies site-wide. It helps us determine what level of human factors effort we need to apply to changes, and what types of analysis, review and considerations are necessary. One of the major considerations is how changes will be implemented, and that is the topic of this presentation. Some of the information presented as background may be very basic to some of you present, but since I am not sure how familiar everyone is with CANDU or the Canadian regulatory system, I will be giving some back ground. As a note, I will be giving general Bruce Power examples, but the HF and the designs will not necessarily be mine. So if you have specific questions about the design, I may not be able to answer.Good Morning. My name is Kira Berntson, and I am one of the site Human Factors Specialists at Bruce Power. Bruce Power has developed an overall Human Factors program that applies site-wide. It helps us determine what level of human factors effort we need to apply to changes, and what types of analysis, review and considerations are necessary. One of the major considerations is how changes will be implemented, and that is the topic of this presentation. Some of the information presented as background may be very basic to some of you present, but since I am not sure how familiar everyone is with CANDU or the Canadian regulatory system, I will be giving some back ground. As a note, I will be giving general Bruce Power examples, but the HF and the designs will not necessarily be mine. So if you have specific questions about the design, I may not be able to answer.
2. Regulatory Documents - Canada Policy Documents
P-119 Policy on Human Factors
Guidance Documents
G-276 Human Factors Engineering Program Plans
G-278 Human Factors Verification and Validation Plans The regulatory body in Canada is the Canadian Nuclear Safety Commission, or CNSC. They currently have three documents issued specific to Human Factors. Their policy document is P-119, which basically states the CNSC will take human factors into account in their reviews where it can impact on the protection of the environment, human health and safety, maintenance of national security or impact on Canada’s international obligations. In addition, the CNSC will evaluate the planning and implementation of measures to address human factors by the licensee, and provide guidance on how to address HF when needed. This document also contains a statement of intent to cooperate with other agencies to foster consistent human factors Standards.
They also have two guidance documents, one for human factors plans generally, and on specifically for verification and validation plans. G-276 outlines the type of information that human factors plans should contain, including the goals and scope of the plan, any relevant background or history for the project or activity, and criteria for determining what aspects of a project will receive HF review and how much review they will receive. Additionally, the plan needs to contain information on human factors inputs, such as roles and responsibilities, the technical considerations, such as the basis documents and intended tools and methods, and the general processes, such as timelines, communication and handling HF issues and discrepancies. G-278 outlines expectations regarding verification and validation plans and their contents. Verification and validation plans, if written in support of a general HF plan, should contain the basis and objectives of the plan, the methods and scope of verification, and the methods and scope of validation, including acceptance criteria. Both of these documents define human factors as relating to “all phases, including design, construction, commissioning, operation, maintenance, and decommissioning.”The regulatory body in Canada is the Canadian Nuclear Safety Commission, or CNSC. They currently have three documents issued specific to Human Factors. Their policy document is P-119, which basically states the CNSC will take human factors into account in their reviews where it can impact on the protection of the environment, human health and safety, maintenance of national security or impact on Canada’s international obligations. In addition, the CNSC will evaluate the planning and implementation of measures to address human factors by the licensee, and provide guidance on how to address HF when needed. This document also contains a statement of intent to cooperate with other agencies to foster consistent human factors Standards.
They also have two guidance documents, one for human factors plans generally, and on specifically for verification and validation plans. G-276 outlines the type of information that human factors plans should contain, including the goals and scope of the plan, any relevant background or history for the project or activity, and criteria for determining what aspects of a project will receive HF review and how much review they will receive. Additionally, the plan needs to contain information on human factors inputs, such as roles and responsibilities, the technical considerations, such as the basis documents and intended tools and methods, and the general processes, such as timelines, communication and handling HF issues and discrepancies. G-278 outlines expectations regarding verification and validation plans and their contents. Verification and validation plans, if written in support of a general HF plan, should contain the basis and objectives of the plan, the methods and scope of verification, and the methods and scope of validation, including acceptance criteria. Both of these documents define human factors as relating to “all phases, including design, construction, commissioning, operation, maintenance, and decommissioning.”
3. Other Programmatic Documents NUREG-0711 (US NRC) – Human Factors Engineering Program Review Model.
IEEE 1023 - Recommended Practice for the Application of Human Factors Engineering to Systems, Equipment and Facilities.
EPRI NP-3659 – Human Factors Guide for Nuclear Power Plant Control Room Development.
COG 92-444 - A Guide for the Development of Project Specific Human Factors Engineering Program Plans Beyond the policy and guidance documents provided by Canada’s regulator, Bruce power has drawn on other documents when developing our Human Factors program. Two documents that include consideration for design changes in existing plants are NUREG- 0711 and IEEE 1023. The NRC’s NUREG-0711 outlines the expected steps of a human factors review, broken down into 12 elements. These elements are grouped into the four categories of planning and analysis, design, verification and validation, and implementation and operation. The most current revision of this document specifically references design implementation as the eleventh element that would be expected in an appropriate human factors review. IEEE-1023 is a less prescriptive documents, outlining important considerations when performing HF work, including task considerations, environmental considerations, equipment considerations, personnel considerations and organizational considerations, and general methods for HF implementation. Like the CNSC documents, 1023 recommended considering the entire design lifecycle. In it’s discussion of human factors implementation, 1023 also has a specific section discussing implementation, which recommends testing and evaluation activities to ensure that the implementation will be acceptable. Other programmatic guidance documents also exist, including EPRI 3659 and the CANDU Owner’s Group document COG 92-444. Many of these tend to focus largely on new design development, but they contain information on human factors techniques that can be used to resolve the issues that can arise when installing newer technologies into existing plants or control centers.Beyond the policy and guidance documents provided by Canada’s regulator, Bruce power has drawn on other documents when developing our Human Factors program. Two documents that include consideration for design changes in existing plants are NUREG- 0711 and IEEE 1023. The NRC’s NUREG-0711 outlines the expected steps of a human factors review, broken down into 12 elements. These elements are grouped into the four categories of planning and analysis, design, verification and validation, and implementation and operation. The most current revision of this document specifically references design implementation as the eleventh element that would be expected in an appropriate human factors review. IEEE-1023 is a less prescriptive documents, outlining important considerations when performing HF work, including task considerations, environmental considerations, equipment considerations, personnel considerations and organizational considerations, and general methods for HF implementation. Like the CNSC documents, 1023 recommended considering the entire design lifecycle. In it’s discussion of human factors implementation, 1023 also has a specific section discussing implementation, which recommends testing and evaluation activities to ensure that the implementation will be acceptable. Other programmatic guidance documents also exist, including EPRI 3659 and the CANDU Owner’s Group document COG 92-444. Many of these tend to focus largely on new design development, but they contain information on human factors techniques that can be used to resolve the issues that can arise when installing newer technologies into existing plants or control centers.
4. Implementation Consideration One modification, or spread over time?
Leave existing equipment in place?
How much new functionality to implement?
How similar to existing equipment?
Dealing with multi-Unit control rooms
Some of those considerations are listed on this slide. These issues won’t be driven completely by human factors of course, as issues like availability of resources, technological limitations, and other factors can constrain how the final design will be implemented.
You have to consider whether a design should be one single modification, or whether it is better to implement it gradually over time. This can be particularly important for large scale changes, such as changing out all of the controllers in a unit. However, it should also be considered for smaller scale changes. When you are replacing one type of equipment with another you also have to consider how you will handle the transition in terms of what equipment the operator can see and use. Will you leave the existing equipment in place for a time, or take it out as soon as the new equipment is in? Will you leave the original equipment functional for a time? Will you activate the new equipment immediately, or wait? These are all key considerations in implementation.
When dealing with new technologies, which typically are a lot more functional and flexible than existing technologies, there are other considerations as well. A person needs to consider whether they want to take advantage of all the new functionality of the equipment or interface, or should it be limited. Is it more important to try to make the interface similar to the existing equipment for familiarity, or is it better to make it as different as possible to prevent confusion.
In CANDUs, where we often have multi-Unit control rooms, we also need to consider how the implementation will be scheduled on the various units, and what the impact will be of differences in control room configuration.Some of those considerations are listed on this slide. These issues won’t be driven completely by human factors of course, as issues like availability of resources, technological limitations, and other factors can constrain how the final design will be implemented.
You have to consider whether a design should be one single modification, or whether it is better to implement it gradually over time. This can be particularly important for large scale changes, such as changing out all of the controllers in a unit. However, it should also be considered for smaller scale changes. When you are replacing one type of equipment with another you also have to consider how you will handle the transition in terms of what equipment the operator can see and use. Will you leave the existing equipment in place for a time, or take it out as soon as the new equipment is in? Will you leave the original equipment functional for a time? Will you activate the new equipment immediately, or wait? These are all key considerations in implementation.
When dealing with new technologies, which typically are a lot more functional and flexible than existing technologies, there are other considerations as well. A person needs to consider whether they want to take advantage of all the new functionality of the equipment or interface, or should it be limited. Is it more important to try to make the interface similar to the existing equipment for familiarity, or is it better to make it as different as possible to prevent confusion.
In CANDUs, where we often have multi-Unit control rooms, we also need to consider how the implementation will be scheduled on the various units, and what the impact will be of differences in control room configuration.
5. One Mod or Over Time The size and impact of the overall modifications
Training/Relearning
Resources available to review and implement
Technological limitations (e.g. how much can be done at once) Looking at the consideration for whether to implement all at once or over time, there are a few issues that will feed into this decision. A large change done all at once could be overwhelming to the users, providing them with more new processes and information than they are able to deal with in a short time. On the other hand, the change mentioned earlier, where all of a certain type of controller were being replaced might be huge, but not so overwhelming, since all the new controllers work in a similar manner to one another. When considering training, there are two possible issues. Implementing too much change at once may overwhelm the users. On the other hand, implementing the change in too many stages can also result in a drain on users while they have to keep learning and relearning the systems.
Resources and technology will also be an issue. If you want to change 25 controllers, but you only have 15 new controllers available, or only a single engineer to prepare the designs, then how many can be installed will be limited by those resources. Additionally, if work needs to be performed during an outage with a limited window, or if step B requires step A to be installed and functional first, then this will impact on how the design is implemented.Looking at the consideration for whether to implement all at once or over time, there are a few issues that will feed into this decision. A large change done all at once could be overwhelming to the users, providing them with more new processes and information than they are able to deal with in a short time. On the other hand, the change mentioned earlier, where all of a certain type of controller were being replaced might be huge, but not so overwhelming, since all the new controllers work in a similar manner to one another. When considering training, there are two possible issues. Implementing too much change at once may overwhelm the users. On the other hand, implementing the change in too many stages can also result in a drain on users while they have to keep learning and relearning the systems.
Resources and technology will also be an issue. If you want to change 25 controllers, but you only have 15 new controllers available, or only a single engineer to prepare the designs, then how many can be installed will be limited by those resources. Additionally, if work needs to be performed during an outage with a limited window, or if step B requires step A to be installed and functional first, then this will impact on how the design is implemented.
6. Leave equipment in place Is old equipment desirable as back up
Will two sets of controls cause confusion
What equipment should be functional when?
What is the worst that can happen if contaminated logic causes an unexpected response?
How much space is available for controls/displays? When looking at existing and new equipment, what should be left in place and what should be removed? If old equipment is left in place, what equipment should be active, and what should be only a visual aid. The kinds of questions to ask when making these decisions are outlined on this slide. If the system requires high reliability, or if the users have doubts about the reliability of the new equipment, then old equipment can be left in place to increase reliability or perceived reliability and acceptance. An example of this would be adding a computer interface while leaving the old panel controls or indications in place. A Bruce Power example of this is discussed later in this presentation. On the other hand, the presence of two sets of controls could cause confusion, particularly if the controls are to be used in a stressful situation. If one set is disabled, how will you indicate which one works. More important, what is the worst possible result of problems with the logic that determines which control will actually have control. If the operator selects a different control than anticipated and gets an unexpected response, what are the worst consequences to the plant. Of course, all of this is a moot point if the panels or areas in question have only a small amount of space available. In the example of replacing the controllers, the control room panels were fairly limited in space. Therefore a transition period with two controllers in place would not have been an option, even if it had been determined to be desirable.When looking at existing and new equipment, what should be left in place and what should be removed? If old equipment is left in place, what equipment should be active, and what should be only a visual aid. The kinds of questions to ask when making these decisions are outlined on this slide. If the system requires high reliability, or if the users have doubts about the reliability of the new equipment, then old equipment can be left in place to increase reliability or perceived reliability and acceptance. An example of this would be adding a computer interface while leaving the old panel controls or indications in place. A Bruce Power example of this is discussed later in this presentation. On the other hand, the presence of two sets of controls could cause confusion, particularly if the controls are to be used in a stressful situation. If one set is disabled, how will you indicate which one works. More important, what is the worst possible result of problems with the logic that determines which control will actually have control. If the operator selects a different control than anticipated and gets an unexpected response, what are the worst consequences to the plant. Of course, all of this is a moot point if the panels or areas in question have only a small amount of space available. In the example of replacing the controllers, the control room panels were fairly limited in space. Therefore a transition period with two controllers in place would not have been an option, even if it had been determined to be desirable.
7. How much new functionality to Implement Many modern systems have greatly increased functionality compared to systems in place
Strong temptation to take advantage of all the new abilities
Too much or inappropriate functionality can increase opportunity for error The abilities of digital systems and computerized interfaces have come a long way since many plants were built. Modern systems have a lot more functionality available. While before a panel might be able to tell you a general location of a problem in the field, and you had to send people out for more information, systems can now feed into computer interfaces that could, in theory, tell you where the problem was, bring up live video of the area for further diagnosis, and coordinate the response. When this ability is available, there is a strong temptations to take advantage of it. After all, giving the operators, maintainers or other user more information and letting them do more with it can only improve their ability, right? But of course, that isn’t always true, and sometimes we set people up for failure by giving them more information than they need, and leading them down the completely wrong path.The abilities of digital systems and computerized interfaces have come a long way since many plants were built. Modern systems have a lot more functionality available. While before a panel might be able to tell you a general location of a problem in the field, and you had to send people out for more information, systems can now feed into computer interfaces that could, in theory, tell you where the problem was, bring up live video of the area for further diagnosis, and coordinate the response. When this ability is available, there is a strong temptations to take advantage of it. After all, giving the operators, maintainers or other user more information and letting them do more with it can only improve their ability, right? But of course, that isn’t always true, and sometimes we set people up for failure by giving them more information than they need, and leading them down the completely wrong path.
8. Functionality Example