Modularity in the Phase II Upgrade of the ATLAS Strip Tracker

Ian Wilmut

AbstractFor the phase II upgrade of the ATLAS tracker the Silicon strip tracker will be fully replaced by a larger system, which will need to be accomplished with fewer resources and on a tighter construction and installation schedule than for the current system. One measure to achieve this goal is by the use of modularity throughout the tracker project. Modularity in this context is the use of a number of identical subsystems with simple interfaces to the rest of the system. The modular objects can be produced in dedicated assembly sites and will be fully tested before being used in the next steps of the tracker integration. In this presentation we will illustrate this principle with various examples for modularity throughout the phase II strip tracker project, among which will be the local detector supports (staves/petals), the internal (type I) services and the segmentation of the evaporative cooling plant. We will demonstrate the various advantages this modular approach promises, comparing it with our experiences during the integration of the current ATLAS tracker. We will also discuss the limitations in achieving full modularity due to the finite size, geometry and local non-uniformities of the system and how they can be addressed.

What I will talk about• What Modular and what we mean by modular• Where we are trying to take this approach in the

ATLAS Upgrade. Examples:– Service modules– Staves– Cooling plant

• What we did before– What we are changing

• Benefits of a modular detector• Modular vs common parts• Challenges in modular construction

What the construction industry mean by modular construction.

• The construction industry has been exploring modular buildings for many years.

• In short, they aim to pre-fabricate building sections off site during the groundwork phase and then assemble the building very quickly.

• Building 41 at CERN and Ridgeway House at RAL were both built like this

Images from http://www.rollalong.co.uk/http://www.wikipedia.com/

What has this to do with detectors?• We care about the construction time.• If we rewrite the timeline on the last page for the ATLAS Upgrade it might look like

this:

R&D and Design

FDR and procurement

Module assembly

Service assembly

Structure assembly

Integration Commissioning

R&D and Design

FDR and procurement

Module assembly

Service assembly

Structure assembly

CommissioningInte grat ion

Time Saving

• We could save significant time building and assembling the detector if we can de-serialise the build.

• A modular build could de-centralise the build so we don’t need an army of technicians working abroad for extended periods

• A modular build could give us the chance to get really good at making things, rather than “crafting” them each time and knowing what we would do differently next time

What do we mean by modular?• The dictionary doesn’t help that much:

– OED “each of a set of standardized parts or independent units that can be used to construct a more complex structure…”– Merrium-Webster “…any in a series of standardized units for use together…”

• So for a detector build it suggests that the system is assembled from as few similar systems as possible– This makes sense, and for me is linked very closely to the idea of a learning curve

• But for there to be real saving the “modules” must be minimally customised as they are assembled• In the ‘60s Bruce D. Henderson from BCG in Boston (management consultants) started to formalise the idea of a learning

curve– In short there are significant savings in construction time as you become familiar with the task the graphs below assume a very modest

20% increase in speed for each doubling of output.– The left hand graph shows the cost/time per item for a single assembly– The graph on the right shows the total cost/time for a system of 1000 assemblies depending on the number of modules in the system

• Empirically the SCT build was about here (note item axis values are arbitrary)• Ideally we want the ATLAS upgrade to be here

0 5 10 15 20 25 30 35 40 450

0.2

0.4

0.6

0.8

1

1.2

Number of items produced

Cost

/tim

e of

item

0 200 400 600 800 1000 12000

0.5

1

1.5

2

2.5

3

3.5

4

4.5

Number of types of module in the system

Tim

e ta

ken

for b

uild

ATLAS context

What we can make modular and how• The modules – We have long and short strip types in the barrel,

and 7 types in the endcap• The staves – a structure with 24 or 26 modules upon it

• The services – prefabricated into between 20 and 36 units per end

• The cooling system– 10 identical cooling plants for two “swappable”

spare plants for maintenance/disaster recovery

Modules to structures in the SCT (Barrel)

We had 2112 identical barrel modules

The services and brackets were laid by hand onto the cylinder

The whole cylinder was populated with services

The modules were all mounted

Structures to detector on the SCT barrel

The populated cylinders are then inserted one into the next and their services opened out.

What we propose for the Upgrade• The cylinders will be exclusively mechanical devices,

no services will be laid in before modules are added.• Modules will be installed into a pre-built structure

on individual staves containing 26 modules and all the associated services.

• Although we will have 12272 (6 x SCT) modules on the barrel we only have to install 472 (0.25 x SCT) staves .

• The services no longer need to be integrated/folded out by having a service break at the end of the cylinder

STAVES NOT MODULES

Integrating all the “on cylinder” items

• The key design feature of the stave is the combination of modules, cooling, electrical and optical services into one easy to install unit.

• All of the services are terminated at the end of the stave.

• The stave can be built and tested as a single unit

• The stave is a pair of CFRP skins with a carbon foam/honeycomb core, a cooling pipe is embedded in the core. Kapton power tapes run the length of the stave between modules and core.

Real staves• Image on the left is a full size

thermo-mechanical prototype with old design locking points

• Image below is a 4 module electrical stavelet for electrical testing

• Present planning expects we will build staves 13 modules long (1.3m) housing 26 modules.

Stave insertion

• Staves can then be slid into the cylinders and locked in place

• Once in place the tooling can be removed and the services connected.

Problems with modular staves• One size doesn’t quite fit all• The first problem on a barrel structure is the two ends (ATLAS calls

them A and C)

• So we immediately need A and C end staves• There are other variables as well:

– Long and short strips– U and V layers (variation in stereo)– Orientation of locking points– Service connector orientation

• To cope with this approach we are proposing a “semi modular” approach

A C

Semi Modular staves

Top

bus

(str

aigh

t) Temporary SMC connection for testing

Temporary PPB0 connection

Bott

om b

us (+

ve o

r -ve

)

Temporary PPB0 connection

Temporary Wire bonds

Top side Bottom side

Final SMC

final PPB0 connection

final PPB0 connectionFinal Wire bonds

Top side Bottom side

• We will build completed staves from kits of parts that allow the stave to be configured for its exact location

• We expect 8 variants (long & short strip, A & C ends, U & V stereo)

• We hope this “semi-modular” approach will provide the benefits of modularity, but will give us the flexibility required for to meet the physics requirements

SERVICE MODULES NOT SERVICES

SCT Service management

ATLAS Upgrade modular service management

Stave cooling pipe (in plane with stave, looped to deal with any movement during thermal contraction, include some electrical break)

ID interlink

Stave Connector (mounted to interlink for strain relief)

Stave

SM Electrical Services

CO2 ip/op

FO Connectors

SM sealing plate

PP1 Connectors

Installing service modules

Mechanical prototype Service Module being offered up to structure mock up

Service module in place with possible pipework routing at barrel end

Close up of pipe work – note the identical structures coming from each service module

22

Number of cooling modules

0.0%

10.0%

20.0%

30.0%

40.0%

0.0% 10.0% 20.0% 30.0% 40.0% 50.0%

percentage of service sets across barrels (=material)

per

cen

tag

e o

f d

ark

fib

re (

=co

st)

1/28

1/36

1/32

1/20

1/24

Challenges in service modules design• Our patch panels need to be very compact (i.e. we

need a patch panel at the end of the detector)– We have committed to manifolding inside the detector

• All the services need a connection at the stave/service module interface– Cooling connections will be orbitaly welded to save mass –

modules on staves will be multiplexed on the stave to reduce services

• The number of staves per cylinder is not optimal for identical service modules– Service modules need to be able to be configures for a

specific location

Detail on the Service Module• We expect between 20 and 36 service modules per end of

the detector• They will all be identical and interchangeable• In the event of service failure during the build they will be

swapped out not repaired in situ• The cooling pipes will manifold between 8:1 and 8:3 • The electrical cables will be sorted in the service module

to deliver combined services at the stave and service types at the ID patch panel

• The opto will be sorted in the service module to ensure that any ribbon failures have distributed impact rather than a large local “hole”

COOLING PLANT

26

Cooling system• Cooling is a critical infrastructure for a tracker at

LHC• So far we have discussed modularity in local

supports (which typically includes cooling channels/evaporators), and in services, both also part of the cooling system

• What about the plant? Can we push the concept of modularity there as well?

• Note: the work on the cooling plant in the Tracker upgrade are less developed than other aspects of the tracker

27

Current ATLAS• Here we will not discuss the various adventures we had with evaporative

cooling, but the issue of modularity• One plant to cool SCT and pixels

– Design: 70kW at -25°C, 1.1kg/s of C3F8 (6 compressors)– Plant has been installed and commissioned in pit in parallel with ATLAS

• For R&D and assembly of detector components smaller plants have been used – which were critically different from final plant– For example single-stage instead of two stage compressors– Some vital lessons could only be learned at a very late stage, the hard way

• e.g. mechanical stress on compressors too high in final plant

28

Evaporative cooling for ATLAS Upgrade

• Baseline is CO2, most likely concept 2PACL• Challenge is scaling from existing plants (2kW) to phase II (by factor ~100)

– Two steps• Step 1: scale plant capacity by factor ~10• Step 2: use 10 plants in parallel

– Exact distribution to detector not yet decided, probably split into strips and pixels– Would match 10 existing PP2 areas inside ATLAS for close-to-detector distribution

• Apart from reducing the technical challenge of scaling, this has other benefits– Cooling plants of the final size/design can be used during assembly and

commissioning of tracker subdetectors• This should help us identify any issues with the plant design or other aspects of the

cooling system relatively early– Plan to have 2 additional plants as spares/for maintenance

• Design for simple interfaces (fluid and control) for fast and arbitrary swap– Complete isolation of circuits in different plants limits damage if something

goes seriously wrong (contamination)

SUMMARY

Benefits of Modular• Reduce learning time in the build phase of a detector• Make detector elements interchangeable

– Failures can be replaced rather than repaired• We can afford to prototype much more of the detector• Less “craft” in detector build

– We will need less technician time at CERN for the build, the time will instead be needed at contributing institutes

• Full system prototype will be easier and more representative– A prototype with one service module and appropriate staves will be

very close to a full system prototype – this will be a very reasonable goal of a system test.

• The less items we have to optomise the better we will do– One significant lesson from the SCT is that to many systems were being

built for the first time on the real detector

Configurable modules• Detector physics is badly suited to 1000s of identical objects – but

it certainly has 10 lots of 100 similar objects• We are aiming to build:

– 8 flavours of staves from a standard kit of bits– Up to 72 service modules that can be configured 3 or 4 ways for

different locations– 1 structure that can accommodate all of the variations in the staves and

service modules– 10 cooling plants that are identical but configured and run for specific

loads• Just down the road in Cowley is the Mini plant, they produce 200

000 cars a year (one every 68 seconds) one line produces 5 body styles in any order from a parts list of 6000 parts. – By the definitions I use here a mini is very similar to a set of “configured modules”