1 / 6

Accelerator Interlock System Issues

Accelerator Interlock System Issues. Flow Down of Requirements from the Safety Order to Engineered Safety Systems Questions Explored What should and should not be in the ASO? What should and should not be in the Guidance? How can we make requirements traceable?

yuli-hays
Télécharger la présentation

Accelerator Interlock System Issues

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Accelerator Interlock System Issues • Flow Down of Requirements from the Safety Order to Engineered Safety Systems • Questions Explored • What should and should not be in the ASO? • What should and should not be in the Guidance? • How can we make requirements traceable? • Should there be predefined “levels of effectiveness” for certain engineered safety functions? • Overall working group felt the ASO did not need any changes. • One possible recommendation for the guide. • Many but not all laboratories have an interlocks policy document that is used to flow down requirements from the ASO for engineered safety systems. • Working group found this to be an effective mechanism to flow down requirements from the ASO and Guide for interlock system development. John Anderson

  2. Accelerator Interlock System Issues • Beam interlock system requirements implement some form of an independent design review requirement. • With technology advancements and interlock system complexity do we have adequate technical experts in house (within the laboratory) to perform reviews? • Third party outside consultants used by one laboratory also did not seem to be effective. Outside consultants lack sufficient accelerator knowledge to provide constructive feedback. • Most in the discussion felt that using interlock system experts from other labs was an effective peer review mechanism. • Overall the working group thought it would be beneficial to have accelerator specific examples for levels of effectiveness for certain engineered safety functions. • This would result in a more uniform definition of accelerator operational risks. • The working group felt this should be left as examples of levels of effectiveness and not requirements for levels of effectiveness. • This would allow various sites to set their own acceptable risk criteria. John Anderson

  3. Accelerator Interlock System Issues • “One Box” Safety Rated PLCs • Technology advancements have created single box safety rated PLCs. • Important to note that these components are typically certified by independent testing agencies such as Europe's TUV or the US Factory Mutual for requirements up to Safety Integrity Level (SIL) 3. • Discussed what needs to be done to get the radiation protection community to accept these one box solutions? • Hardware is now certified by the manufacturer. • No longer need to prove the hardware is safe for use. • Manufacturers provide this information. • One box solutions do not mean a non redundant architecture. • The issue is in the system availability numbers. • Safety rated PLC solutions in many cases have better availability performance than redundant two box solutions. John Anderson

  4. Accelerator Interlock System Issues • Software is now the driving issue for the community. • Use of two programmers writing separate safety functions to be installed in a single safety rated PLC. • Pair programming where two programmers write the safety function together. • Single programmer writes the program and a second programmer validates the safety functions and works to find any bugs in the code. • All three approaches have their own advantages and disadvantages. • Regardless of the programming model chosen, the working group felt that any approach needs to stress the importance of getting the specifications correct. • Second there needs to be some form of rigorous validation protocol to verify software functionality against the requirements. John Anderson

  5. Accelerator Interlock System Issues • Acceptable Software Assurance Practices • Discussed at length the ANSI/ISA 84.00.01-2004 Application software specification and development checklist. • Mainly looked at what sections of the standard the various laboratories have implemented. • Software QA working group provided a mapping of ANSI/ISA 84.00.01 to the10 elements of DOE G 414.1.4 • ANSI/ISA 84.00.01 Part 1 Clause 12 maps directly to of DOE G 414.1-4. elements 1 through 9 and Clause 5 to element 10. • Engineered Controls for other Accelerator Hazards – ODH, Electrical, Magnetic Fields, Lasers, … • The working group felt they should they follow the same requirements/lifecycle as radiation protection systems. • Since most of these hazards are covered by other standards, those standards should take precedence. John Anderson

  6. Accelerator Interlock System Issues • Recommendations • Pole the accelerator community for examples of “levels of effectiveness” used at their respective laboratories for engineered safety functions. • Develop a list of examples for use within the community. This could be included in the ASO guide, written into a technical standard, or best practices manual. • Capture best practices and consensus from the accelerator community for ASE identified software to create a uniform software specification and development guide. • Include in the ASO guide, written into a technical standard, or best practices manual that is consistent with DOE G 414.1-4. John Anderson

More Related