C. Parente (HL-LHC Technical Quality Officer) Date:

Click here to add footer 2 C. Parente (HL-LHC Technical Quality Officer) Contents Documentation management Specifications process Specifications template General approach Contents, inputs & outputs

Click here to add footer 3 C. Parente (HL-LHC Technical Quality Officer) Preparation of functional/engineering specifications for HL-LHC

Click here to add footer 4 C. Parente (HL-LHC Technical Quality Officer) Documentation types Baseline documentation: Documentation that will have to be stored and updated until the dismantling of the LHC and that is under configuration control  related to “configured items”, i.e., entities within a given system architecture that are also under configuration control (ref.: LHC-PM-QA-304) Non-baseline documentation: Documentation that are required for the well functioning of the project but which storage will not be considered critical after the commissioning phase. HL-LHC is an upgrade of LHC and therefore all documents will be stored and managed according to the LHC procedures: LHC-PM-QA-202: Document types and naming conventions LHC-PM-QA-303: Documents and parameters process and control LHC-PM-QA-305: Drawing and 3D model management and control LHC-PM-QA-304: Configuration management – Change process and control

Click here to add footer 5 C. Parente (HL-LHC Technical Quality Officer) Baseline documentation (1/2) From system requirements to technical solutions and products EDMS # Project management Acquisition Technical Safety

Click here to add footer 6 C. Parente (HL-LHC Technical Quality Officer) Baseline documentation (2/2) Safety File Links to already existing documentation will be made, whenever required EDMS # Project management Acquisition Technical Safety

Click here to add footer 7 C. Parente (HL-LHC Technical Quality Officer) Documentation storage EDMS/CDD* *CDD for drawings (& 3D models) MTF

Click here to add footer 8 C. Parente (HL-LHC Technical Quality Officer) EDMS documents storage Baseline documentation Non-baseline documentation Image in the HL-LHC Project Documentation Create documents in context: HL-LHC-WP: High Luminosity LHC Workpackages EDMS training to all WPL/WPE

Click here to add footer 9 C. Parente (HL-LHC Technical Quality Officer) Use appropriate templates TemplateEDMS # Functional/engineering specifications Interface specifications Procedures Reports (except non-conformity reports) Non conformity Report Engineering Change Requests Minutes of meetings Other (general purpose)

Click here to add footer 10 C. Parente (HL-LHC Technical Quality Officer) Define document reference naming BaselineNon-Baseline LHC naming portal & WP systems architectures According to LHC-PM-QA-202 Controlled number (based on last used) Idem to baseline Mandatory Not mandatory

Click here to add footer 11 C. Parente (HL-LHC Technical Quality Officer) CDD - Drawings/3D models Associated to each equipment code (for the entities identified in the system architecture) Example (QQS folder)

Click here to add footer 12 C. Parente (HL-LHC Technical Quality Officer) MTF Fabrication and installation processes workflow (quality assurance and quality controls) Example: LQASA

Click here to add footer 13 C. Parente (HL-LHC Technical Quality Officer) Preparation of functional/engineering specifications for HL-LHC

Click here to add footer 14 C. Parente (HL-LHC Technical Quality Officer) HL-LHC life-cycle processes overview Ref.: EDMS #

Click here to add footer 15 C. Parente (HL-LHC Technical Quality Officer) Specifications process Systems requirements & verification criteria Conceptual specifications Functional specifications Engineering specifications Lower-level entities requirements & verification criteria Systems architecture & interfaces Acquisition strategy Specifications tree Interface specifications FS/ES template Selection of technical standards Definition of QA & QC processes Technical risks assessment (reliability, maintainability) Design Concept Preliminary Detailed Launch Safety Agreement (LSA)

Click here to add footer 16 C. Parente (HL-LHC Technical Quality Officer) Differences between Functional and Engineering specifications Functional (“Performance”, “Design-to”) required results and the criteria for verifying compliance States the requirements in terms of the required results and the criteria for verifying compliance, without specifically stating how the results are to be achieved Describes the functional requirements for an item, its capabilities, the environment in which it must operate, and any interface, interoperability, or compatibility requirements Engineering (“Detail”, “Build-to-print”) preconceived solutions to requirements and describes exactly how an item is to be produced Provides preconceived solutions to requirements and describes exactly how an item is to be produced. Identifies materials to be used, specific parts and components, and how the item is to be fabricated and assembled Functional specifications are used during the systems development and mix of functional and engineering specifications preliminary design while engineering specifications are produced in the detailed design phase although in they are usually a mix of functional and engineering specifications

Click here to add footer 17 C. Parente (HL-LHC Technical Quality Officer) Preparation of functional/engineering specifications for HL-LHC

Click here to add footer 18 C. Parente (HL-LHC Technical Quality Officer) Specifications template

Click here to add footer 19 C. Parente (HL-LHC Technical Quality Officer) General overview Requirements definition (conceptual specifications) Functional specifications Engineering specifications In-kind/In-house construction Discussed with the QMC Introduction Scope of supply Technical requirements & Verification Applicable documents Documentation Performance of the Contract Annexes CERN contact persons From existing MS/IT template From FS/ES template Main contents of MS/IT template Industrial procurement

Click here to add footer 20 C. Parente (HL-LHC Technical Quality Officer) Acquisition process Acquisition In-kind/in-house construction Industrial procurement Internal/Collaboration Agreement MS/IT/DO specification Contract or InputsOutputs List of specification committee HL-LHC members Functional specification Engineering specification SCR SCR: Specification Committee Review Procurement templates Acquisition strategy

Click here to add footer 21 C. Parente (HL-LHC Technical Quality Officer) Fundamental aspects The approach to the specifications template is based on: 1. Identification of the “entities” falling under the scope of the specification, and their architecture 2. Identification of the processes through which each “entity” is obtained 3. Specification of requirements entity by entity, in a bottom-up sense (grouping the entities requirements is possible whenever they are identical

Click here to add footer 22 C. Parente (HL-LHC Technical Quality Officer) Entity architecture HL-LHC System #1 Sub-system #1.1 Equipment #1.1.1 Assembly #1.1.1 Part # Component # Component # Component # Part # Assembly #1.1.2 Equipment #1.1.2 Sub-system #1.2 Equipment #1.2.1 System #2(…)System #N Example: entities falling under the scope of a specification

Click here to add footer 23 C. Parente (HL-LHC Technical Quality Officer) Example Crab Cavities Cryomodule (SPS) WP4 Crab cavities (ACF) SPS prototype (ACF) Cryomodule (ACFGA) Vacuum vessel (ACFVT) External supports (HACF) Cryostat components (ACFAC) Cryogenic circuits Supports Thermal shield Warm magnetic shield Dressed cavities (ACFDC) Bare cavities with interfaces (ACFCA) Tuning system (ACFTU) Helium vessel (ACFHT) HOM couplers (ACFHC) Cold magnetic shield Instrumentation (ACFIS) Main coupler (ACFMC) Vacuum valves (VVG) RF services (ACFSV) LLRF & Fast Controls (ALL) RF racks (AY) Slow controls (AS) Transmission lines (ACFWG) Pick-ups (APW)

Click here to add footer 24 C. Parente (HL-LHC Technical Quality Officer) Process(es) # Materials Machines/Equipment/Tools Methods/Procedures Training/qualifications Verifications/Tests Environment Component # Component # Process(es) # Component # Part # Process(es) #1.1.1 Part # Assembly # Materials Machines/Equipment/Tools Methods/Procedures Training/qualifications Verifications/Tests Environment Materials Machines/Equipment/Tools Methods/Procedures Training/qualifications Verifications/Tests Environment Processes Processes through which the entities are obtained (e.g., design, manufacture, installation,….)

Click here to add footer 25 C. Parente (HL-LHC Technical Quality Officer) Example To obtain the required “entities”, or products, previously identified Design Shaping & machining EB Welding Cleaning Vacuum Brazing Manufacturing (…) RF expected performance tests Leak tightness tests Packaging & shipping Finalization of manufacturing process Dimensional checks Delivery Simplified processes for bare cavities (with interfaces) Chemical polishing (…)

Click here to add footer 26 C. Parente (HL-LHC Technical Quality Officer) Specifications template

Click here to add footer 27 C. Parente (HL-LHC Technical Quality Officer) Main contents Scope Scope Description Life-cycle overview Identification on the HL-LHC system architecture Processes identification on the HL-LHC system life-cycle Applicable documents Applicable documents Technical requirements for [Entity #1] Technical requirements for [Entity #1] Description Materials Physical characteristics Operational modes and states Reliability Maintainability Inspectability Availability Dismountability Interfaces Environmental conditions Design Manufacturing Delivery Installation Logistics Disposal Any other requirements… Verification of [Entity #1] Verification of [Entity #1] (…) Technical requirements for [Entity #N] Technical requirements for [Entity #N] (…) Verification of [Entity #N] Verification of [Entity #N] Documentation Documentation Appendix(es) Appendix(es) Qualitative assessment (supported by TQO) Processes definition (supported by TQO) EDMS # Flexibility: Sections can be added if needed or removed (when not applicable) Re-adjustment of structure (grouped requirements for entities in each section) whenever requirements are identical Completed by Interface specifications

Click here to add footer 28 C. Parente (HL-LHC Technical Quality Officer) Hazards assessment Per individual entities or, Per entity life-cycle Example: Dismantling (old) Construction (design, manufacture) Installation Operation/Maintenance/Interventions Dismantling (new) Optimization will be made whenever hazards are identical EDMS # Required to obtain Launch Safety Agreement Launch Safety Agreement from HSE Unit Contact person  PSO: Th. Otto

Click here to add footer 29 C. Parente (HL-LHC Technical Quality Officer) Specifications process Systems requirements & verification criteria Conceptual specifications Functional specifications Engineering specifications Lower-level entities requirements & verification criteria Systems architecture & interfaces Acquisition strategy Specifications tree Interface specifications FS/ES template Selection of technical standards Definition of QA & QC processes Technical risks assessment (reliability, maintainability) Design Concept Preliminary Detailed Launch Safety Agreement (LSA)

Click here to add footer 30 C. Parente (HL-LHC Technical Quality Officer) Selection of technical standards EDMS # Maps of standards Maps of standards have been created based on LHC specified technical standards. Since LHC systems can be related with HL-LHC WPs, these maps can be used as a starting point for the identification of the applicable standards

Click here to add footer 31 C. Parente (HL-LHC Technical Quality Officer) Identification of technical standards Example Technical requirements Standards fields/groupsSelected standards EB weldingManufacturing engineering  Welding processes ASME BPVC Section IX PART- QW Visual examination of EB welds Manufacturing engineering  Welded joints ISO Pressure vesselFluid systems and components for general use  Pressure vessels ASME BPVC Niobium – Titanium transition pieces Metallurgy  Other products of non-ferrous metals ASTM B Global overview EDMS: To be discussed and validated by the project management

Click here to add footer 32 C. Parente (HL-LHC Technical Quality Officer) Quality assurance and quality controls (1/2) Quality assurance and quality controls needed to meet the requirements  input to MTF Quality control step  supported by validated technical standards An excel template exists but it has many limitations  a dedicated tool (ideally embedded in MTF) would be most advantageous

Click here to add footer 33 C. Parente (HL-LHC Technical Quality Officer) Quality assurance and quality controls (2/2) Quality assurance steps  supported by validated technical standards and/or by CERN best practices Other CERN best practices used to support the specification (examples): Niobium RRR Material Technical Specification N° 3300 Cleaning procedure for stainless steel components

Click here to add footer 34 C. Parente (HL-LHC Technical Quality Officer) Risk assessment Risk assessment allows to: Identify the equipment, or processes, which represent higher risks in a system life-cycle and how these risks can be eliminated or mitigated Definition and application of quality assurance procedures and quality control tests Identify training/qualification requirements Identify and perform measurements/studies Identify standardization needs Comply with CERN Safety rules Particularly important in case of new technologies and when technical standards for construction are not available

Click here to add footer 35 C. Parente (HL-LHC Technical Quality Officer) Reliability, Availability, Maintainability, Inspectability (RAMI) Engineering, fabrication, assembly, installation, verification and commissioning processes Technical standards Quality assurance and quality control Best practices Availability (A) Reliability (R) Probability of a system operating correctly over its assigned operational time Maintainability (M) Probability of returning a failed/degraded system to operation in a fixed time period, or average time to 100% repair Inspectability (I) Production time lost or gained due to test and inspection requirements Spare parts policy Environmental constraints –Radiation  Remote handling –Accessibility Regulations Best practices Technical risk assessment

Click here to add footer 36 C. Parente (HL-LHC Technical Quality Officer) Thank you for your attention! Questions? For any questions/support on the presented activities please contact TQO (C. Parente)

Click here to add footer 37 C. Parente (HL-LHC Technical Quality Officer) Preparation of functional/engineering specifications for HL-LHC

Click here to add footer 38 C. Parente (HL-LHC Technical Quality Officer) Systems architectures HL-LHC System #1 Sub-system #1.1 Equipment #1.1.1 Assembly #1.1.1 Part # Component # Component # Component # Part # Assembly #1.1.2 Equipment #1.1.2 Sub-system #1.2 Equipment #1.2.1 System #2(…)System #N SystemEDMS Accelerator Physics & Performance Magnets RF & Accelerating cavities Collimation Cold Powering Machine Protection Collider-Experiments Interface Cryogenics Energy Deposition & Absorber 11 T Dipoles Vacuum Beam Diagnostics & Instrumentation Beam Transfer & Kickers Integration & (De-)Installation Hardware Commissioning Infrastructure, Logistics & CE

Click here to add footer 39 C. Parente (HL-LHC Technical Quality Officer) Interface specifications External interfaces matrix 1. Identification 2. Definition 3. Requirements specification Can be used for external and/or internal interfaces EDMS #

Click here to add footer 40 C. Parente (HL-LHC Technical Quality Officer) Interfaces types Internal: within a given system External: between different systems A functional interface may exist without a physical interface. A physical interface implies always a functional interface. Temperature Pressure Mass-flow rate Alignment requirements (…) External Internal Physical Functional Magnets-Cryogenics Magnets

Click here to add footer 41 C. Parente (HL-LHC Technical Quality Officer) How to specify requirements? Criteria: Each requirement shall be stated in such a way that an objective verification can be defined for it. Each requirement should be cross-referenced to the associated verification. Only requirements that are necessary, measurable, achievable, and verifiable shall be included. Requirements shall be worded to provide a definitive basis for acceptance or rejection. Requirements shall be described in a manner to encourage competition. Requirements shall be worded such that each paragraph only addresses one requirement or topic. Degree of detail Degree of detail: include only requirements (i.e., characteristics) of the system, conditions for the entity acceptance sub-system,…, component that are conditions for the entity acceptance