1. ESHAC #8 Safety Readiness Review 2018-04-10 Thomas Hansson, ESH

2. Outline Safety Readiness Reviews (SRR) ESS reviews
Status and next steps
Preparations for SRR1

3. Safety Readiness Reviews
The purpose is to review readiness to safely commission/operate.
It is a process by which HARDWARE, PERSONNEL and PROCEDURES associated with commissioning/operation are verified.
The scope is safety, both conventional safety and ionizing radiation.
The ownership of the process lies within ESH division.
The scope of SRR1 (end of June 2018) is limited to
the Ion Source (IS) and
the Low Energy Beam Transport (LEBT)

4. ESS Reviews SRR Describes verification activities,
resources, associated requirements
prior to commissioning, after parts
have been built and installed.
Specifying “As-built”.
Reports the outcomes of
the verification activities.
Specifying “As-verified”.
FR, system Functional Review
PDR, system Preliminary Design Review
CDR, system Critical Design Review
FAT, system Factory Acceptance Test
SAT, system Site Acceptance Test
TRR, system Test Readiness Review
SAR, System Acceptance Review
ORR, system Operation Readiness Review
ESS

5. Status and next steps Activity
Appointment of SRR process owner (ESS ) August 2017
SRR process description (ESS ) January 2018
Description of needed documentation (ESS )* November 2017
Internal communication (AD Tech Board, Brightness session) November 2017
Scheduling of SRR1 for IS & LEBT Recently
Invitation to internal/external SRR team Next step Proposal with Members, Invitation letter, Charge & Agenda exists since February
Follow-up on progress of preparations Next step Documentation* to be distributed to SRR Committee Members 18th of June
Safety Readiness Review of IS & LEBT (1,5 day) Last week of June

6. Preparations for SRR1 (IS & LEBT)
Documentation needed prior to a SRR.
Possible to provide 1 concluding document with references.
Descriptions of expectations on the documentation is found in ESS
Design descriptions
purpose of the system
technical solution, derived from relevant requirements
Architecture description
the specific system, involved equipment and devices.
interfacing systems
appropriate pictures and schematics
Concept of Operations
scope of proposed testing.
operation modes of the system, including maintenance
needed operators, disciplines, training requirements
list of the specific individuals that are qualified to operate the system
Requirements Specification
Test envelope limitations and conditions
Hazard identification
Safety systems, belonging administrative procedures and their limits and conditions
Descriptions of the derived requirements for safety systems (engineered controls) together with a description of the administrative procedures (administrative controls) which should include both the perspective of prevention and mitigation.
required personal protective equipment.
procedures describing handling of deviation from the testing envelope
Interface descriptions
interfaces / boundaries (access control, ventilation, power supply, etc.)
Integration Plan
includes intermediate demonstrations (for instance for belonging supporting systems and/or safety systems) finally leading to test readiness of the specific system of interest.
can refer to already performed verification of required subsystems supporting systems and/or safety systems.
Operation and maintenance documents
allowed testing envelope from an operator point of view
specific operating and maintenance procedures
A list of the safety systems (engineered controls) together with alarm response procedures (administrative controls), that shall be available for the operators.
Verification Plan
detailed steps to be followed to verify a system meeting requirements
who
when and where
responsibilities of each participant
and the documents to be prepared as a record
consider validation plans, and even validation reports, from underlying subsystems.
Verification Report
Identifies the type of verification performed and reports on the results
also cover “Lessons learned” in order to share gained experience

7. Thank you!
Questions?

8. How do activities relate to each other?
Backup slide
How do activities relate to each other?
“Internal readiness” is owned by the System Owners and accomplished by:
lower level SAR and ORR for all concerned sub-systems (for instance “sub-system level” below)
the specific level of TRR (for instance “ESS level” below)
A SRR is
an independent review
of the safety aspects, after the corresponding TRR.

9. ESS Management System Expectations
Backup slide
ESS Management System Expectations
ESSMS expectation
SRR focus prior to commissioning
Comment
Design descriptions
Description of the purpose of the system and the technical solution.
Architecture description
Description of the system, involved equipment and devices.
Concept of Operations
Descriptions of operation modes including maintenance modes and need of operators, their disciplines and their training requirements.
Requirements Specification
Descriptions of operational limits and conditions for the specific testing envelope, belonging hazard identification together with the requirements for engineered controls and administrative controls (preventing and/or mitigating controls).
Interface descriptions
Interfaces and boundaries to the surrounding structures, systems and components, for instance access control, supporting systems, power supply, etc.
Integration Plan
The integration plan is expected already in connection to the CDR, and includes intermediate demonstrations finally leading to the main validation activity; commissioning.
Operation and maintenance documents
The specific operating and maintenance procedures including the allowed testing envelope, list of administrative and engineered controls together with emergency response procedures.
Verification Plan
Prior to any verification activity a test readiness review (TRR) will assess the maturity of the resources for supporting the verification activities for a system (test stand accessibility, test equipment readiness, availability of the personnel).
The System Verification Plan documents the detailed steps to be followed to verify and ensure that a product or system meets its specific list of requirements.
The verification plan defines: who does the verification; when and where it is to be done; the responsibilities of each participant before, during, and after each verification; the hardware and software to be used (and other systems if applicable); and the documents to be prepared as a record of the verification activity.
Could also consider validation plans, and even validation reports, from underlying subsystems.
Verification Report -
Identifies the type of verification performed and reports on the results of the verification activities.