CERN-ACC-2023- 0002

[email protected]

Report
Assessing the Usefulness of Assurance Cases:
an Experience with the CERN Large Hadron Collider
• Chris Rees, Mateo Delgado, Rolf Lippelt, Jeff Joyce, Simon Diemert – Critical Systems Labs,
Vancouver, Canada
• Claudio Menghi – McMasters University, Hamilton, Canada
• Torin Viger, Marsha Chechik – University of Toronto, Toronto, Canada
• Jan Uythoven, Markus Zerlauth, Lukas Felsberger - CERN

Keywords:
CERN LHC
Systems Engineering
Risk Management
Free keywords:
Machine Protection System
Assurance Case

Abstract:

Assurance cases are structured arguments designed to show that a system functions properly in its operational
environment. They are mandated by safety standards and are largely used in the industrial domain; however, they are
typically proprietary and not publicly available. Therefore, the benefits of assurance case development are usually not
rigorously documented, measured, or assessed.
In this paper, we present an assurance case for the CERN Large Hadron Collider (LHC) Machine Protection System (MPS).
We relied on open-source documentation for its creation and used eliminative argumentation, a well-known methodology
for assurance case development. The development involved four authors with considerable experience in assurance case
development, three of whom work for Critical System Labs, a small enterprise specializing in assurance case development.
The process required approximately three months and led to an assurance case with 506 nodes. The results have been
validated with CERN experts.
Our experience shows that (a) the effort (cost and time) required to develop our assurance case is negligible compared to
the time needed to develop the system, (b) eliminative argumentation helped identify 10 defeaters not detailed in the
documentation we used for creation of the assurance case (and in general can identify correct defeaters with high precision
and recall). In the paper, describe our experience and discuss how the LHC assurance case helped accurately identify Key
Performance Indicators for the Machine Protection System.

Submitted to: Reliability Engineering & System Safety Journal

(Full paper uploaded after the submission)

Geneva, Switzerland
March, 2023
LHC Machine Protection System
Assurance Case
In collaboration with CERN, researchers at the University of
Toronto, McMaster University, and Critical Systems Labs have
developed a public demonstration of an ‘assurance case
argument’ (AC) for the Large Hadron Collider (LHC) Machine
Protection Systems (MPS).
A top-level claim about the MPS is supported by a structured
argument represented via Eliminative Augmentation (EA), a
variant of the well-known Goal Structuring Notation (GSN). EA
involves the explicit representation and reasoning about
potential doubts within the argument, in order to effectively
eliminate or address them.
This AC argument is made publicly available for researchers in
EA methodology and practitioners interested in applying AC
methods to large complex systems.
The entire argument consists of more than 500 “nodes” covering
four main components of the MPS, namely, the Beam Loss
Monitoring System (BLMS), the Beam Interlock System (BIS), the
Beam Dumping System (BDS), and the Safe Machine Parameters
(SMP) System.
A representation of the argument has been automatically
generated from the AC software and is displayed in the following
pages. Further, the basic structure of the argument can be seen
in the corresponding .CSV file, which was automatically
generated from the original .JSON format representation of the
argument.
Page 1 of 119
LHC MPS - Original EA
This file was generated by Socrates based on the argument at: https://cern.socrates.cslabs.com/arguments/7
Argument Created: 2022-06-27T16:32:41.000+00:00
Last Modified: 2023-03-03T20:15:13.000+00:00
Owner: Critical Systems Labs

Page 2 of 119
Argument
C0001 - The LHC Machine Protection System (MPS) protects against damage from potential beam losses, whilst avoiding unnecessary interruptions to exp...

Parent None Descendant C0009, C0010, C0011, C0061, IR0129, C0667, C0668
subtree(s) subtree(s)

Description The primary relationship between the BLMS, BIS and BDS is sequence of events in which (1) in response, the BLMS detects a dangerous beam loss and
communicates this condition to the BIS, (2) the BIS withdraws the beam permit which in turn (3) causes the BDS to dump the beam. Although not directly
involved in this sequence of events, the SMP provides critical parameter values that affects the actions of the BLMS, BIS and BDS. There are other relationships
between these components.
At present, they are excluded due to limitations of resources. The argument could be extended to include other aspects if so desired.
It should be noted that the LHC MPS is far more complex than the system considered here. All hardware that can potentially cause damage to the LHC (either via
the beam or by its own failure) is connected directly to the BIS. As a result, the BLMs are only a safety net (additional interlock) on top of the direct hardware
failure. It is only for beam instabilities (which are generally slow and losses distributed over the LHC) where we rely on the BLMs for stopping the beam.
The 'critical system components' of the LHC are defined as those that allow safe operation of the facility. No specific list is defined here, however from the
artifacts used in the EA, especially those that define the MPS, would allow a reader to gain an understanding of the whole system and the requirements to
protect it.
This 'unwarranted' beam dump could result due to incorrect unhealthy status from critical elements of the LHC, i.e. a "spurious beam dump" is simply a beam
dump that occurs when neither a beam dump was commanded by an operator nor a beam loss above the tolerable threshold existed (regardless of whether it
was detected or not).

Page 3 of 119
C0009 - The Beam Loss Monitoring System (BLMS) provides timely indications of an intolerable beam loss within the LHC.

Parent C0001 Descendant C0014, C0015, C0016, IR0110, C0119, C0200

subtree(s) subtree(s)

Description Note: the BLMS is only one of the systems that will help to protect the LHC against the occurrence of (intolerable) beam losses. Other equipment should send a
beam loss signal to the BIS, allowing the MPS to safely dispose of the beam before beam losses are even occurring. For these failure cases the BLMS is a
redundant system only, while for other failure cases it might well be the only system to detect them timely.
The tunnel installation consists of around 4000 detectors, placed at various locations around the ring, tunnel electronics, which are responsible for acquiring,
digitising, and transmitting the data. In the surface installation, electronics receive the data via 2km redundant optical data links, process, analyze, store, and
issue warning and abort triggers. The latter provide also the connections to the Beam Interlock, the Beam Energy Tracking, the Collimation, the Logging and the
Post Mortem systems.

Page 4 of 119
C0014 - The BLMS detectors are designed, located, operated, calibrated to ensure detection and signaling of any beam loss from the LHC.

Parent C0009 Descendant C0173, C0175, C0177, C0178, C0179, IR0181

subtree(s) subtree(s)

Description

Page 5 of 119
C0173 - The BLMS detectors are designed so that they can detect a loss of beam from the LHC.

Parent C0014 Descendant None

subtree(s) subtree(s)

Description Physical failures here relate to a loss of power etc. from potential sources such as an impact or external influence on the system. Operational failures relate to
the function of the detectors and their ability to record/detect potential beam losses.
No direct evidence has been found to support a tolerance for a loss of a single detector. However, it is likely that due to the number of detectors and level of
redundancy that CERN will have an operating threshold for detector availability.
No direct evidence has been found to support a tolerance for a loss of a single detector. However, it is likely that due to the number of detectors and level of
redundancy that CERN will have an operating threshold for detector availability.
See information on Beam Permit and requirements therein for LHC operations.
Note: the BLM sanity check is only performed at the start of each fill, but will not directly result in an active beam dump request during a fill. Hence a faulty BLM
detector might only be detected at the time of starting the next fill.
Note: that spurious detection of particles could result in an inability to detect a "true" beam loss.

Page 6 of 119
Page 7 of 119
C0175 - The BLMS detectors operate within a set of pre-determined energy values to detect beam losses from the LHC.

Parent C0014 Descendant None

subtree(s) subtree(s)

Description Note: each BLM has around 5-7 energy values, but also thresholds for 12 different integration windows from 40us - 83s.
If a parameter is incorrect or set to low then saturation of the detector could occur, with it being "blinded" to detecting
particles from the LHC.
Note: saturation will not result in damage of the detector, but will only result in the inability to quantify the exact loss
level tat has occurred for this monitor. The beam dump signal (as long as the threshold was correctly set) will be issued
correctly.
Note: there is no identified safety related failings from the saturation of the detector as it would still initiate a removal
of the beam permit. However, it would prevent the system from accurately monitoring any beam losses which is a
functional system requirement opposed to a safety requirement.
Note: see claims and defeaters related to SMP under C0291.
This evidence node is not to suggest that the CERN Large Hadron Collider (LHC) is safe simply because it has been in
operation for years (e.g., the infamous Nimrod safety case). But rather because many very good people have
exhaustively studied the many aspects of the CERN Machine Protection System (MPS) to ensure the system is safe, and
if a shutdown is required, it can be accomplished timely, accurately, and safely.

Page 8 of 119
Page 9 of 119
C0177 - The BLMS detectors are positioned at strategic locations around the LHC ring in order to detect potential beam loss.

Parent C0014 Descendant None

subtree(s) subtree(s)

Description Note: as per earlier comments/description on BLM detectors, the loss of a single detector shall not affect operations, as during a failure case multi detectors
would likely detect and report the loss of the beam.
An impact from a person and subsequent damage is not considered reasonably foreseeable due to this claim/operation procedure.

Page 10 of 119
Page 11 of 119
C0178 - The BLMS detectors are calibrated for detecting particles lost during a beam loss event from the LHC.

Parent C0014 Descendant None

subtree(s) subtree(s)

Description

Page 12 of 119
Page 13 of 119
C0179 - The BLMS detectors signal detections to the Tunnel Electronics.

Parent C0014 Descendant None

subtree(s) subtree(s)

Description No specific artifact or evidence was found to support this node. However, it is likely that CERN has suitable quality assurance (QA) procedures in place for
supplied detectors.
No specific artifact/evidence link has been identified here, however it is likely that suitable quality assurance (QA) checks are in place for supplied detectors.

Page 14 of 119
Page 15 of 119
IR0181 - If BLMS detectors are designed, positioned, calibrated and operated to pre-defined parameters, then they will successfully signal the Tunnel...

Parent C0014 Descendant None

subtree(s) subtree(s)

Description

Page 16 of 119
C0015 - The Tunnel Electronics are capable of receiving, processing and relaying detection count signals from the BLMS detectors to the Surface Elec...

Parent C0009 Descendant None

subtree(s) subtree(s)

Description

Page 17 of 119
C0016 - The BLMS Surface Electronics are operational, capable of receiving, processing and signaling a withdrawal of a user permit, upon beam loss, ...

Parent C0009 Descendant C0192, C0193, C0194, C0195, C0196, IR0275

subtree(s) subtree(s)

Description

Page 18 of 119
C0192 - The Surface Electronics will receive an accurate signal from the Tunnel Electronics via the optical fiber cables.

Parent C0016 Descendant None

subtree(s) subtree(s)

Description

Page 19 of 119
C0193 - The Surface Electronics are in receipt of a Beam Permit from the larger MPS which allows operation.

Parent C0016 Descendant None

subtree(s) subtree(s)

Description

Page 20 of 119
C0194 - The beam energy levels are specified by the larger LHC system/operations to ensure an accurate beam user permit.

Parent C0081, C0097, C0016 Descendant None

subtree(s) subtree(s)

Description This claim notes that the beam energy levels specified along with the results from the BLMS detectors ensure that the system has sufficient information to
withdraw it's permit and enable a dump signal.
Note: The SMP parameters sub-tree discusses inputs to the system and this should be reviewed as part of this argument.

Page 21 of 119
C0195 - The Surface FPGA will ensure that signals received, processed and enable the relay of a beam loss signal.

Parent C0016 Descendant None

subtree(s) subtree(s)

Description Note: critical users here refers to the bump dump signal via the BIC, and other data logging.
This evidence node is not to suggest that the CERN Large Hadron Collider (LHC) is safe simply because it has been in operation for years (e.g., the infamous
Nimrod safety case). But rather because many very good people have exhaustively studied the many aspects of the CERN Machine Protection System (MPS) to
ensure the system is safe, and if a shutdown is required, it can be accomplished timely, accurately, and safely.

Page 22 of 119
Page 23 of 119
C0196 - The Surface Electronics will provide or withdraw a user permit and enable a beam dump signal to the Beam Interlock Controller (BIC).

Parent C0016 Descendant None

subtree(s) subtree(s)

Description Note: There does not appear to be any independent control or monitoring. Left here as a residual risk, pending evidence of mitigation of potential failures to
signal correct beam dump based on energy levels.

Page 24 of 119
Page 25 of 119
IR0275 - If the Surface Electronics, including the inputs from the optical fibers, beam energy and permit, function as intended and are able to trans...

Parent C0016 Descendant None

subtree(s) subtree(s)

Description

Page 26 of 119
IR0110 - If claims about the BLMS detector, Tunnel Electronics, Surface Electronics, transmission and Optical Fibers are fully substantiated and the ...

Parent C0009 Descendant None

subtree(s) subtree(s)

Description

Page 27 of 119
C0119 - Fiber optical cables for transmission from the Tunnel electronics to Surface Electronics are robust and with adequate redundancy to ensure t...

Parent C0009 Descendant None

subtree(s) subtree(s)

Description See context node X0197 with regards definition of "robust". Noting that it refers to the suitable design of the cables.

Page 28 of 119
Page 29 of 119
C0200 - The BLMS shall process a beam loss signal within 300 ns, which includes transmission of a beam loss to the BIS signaling its withdrawal of i...

Parent C0009 Descendant None

subtree(s) subtree(s)

Description Note: the larger system here refers to the BIS, BDS and associated control systems.
"Operate" here refers to the whole BLMS, which covers everything from the beam loss monitors, processing of signals, ready for transmission to the larger MPS.
100% Testing of critical signals is a method used to test the response of the beam interlock system to changes of inputs and fail-safe procedures to extract the
beams if a critical signal is incorrect or missing.

Page 30 of 119
Page 31 of 119
C0010 - The Beam Interlock System (BIS) actively collects USER_PERMIT signals from User Systems in the LHC and produces BEAM_PERMIT statuses and dis...

Parent C0001 Descendant C0029, C0030

subtree(s) subtree(s)

Description

Page 32 of 119
C0029 - The BIS will withdraw the beam permit when intolerable beam loss is detected.

Parent C0010 Descendant C0023, C0024, C0025

subtree(s) subtree(s)

Description

Page 33 of 119
C0023 - The Beam Interlock Controllers (BIC) collects USER_SYSTEM signals for both Anti-Clockwise and Clockwise Beams from the Beam Loss Monitors in...

Parent C0029 Descendant None

subtree(s) subtree(s)

Description 100% Testing of critical signals is a method used to test the response of the beam interlock system to changes of inputs and fail-safe procedures to extract the
beams if a critical signal is incorrect or missing.

Page 34 of 119
Page 35 of 119
C0024 - The BICs generate FALSE BEAM_PERMIT statuses and transmit them throughout the Beam Permit Loops to the Beam Dumping System.

Parent C0029 Descendant None

subtree(s) subtree(s)

Description

Page 36 of 119
Page 37 of 119
C0025 - The BIS will withdraw the beam permit when any critical component of the LHC's Machine Protection System fails, including loss of redundancy...

Parent C0029 Descendant None

subtree(s) subtree(s)

Description

Page 38 of 119
C0030 - The BIS will transmit loss of the beam permit to the BDS in less than 100 microseconds.

Parent C0010 Descendant D0031, D0036, D0438, D0512

subtree(s) subtree(s)

Description

Page 39 of 119
D0031 - Unless the beam loop is damaged in a way that interferes with the transmission of the loss of the beam permit.

Parent C0030 Descendant None

subtree(s) subtree(s)

Description Any physical interruption/degradation of any fibre or component of the beam permit loop will result in the non-
reception of the 10 MHZ signal and hence a beam dump.

Page 40 of 119
D0036 - Unless transmission of the withdrawal of the beam permit is too slow. (i.e., not less than 100 microseconds)

Parent C0030 Descendant None

subtree(s) subtree(s)

Description Note: the transmission time is mainly determined by the delay time along the 30km fiber cable.

Page 41 of 119
D0438 - Unless the BIC power fails and thus the beam permit withdrawal signal is not sent or received by the BIC Loop.

Parent C0030 Descendant None

subtree(s) subtree(s)

Description This requires more information to know the involvement of the BIS has in emergency shutdown procedures.

Page 42 of 119
D0512 - Unless the Beam Loss Signal is not received by a Beam Interlock Controller within 70 microseconds of the BLMS detecting
high beam loss.

Parent subtree(s) C0030 Descendant subtree(s) None

Description

Page 43 of 119
C0011 - Whenever the Beam Dumping System (BDS) detects the withdrawal of a beam permit, it will fast-extract the beam from the LHC ring without caus...

Parent C0001 Descendant C0021, C0069

subtree(s) subtree(s)

Description

Page 44 of 119
C0021 - Whenever a beam dump request is received by the BDS, all components of the BDS will become active within 92 μs, and will not cause intolerab...

Parent C0668 Descendant C0085, C0094, C0097, C0299, C0378

subtree(s) subtree(s)

Description

Page 45 of 119
C0085 - All BDS components other than the MKD and MKB magnets will already be in an active state whenever a beam dump is issued.

Parent C0021 Descendant None

subtree(s) subtree(s)

Description

Page 46 of 119
C0094 - When the MKD magnets receive a beam dump request, they will wait at most one beam cycle (89 μs) before beginning to activate.

Parent C0021 Descendant C0357, D0640

subtree(s) subtree(s)

Description

Page 47 of 119
C0357 - In the event of a false abort gap detection, an asynchronous dump will be safely performed.

Parent C0094 Descendant C0194

subtree(s) subtree(s)

Description

Page 48 of 119
C0194 - The beam energy levels are specified by the larger LHC system/operations to ensure an accurate beam user permit.

Parent C0081, C0097, C0016 Descendant None

subtree(s) subtree(s)

Description This claim notes that the beam energy levels specified along with the results from the BLMS detectors ensure that the system has sufficient information to
withdraw it's permit and enable a dump signal.
Note: The SMP parameters sub-tree discusses inputs to the system and this should be reviewed as part of this argument.

Page 49 of 119
D0640 - Unless no abort gap is detected.

Parent C0094 Descendant None

subtree(s) subtree(s)

Description

Page 50 of 119
C0097 - While activating, the MKD kicker magnets will not cause intolerable beam loss.

Parent C0021 Descendant C0194

subtree(s) subtree(s)

Description

Page 51 of 119
Page 52 of 119
C0194 - The beam energy levels are specified by the larger LHC system/operations to ensure an accurate beam user permit.

Parent C0081, C0097, C0016 Descendant None

subtree(s) subtree(s)

Description This claim notes that the beam energy levels specified along with the results from the BLMS detectors ensure that the system has sufficient information to
withdraw it's permit and enable a dump signal.
Note: The SMP parameters sub-tree discusses inputs to the system and this should be reviewed as part of this argument.

Page 53 of 119
C0299 - MKD magnet activation takes no more than 2.8 μs to generate an appropriate magnetic field for extracting the beam.

Parent C0021 Descendant None

subtree(s) subtree(s)

Description

Page 54 of 119
Page 55 of 119
C0378 - The magnets used to dilute the beam (called the MKB magnets) activate within 18 μs of receiving a beam dump signal and do not cause losses a...

Parent C0021 Descendant None

subtree(s) subtree(s)

Description

Page 56 of 119
Page 57 of 119
C0069 - When all components of the BDS are active, the beam will be safely extracted from the LHC ring within one beam cycle (89 μs).

Parent C0668 Descendant C0077, C0079, C0080, C0081

subtree(s) subtree(s)

Description

Page 58 of 119
C0077 - When active, the MKD kicker magnets will extract the beam within one beam cycle without causing intolerable losses.

Parent C0069 Descendant None

subtree(s) subtree(s)

Description The MKD kicker magnets are a set of magnets intended to extract beams from the main LHC ring by horizontally deflecting them into the appropriate extraction
channel.

Page 59 of 119
C0079 - When active, the MSD magnets correctly divert the beam vertically towards the extraction lines and ultimately the TDE dumping block.

Parent C0069 Descendant None

subtree(s) subtree(s)

Description MSD magnets are a set of magnets intended to vertically divert an extracted LHC beam towards the target dump block.

Page 60 of 119
Page 61 of 119
C0080 - When active, the MKB diluter magnets dilute the beam to appropriately mitigate impact on the TDE dump block.

Parent C0069 Descendant None

subtree(s) subtree(s)

Description

Page 62 of 119
C0081 - The Target Dump External (TDE) block safely absorbs beams that pass through the MKB kicker magnets.

Parent C0069 Descendant C0194

subtree(s) subtree(s)

Description

Page 63 of 119
Page 64 of 119
C0194 - The beam energy levels are specified by the larger LHC system/operations to ensure an accurate beam user permit.

Parent C0081, C0097, C0016 Descendant None

subtree(s) subtree(s)

Description This claim notes that the beam energy levels specified along with the results from the BLMS detectors ensure that the system has sufficient information to
withdraw it's permit and enable a dump signal.
Note: The SMP parameters sub-tree discusses inputs to the system and this should be reviewed as part of this argument.

Page 65 of 119
C0061 - The Safe Machine Parameters (SMP) system calculates, communicates, and compares critical parameters to elements of LHC machine protection.

Parent C0001 Descendant S0213, S0219, S0313

subtree(s) subtree(s)

Description The argument underneath Claim C0061 focuses on the functionality provided by the Safe Machine Parameters System (SMPS).
This system is responsible for calculating and communicating some Safe Machine Parameters (SMPs) to diverse elements of the LHC machine protection.
The Safe Machine Parameter Controllers (SMPCs) first calculate the SMPs (the algorithms are defined in the SMP Func. Spec.), the SMPCs then prepare to send
these critical parameters to the various user systems. Prior to the user systems receiving the SMPs they are intercepted and compared against the source data
received from the source systems. If the comparison is favorable, permits are communicated to the Beam Interlock System (BIS). If the comparison is not
favorable, permits are removed from the BIS.

Page 66 of 119
S0213 - Argue over the hardware aspects of communicating the Safe Machine Parameters (SMPs) from the source systems, through the conversions and cal...

Parent C0061 Descendant None

subtree(s) subtree(s)

Description This subtree focuses on mitigations of potential hardware failures of the communications process.
The Safe Machine Parameters (SMPs) are compared (cross-checked) within this system. If they compare successfully, beam permits are communicated to the
Beam Interlock System (BIS). If they do not compare successfully, the beam permit is removed from the BIS.
Direct Serial Communication (DSC) is one of two methods of communication that the Safe Machine Protection System (SMPS) uses to distribute the SMPs from
source systems to user systems.
Ways in which the serial card/port, can be defective include: a bad (cold) solder connection, a bad crimp connection, one (or more) of the female sockets that
the serial cable will plug into is defective/broken.
Ways in which a serial cable can be defective include: one of the wires within the cable is broken (severed), the solder/crimp connection of a wire to a
terminator is defective, a male pin or a female socket within the cable's terminator is defective.
Unable to locate a CERN artifact to corroborate this evidence. However, checking all ports and cards within a device is a common function of POST processing
Ways in which a serial card/port can become defective while in operation include: heat build-up due to lengthy operation causes the serial card/port to fail,
electro-magnetic or radioactive radiation build-up causes the serial card/port to fail, Electrostatic Discharge (ESD) occurs while the serial card/port is in
operation.
Note: some devices require a separate i/o card to be plugged into a slot on the motherboard to provide serial communications. The i/o card provides the port
into which serial cables are plugged. Other devices have serial communications integrated onto the motherboard terminating at a port at the back of the device.
Hence the use of the term "serial card/port"
Unable to locate a CERN artifact to corroborate this evidence. However, if a serial device becomes defective during operation, communications will cease. If the
Beam Interlock System (BIS) fails to receive communications from a device, the User_Permit will be removed resulting in a beam dump.
Figure 3 from the Safe Machine Parameter (SMP) Functional Specification indicates that data communicated over Direct Serial Communications (DSC) is sent to
"critical users"
Note: the term "users" within the Safe Machine Parameter System (SMPS) refers to "user systems". It does NOT refer to human users. Source systems are those
that provide data to the Safe Machine Parameter Controllers (SMPCs). User systems are those that receive the SMPC information. This is described in the
"Figure 1" artifact attached to this node.
General Machine Timing (GMT) broadcast communication is one of two methods of communication that the Safe Machine Parameter System (SMPS) uses to
distribute Safe Machine Parameters (SMPs) from source systems to user systems.
The GMT broadcast communication may communicate timing events, telegrams, or Data Interchange Protocol (DIP) items.
Examples of NIC defects includes: a cold solder joint somewhere on the card, a defective chip on the card, the card is not seated into the motherboard slot
properly, etc.
Note: some devices require a separate Network Interface Card (NIC) i/o card to be plugged-in to the motherboard to provide network communications. Other
devices have NICs incorporated onto the motherboard. Hence the use of the term "Network Interface Card/port (NIC)"
Unable to locate a CERN artifact to corroborate this evidence. However, checking NIC connectivity is a common function of POST processing.

Page 67 of 119
Examples of network cabling defects includes: one of the wires is severed at some point within the cable, one or more wires are not terminated correctly thus
inhibiting connectivity, the cable is not shielded appropriately thus allowing electro-magnetic or radioactive interference to affect the data being transmitted,
etc.
Note, the term "wire" is used to refer to the comparatively thin end-to-end connectors within a cable. The term "cable" is used to refer to the outer "jacket" that
houses the wires that make-up a connector. the term "cable" often includes the terminator(s) at either end of a cable. A cable is comprised of one or more
wires, ending in terminators (female sockets or male pins).
Unable to locate a CERN artifact to corroborate this evidence. However, checking network cable connectivity is a common function of POST processing.
Any kind of network communication relies on 2 primary components: 1) the network's topology (generally considered the physical layout of the network's
wiring) e.g., a ring, a star, a bus, and variations there-of, 2) the network's protocol (generally considered the software rules that are implemented to provide
communications) e.g., ethernet, token ring, TCP/IP, FTP, etc.
Figure 3 from the Safe Machine Parameter (SMP) Functional Specification indicates that data communicated via the General Machine Timing (GMT) link is sent
to "non-critical users"
The Safe Machine Parameter System (SMPS) uses two methods to communicate Safe Machine Parameters (SMPs) from source systems to user systems: a)
direct connect communication via serial cables b) the General Machine Timing (GMT) broadcast link If any hardware-based or software-based defeaters with
respect to these two communication methods can be resolved, then there should be no reason for communications to fail.
If any unknown hardware communications errors present themselves, they will need to be added to the safety case along with their mitigation and evidence
nodes.
Node reflects discussions with CERN on 31/8/22.
The text within this evidence node has been enhanced to describe where within this safety case the two cross-checkers are discussed.
Select S0213, then r-click and select "Jump to Parent". Select S0313, then r-click and select "Jump to sub-tree" Node C0315 discusses the hardware cross-
checker Node C0316 discusses the software cross-checker.
If the most common types of hardware failures are eliminated, and any unknown types of hardware failures are eliminated, then communications errors due to
hardware failures should be eliminated.

Page 68 of 119
Page 69 of 119
S0219 - Argue over the process of calculating the critical Safe Machine Parameters (SMPs).

Parent C0061, C0701 Descendant None

subtree(s) subtree(s)

Description This strategy describes how the Safe Machine Parameters (SMPs) are determined. Source systems provide data to either the Large Hadron Collider (LHC) or the
Super Proton Synchrotron (SPS) Safe Machine Parameter Controllers (SMPCs). The two SMPCs calculate the SMPs from this source data. The algorithm for each
of the SMPs is defined in the "Safe Machine Parameter 3v0" Functional Specification. Once calculated, the SMPs are communicated to the user systems via
either the Direct Serial Communication (DSC) link or the General Machine Timing (GMT) broadcast link.
Two Safe Machine Parameter Controller (SMPC) devices are used to calculate a subset of the Safe Machine Parameters (SMPs). One SMP subset is calculated for
the Large Hadron Collider (LHC) ring, and one SMP subset is calculated for the Super Proton Synchrotron (SPS) ring. Combined they make up the complete set of
SMPs. This branch of the safety case defines the arguments for the LHC ring.
This node lists the Safe Machine Parameters (SMPs) that are calculated by the Large Hadron Collider's (LHC's) Safe Machine Parameter Controller (LHC-SMPC)
for communication via the General Machine Timing (GMT) broadcast link.
Note: the last 4 flags are also listed in the sibling node which defines the Safe Machine Parameters (SMPs) calculated for Direct Serial Communication (DSC). The
functional specification does not specify whether: a) the last 4 flags are communicated by both communication methods, or b) the last 4 flags are communicated
by only one of the communication methods and have been listed in error in the other communication method. I suspect that only individuals at CERN, familiar
with the Safe Machine Parameter System (SMPS), can provide an answer to this conundrum. See the "Figure 1" artifact attached to this node, which is derived
from the Safe Machine Parameters Functional Specification
The algorithms for all of the Safe Machine Parameters (SMPs) are defined in the SMP Functional Specification. This defeater applies to any one and all of the
SMPs whether calculated by the Large Hadron Collider's (LHC's) or the Super Proton Synchrotron's (SPS') Safe Machine Parameter Controllers (SMPCs) and
communicated via the General Machine Timing (GMT) broadcast link or the Direct Serial Communication (DSC) link. This defeater has been mitigated in that the
LHC has been operating for many years already. Many beam dumps have occurred either as part of normal shut-down procedures or due to the occurrence of
beam anomalies.
This node argues that Safe Machine Parameters (SMPs) calculated by the Large Hadron Collider's Safe Machine Parameter Controller (LHC-SMPC) and
communicated via the General Machine Timing (GMT) broadcast link, have been correctly defined in the SMP Functional Specification and are correctly
communicated to non-critical user systems.
This evidence node is not to suggest that the CERN Large Hadron Collider (LHC) is safe simply because it has been in operation for years (e.g., the infamous
Nimrod safety case). But rather because many very good people have exhaustively studied the many aspects of the CERN Machine Protection System (MPS) to
ensure the system is safe, and if a shutdown is required, it can be accomplished timely, accurately, and safely.
This node argues that Safe Machine Parameters (SMPs) calculated by the Large Hadron Collider's Safe Machine Parameter Controller (LHC-SMPC) and
communicated via Direct Serial Communication (DSC) links, have been correctly defined in the SMP Functional Specification and are correctly communicated to
critical user systems.
This node argues that Safe Machine Parameters (SMPs) calculated by the Super Proton Synchrotron's Safe Machine Parameter Controller (SPS-SMPC) and
communicated via the General Machine Timing (GMT) broadcast link, have been correctly defined in the SMP Functional Specification and are correctly
communicated to non-critical user systems.
This node argues that the Safe Machine Parameters (SMPs) calculated by the Super Proton Synchrotron's Safe Machine Parameter Controller (SPS-SMPC) and
communicated via the Direct Serial Communication (DSC) broadcast link, have been correctly defined in the SMP Functional Specification and are correctly
communicated to critical user systems.

Page 70 of 119
This node lists the Safe Machine Parameters (SMPs) that are calculated by the Large Hadron Collider's (LHC's) Safe Machine Parameter Controller (LHC-SMPC)
for communication via the Direct Serial Communication (DSC) link.
Note: that these 4 flags are also listed in the sibling node which defines the Safe Machine Parameters (SMPs) calculated for General Machine Timing (GMT)
broadcast link. The functional specification does not specify whether: a) these 4 flags are communicated by both communication methods, or b) these 4 flags are
communicated by only one of the communication methods and have been listed in error in the other communication method. I suspect that only individuals at
CERN, familiar with the Safe Machine Parameter System (SMPS), can provide an answer to this conundrum. See the "Figure 1" artifact attached to this node. This
artifact is derived from the Safe Machine Parameters Functional Specification
Two Safe Machine Parameter Controller (SMPC) devices are used to calculate a subset of the Safe Machine Parameters (SMPs). One SMP subset is calculated for
the Large Hadron Collider (LHC) ring, and one SMP subset is calculated for the Super Proton Synchrotron (SPS) ring. Combined they make up the complete set of
SMPs. This branch of the safety case defines the arguments for the SPS ring.
This node lists the Safe Machine Parameters (SMPs) that are calculated by the Super Proton Synchrotron's (SPS') Safe Machine Parameter Controller (SPS-SMPC)
for communication via the General Machine Timing (GMT) broadcast link.
This node lists the Safe Machine Parameters (SMPs) that are calculated by the Super Proton Synchrotron's (SPS') Safe Machine Parameter Controller (SPS-SMPC)
for communication via the Direct Serial Communication (DSC) link.
If there are any undetermined errors in the algorithms that define how the Safe Machine Parameters (SMPs) are to be calculated as specified in the SMP
Functional Specification, then these will need to be added to this safety case once they are discovered.
If the Large Hadron Collider's (LHC's) and the Super Proton Synchrotron's (SPS') Safe Machine Parameters (SMPs) are calculated correctly, and there are no
unknown calculation errors, then the SMPs must be calculating correctly. If at some future point it is discovered that one or more SMPs are being calculated
incorrectly, then these must be added to this safety case along with their mitigations and evidence nodes.

Page 71 of 119
Page 72 of 119
S0313 - Argue over the cross-checking of the Safe Machine Parameters (SMPs).

Parent C0061 Descendant None

subtree(s) subtree(s)

Description Safe Machine Parameters (SMPs) derived from source systems are compared against those same SMPs communicated to user systems to ensure that nothing
has been corrupted during the conversion and communication process.
The hardware cross-check is one of two cross-checks that are performed. The hardware cross-check is performed on the Safe Machine Parameters (SMPs) that
are communicated via Direct Serial Communication (DSC). These SMPs are communicated to "critical" users systems.
This defeater is intended to describe a situation where data is corrupted while in serial communication e.g. electromagnetic or radioactive interference causes
an unshielded serial cable to flip a bit while being communicated.
There could be some unidentified reason(s) for the hardware cross-check to fail. If this occurs the User_Permit will be removed from the Beam Interlock System
(BIS).
If the hardware cross-check is successful, and there are no unidentified reasons for the hardware cross-check to fail, then two User_Permits will be sent to the
Beam Interlock System (BIS).
If nothing was corrupted during Direct Serial Communication (DSC), then the hardware cross-check will be successful; where "successful" will result in two
User_Permits being communicated to the Beam Interlock System (BIS). Two permits are communicated, one for each beam.
Node reflects discussions with CERN on 31/8/22.
The text within this evidence node has been enhanced to describe where within this safety case the two cross-checkers are discussed.
Select S0213, then r-click and select "Jump to Parent". Select S0313, then r-click and select "Jump to sub-tree" Node C0315 discusses the hardware cross-
checker Node C0316 discusses the software cross-checker.
The software cross-check is one of two cross-checks that are performed. The software cross-check is performed on the Safe Machine Parameters (SMPs) that
are communicated via the General Machine Timing (GMT) broadcast link. These SMPs are transmitted to "non-critical" users systems.
This defeater is intended to describe data being corrupted during communication e.g., electromagnetic or radioactive interference affecting an unshielded
network cable, causes a bit to flip while being communicated.
Cyclic redundancy check (CRC) is a frequently used error detecting code used to ensure that software that was communicated, has not been modified when it
arrives at its destination. At the data's source, each block of data is divided by a polynomial number. The remainder of this division is recorded with the block of
data. At the destination this division is repeated. If the remainders match, the data is confirmed to be unaltered.
If nothing was corrupted during General Machine Timing (GMT) broadcast communication, then the software cross-check will be successful where "successful"
will result in two Software_Permits being communicated to the Beam Interlock System (BIS). Two permits are communicated, one for each beam.
There could be some unidentified reason(s) for the software cross-check failing. If this occurs the Software_Permit will be removed from the Beam Interlock
System (BIS).
If the software cross-check is successful, and there are no unidentified reasons for the software cross-check to fail, then two Software_Permits will be sent to
the Beam Interlock System (BIS).
The sibling nodes describe the hardware cross-check (CISC) and the software cross-check (SIS) that are performed as part of the Safe Machine Parameter System
(SMPS).

Page 73 of 119
The result of the hardware cross-check is either two User_Permits (if the check was successful) being communicated to the Beam Interlock System (BIS), or a
removal of the User_Permit (if the check was unsuccessful). Two permits are communicated, one for each beam.
The result of the software cross-check is either two Software_Permits (if the check was successful) being communicated to the Beam Interlock System (BIS), or a
removal of the Software_Permit (if the check was unsuccessful). Two permits are communicated, one for each beam.

Page 74 of 119
IR0129 - If the SMP appropriately sets all the parameters for MPS subsystems, if the BLMS correctly detects an intolerable beam loss, if the BIS comm...

Parent C0001 Descendant None

subtree(s) subtree(s)

Description

Page 75 of 119
C0667 - The systems of the MPS have suitable reliability and redundancy that they are capable of accurately detecting and requesting beam dumps, i.e...

Parent C0001 Descendant IR0675, C0699, C0700, C0701

subtree(s) subtree(s)

Description

Page 76 of 119
IR0675 - If the SMP appropriately sets the parameters for the MPS subsystems, and the BLMS is fully operational and capable of detecting beam losses,...

Parent C0667 Descendant None

subtree(s) subtree(s)

Description

Page 77 of 119
C0699 - The BLMS detectors and associated systems are fully operational during LHC operations.

Parent C0667 Descendant None

subtree(s) subtree(s)

Description Note: that spurious detection of particles could result in an inability to detect a "true" beam loss.
No direct evidence has been found to support a tolerance for a loss of a single detector. However, it is likely that due to the number of detectors and level of
redundancy that CERN will have an operating threshold for detector availability.
No direct evidence has been found to support a tolerance for a loss of a single detector. However, it is likely that due to the number of detectors and level of
redundancy that CERN will have an operating threshold for detector availability.
See information on Beam Permit and requirements therein for LHC operations.
Note: the BLM sanity check is only performed at the start of each fill, but will not directly result in an active beam dump request during a fill. Hence a faulty BLM
detector might only be detected at the time of starting the next fill.

Page 78 of 119
C0700 - The BIS is fully operational during LHC operations.

Parent C0667 Descendant None

subtree(s) subtree(s)

Description

Page 79 of 119
C0701 - The SMP accurately sets out operating paraments for all critical components of the LHC.

Parent C0667 Descendant S0219

subtree(s) subtree(s)

Description

Page 80 of 119
S0219 - Argue over the process of calculating the critical Safe Machine Parameters (SMPs).

Parent C0061, C0701 Descendant None

subtree(s) subtree(s)

Description This strategy describes how the Safe Machine Parameters (SMPs) are determined. Source systems provide data to either the Large Hadron Collider (LHC) or the
Super Proton Synchrotron (SPS) Safe Machine Parameter Controllers (SMPCs). The two SMPCs calculate the SMPs from this source data. The algorithm for each
of the SMPs is defined in the "Safe Machine Parameter 3v0" Functional Specification. Once calculated, the SMPs are communicated to the user systems via
either the Direct Serial Communication (DSC) link or the General Machine Timing (GMT) broadcast link.
Two Safe Machine Parameter Controller (SMPC) devices are used to calculate a subset of the Safe Machine Parameters (SMPs). One SMP subset is calculated for
the Large Hadron Collider (LHC) ring, and one SMP subset is calculated for the Super Proton Synchrotron (SPS) ring. Combined they make up the complete set of
SMPs. This branch of the safety case defines the arguments for the LHC ring.
This node lists the Safe Machine Parameters (SMPs) that are calculated by the Large Hadron Collider's (LHC's) Safe Machine Parameter Controller (LHC-SMPC)
for communication via the General Machine Timing (GMT) broadcast link.
Note: the last 4 flags are also listed in the sibling node which defines the Safe Machine Parameters (SMPs) calculated for Direct Serial Communication (DSC). The
functional specification does not specify whether: a) the last 4 flags are communicated by both communication methods, or b) the last 4 flags are communicated
by only one of the communication methods and have been listed in error in the other communication method. I suspect that only individuals at CERN, familiar
with the Safe Machine Parameter System (SMPS), can provide an answer to this conundrum. See the "Figure 1" artifact attached to this node, which is derived
from the Safe Machine Parameters Functional Specification
The algorithms for all of the Safe Machine Parameters (SMPs) are defined in the SMP Functional Specification. This defeater applies to any one and all of the
SMPs whether calculated by the Large Hadron Collider's (LHC's) or the Super Proton Synchrotron's (SPS') Safe Machine Parameter Controllers (SMPCs), and
communicated via the General Machine Timing (GMT) broadcast link or the Direct Serial Communication (DSC) link. This defeater has been mitigated in that the
LHC has been operating for many years already. Many beam dumps have occurred either as part of normal shut-down procedures or due to the occurrence of
beam anomalies.
This node argues that Safe Machine Parameters (SMPs) calculated by the Large Hadron Collider's Safe Machine Parameter Controller (LHC-SMPC) and
communicated via the General Machine Timing (GMT) broadcast link, have been correctly defined in the SMP Functional Specification and are correctly
communicated to non-critical user systems.
This evidence node is not to suggest that the CERN Large Hadron Collider (LHC) is safe simply because it has been in operation for years (e.g., the infamous
Nimrod safety case). But rather because many very good people have exhaustively studied the many aspects of the CERN Machine Protection System (MPS) to
ensure the system is safe, and if a shutdown is required, it can be accomplished timely, accurately, and safely.
This node argues that Safe Machine Parameters (SMPs) calculated by the Large Hadron Collider's Safe Machine Parameter Controller (LHC-SMPC) and
communicated via Direct Serial Communication (DSC) links, have been correctly defined in the SMP Functional Specification and are correctly communicated to
critical user systems.
This node argues that Safe Machine Parameters (SMPs) calculated by the Super Proton Synchrotron's Safe Machine Parameter Controller (SPS-SMPC) and
communicated via the General Machine Timing (GMT) broadcast link, have been correctly defined in the SMP Functional Specification and are correctly
communicated to non-critical user systems.
This node argues that the Safe Machine Parameters (SMPs) calculated by the Super Proton Synchrotron's Safe Machine Parameter Controller (SPS-SMPC) and
communicated via the Direct Serial Communication (DSC) broadcast link, have been correctly defined in the SMP Functional Specification and are correctly
communicated to critical user systems.

Page 81 of 119
This node lists the Safe Machine Parameters (SMPs) that are calculated by the Large Hadron Collider's (LHC's) Safe Machine Parameter Controller (LHC-SMPC)
for communication via the Direct Serial Communication (DSC) link.
Note: that these 4 flags are also listed in the sibling node which defines the Safe Machine Parameters (SMPs) calculated for General Machine Timing (GMT)
broadcast link. The functional specification does not specify whether: a) these 4 flags are communicated by both communication methods, or b) these 4 flags are
communicated by only one of the communication methods and have been listed in error in the other communication method. I suspect that only individuals at
CERN, familiar with the Safe Machine Parameter System (SMPS), can provide an answer to this conundrum. See the "Figure 1" artifact attached to this node. This
artifact is derived from the Safe Machine Parameters Functional Specification
Two Safe Machine Parameter Controller (SMPC) devices are used to calculate a subset of the Safe Machine Parameters (SMPs). One SMP subset is calculated for
the Large Hadron Collider (LHC) ring, and one SMP subset is calculated for the Super Proton Synchrotron (SPS) ring. Combined they make up the complete set of
SMPs. This branch of the safety case defines the arguments for the SPS ring.
This node lists the Safe Machine Parameters (SMPs) that are calculated by the Super Proton Synchrotron's (SPS') Safe Machine Parameter Controller (SPS-SMPC)
for communication via the General Machine Timing (GMT) broadcast link.
This node lists the Safe Machine Parameters (SMPs) that are calculated by the Super Proton Synchrotron's (SPS') Safe Machine Parameter Controller (SPS-SMPC)
for communication via the Direct Serial Communication (DSC) link.
If there are any undetermined errors in the algorithms that define how the Safe Machine Parameters (SMPs) are to be calculated as specified in the SMP
Functional Specification, then these will need to be added to this safety case once they are discovered.
If the Large Hadron Collider's (LHC's) and the Super Proton Synchrotron's (SPS') Safe Machine Parameters (SMPs) are calculated correctly, and there are no
unknown calculation errors, then the SMPs must be calculating correctly. If at some future point it is discovered that one or more SMPs are being calculated
incorrectly, then these must be added to this safety case along with their mitigations and evidence nodes.

Page 82 of 119
Page 83 of 119
C0668 - In the event of a spurious beam dump, the Beam Dumping System (BDS) will safely extract the beam without causing damage to the LHC.

Parent C0001 Descendant C0021, C0069, C0692

subtree(s) subtree(s)

Description

Page 84 of 119
Page 85 of 119
C0021 - Whenever a beam dump request is received by the BDS, all components of the BDS will become active within 92 μs, and will not cause intolerab...

Parent C0668 Descendant C0085, C0094, C0097, C0299, C0378

subtree(s) subtree(s)

Description

Page 86 of 119
C0085 - All BDS components other than the MKD and MKB magnets will already be in an active state whenever a beam dump is issued.

Parent C0021 Descendant None

subtree(s) subtree(s)

Description

Page 87 of 119
C0094 - When the MKD magnets receive a beam dump request, they will wait at most one beam cycle (89 μs) before beginning to activate.

Parent C0021 Descendant C0357, D0640

subtree(s) subtree(s)

Description

Page 88 of 119
C0357 - In the event of a false abort gap detection, an asynchronous dump will be safely performed.

Parent C0094 Descendant C0194

subtree(s) subtree(s)

Description

Page 89 of 119
C0194 - The beam energy levels are specified by the larger LHC system/operations to ensure an accurate beam user permit.

Parent C0081, C0097, C0016 Descendant None

subtree(s) subtree(s)

Description This claim notes that the beam energy levels specified along with the results from the BLMS detectors ensure that the system has sufficient information to
withdraw it's permit and enable a dump signal.
Note: The SMP parameters sub-tree discusses inputs to the system and this should be reviewed as part of this argument.

Page 90 of 119
D0640 - Unless no abort gap is detected.

Parent C0094 Descendant None

subtree(s) subtree(s)

Description

Page 91 of 119
C0097 - While activating, the MKD kicker magnets will not cause intolerable beam loss.

Parent C0021 Descendant C0194

subtree(s) subtree(s)

Description

Page 92 of 119
Page 93 of 119
C0194 - The beam energy levels are specified by the larger LHC system/operations to ensure an accurate beam user permit.

Parent C0081, C0097, C0016 Descendant None

subtree(s) subtree(s)

Description This claim notes that the beam energy levels specified along with the results from the BLMS detectors ensure that the system has sufficient information to
withdraw it's permit and enable a dump signal.
Note: The SMP parameters sub-tree discusses inputs to the system and this should be reviewed as part of this argument.

Page 94 of 119
C0299 - MKD magnet activation takes no more than 2.8 μs to generate an appropriate magnetic field for extracting the beam.

Parent C0021 Descendant None

subtree(s) subtree(s)

Description

Page 95 of 119
Page 96 of 119
C0378 - The magnets used to dilute the beam (called the MKB magnets) activate within 18 μs of receiving a beam dump signal and do not cause losses a...

Parent C0021 Descendant None

subtree(s) subtree(s)

Description

Page 97 of 119
Page 98 of 119
C0069 - When all components of the BDS are active, the beam will be safely extracted from the LHC ring within one beam cycle (89 μs).

Parent C0668 Descendant C0077, C0079, C0080, C0081

subtree(s) subtree(s)

Description

Page 99 of 119
C0077 - When active, the MKD kicker magnets will extract the beam within one beam cycle without causing intolerable losses.

Parent C0069 Descendant None

subtree(s) subtree(s)

Description The MKD kicker magnets are a set of magnets intended to extract beams from the main LHC ring by horizontally deflecting them into the appropriate extraction
channel.

Page 100 of 119

C0079 - When active, the MSD magnets correctly divert the beam vertically towards the extraction lines and ultimately the TDE dumping block.

Parent C0069 Descendant None

subtree(s) subtree(s)

Description MSD magnets are a set of magnets intended to vertically divert an extracted LHC beam towards the target dump block.

Page 101 of 119

Page 102 of 119
C0080 - When active, the MKB diluter magnets dilute the beam to appropriately mitigate impact on the TDE dump block.

Parent C0069 Descendant None

subtree(s) subtree(s)

Description

Page 103 of 119

C0081 - The Target Dump External (TDE) block safely absorbs beams that pass through the MKB kicker magnets.

Parent C0069 Descendant C0194

subtree(s) subtree(s)

Description

Page 104 of 119

Page 105 of 119
C0194 - The beam energy levels are specified by the larger LHC system/operations to ensure an accurate beam user permit.

Parent C0081, C0097, C0016 Descendant None

subtree(s) subtree(s)

Description This claim notes that the beam energy levels specified along with the results from the BLMS detectors ensure that the system has sufficient information to
withdraw it's permit and enable a dump signal.
Note: The SMP parameters sub-tree discusses inputs to the system and this should be reviewed as part of this argument.

Page 106 of 119

C0692 - Any beam losses that occur while the MKD magnets are being activated during an asynchronous dump will be safely absorbed without causing dam...

Parent C0668 Descendant C0194

subtree(s) subtree(s)

Description

Page 107 of 119

Page 108 of 119
C0194 - The beam energy levels are specified by the larger LHC system/operations to ensure an accurate beam user permit.

Parent C0081, C0097, C0016 Descendant None

subtree(s) subtree(s)

Description This claim notes that the beam energy levels specified along with the results from the BLMS detectors ensure that the system has sufficient information to
withdraw it's permit and enable a dump signal.
Note: The SMP parameters sub-tree discusses inputs to the system and this should be reviewed as part of this argument.

Page 109 of 119

Artifacts
Name Beam Dumping System Description

Description This document is among of a set of documents identified as inputs to a 2010 review of
LHC machine protection.

References E0577, E0368, E0379, E0385, E0351, E0347, C0011, E0582, E0304, E0358, E0355, E0554,
E0376, E0392, E0387, E0363, E0143

Link Beam Dumping System Description

Version None

Status None

Date updated None

Name Beam Loss Monitoring Detector

Description The yellow tubes in the photo are beam loss monitoring detectors.

References C0014

Link Beam Loss Monitoring Detector

Version None

Status None

Date updated None

Name BIS Beam Loops Diagram

Description BICs arranged in a ring with 4 beam loops

References X0019, E0055, E0618

Link BIS Beam Loops Diagram

Version None

Status None

Date updated None

Name BLMS Review Nov 2010

Description This is set of documents and presentations used during a site visit by CSL to CERN in
November 2010.

References C0009

Link BLMS Review Nov 2010

Version None

Status None

Date updated None

Page 110 of 119

Name SMP discussion paper

Description 2010

References

Link SMP discussion paper

Version None

Status None

Date updated None

Name Safe Machine Parameters 3v0

Description This artifact defines the functional specification of the Safe Machine Parameters (SMP) of
the Large Hadron Collider (LHC) at CERN

References X0471, E0309, E0418, X0470

Link Safe Machine Parameters 3v0

Version None

Status None

Date updated None

Name Figure 1 of SMP Func Spec - SMPC IO

Description Shows which Safe Machine Parameters (SMPs) are generated by which Safe Machine
Parameter Controller (LHC or SPS) and how they are communicated (via General Machine
Timing link or via Direct Serial Connection). This 1-page reference was taken from the
Safe Machine Parameters 3v0 Functional Specification document, page 6.

References E0309, C0472, C0289, X0469, X0468

Link Figure 1 of SMP Func Spec - SMPC IO

Version None

Status None

Date updated None

Name Figure 3 of SMP Func Spec - User Sys Connex to SMPC

Description Shows how the Safe Machine Parameters (SMPs) communicated via the General Machine
Timing (GMT) broadcast link and the Direct Serial Communications link are distributed to
critical and non-critical user systems. This 1-page reference was taken from the Safe
Machine Parameters 3v0 Functional Specification document, page 8.

References X0469, X0468

Link Figure 3 of SMP Func Spec - User Sys Connex to SMPC

Version None

Page 111 of 119

Status None

Date updated None

Name Figure 4 of SMP Func Spec - SMP Cross-Check

Description Shows how the Safe Machine Parameters (SMPs) distributed by the General Machine
Timing (GMT) broadcast link and the Direct Serial Communications link are checked by
either the Hardware Cross Check (CISC) or the Software Cross Check (SIS) and then
Software_Permits or User_Permits are generated to the Beam Interlock System (BIS). This
1-page reference was taken from the Safe Machine Parameters 3v0 Functional
Specification document, page 9.

References E0462, E0463

Link Figure 4 of SMP Func Spec - SMP Cross-Check

Version None

Status None

Date updated None

Name BLMS Overview

Description Provides details on functionality of BLMS as well as schematic overview of the

input/outputs.

References

Link BLMS Overview

Version None

Status None

Date updated None

Name Design of Beam Loss Detectors

Description CERN BLMS Design of System and Detectors

References E0171, E0485, E0208, E0114, E0482, E0480, E0644

Link Design of Beam Loss Detectors

Version None

Status None

Date updated None

Name System for Personnel Protection

Description Safety for protection of personnel in LHC tunnel

References E0162, E0486

Link System for Personnel Protection

Page 112 of 119

Version None

Status None

Date updated None

Name Tunnel and Surface Electronics Data Card

Description Acquisition of data for the Tunnel and Surface Electronics.

References E0254, E0247, E0256, E0242, E0634, E0261, E0263, E0509, E0500, E0270, E0499, E0507

Link Tunnel and Surface Electronics Data Card

Version None

Status None

Date updated None

Name Beam Dumping System Parameters

Description Parameters of BDS and Permits

References E0258, E0509

Link Beam Dumping System Parameters

Version None

Status None

Date updated None

Name Beam Interlock Strategy between the LHC and its Injector

Description This document outlines the functionality of the Beam Interlock System for the CERN LHC
and SPS particle accelerators. It provides supporting evidence of the operational
requirements for beam injection and extraction as well as the organization for beam
transfer interlocking.

References E0443, E0601

Link Beam Interlock Strategy between the LHC and its Injector

Version None

Status None

Date updated None

Name Architecture of Beam Interlock System

Description This document provides a technical report and overview of the architecture of the Beam
Interlock System and its role in machine protection.

References E0609, E0543, E0604, C0023, E0444, E0541, E0612, E0055, E0618

Link Architecture of Beam Interlock System

Page 113 of 119

Version None

Status None

Date updated None

Name Interlock System Upgrades at the CERN Accelerator Complex During Long Shutdown 2

Description The CERN accelerator complex stopped operation at the end of 2018 for the Long
Shutdown 2 (LS2), allowing for the LHC Injector Upgrade program (LIU) and consolidation
work to be accomplished. A gradual restart of the different accelerators is ongoing in
2021, culminating with the LHC foreseen to be back in operation early 2022. During LS2 a
very large range of systems was modified throughout the accelerator complex. This
includes the so-called Machine Interlock systems, which are at the heart of the overall
machine protection system. This paper gives an overview of the Machine Interlock
systems changes during LS2. It includes the installation of a Beam Interlock System (BIS)
at the new linear accelerator LINAC4, at the PS-Booster and the installation of a new
Injection BIS for the SPS synchrotron. New Safe Machine Parameter flags to protect the
SPS transfer line mobile beam dumps against high intensity beams were put in place. The
new Warm Magnet Controller (WIC) installations at LINAC4 the PS Booster and the
different transfer lines and experimental areas are presented together with the
modifications to the Power Interlock Controller protecting the LHC superconducting
magnets.

References E0444, E0612

Link Interlock System Upgrades at the CERN Accelerator Complex During Long Shutdown 2

Version None

Status None

Date updated None

Name THE BEAM INTERLOCK SYSTEM FOR THE LHC

Description Engineering specification report of the Beam Interlock System for the LHC. Definitions of
commonly used terms and critical components.

References C0010

Link THE BEAM INTERLOCK SYSTEM FOR THE LHC

Version None

Status Complete

Date updated None

Name Glossary and Acronyms Register

Description Full list of acronyms and glossary,

References X0653

Link Glossary and Acronyms Register

Version None

Page 114 of 119

Status None

Date updated None

Name CERN Dependable Design Example - Beam Machine Protection

Description Presentation detailing the safety analysis of the Beam Interlock System's design and
testing procedure for operation at higher energy levels

References E0544

Link CERN Dependable Design Example - Beam Machine Protection

Version None

Status Complete

Date updated None

Name BEAM INTERLOCK SYSTEM AND SAFE MACHINE PARAMETERS SYSTEM - 2010 AND
BEYOND

Description The Beam Interlock System (BIS) and Safe Machine Parameters (SMP) system are central
to the protection of the Large Hadron Collider (LHC) machine. The BIS has been critical for
the safe operation of LHC from the first day of operation. It has been installed and
commissioned, only minor enhancements are required in order to accommodate all
future LHC machine protection requirements.

References

Link BEAM INTERLOCK SYSTEM AND SAFE MACHINE PARAMETERS SYSTEM - 2010 AND
BEYOND

Version None

Status None

Date updated None

Name Beam Interlock System - BIS IPOC

Description Description of specific function of the Beam Interlock Systems Internal Post-Operational
Check (IPOC)

References

Link Beam Interlock System - BIS IPOC

Version None

Status None

Date updated None

Name A Beam Interlock System for CERN High Energy Accelerators

Description Chapter 4.4 - Describes the role of the Manager Board of Beam Interlock Controllers to
derive LOCAL BEAM PERMIT from the USER PERMIT input signals. There are two key

Page 115 of 119

 components of the Beam Interlock Controller, a Manager board (CIBM) responsible for
the critical functions of the controller, and a Test & Monitor board (CIBT) which is
responsible for the remote supervision and control of the distributed User Interfaces
(CIBU). The User Interfaces are connected to the controller by NE12 cables, the rear of
the controller has been fitted with a patch-panel (CIBPx) and extender boards (CIBEx)
connecting these cables to the user defined pins of the VME bus.

References E0656

Link A Beam Interlock System for CERN High Energy Accelerators

Version None

Status Complete

Date updated None

Name USER INTERFACE TO THE BEAM INTERLOCK SYSTEM

Description Technical description of Beam interlock controller's architecture and signal processing
structure.

References E0720

Link USER INTERFACE TO THE BEAM INTERLOCK SYSTEM

Version None

Status Complete

Date updated None

Page 116 of 119

Issues
No Issues

Page 117 of 119

Comments
No Comments

Page 118 of 119

END

Page 119 of 119