Вы находитесь на странице: 1из 36

AN INNOVATIVE TIME-OF-FLIGHT BASED

SAFETY SYSTEM FOR THE TRAIN


INSPECTION MONORAIL OF THE LARGE
HADRON COLLIDER AT CERN

Mattia Martinelli
Acknowledgments.

This project has been carried out at CERN (European Organization for Nuclear Research) in
collaboration with a partner company: TeraBee1.

I would like to thank all the following people:


Mario Di Castro (CERN): TIM2 project leader and technical support.
Gilles Foucard (CERN): project developing and documentation revising.
Jan Kovermann (TeraBee): project developing.
Paul Peronnard (CERN): technical support.
Alessandro Masi (CERN): EN-STI-ECE section leader.
Giacomo Lunghi (CERN): testing.
All the guys of the building 628 who helped me in every way.

Mattia Martinelli
Geneva, the 27th of August 2015

1
http://www.terabee.com/
2
Train Inspection Monorail (explained in this document).
This page was intentionally left blank.
TABLE OF CONTENTS

Introduction 3

1 Overview of the equipment


1. The Train Inspection Monorail ........................................................................................................ 4
1.1 Description .............................................................................................................................. 4
1.2 Radioprotection arm ............................................................................................................... 5
1.3 Obstacle detection principle. .................................................................................................. 6
2. The TeraRanger One (TR1) .............................................................................................................. 7
2.1 Description .............................................................................................................................. 7
2.2 Technical specification ............................................................................................................ 7
2.3 Operating modes .................................................................................................................... 8
2.4 Impact of the material on the detection efficiency ................................................................ 8
3. Using TeraRanger One for TIM ....................................................................................................... 8
3.1 Arrangement ........................................................................................................................... 8
3.2 TR1 placed to avoid field of view overlapping ........................................................................ 8
3.1 TR1 placed to reduce blind areas.......................................................................................... 10
3.2 Taking into account the TIM travel speed ............................................................................ 11
3.3 TeraHub mechanical holder adapted for TIM ....................................................................... 11

2 The TeraHub board


1. Specifications ................................................................................................................................ 12
2. Safety redundancy ........................................................................................................................ 13
3. Board electrical test ...................................................................................................................... 13

3 Firmware
1. Specifications ................................................................................................................................ 15
1.1 Brief description .................................................................................................................... 15
1.2 Distance check ...................................................................................................................... 15
1.3 Data integrity check .............................................................................................................. 16
1.4 System check......................................................................................................................... 16
1.5 Upper level interface ............................................................................................................ 16

1
1.6 Output flags........................................................................................................................... 16
2. Simplified structure....................................................................................................................... 17
3. Firmware versions ......................................................................................................................... 18
3.1 Version 1 ............................................................................................................................... 18
3.2 Version 1.1 ............................................................................................................................ 18
3.3 Version 1.2 ............................................................................................................................ 18
2.4 Version 1 NO UART ............................................................................................................... 19
2.5 Version 2.0 ............................................................................................................................ 19
3. Firmware development................................................................................................................. 20
4. Firmware test ................................................................................................................................ 21
4.1 Description ............................................................................................................................ 21
4.2 Test results ............................................................................................................................ 22
4.3 Conclusions ........................................................................................................................... 23

4 Upper level interface


1. PC interface ................................................................................................................................... 24
1.1 Description ............................................................................................................................ 24
1.2 Electrical characteristics........................................................................................................ 24
1.3 Data link layer ....................................................................................................................... 24
4.4 User Interface ....................................................................................................................... 25
4.5 Application software development ...................................................................................... 27
2. PLC interface ................................................................................................................................. 28
4.6 Description ............................................................................................................................ 28
4.7 Electrical characteristics........................................................................................................ 28
4.8 Communication with the board ............................................................................................ 28
3. TIM interface ................................................................................................................................. 29
4.9 Description ............................................................................................................................ 29
4.10 Interface implementation ..................................................................................................... 30

Present and future of the project 32

2
INTRODUCTION

The European Organization for Nuclear Research (CERN) is the largest particle physics
laboratory in the world. The organization, established in 1954 and based in Geneva,
Switzerland, is the result of a cooperation of several states, both European and non-
European.

CERN provides particle accelerators and other infrastructure for high energy physics
research. Moreover also a strong industrial research is performed at CERN. Knowledge
transfer is a key factor of the organization and everyday many companies are involved in
a tight collaboration.

The largest facility at CERN is called the Large Hadron Collider (LHC), a 27 km circular
particle accelerator which runs 100 meters under the French and the Swiss countryside.
It is the longest and most powerful particle accelerator in the world. The LHC needs regular
maintenance and unfortunately its dimensions do not make the operations easy. Other
problems concern the presence of radiation and harmful gas, exposing the personal to
dangerous risks. Thus, an automatic inspection system was developed: the Train
Inspection Monorail (TIM).

TIM is a remotely-controlled monorail train placed on the ceiling of the LHC tunnel. It is
able to take several measurements with a mechanical arm and send them automatically
to a control station.

The aim of this project

When people are operating in the tunnel, TIM can only perform a few measurements since
the mechanical arm cannot be deployed for security reason.

The purpose of the project is to allow TIM to operate in every circumstances, especially in
the case of emergency in the LHC tunnel. In doing so, TIM will allow a human-robot
cooperation and the train will be able to carry out all the measurements even in the
presence of people. Moreover, thanks to the work of this project, tasks like reconnaissance
in case of emergency could be performed.

3 | CERN - European Organization for Nuclear Research


CHAPTER 1 - OVERVIEW OF THE EQUIPMENT

The LHC tunnel is equipped with a remotely-controlled monorail train able to carry out
Radio-Protection (RP) survey and visual inspections. This train is composed of five wagons.
Among them the RP wagon has a retractable arm for RP measurements, which can be
deployed while the train is moving.

1. The Train Inspection Monorail

1.1 Description
A remote controlled inspection vehicle was developed at CERN for the LHC tunnel.
This equipment called TIM is able to perform radiation, temperature and oxygen
measurements, as well as visual inspections with HD and infrared cameras. It is
battery powered and additional payload can be added on demand.

Figure 1 - Train Inspection Monorail

TIM travels at a maximum speed of 6 km/h. The wagon dimensions are


L 120 x W 30 x H 30cm (Figure 1). TIM can be composed of several wagons
including the:

Motor wagon

4 | CERN - European Organization for Nuclear Research


Reconnaissance wagon
RP wagon
Battery wagon
Control wagon

1.2 Radioprotection arm

RP wagon

RP arm deployed

First four
wagons of TIM

Figure 2 - Radioprotection arm deployed

The RP wagon is equipped with a retractable arm fitted with radiation sensors
mounted at its end. In normal traveling mode this arm is retracted in the wagon.
Whenever required the arm can be deployed to measure the radiation levels at
different heights near the equipment. The train can be moving along the LHC
tunnel during this operation (see Figure 2). In fully deployed configuration, the
arm can reach a maximum length of 1.7 m. The train being suspended at an
average height of 2.1m above the tunnels floor, the fully deployed arm can reach
down a minimum height of 40 cm above the floor. Therefore, there is the risk that
it could collide with objects that could be left in the tunnel (bike cycle, ladder,

5 | CERN - European Organization for Nuclear Research


etc). In order to ensure secure operations of the RP arm, object detection had to
be implemented to stop the train motion before the arm can hit the obstacle.

1.3 Obstacle detection principle.


The principle consists of detecting objects that could be left in the RP arm path
and to stop the train before the collision. An alarm is also triggered for the train
operator that will then proceed to a visual inspection and decide which appropriate
action should be taken. The idea is to create a safety volume below the RP wagon
that would detect any object above the floor level that could be hit by the arm
while the train is travelling. This detection is made with proximity sensors able to
return the range of objects located in their sight range.

TIM wagon RP wagon TIM wagon

Traveling direction Safety


volume

Alarm Threshold
Safe detection
distance
Deployed
RP arm

Floor

Figure 3 - Principle of safe volume under the RP wagon

6 | CERN - European Organization for Nuclear Research


2. The TeraRanger One (TR1)

2.1 Description
The TeraRanger one sensor (Figure 4) is produced by Terabee Company. It is
based on the Time-of-Flight (ToF) principle where the device measures the time
between the emission of the signal and its return home after being reflected by
an object. It uses infrared light and the TeraRanger can provide a reading speed
up to 1 kHz.

Figure 4 - TeraRanger One

2.2 Technical specification


TeraRanger One is a fully digital distance measurement sensor and streams values
in form of numbers (absolute distance in mm) at high speed. It comes pre-
calibrated.

Principle: Time of Flight


Range: Approx. 14m (in non-sunlight conditions about 5-6m under direct
sunlight)
Range resolution: 5mm
Accuracy: 2cm (in precision mode)
Field of view: 2
Update rate: Above 1kHz (in speed mode) up to 600Hz (in precision
mode)
Supply voltage: 10-20VDC max (10-15V advised)
Supply current: 50mA@12V in general environment, 150mA worst case
situations
Number of interfaces: 4
Interface1: UART, +5V level, up to 115200,8,N,1, user programmable
Interface2: TWI (I2C compatible). +5V level, master or slave
Interface3: SPI (shared with JTAG), one CS line, +5V level
Interface4: Two user I/O lines, +5V level, e.g. for PWM, interrupts, LEDs
etc.
Auxiliary interface: +5V and reset input available on connector

7 | CERN - European Organization for Nuclear Research


Expansion: SDK available
Connector: 15 pin DF13
Size (circa): L 35 x W 30 x H 18mm
Weight: 8g or 10g (depending on protection case)

2.3 Operating modes


TeraRanger One can operate in two different ways: fast mode and precision mode.
In fast mode TeraRanger One takes a fixed time to perform the measurement
(around 1 ms), in precision mode the time depends by the distance of the object
but the measure is more accurate.

2.4 Impact of the material on the detection efficiency


According to technical specifications provided on TR1 website, the nature of the
material has no impact on the detection efficiency with the exclusion of fully
transparent media. Accuracy is not impacted by the material, only the read-out
rates (slower on most difficult materials).

3. Using TeraRanger One for TIM

3.1 Arrangement
As a first approach the sensors were mounted inside the RP wagon at the bottom
and facing the floor in order to detect objects below the wagon.

Another important issue was to determine the number of sensors required to


achieve the safety volume described in section 1.3 as it defines the required
hardware resources. In the following sections different location setups are
presented for the TeraRanger sensors.

3.2 TR1 placed to avoid field of view overlapping


The minimum number of TR1 sensors required to create a safety surface under
the RP wagon can be achieved so that the Field of View (FoV) of each sensor do
not overlap with its neighbor. According to specifications the TR1 FoV is 2. The
RP arm being 1.7m long, we can assume a threshold detection distance (see
Figure 5) of 2m from the wagon. At 2m the detection surface can be calculated
as follow:

= . tan

With H = 200cm (the distance between the sensor and the maximum
measurement distance) and = 2 (FOV angle divided by 2).

8 | CERN - European Organization for Nuclear Research


2 X
TR1

H = 200cm

Figure 5 Field of view principle

The detection surface can be deduced from the previous equation as being
14x14cm. At a 2m distance from the train, the 30cm-wide wagon can almost be
covered by 2 TR1 (see Figure 6). The advantage of the solution is that it reduces
the number of sensors required. It also avoids potential cross-talk between the
sensors, thus ensuring no interaction between them. However, blind areas remain
if the sensors are positioned as suggested in Figure 6. Consequently,
objects can potentially enter the safety volume without being detected and hit the
RP arm.

30cm

Wagon front view


TR1 TR1

Blind area Blind area

Blind area

Minimum full
200cm detection
distance

Safety volume Safety volume

Threshold
detection
distance
28cm

Figure 6 Detection coverage at 2m from the wagon without FoV overlapping

9 | CERN - European Organization for Nuclear Research


3.1 TR1 placed to reduce blind areas
The distance between the TR1s is reduced in order to reduce blind area as depicted
in Figure 7.

30cm

Wagon front view


TR1 TR1 TR1

Blind area Blind area


Blind area Blind area

200cm
Safety Minimum full
detection
volume
distance
Safety volume Safety volume

Threshold
detection
distance
28cm

Figure 7 Safety volume created with FoV overlapping

Positioning the sensors closer one to the other allows adjusting the height of the
safety volume. The closer they are, the higher the volume will be. This also means
than their Field of View overlaps and it may cause cross-talk between the sensors.
According to the datasheet, the TR1 do not suffer from this effect.

10 | CERN - European Organization for Nuclear Research


3.2 Taking into account the TIM travel speed
The sensors must tilted in order to compensate the 6km/h TIL traveling speed as
illustrated in Figure 8.

TIM wagon RP wagon TIM wagon


TR1

Traveling direction

Deployed Threshold
RP arm detection
distance

Floor

Figure 8 Sensors tilted to compensate traveling speed

3.3 TeraHub mechanical holder adapted for TIM


The mechanical holder is designed to be screwed into the bottom part of the RP
wagon (Figure 9).

Figure 9 - TeraHub holder

11 | CERN - European Organization for Nuclear Research


CHAPTER 2 THE TERAHUB BOARD
A board, so-called TeraHub, was designed to read eight TR1s. It is equipped with an ARM
Cortex-M3 processor able to achieve the functionalities required for this project.

1. Specifications
TeraHub has the following specifications:

ARM Cortex-M3 processor from ST Microelectronics. Internal frequency:


72MHz.

Up to 8 multiplexed TR1

OSD functionality

Interface1: USB

Interface2: UART, +3.3V level

Interface3: CAN

Supply voltage: 12VDC

Dimensions: 50x50mm board

Three communication interfaces were embedded in order to guarantee flexibility


for future re-use of the board.

Figure 10 The TeraHub board

12 | CERN - European Organization for Nuclear Research


2. Safety redundancy
The collision detection, being a safety system, needs to be robust and reliable.
Moreover, TIM is operating in a radioactive environment so a fault mitigation
scheme needs to be adopted. An architecture based on a full duplex is proposed
to achieve the desired reliability such as depicted in Figure 11. Two identical and
independent TeraHub boards are used. Each of them has its own detectors and
whenever a threat is detected each system can trigger its own alarm to the TIM
controller. If both alarms are activated this confirms that an object was detected
and the threat is real. If only one alarm is triggered there might be an issue with
one of the two TeraHub boards or sensors. In this case the operator will have to
analyze if an object is actually in the path and take an appropriate decision.

TIM controller

TR1 Alarm 1 Alarm 2 TR1

Up to 8 Up to 8
TeraHub TeraHub TR1
TR1

TR1 TR1

Figure 11 Two identical TeraHub-based systems used in duplex

One issue to address is the positioning of the redundant sensors. Due to their
size, two sensors cannot monitor exactly the same volume. Consequently, the
sensors may not trigger at the same time, or only one may trigger because the
second sensor does not see the obstacle at all. In this case the redundancy is not
efficient.

3. Board electrical test


TeraHub embeds a voltage shifter in order to electrically interface the processor
(+3.3V) with the OSD (On-Screen Display) chip (+5V). This shifter is mounted in
a thin quad flat 12-terminal package with a 1.7x2.0x0.5mm body. This type of
package is difficult to solder as the solder paste is manually deposited on
0.5x0.22mm pads. Moreover, an offline continuity test cannot be performed
electrically nor visually as the pads are not accessible.

An online test was performed while the component was powered. This consisted
of applying a positive voltage on port A and checking that it is correctly shifted on

13 | CERN - European Organization for Nuclear Research


port B. This was only possible by programming the microprocessor so that it
applies the desired level (low or high) on its IOs.

The task here was to have different tests:

1. Apply all 1 on the IOs to verify that the voltage is correctly shifted

2. Apply a 1010 pattern (alternate 1 and 0) to check that there are no


shortcuts between two adjacent pins

Each TeraHub board was tested to ensure the correct soldering of the voltage
shifters.

14 | CERN - European Organization for Nuclear Research


CHAPTER 3 - FIRMWARE
The firmware is the core part of TeraHub. Implemented on the Cortex M3 processor, it
guarantees flexibility, allowing possible future changes. Two versions were developed: one
to be interfaced to a PLC and one to be interfaced to a PC (or an industrial PC).

The main task of the firmware is to read all the distance sensors and compare their values
to a fixed threshold. Therefore, TeraHub has to notify an alarm signal in the case one
sensor returns a value under the threshold, meaning that an object was found inside the
security volume.

As default, there are eight TR1 sensors connected to TeraHub. In the present project the
TIM controller is composed of PLC modules and TeraHub has to interface with them only
through digital IOs. Further explanations are in the next chapter.

1. Specifications

1.1 Brief description


The generic firmware has the following specifications:

Sequential reading of each TR1 sensor

Frame error check on incoming data

CRC8 check on incoming data

Distance check

Number of warnings check

Number of received frames check

Interface with the upper level

Flags on digital outputs

The actual implementation changes according to the firmware version.

1.2 Distance check


Distance values are continuously read by the program. Each value is compared to
a distance threshold, if the value is lower than the threshold, the program triggers
an alarm signal. Depending on the firmware version, the alarm can be a digital
parallel output or a message sent through a serial line. The version also affects
the nature of the distance threshold: it may be a fixed value given by the firmware
or it may be adjustable through the serial connection.

15 | CERN - European Organization for Nuclear Research


1.3 Data integrity check
In order to ensure that the data coming from the sensors is not corrupted, two
controls are performed. First the firmware verifies the integrity of the data frame
by checking the frame header. Then a CRC8 control is implemented on the whole
data packet. If the incoming data is corrupted the firmware triggers a warning
signal.

1.4 System check


Other controls are performed. Each second the number of occurred warnings and
the number of received distance values are counted. Both are compared to fixed
thresholds: in the first case the value must be lower while in the second higher,
otherwise an alarm signal is triggered. The warnings are counted in order to
prevent failures in the sensor or in the communication system, whereas the
number of received distance values is counted to prevent a lack of information.
Indeed, since TIM is moving, too few values can cause blind areas between two
full sensors reading cycles, in which it is not possible to know the distance of the
objects. The faster TIM moves, the quicker the firmware has to retrieve data from
the sensors.

1.5 Upper level interface


After the data processing, the program communicates with the high level interface
implemented on TIM. Depending on the firmware version two different interfaces
are available. The first one is made up of digital IOs to be interfaced to a PLC
system. The second one relies on a serial communication. Further explanations
are in the following section.

1.6 Output flags


Every firmware version has two digital outputs which signal the presence of an
object under the given threshold. If an object is detected, both the two outputs
supply a digital 0. The two outputs switch to a logic 0 in the presence of system
errors as well.

16 | CERN - European Organization for Nuclear Research


2. Simplified structure

Start main Start wait

System init. Wait for an external


trigger
TH init.
No
Received?
Call wait

System check Yes

End
Alarm? Yes

Call wait

For n = 1 to 8

Get the distance


from sensor n
Data integrity
check

Distance check

Alarm? Yes

Call wait

Update system
paramaters

Figure 12 - Flowchart of the firmware

The picture above shows a simplified flowchart of the firmware. The


communication protocol to the upper level is not taken into account, as it can
change substantially according to the version.

The core part of the firmware is directly implemented in the main function, where
an endless loop reads continuously the distance values from the sensors. As the
program starts, an initialization phase takes place where all the TR1 sensors are
tested and set in the default operating mode. In this phase the default settings
are defined by firmware and the users are not allowed to change them. A second

17 | CERN - European Organization for Nuclear Research


initialization follows, in this phase all the thresholds are set and in some versions
of the firmware it is possible to change them run-time.

After the initialization, the system puts itself in a pending state, waiting for a start
signal from the upper system. The signal can be either a digital input or specific
message on the serial connection, depending on the version.

In the case of an object being found under the given threshold or a critical error
occurs, the system stops itself again, waiting to be re-armed from the upper level.

3. Firmware versions
Several versions of the firmware were developed.

3.1 Version 1
The first version is the software framework of the firmware. In this version the
standard library for the communication TeraHub TeraRanger was developed, as
well as the main structure of the firmware. The following versions add or remove
features but dont change this main skeleton. In this version, a simple serial
interface (UART) to send and to receive basic data from TeraHub was developed,
just as a test.

3.2 Version 1.1


In this version the UART interface to the upper level system was improved. More
features were added, a large set of commands are available to send and retrieve
data to and from TeraHub. One piece of software was also developed in C for
Windows to communicate easily with the board. However, the UART interface
works in polling mode, therefore slowing the system. Thus, another version was
developed.

3.3 Version 1.2


The final UART-interface version. The serial communication to the upper level
works in interrupt mode, therefore not affecting the normal operation of the
program. Moreover, even more commands are available. To avoid errors and to
simplify the handling of the messages, a communication protocol was embedded,
with fixed 8-bytes length frames and transmission buffers.

FRAME DATA DATA DATA DATA DATA DATA DATA/FRAME


START END

To interact with TeraHub a full GUI piece of software for Windows was developed
as well (further information in the next chapter).

18 | CERN - European Organization for Nuclear Research


2.4 Version 1 NO UART
This version of the firmware was thought for a PLC environment. The present TIM
controller is indeed a Siemens PLC system. In this version the serial interface is
no longer available, some digital IOs compose the interface instead. TeraHub
becomes completely independent: it is not possible to access or modify its data
anymore. The control is given by 2 digital inputs which can only enable and reset
TeraHub. In the event that an object is detected, TeraHub sends a stop signal
through two digital outputs.

2.5 Version 2.0


In the previous versions the sensors are read sequentially. Every time TeraHub
needs a value from a sensor, it sends a message and after waiting a certain time
(due to the measurement) it gets the value. Since this time is basically wasted,
in order to retrieve more data, TeraHub can request values from the other sensors
in the meantime. In this firmware version TeraHub performs parallel readings of
the sensors, therefore increasing the acquisition speed. However the time delay
between the value request and value receiving is variable, making it difficult to
synchronize the reception of the values.

19 | CERN - European Organization for Nuclear Research


3. Firmware development
All the firmware versions were developed in C. The used IDE is Keil uVision 5 with
the help of a comprehensive software tool, STM32Cube. This tool provides useful
software libraries and hardware configuration wizards.

Figure 13 Development environment

20 | CERN - European Organization for Nuclear Research


4. Firmware test
The aim of the test was to ensure the reliability of the system, in particular to
check the failure rate.

4.1 Description

Figure 14 Test bench front

To test TeraHub a special carriage was used. The sensors were fixed over the
carriage, all aiming at a fixed target. The carriage, moving back and forth,
simulated the presence of objects at different distances. The goal of the test was
to ensure a response from TeraHub when it moved beyond the distance threshold.
In order to the test the reliability hundreds of cycles were made.

Both the carriage and TeraHub were connected to a PC in a Linux environment.


The carriage was connected via Modbus and TeraHub via UART, both adapted to
USB. We developed a piece of software to control them at the same time. The
software had to move the carriage over the threshold and then to expect an alarm
from TeraHub, every missing alarm was counted. The position of the carriage was
acknowledged by an encoder mounted on the carriage structure.

21 | CERN - European Organization for Nuclear Research


Figure 15 - Test bench side

Since the TR1 sensors require an optimal calibration we also checked their
reported distances.

4.2 Test results


Thousands of cycles were carried out. TeraHub never failed in the obstacle
detection but, as pictured below, there was a mismatch between TeraHub
measured distance threshold and the real distance threshold.

450000
400000
350000
300000
250000
Measured threshold
200000
Real Threshold
150000
100000
50000
0
507

645

783

921
139
185
231
277
323
369
415
461

553
599

691
737

829
875

967
1
47
93

Figure 16 Result of one test

22 | CERN - European Organization for Nuclear Research


Figure 16 shows the result of one of the tests. On the x axis the cycle number
(1000 in total) is reported and on the y axis the distance of the sensors from the
target (measured in resolution of the encoder) is shown. The red line represents
the distance threshold. Beyond the distance threshold the TeraHub should notify
an alarm. However, the blue values represent where the TeraHub actually sent
the alarm, therefore where the TeraHub thought the threshold was.

4.3 Conclusions
The program never failed in the obstacle detection. However the sensors needed
a better calibration, since the measured values detached from the real ones. In
the end the problem was solved with a software adjustment.

23 | CERN - European Organization for Nuclear Research


CHAPTER 4 UPPER LEVEL INTERFACE
The upper level interface allows the user to monitor and to control TeraHub. Two
different interfaces were developed: one for PCs and one for PLCs.

1. PC interface

1.1 Description
This interface was thought mainly to test the functionalities of TeraHub. It
provides data communication with the board, allowing the user run- time control
of the system.

1.2 Electrical characteristics


TeraHub communicates with the PC through the UART module. However, this
protocol does not allow a direct communication due to the different electrical
characteristics. It is therefore necessary to adapt the signal to the RS232 levels
in order to connect the board to the serial port of the PC.

Figure 17 - PC adapter

The board shown above, designed at CERN and provided by an external company,
converts UART signals in RS232 signals (and vice-versa) through the MAX3232
chip. It can work with a supply voltage of maximum 24 V.

1.3 Data link layer


Depending on the firmware version, different ways to communicate were
developed. In the first versions the length of the data frames was variable. Both
the PC and TeraHub recognized the incoming frame by checking the first byte and
the communication was performed in polling mode. In the last firmware version,

24 | CERN - European Organization for Nuclear Research


an interrupt-oriented protocol was implemented instead. The length of the frames
is fixed and first byte always represents the start of the frame. However, no error
detection system was embedded.

4.4 User Interface


The last firmware version of TeraHub is optimized to be interfaced with a specific
piece of software: TeraHub Control Panel.

Figure 18 TeraHub Control Panel

By using this program it is possible to have an overview of the status of TeraHub


as well as to check the status of every single TR1 sensor.

Two working modes are available: automatic and manual. In the first mode all the
sensors are read automatically and when an event occurs (such as an alarm or a
warning), the program automatically displays a message. It is also possible to
modify the distance and the frequency thresholds run-time. The second mode can
be used for testing the sensors; TeraHub is stopped and the user can either read
each single TeraHub, or retrieve the measured distance or get general
information.

25 | CERN - European Organization for Nuclear Research


Figure 19 - Error message when an object is found

When an alarm occurs, TeraHub stops reading the sensors, awaiting an action
from the user. To restart TeraHub again it is necessary to click the resume button;
it is also possible to read every single sensor and to disable some TeraHubs.

A found object is not the only event that can trigger an alarm. Different system
errors may occur in TeraHub and the program can supply details about their
origin.

Summarizing, the following events can trigger an alarm:

An object was found under the distance threshold.

Too many error events occurred (for example a TR1 is not working
correctly or several communication errors occurred between TeraHub and
the sensors).

TeraHub reads the sensors too slowly.

26 | CERN - European Organization for Nuclear Research


Figure 20 - Error message when the reading speed is too slow

When TeraHub fails in keeping the number of reading cycles over the threshold,
an alarm is triggered. A reading cycle is performed when TeraHub reads all the
distance sensors in sequence, the reading frequency is the number of reading
cycles performed in one second. This threshold can be adjusted by modifying the
Min frequency threshold textbox.

4.5 Application software development


The application software was developed in C# in the MS Visual Studio
environment. The latter provides class libraries to easily integrate the graphic
interface and the serial communication in the code.

27 | CERN - European Organization for Nuclear Research


2. PLC interface

4.6 Description
The PLC interface is, basically, the simplified version of the PC interface. In this
version no serial communication is available; the communication is performed
only through the digital IOs of the board. It is neither possible to modify any
parameter of the board nor possible to receive data from it.

4.7 Electrical characteristics


Only two digital inputs and two digital outputs are available. Since TeraHub logic
levels are CMOS but PLCs work at 24 V, also in this case an adaption board is
necessary.

Figure 21 - PLC adapter

As in the previous interface, the board was designed at CERN. The board performs
two operations at the same time: with 2 relays it steps up the voltage of TeraHub
from 3.3 V to 24 V and with 2 voltage dividers it steps down the voltage of the
PLC from 24 V to 3.3 V.

4.8 Communication with the board


Since only a few digital signals are available, the functionality of TeraHub is
reduced to the minimum. The signal are used in the following way:

In order to get redundancy on TeraHub output, the two outputs behave


in exactly the same way. They only signal the presence of an alarm and
they do not provide any information about the details. In the standard
configuration the two outputs are set to 0 when TeraHub is stopped, when
an obstacle is detected or when an error occurs; they are set to 1 when
the system is working correctly and no obstacle is detected.

28 | CERN - European Organization for Nuclear Research


One Enable input: when this input is high TeraHub works automatically,
reading all the sensors; when is low it stops, setting the outputs to 0.

One Restart input: when a pulse is sent through this input, TeraHub is
restarted. This input is used to restart TeraHub in case an object was
detected.

Unlike the PC version, it is not possible to change the distance and the frequency
thresholds run-time. It is therefore necessary to reflash the firmware to perform
setting modifications.

3. TIM interface

4.9 Description
The TIM controller is composed of Siemens PCL modules. Therefore the interface
implemented is the one used for the PLCs. The train is controlled through a
software interface developed in LabView.

Figure 22 - TIM interface

29 | CERN - European Organization for Nuclear Research


The train is allowed to move only when TeraHub outputs are high, otherwise it
has to stop.

4.10 Interface implementation

TeraHub
control

Figure 23 - TeraHub control in the TIM interface

The monitor of the input/output of TeraHub is placed into the program. Some
dedicated buttons perform actions directly on the input of TeraHub while the two
outputs are ANDED to be displayed as a light.

30 | CERN - European Organization for Nuclear Research


Figure 24 - Ladder code of the TeraHub control

31 | CERN - European Organization for Nuclear Research


PRESENT AND FUTURE OF THE PROJECT

TeraHub will be installed in the next maintenance stop, planned for December 2015. A
single TeraHub board with a strip of eight TR1 sensors will be placed in front of the RP
wagon, connected to the PLC controller.

In a future application additional tools will be installed on TIM, therefore several TeraHub
will be placed to create a larger and a user defined safety volume. The boards will be
connected together in a CAN-bus3 network, therefore data communication will be possible
between the PLC controller and the boards.

A further application is to use the TR1 sensors not only to create the safety volume around
the wagons, but also to take distance measurements.

3
Controller Area Network bus, a communication protocol.

32 | CERN - European Organization for Nuclear Research

Вам также может понравиться