Embed Size (px)
Citation preview
UNIVERSIDADE FEDERAL DO RIO DE JANEIRO
ESCOLA POLITÉCNICA
DEPARTAMENTO DE ELETRÔNICA E DE COMPUTAÇÃO
SISTEMA WEB PARA MONITORAÇÃO DE UMCALORÍMETRO DE ALTAS ENERGIAS FINAMENTE
SEGMENTADO
Autor:
Andressa A Sivolella Gomes
Orientador:
Carmen Lúcia Lodi Maidantchik
Orientador:
José Manoel de Seixas
Examinador:
Miguel Elias Mitre Campista
Examinador:
Frank Detlef Block
Examinador:
Ignácio de Bediaga Hickman
DELDezembro de 2013
AGRADECIMENTOS
Primeiramente, à minha mãe, que durante o período de graduação incentivou da
forma que pôde para que fosse possível a conclusão desse curso.
Ao Seixas e à Carmen, que como orientadores durante a iniciação científica, iniciado
no segundo período de graduação, sempre foram excepcionais, contribuindo diretamente
na minha formação profissional e me atendendo prontamente no que fosse necessário.
Agradeço principalmente às oportunidades oferecidas, confiança e investimentos deposi-
tados.
E por falar em abertura de portas, agradeço aos amigos presentes durante todas as
idas e vindas no CERN, que de certa forma, fizeram cada estadia peculiarmente especial e
certamente tornaram a experiência de morar longe do Rio de Janeiro muito mais divertida.
Em especial, aos brasileiros Enoque, Andreza, Chiquito, Torres, Júnior, Frias, Bruno (e
Claire), Kaio, Dhiana e Bené. Aos americanos Brian, Rob e Monica. Aos espanhóis, Sara,
Carlos e José. Aos italianos Andrea, Luca e Francesca. Aos portugueses Felipe e Gabriel.
Aos meninos do Le Club, por suas inúmeras e divertidas festas.
Agradeço também a Ana Henriques e ao Bob, líderes do TileCal em períodos
distintos pelo acolhimento, confiança e inúmeros convites de retorno ao CERN. Obrigada
pelo reconhecimento de todo trabalho sempre feito com muita dedicação.
Aos amigos de graduação, Vinícius, Patrick, Jesusinho, Rafa, Estevam, Felipe de
Leo (e tantos outros) que nos momentos críticos e de total desespero fizeram parte dessa
jornada, incentivando período a período.
Ao Casé, coordenador do curso de engenharia eletrônica, pelas inúmeras inter-
venções de regularizações em inscrições de disciplinas e processos acadêmicos. O SIGA
melhorou muito, mas eu não chegaria até aqui sem a disponibilidade e pro-atividade dele.
Aos amigos do LPS, Balabram, Camila, Fabiano e Aninha, tornando os momentos
de trabalho no laboratório mais amenos.
E finalmente, um agradecimento especial aos meus sócios na TWIST: Fernando,
Lau, Évora e Grael. Vocês fazem parte de um pedaço importante da minha história e em
momentos difíceis são capazes de compreender e segurar qualquer problema em conjunto.
É gratificante poder trabalhar com pessoas muito queridas e competentes.
ii
No mais, agradeço ainda aos demais amigos, por todas as palavras de incentivo
e compreensão quando furei qualquer evento: Nanda, Patrícia, Gabi, Mônica, Andrea e
Bruna.
iii
RESUMO
As atividades deste projeto estão inseridas na colaboração internacional entre
UFRJ e detector de partículas ATLAS (A Toroidal LHC Apparatus), que conta com
a participação de cientistas de diferentes institutos e universidades no mundo. O detec-
tor ATLAS está acoplado ao acelerador LHC (Large Hadron Collider) do CERN (Centro
Europeu de Pesquisa Nuclear) que realiza colisões de partículas com até 14 TeV. No calorí-
metro hadrônico de telhas (TileCal) do detector ATLAS, quando as partículas se chocam,
a luminosidade produzida é absorvida e convertida em sinais. O TileCal é composto por
3 barris, cada qual igualmente divido em 64 módulos. Cada módulo possui até 45 canais
de leitura eletrônica.
A reconstrução de uma colisão caracteriza análises offline e é iniciada a partir da
análise dos dados adquiridos com diferentes níveis de granularidade de informações até
chegar aos canais. Nesta última etapa, a referência de canais conhecidamente danificados
pode ser alterada.
Neste contexto o sistema “Monitoring and Calibration Web System” (MCWS) foi
desenvolvido. O sistema apoia a análise offline dos milhares de canais de leitura eletrônica
do calorímetro, facilitando o trabalho dos membros do TileCal ao possibilitar a atualização
desta referência através de funcionalidades oferecidas. O sistema gera resultados (gráficos)
que são acessados pela web. O MCWS está instalado no servidor do CERN e é atualmente
utilizado pela colaboração, auxiliando-a ao disponibilizar até 99.6% de qualidade nos
dados adquiridos.
Adicionalmente, o TileCal divide-se em diferentes grupos, responsáveis por ativi-
dades específicas no experimento. Ao todo, existem 6 grupos e o compartilhamento de
informações entre eles faz-se necessário.
Neste contexto a plataforma, Tile-in-ONE, também desenvolvida, reúne os recur-
sos necessários para integração de diferentes sistemas e ferramentas, a fim de fornecer
em um único local todas as informações relacionadas ao calorímetro. O compartilha-
mento de informações, não exige nenhuma ação extra por parte dos colaboradores. Novas
funcionalidades podem ser estendidas através do desenvolvimento de plug-ins.
Palavras-chave: Calorímetro Hadrônico, Sistemas Web, Qualidade de Dados
Sumário
1 Introdução 1
1.1 Motivação . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2
1.2 Objetivo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
1.3 Organização do Documento . . . . . . . . . . . . . . . . . . . . . . . . . . 7
2 A Física de Altas Energias e Calorimetria 8
2.1 O CERN e o Acelerador de Partículas LHC . . . . . . . . . . . . . . . . . 8
2.2 Experimento ATLAS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
2.3 Calorímetro Hadrônico de Telhas . . . . . . . . . . . . . . . . . . . . . . . 13
3 Qualidade de Dados no TileCal 16
3.1 Análises Online x Offline . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
3.2 Análise Offline de Qualidade de Dados no TileCal . . . . . . . . . . . . . . 19
3.3 A Colaboração TileCal . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
4 Sistema Proposto 24
4.1 Análise do Problema . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
4.2 Análise dos Requisitos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
4.3 Proposta . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
5 Sistema Web de Monitoração e Calibração (MCWS) 31
5.1 Monitoração dos canais de leitura eletrônica . . . . . . . . . . . . . . . . . 31
5.2 Atualização do banco de dados de condicionamento do ATLAS . . . . . . . 33
5.3 Tecnologias utilizadas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35
v
6 Plataforma Tile-in-ONE 41
6.1 Arquitetura da Plataforma . . . . . . . . . . . . . . . . . . . . . . . . . . . 42
6.2 Dashboards . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45
6.3 Desenvolvimento de plug-ins . . . . . . . . . . . . . . . . . . . . . . . . . . 47
6.4 Tecnologias utilizadas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48
7 Conclusão 53
Bibliografia 56
A Produção Bibliográfica 61
Lista de Figuras
2.1 Representação aérea do LHC e seus detectores no CERN. Extraído de [1]. . 9
2.2 Esquema do detector ATLAS. Adaptado de [2] . . . . . . . . . . . . . . . . 11
2.3 Sistema de Coordenadas do detector ATLAS. Extraído de [3] . . . . . . . . 12
2.4 Calorímetro de Telhas do ATLAS (com suas 4 partições na cor verde)
envolvendo o calorímetro de argônio líquido. O Sistema Magnético e a
Câmara de Múons não estão ilustrados nesta figura. Adaptado de [4]. . . . 13
2.5 Estrutura de absorção e amostragem do TileCal. Extraído de [5] . . . . . . 14
2.6 Esboço das células do TileCal. Extraído de [4]. . . . . . . . . . . . . . . . . 14
3.1 Esquema do processo de análise do grupo DQ do TileCal . . . . . . . . . . 20
3.2 Documentações de ferramentas de auxílio a análises do TileCal dispersas . 22
4.1 Ilustração das 3 fases que resumem o processo de análise do grupo DQ. . . 28
4.2 Arquitetura do sistema proposto, MCWS. . . . . . . . . . . . . . . . . . . 29
5.1 Funcionalidade Bad Channels Lists do MCWS . . . . . . . . . . . . . . . . 32
5.2 Canais em detalhes no MCWS . . . . . . . . . . . . . . . . . . . . . . . . . 33
5.3 Resultados gerados pelo MCWS . . . . . . . . . . . . . . . . . . . . . . . . 34
5.4 Interface da funcionalidade para administração de usuários do MCWS . . . 35
6.1 Arquitetura da plataforma Tile-in-ONE . . . . . . . . . . . . . . . . . . . 44
6.2 Painel personalizado para o usuário rdecatr. . . . . . . . . . . . . . . . . 45
6.3 Exemplo de plug-in implementado na linguagem Python. . . . . . . . . . . 47
Capítulo 1
Introdução
Seja na área de pesquisa ou em ambientes corporativos, a adoção de desenvol-
vimento de software já é considerada uma opção de auxílio a modelos de trabalho. A
indústria de Tecnologia da Informação (TI) vem utilizando desde o início deste século
a terceirização em desenvolvimento de código de países onde a mão de obra é mais ba-
rata [6] [7].
Outra tendência de desenvolvimento de projetos de software atualmente [8] é a in-
terdisciplinaridade. Para sistemas complexos, é difícil oferecer soluções que não englobem
diferentes áreas de conhecimento. Combinar informação com conhecimento e expertise de
áreas distintas permite que pessoas com diferentes especialidades possam trabalhar em
conjunto em busca de novas metodologias, soluções e sistemas que atendam necessidades
globais [9].
Por outro lado, existem desafios relacionados a projetos de desenvolvimento de
software que acentuam-se ao englobar diferentes localidades e fusos horários. Neste caso,
é necessário que haja integração entre os diferentes grupos de tal forma que a comunicação
entre os envolvidos ocorra de maneira clara. Tal integração permite que pessoas contri-
buam individualmente com suas áreas de conhecimentos específicas, agregando valor à
soluções adotadas [8] [9].
O aumento do volume de dados gerados pela sofisticação cada vez maior de sen-
sores cria um novo desafio. É fundamental que projetos de desenvolvimento de software
2
tenham habilidades para lidar com dados em diferentes formatos, em alguns casos, não
estruturados. Adicionalmente, a necessidade de integrar fontes de naturezas distintas
evidencia problemas relacionados a sua qualidade.
Neste contexto, monitorar qualidade de dados torna-se fundamental. Ao apresentar
diversas dimensões, tais como interpretabilidade, forma de representação e credibilidade,
monitorar qualidade de dados é uma atividade que pode ser entendida de diversas for-
mas. O aspecto humano e principalmente o contexto em que estão inseridos contribuem
diretamente com tal definição. Sendo assim, a qualidade dos dados deve ser definida,
medida, analisada e monitorada de acordo com os dados, contexto e especificações de
usuários. Problemas podem impactar diretamente no desempenho de sensores de aquisi-
ção e, em caso de ambientes corporativos, podem inferir em competitividade de mercado.
Quando não identificados e corrigidos no momento correto, tais erros podem propagar-se,
culminando em perdas maiores [10].
O tema deste trabalho consiste no projeto e desenvolvimento de uma solução com-
putacional para auxiliar a monitoração de qualidade de dados de sensores de aquisição
sofisticados. O ambiente em questão é composto por diversos países, e as pessoas envol-
vidas podem estar geograficamente dispersas.
O desenvolvimento gradativo de ferramentas para apoiar outras atividades no am-
biente complexo no qual este projeto está inserido motivou a elaboração de uma plata-
forma de integração, também abordada neste projeto final de graduação.
1.1 Motivação
O CERN (Organização Europeia para Pesquisa Nuclear) [11] é um dos mais res-
peitados centros de pesquisa científica do mundo. Representando um dos maiores empre-
endimentos europeus, com 20 estados membros, além do envolvimento de 113 países por
meio da colaboração de 608 universidades espalhadas pelo mundo. O CERN atualmente
tem no LHC (Large Hadron Collider) [12] seu principal experimento. O LHC consiste
em um grande túnel na forma de anel, com 27 km de perímetro, instalado a 175 metros
3
abaixo do solo, em território suíço e francês.
Durante o experimento, dois feixes de prótons são acelerados em sentidos opostos
até alcançarem velocidades próximas a da luz. Ao colidirem, geram energia e os sub-
produtos das colisões são absorvidos por detectores posicionados ao redor dos pontos de
colisão ao longo do túnel subterrâneo. Os principais detectores do LHC são o ATLAS,
CMS, ALICE e LHCb.
O ATLAS (A Toroidal LHC AparatuS) [13] é o maior dos detectores do LHC sendo
operado por mais de 3.000 cientistas de 174 universidades e laboratórios, de 38 países,
incluindo 1.000 estudantes. O detector ATLAS é composto por 4 componentes principais
(do mais interno para o mais externo): o Detector Interno (ID), o Sistema de Calorimetria,
o Sistema Magnético e o Espectrômetro de Múons. O Sistema de Calorimetria é composto
pelos calorímetros de Argônio Líquido e Hadrônico de Telhas, sendo este último o foco
deste projeto de graduação. O experimento ATLAS gera um enorme volume de dados
(na ordem de 3,2 PetaBytes ao ano [14]), que precisa ser armazenado e processado.
As interações que ocorrem no detector criam um enorme fluxo de dados, que deve
ser monitorado e controlado através dos seguintes sistemas: Sistema de Trigger (de tal
modo que a taxa de eventos de 40 MHz é reduzida para uma taxa de 100 Hz para ar-
mazenamento em mídia permanente) [15], Sistema de Aquisição de Dados (canalizando
os dados do detector para o armazenamento) e o Sistema de Computação (analisando
milhões de eventos realizados por ano).
Os calorímetros do ATLAS têm como função medir a energia das partículas geradas
após a colisão [16]. Um calorímetro pode ser definido como um bloco de matéria que
interage com as partículas, fazendo-as decair em outras partículas menos energéticas e
mais estáveis. Ao decaírem, tais partículas liberam energia, medida pelo calorímetro [16].
Sendo amplamente utilizados em pesquisas relacionadas a física de partículas, ca-
lorímetros apresentam as seguintes vantagens:
• São sensíveis a partículas neutras e carregadas.
• Têm precisão proporcional a energia depositada: quanto maior a energia da partí-
4
cula, mais preciso é o resultado. Tal característica não aparece em outros detectores.
• A profundidade de calorímetros aumenta logaritmicamente com a energia, o que
torna possível o desenvolvimento de detectores mais compactos.
• Não necessitam campos magnéticos.
• Apresentam respostas rápidas, e este é um fator importante em um ambiente de
alta taxa de eventos.
• Podem ser segmentados, permitindo melhor visualização de eventos e medições de
energia mais acuradas.
O sistema de calorimetria do ATLAS é composto por dois calorímetros: eletromag-
nético e hadrônico, sendo este o calorímetro de interesse neste projeto final de graduação.
Composto por uma liga com aço, o calorímetro hadrônico possui telhas cintilantes como
material amostrador, e por isso também é chamado de TileCal (do inglês, Tile Calori-
meter) [5]. Quando uma partícula interage com o aço, as telhas cintilam, levando essa
informação luminosa, através de fibras óticas, até células fotomultiplicadoras, onde o sinal
luminoso é convertido em elétrico.
O TileCal é formado por três barris, cada um dividido, igualmente, em 64 módulos.
Existem até 45 canais de leitura eletrônica (em inglês, PhotoMultiplierTube ou PMT, cujo
sensor é o tubo fotomultiplicador) em cada módulo do detector. A passagem de partículas
ionizadas pelo TileCal produz luz, cuja intensidade é proporcional à energia depositada
pela partícula. A luz produzida se propaga através das telhas para suas bordas, onde é
absorvida e deslocada por reflexão interna total até as PMTs, onde é convertida em sinal de
corrente. Uma vez digitalizados, os sinais são enviados para o sistema de armazenamento
do calorímetro.
Durante toda a operação do TileCal, é fundamental identificar os canais de leitura
eletrônica ativos, mortos (sem funcionamento), ruidosos e os chamados “hot cells”, ou
seja, canais que apresentam saturação na digitalização dos sinais. O objetivo de identifi-
car esses canais é manter a referência de PMTs que estejam danificados sempre atualizada.
5
Esta lista serve para configurar a aquisição de novos dados e permite que as informações
resultantes das colisões, ao serem armazenadas, não sofram influência negativa de um
canal danificado. Ao final de cada análise, relatórios são gerados pelo grupo de qualidade
de dados do TileCal e os resultados encontrados são regularmente apresentados em reu-
niões da colaboração. Sendo assim, é necessário monitorar o estado dos aproximadamente
10.000 canais de leitura eletrônica do TileCal e e a ausência de um modelo computacional
unificado provavelmente prejudica a evolução das análises necessárias, em um ambiente
complexo como CERN.
Paralelamente, uma característica marcante de projetos no CERN é a alta rota-
tividade de pesquisadores dentro do experimento. Um novo entrante no projeto ou a
simples troca de funções exige um tempo de treinamento. Muitas são as tarefas que pre-
cisam ser realizadas pela equipe que analisa os resultados gerados, a fim de garantir a
qualidade de dados do TileCal. A maior parte dessas tarefas é realizada com o auxílio de
sistemas computacionais desenvolvidos ao longo da colaboração de diferentes institutos.
A manutenção de todas essas ferramentas pode ficar comprometida uma vez que não ne-
cessariamente os programas foram implementados utilizando-se a mesma tecnologia e a
quantidade de sistemas existentes para auxiliar o processo de análise do grupo de quali-
dade de dados precisam ser atualizados e expandidos por colaboradores que talvez não os
tenha desenvolvido, o que demanda mais tempo e esforço.
A falta de padrão no processo de monitoração de canais defeituosos entre os aproxi-
madamente 10.000 existentes no calorímetro hadrônico de telhas compromete a qualidade
dos dados que estão sendo adquiridos. Concomitantemente, o crescimento do experimento
requer o desenvolvimento de novas ferramentas e a ausência de um padrão computacional
compromete a evolução das análises necessárias, em um ambiente complexo como CERN.
1.2 Objetivo
O objetivo deste projeto final de curso é desenvolver um sistema web para moni-
torar canais de leitura eletrônica do calorímetro de telhas do detector ATLAS.
6
A rápida identificação de PMTs que apresentam problemas de aquisição de dados
é fundamental para a garantir a qualidade das informações adquiridas, que serão posteri-
ormente analisadas. Recentemente, cientistas do LHC anunciaram a descoberta de uma
nova partícula fundamental da matéria [17], cujos resultados são consistentes com o bóson
de Higgs. O modelo científico para explicar os fenômenos físicos foram confirmados de
forma experimental e, por esse motivo, os dados adquiridos pelo experimento precisam
ter a maior confiabilidade possível.
O sistema web desenvolvido, permite que os colaboradores do TileCal tenham
acesso à lista de PMTs identificados como ruins e seus respectivos problemas, que podem
ter diferentes origens, como por exemplo, falha na transmissão de sinais (“No Data”,
“Data corruption”), falha na alimentação do canal (“No HV”, “Wrong HV”), problemas
de calibração a laser (“No laser calibration”, “Bad laser calibration”), dentre outros. Este
sistema apoia a análise exaustiva dos milhares de canais de leitura eletrônica do TileCal,
permitindo a atualização desta referência através de seleções apresentadas na interface.
Esta referência é utilizada na configuração da aquisição de novos dados e na análise dos
dados propriamente dita.
Adicionalmente, outro objetivo deste projeto de graduação é desenvolver uma pla-
taforma que se que se propõe a reunir, através de painéis de controle, dados gerados pelo
experimento ATLAS. Os grupos que compõe o TileCal possuem diferentes interesses e po-
dem acessar uma única interface, cada um com um objetivo próprio. O compartilhamento
de informações deve dar-se naturalmente, não sendo necessária nenhuma ação extra por
parte dos colaboradores. Por se tratar de um ambiente colaborativo, as funcionalidades
podem ser estendidas através de plug-ins pelo próprio usuário, guiado por uma interface
de desenvolvimento que será fornecida pela plataforma projetada.
O sistema de monitoramento dos canais de leitura eletrônica do calorímetro de
telhas será integrado à plataforma única responsável por fornecer todas as informações
relacionadas ao TileCal.
7
1.3 Organização do Documento
No Capítulo 2, é apresentada uma descrição do ambiente CERN, do colisor de
partículas LHC e do detector ATLAS com ênfase para o funcionamento do Calorímetro
Hadrônico de Telhas para qual o projeto em questão foi concebido.
No Capítulo 3 é apresentado um estudo sobre as análises do grupo de qualidade de
dados do TileCal. Neste estudo, descreve-se o sistema de filtragem e aquisição de dados
que ocorrem quando feixes de luz são acelerados no LHC. Os diferentes tipos de análise
são apresentados e, por fim, descreve-se o processo realizado pela colaboração para se
garantir qualidade nos dados que estão sendo adquiridos e serão analisados.
No Capítulo 4, são apresentadas a análise dos fatores que motivaram a elaboração
do projeto e suas especificações, através da escolha de parâmetros de interesse, baseando-
se em um estudo do processo de análise exercido pelo grupo de qualidade de dados do
TileCal. Por fim, a proposta do sistema é explicada.
A solução proposta e implementada que se encontra atualmente em operação é des-
crita no Capítulo 5. Para tal, todas as funcionalidades do Monitoring & Calibration Web
System (MCWS) que contribuem com a monitoração da qualidade dos dados adquiridos
pelo calorímetro são apresentadas.
O Capítulo 6 apresenta a plataforma única de integração Tile-in-ONE elaborada
recentemente, como resultado do trabalho desenvolvido até o presente momento.
Por fim, o Capítulo 7 traz as conclusões, resultados obtidos e os trabalhos futuros
do projeto.
Capítulo 2
A Física de Altas Energias e
Calorimetria
A Física de Partículas estuda os ínfimos constituintes da matéria e a forma com que
as partículas interagem. Também é chamada de física de altas energias, devido à grande
quantidade de energia necessária para a observação das estruturas básicas da matéria.
Este capítulo aborda o ambiente da física de partículas no CERN, bem como o colisor de
partículas LHC, com destaque para o experimento ATLAS.
2.1 O CERN e o Acelerador de Partículas LHC
O CERN (Centre Européen pour la Recherché Nucléaire) [11] é o maior centro de
pesquisa na área de física de partículas de altas energias do mundo. Fundado em 1954,
inicialmente a instituição foi formada com 12 países membros. Atualmente, o CERN
conta com a participação de 20 países membros e outros países colaboradores, como o
Brasil. Seu principal objetivo é estudar os constituintes básicos da matéria, as partículas
fundamentais e assim descobrir como funciona e do que o Universo é formado.
A aceleração de partículas consiste em um processo no qual partículas eletrica-
mente carregadas são submetidas a pulsos eletromagnéticos no interior de tubos. Tais
partículas adquirem força (aceleração) ao serem envolvidas a campos eletromagnéticos
9
variantes [18]. Em aceleradores circulares, partículas são injetadas e circulam no anel até
atingirem a energia desejada. O formato circular permite que diversos experimentos sejam
realizados em determinados pontos de colisão ao longo da circunferência. Quanto maior
a energia necessária na colisão, maior deve ser o perímetro do acelerador circular. Ao
atingir a energia desejada, os feixes de partículas aceleradas em sentidos opostos colidem
e, nesse caso, detectores em formato cilíndrico são os mais utilizados. Cada colisão gera
informações que devem ser analisadas por especialistas, com objetivos distintos, tais como:
identificação de partículas, observação de fenômenos e a comprovação ou a eliminação de
teorias físicas. Nos pontos de colisão, detectores são montados para observação e coleta
de dados. Existem, por exemplo, detectores de calorimetria, para identificar a energia
depositada pelas partículas colisionadas; detectores de traços, para observar trajetórias
após colisões; e detectores de múons, responsáveis por absorver tais partículas.
Figura 2.1: Representação aérea do LHC e seus detectores no CERN. Extraído de [1].
O LHC (do inglês, Large Hadron Collider) [12] é o maior colisor de partículas já
construído. Projetado e montado no próprio CERN, sua operação iniciou-se em 2008. Em
10
2 meses, identificou-se um problema no acelerador durante um teste e o funcionamento
do detector teve que ser interrompido pois uma ligação entre dois supercondutores mag-
néticos, responsáveis por acelerar as partículas no colisor, se rompeu. Estima-se que 700
metros, dos 3.3 km do setor afetado sofreram danos [19]. Após um período de manutenção
e novos testes, o LHC voltou a operar em 2009. Situado dentro de um túnel circular com
27 km de perímetro e a 100 metros abaixo da superfície, o acelerador de partículas LHC é
capaz de colidir prótons à 14 TeV, com o objetivo de recriar as condições existentes logo
após o Big Bang [20].
Ao longo do túnel do LHC estão quatro detectores de partículas altamente especia-
lizados: ALICE [21], ATLAS [13], CMS [22] e LHCb [23]. Estes complexos equipamentos
permitem obter uma visão detalhada das colisões ocorridas, como as características ener-
géticas e imagens com alta resolução da trajetória das partículas resultantes. Com as
informações fornecidas pelos detectores, pode-se caracterizar cada sub-partícula criada
após a colisão. A figura 2.1 apresenta uma representação aérea do LHC e os 4 detectores
citados.
2.2 Experimento ATLAS
O ATLAS (A Toroidal LHC ApparatuS ) [24] é um detector em formato cilíndrico.
Possui 44 metros de comprimento e 25 metros de altura, pesando aproximadamente 7.000
toneladas. O detector é composto por diversos subsistemas, conforme ilustrado na fi-
gura 2.2. Cada subsistema possui características específicas de acordo com suas fun-
cionalidades. Da parte interior para a exterior do ATLAS, encontram-se os seguintes
subsistemas:
• Detector Interno (ID), responsável por registrar as trajetórias das partículas resul-
tantes da colisão, bem como o momento e o sinal da carga, se for o caso;
• Sistema de Calorimetria, composto pelos calorímetros eletromagnéticos (LAr) e ha-
drônico (TileCal), sendo este último o foco deste projeto de graduação. Os calorí-
11
metros citados são responsáveis por medirem a energia das partículas resultantes;
• Sistema Magnético, responsável por desviar partículas carregadas para medir o mo-
mento;
• o Espectrômetro de Muóns, responsável por medir a trajetória de uma determinada
partícula denominada Múon.
Figura 2.2: Esquema do detector ATLAS. Adaptado de [2]
Um dos objetivos do LHC (e também do ATLAS) é a comprovação da existência
de uma nova partícula, o bóson de Higgs. Essa partícula, prevista no modelo padrão foi
recentemente comprovada experimentalmente através do experimento em questão, laure-
ando Peter Higgs e François Englert com o prêmio Nobel da Física na sua última edição,
ocorrida em 2013 [25]. Segundo o modelo, o mecanismo de Higgs é o que dá massa a todas
as partículas elementares, e o bóson de Higgs é uma partícula escalar maciça, que valida
o modelo padrão. Sua detecção é difícil, uma vez que é necessária uma energia muito
grande para sua observação. Ainda assim, por ser uma partícula muito energética, sua
detecção se dá através de seus decaimentos, chamados de assinaturas do bóson de Higgs.
12
2.2.1 O Sistema de Coordenadas do ATLAS
Sendo um detector cilíndrico, disposto ao longo do LHC, o detector ATLAS possui
sua estrutura ao redor do ponto de colisão. O sistema de coordenadas acompanha a direção
dos feixes de partículas gerados após a colisão. Assim, o sistema cilíndrico foi escolhido,
mas algumas modificações foram necessárias. As coordenadas η e φ se relacionam com x
e y, respectivamente, através das seguintes relações não-lineares:
• η = − log(tan(Θ2
)), onde Θ = arctan(xz)
• φ = arctan(xy)
onde η representa a rotação do feixe em relação à direção de propagação dos pacotes de
prótons (ao redor de z) e φ (também conhecida como pseudo-rapidez) representa a direção
da projeção da partícula após a colisão. A figura 2.3 apresenta o sistema de coordenadas
descrito.
Figura 2.3: Sistema de Coordenadas do detector ATLAS. Extraído de [3]
13
2.3 Calorímetro Hadrônico de Telhas
Um sistema de calorimetria é projetado para absorver a energia das partículas que
cruzam o detector. O calorímetro hadrônico de telhas (TileCal) [5] é composto por três
barris, um central com 5.6 metros de comprimento (que se divide em duas partições: LBA
e LBC) e dois barris estendidos com 2.9 metros de comprimento (cada um correspondendo
a uma partição, EBA e EBC, respectivamente), como ilustrado na figura 2.4. Cada
partição é dividida igualmente em 64 partes, chamadas módulos. Os módulos do TileCal
são dispositivos compostos de ferro como mediadores passivos e telhas cintilantes como
material ativo. A estrutura absorvedora é coberta de placas de aço de várias dimensões,
conectadas a uma estrutura maciça de suporte. A principal inovação deste detector é a
posição perpendicular das telhas em relação aos feixes do LHC.
Figura 2.4: Calorímetro de Telhas do ATLAS (com suas 4 partições na cor verde) envol-vendo o calorímetro de argônio líquido. O Sistema Magnético e a Câmara de Múons nãoestão ilustrados nesta figura. Adaptado de [4].
A passagem de partículas ionizadas pelo TileCal produz luz no espectro. Sua
intensidade é proporcional à energia depositada pela partícula. A luz produzida se propaga
através das telhas para suas bordas onde é absorvida por fibras óticas e deslocada, por
reflexão interna total, até os canais de leitura eletrônica ou fotomultiplicadores (em inglês
14
PhotoMulTipliers Tubes ou PMTs), onde é convertido em um sinal de corrente. Um
PMT pode ser idealizado como um pulso de corrente. A figura 2.5 ilustra a estrutura de
absorção e amostragem do TileCal sendo possível identificar tubos fotomultiplicadores.
Figura 2.5: Estrutura de absorção e amostragem do TileCal. Extraído de [5]
Figura 2.6: Esboço das células do TileCal. Extraído de [4].
Existem 45 canais nos módulos da parte central do detector e 32 canais nos barris
estendidos. Os PMTs estão localizadas no interior de cada módulo do TileCal. Radial-
mente, cada módulo do TileCal é segmentado em três camadas. A, BC e D, conhecidas
como células. As células são formadas pelo agrupamento de fibras até cada PMT. São
organizadas em torres cada uma com um valor de pseudo-rapidez (coordenada φ). A
15
granularidade de cada célula é dada por ∆η x ∆φ = 0.1 x 0.1 para a camada mais interna
(A) e para a camada mediana (BC) e ∆η x ∆φ = 0.2 x 0.1 para a camada mais externa
(D). O esboço da geometria das células é apresentado na figura 2.6. Existem 11 linhas
transversas de telhas (tile rows) em um módulo. As linhas são numeradas do raio interno
para o externo. Portanto, a faixa de pseudo-rapidez coberta pelo calorímetro vai de 0 a
1,7.
Capítulo 3
Qualidade de Dados no TileCal
Desde o início da década de 90, o interesse pelo tema qualidade de dados cresce
substancialmente. O aumento de tal interesse pode ser relacionado ao crescimento do
uso da Internet e de outras ferramentas provenientes da Tecnologia da Informação (TI),
que possibilita aumento de compartilhamento de dados. O grande volume de informações
trocadas torna problemas relacionados a qualidade mais evidentes, incentivando o seu
tratamento de forma adequada.
Em experimentos de física de altas energias, a monitoração de qualidade de dados
tem grande atuação em processos de aquisição e análise. Para a colaboração ATLAS,
garantir qualidade nas informações coletadas torna-se atividade inerente a processos de
análise.
A complexidade do TileCal, caracterizada, por exemplo, pelo grande número de
canais de leitura eletrônica e pela alta taxa de eventos adquiridos, requer monitoração
detalhada, a fim de verificar o correto funcionamento de sistemas de hardware e software
que o compõe.
Para assegurar o estado do calorímetro e verificar o seu desempenho, a colabora-
ção do TileCal faz uso de diversas ferramentas, desde a monitoração do calorímetro no
momento de aquisição de dados (que corresponde à análise online) até a reconstrução
e posterior análise física (que corresponde à análise offline). A seção 3.1 descreve as
principais características de tais análises.
17
3.1 Análises Online x Offline
Ao examinar os dados adquiridos pelo detector pode-se identificar irregularidades
que precisam ser corrigidas imediatamente ou, que precisam de análises detalhadas po-
dendo ser consertadas posteriormente. Mesmo que posterior, o resultado desta análise
deve ocorrer no menor tempo possível, não excedendo um prazo estabelecido pelo ATLAS
de 24 horas.
Existem, portanto, dois tipos de análises, comum a todos os experimentos. O
experimento ATLAS gera um enorme volume de dados (na ordem de 3,2 PetaBytes ao
ano [14]), os quais precisam ser processados e analisados. Ou seja, é impraticável ar-
mazenar integralmente todas as informações geradas pelo experimento para que ela seja
posteriormente analisada. Por isso, análises definidas como online referem-se a atividades
anteriores ao armazenamento em mídia permanente dos dados resultantes das colisões.
Por outro lado, as análises que ocorrem a partir do acesso de informações em bases de
dados, são definidas como offline.
A monitoração de qualidade de dados online se inicia na configuração dos de-
tectores, quando as partículas serão injetadas no LHC. Os resultados são gerados por
algoritmos semiautomáticos e fornecidos enquanto os dados ainda estão sendo processa-
dos. Tais resultados auxiliam os membros alocados na sala de controle do experimento na
resolução de eventuais problemas, tais como superaquecimento em partições do TileCal
ou falhas de desempenho de software devido a sobrecarga em processamento dos dados.
Note que o foco das análises online não são informações salvas em bases de dados, mas
sim o desempenho do detector e a seleção de quais eventos devem ser armazenados em
mídia permanente. A seção 3.1.1 descreve como esses eventos são selecionados.
O processo de reconstrução consiste em processar, em grids espalhados pelo mundo,
o grande volume de dados adquiridos pelo experimento, recombinando informações prove-
nientes do conjunto de detectores que compõem o LHC. Tal processo é caracterizado com
o início de análises offline. Diferente das análises online, o monitoramento de qualidade
de dados offline tem amplo acesso a qualquer resultado gerado pelo experimento, seja
18
anterior ou relacionado aos eventos reconstruídos na ocasião. Isso permite a identificação
e evolução de problemas incomuns ou estudos detalhados sobre a evolução de problemas
conhecidos, comparando-se resultados obtidos em diferentes períodos.
As soluções desenvolvidas neste projeto graduação, descritas nos capítulos 5 e 6,
atendem o processo de análise offline do grupo de Qualidade de Dados do TileCal.
3.1.1 Aquisição de Dados e o Sistema de Filtragem do ATLAS
Um evento gerado no ATLAS produz informações coletadas por todos os detectores,
formando uma massa de dados, na ordem de 3,2 PetaBytes ao ano. Outro fator que deve
ser considerado no experimento é a elevada taxa de eventos, que aumenta ainda mais a
massa de dados a ser analisada. Operando em luminosidade máxima a taxa de eventos
pode alcançar até 40 MHz [26], tornando impraticável o armazenamento da informação
para posterior análise offline. Desta forma, as informações adquiridas pelos detectores
serão processadas por um sistema de filtragem online, que define quais dados podem
ser descartados de maneira a diminuir a alta taxa de eventos. No experimento ATLAS,
esse sistema de filtragem online é conhecido como Trigger e o grupo DAQ do TileCal é
responsável por tal seleção. A seção 3.3 descreve os grupos que compõem a colaboração
TileCal.
Existe ainda um framework desenvolvido pela colaboração conhecido comoAthena [27]
para a emulação dos algoritmos do sistema de Trigger. O Athena recebe os dados de res-
posta a diversos processos físicos enviados pelo detector e executa os algoritmos de Trigger.
Com isso, é possível que a colaboração teste e crie algoritmos cada vez mais robustos. Im-
plementado em linguagens orientadas a objeto como C++ [28] e Python [29], o Athena é
considerado flexível, uma vez que algoritmos podem ser elaborados e executados em dis-
tribuições locais do próprio framework, o que torna possível o desenvolvimento de novos
algoritmos sem comprometer a operação do experimento.
19
3.2 Análise Offline de Qualidade de Dados no TileCal
A partir da aquisição de um determinado número de eventos, que constituem um
run, o processo de reconstrução é iniciado. Este processo é configurado de acordo com
informações armazenadas no banco de dados de condicionamento do experimento ATLAS,
conhecido pela colaboração como COOL database (COOL DB) [30]. Equipamentos danifi-
cados ou canais desconectados são considerados nesta etapa de configuração. A reconstru-
ção dos dados é automaticamente iniciada assim que o processo de aquisição é finalizado.
Algoritmos do experimento ATLAS geram resultados detalhados automaticamente que
são analisados posteriormente.
Uma vez reconstruídos, os dados obtidos são analisados com diferentes níveis de
granularidade de informações até chegar às PMTs. Após esta fase, o sistema Data Quality
Monitoring Framework (DQMF) [31] gera automaticamente índices de qualidade associ-
ados a cada canal que varia de acordo com o tipo de run. Dependendo da configuração
registrada no DQMF, o estado do canal pode ser automaticamente definido como bom,
afetado ou ruim. Por exemplo, nos runs de calibração a laser, se a luminosidade incidente
não atingir o valor predeterminado, o DQMF identifica aquele PMT como danificado e o
define como ruim. O estado de cada módulo é definido através do percentual da incidên-
cia de canais bons, afetados ou ruins. Nesta etapa, um membro do grupo de qualidade
de dados realiza uma análise por módulos, identificando aqueles que são problemáticos,
através da análise dos gráficos gerados durante a reconstrução.
Posteriormente, é realizada uma análise do desempenho dos módulos por período
de tempo englobando diferentes runs. Adicionalmente, com o objetivo de obter uma rápida
referência durante a análise dos PMTs, o grupo DQ acessa a lista de canais conhecidamente
danificados que estão armazenados no COOL DB. Se um novo problema é identificado
durante o processo, o banco de dados de condicionamento do ATLAS deve ser atualizado
no período máximo de 24 horas para que a nova informação possa configurar a próxima
reconstrução dos dados.
Os problemas dos canais podem ser de diferentes tipos, como por exemplo baixa
20
luminosidade (“Low luminosity”), ausência de transmissão de sinal (“No data”), dados
corrompidos (“Corrupted data”), falha na alimentação do canal (“No HV”), etc. O LHC é
aberto periodicamente para manutenções quando equipamentos danificados são reparados
ou substituídos.
Ao final de cada análise, relatórios são gerados e os resultados encontrados são
regularmente apresentados em reuniões da colaboração.
O processo de análise do grupo de qualidade de dados do TileCal descrito é ilus-
trado no diagrama da figura 3.1.
Figura 3.1: Esquema do processo de análise do grupo DQ do TileCal
3.3 A Colaboração TileCal
O colaboração do Calorímetro de telhas é formada por diferentes grupos, responsá-
veis por atividades específicas no experimento, cada um dedicado a uma etapa do processo
21
de trabalho do calorímetro:
DAQ (do inglês, Data Acquisition ou aquisição de dados) responsável pela aqui-
sição dos sinais resultantes das interações físicas no detector;
DCS (do inglês, Detector Control System, ou sistema de controle do detector)
responsável pela manutenção das fontes de alta e baixa tensão do TileCal, placas
mãe e sistema de refrigeração;
DQ (do inglês, Data Quality, ou qualidade de dados) responsável por avaliar o fun-
cionamento do detector garantindo confiabilidade nos dados adquiridos que serão
analisados;
Calibração (do inglês, Calibration) responsável pela calibração das células do calo-
rímetro e validação da escala eletromagnética, a fim de corrigir desvios que ocorrem
ao longo do tempo devido a desgastes ocorridos pela exposição do detector a altos
níveis de radiação;
Computação e Software responsável por realizar a organização e desenvolvimento da
simulação, reconstrução, digitalização e desenvolvimento de filtros de alto nível;
Dados e Processamento (do inglês, Data and Processing) responsável por coletar
informações dos grupos de qualidade de dados e calibração a fim de decidir que al-
terações nos dados de condições serão realizadas. Responsável também por analisar
os dados físicos.
Ao todo, existem 6 grupos no TileCal e o compartilhamento de informações entre
eles faz-se necessário: se um determinado canal de leitura eletrônica não está sendo ali-
mentado corretamente, a qualidade dos dados adquiridos pode estar comprometida. Esta
situação exige compartilhamento de informações entre os grupos DCS e DQ, por exemplo.
Diversas são as ferramentas desenvolvidas desde a fase de comissionamento do LHC
para auxiliar a colaboração em análises físicas e monitorações do TileCal. Todos os grupos
que compõem o calorímetro de telhas possuem aplicações web que auxiliam a colaboração
22
em suas análises específicas: por exemplo, o TileComm Analysis lista os últimos runs
reconstruídos, informando o grupo DQ quais são os dados que estão prontos para análise
offline; o DCS Web System, ao emitir alertas quando desvios padrão em relação a valores
nominais são identificados, permite que o grupo DCS monitore em tempo real o estado
físico do detector.
(a) TWiki do TileCal. (b) Homepage de Sistemas desenvolvidos pela UFRJ
Figura 3.2: Documentações de ferramentas de auxílio a análises do TileCal dispersas
A existência de várias aplicações implica a elaboração de documentações espe-
cíficas. O CERN possui uma plataforma de documentações exclusiva, a TWiki (fi-
gura 3.2(a)), responsável por reunir informações gerais sobre o detector. Contudo, o
experimento em questão é colaborativo e as ferramentas desenvolvidas são de responsa-
bilidade dos institutos que as elaboram. Esse fato permite que diferentes Homepages,
específicas para cada ferramenta, sejam desenvolvidas, agravando a dificuldade em man-
ter informações agrupadas. A figura 3.2(b) é um exemplo de uma página dedicada aos
projetos desenvolvidos pela UFRJ, em colaboração com o ATLAS.
Outra característica do experimento é a alta rotatividade dos colaboradores. A
inexistência de um local único com todas as ferramentas existentes exige maior tempo para
que um novo membro inicie suas atividades. Além do tempo utilizado para encontrar quais
são as ferramentas que o auxiliará, o novo colaborador precisa aprender a lidar com novas
tecnologias, muitas vezes exclusivas do próprio CERN, sendo o caso do ATHENA [27]
ou ROOT [32] (framework de análise de dados físicos, desenvolvido para acompanhar a
23
estrutura dos detectores do LHC).
Centralizar o grande volume de informações produzidas, bem como as ferramen-
tas existentes e suas documentações em um único ambiente torna-se uma necessidade
do experimento. Adicionalmente, o acesso e processamento dos dados através de uma ca-
mada de abstração reduz o tempo de aprendizagem exigido, permitindo que a colaboração
se dedique às análises físicas, principal motivação do experimento. Uma plataforma de
integração foi recentemente planejada e é descrita em detalhes no capítulo 6.
Capítulo 4
Sistema Proposto
Com o objetivo de auxiliar análises offline do grupo de Qualidade de Dados do
TileCal, este projeto foi especificado e desenvolvido. O aumento do volume de dados
produzido pelo experimento reflete no processo de análise. Por outro lado, a rápida
identificação de novos problemas ou o acompanhamento de problemas já existentes é
uma característica das análises offline do grupo de Qualidade de Dados do calorímetro,
como descrito na seção 3.1. Por isso, ferramentas de auxílio que fornecem resultados
rapidamente são importantes para a colaboração.
A elaboração desde projeto inicia-se com a identificação da inexistência de ferra-
mentas web que auxiliam o grupo de Qualidade de Dados do TileCal na análise offline a
nível de canais de leitura eletrônica. Tal identificação permite a especificação de requi-
sitos, a partir da qual uma solução é elaborada. Essas informações, descritas a seguir,
permitem que uma arquitetura para o sistema desenvolvimento seja projetada.
4.1 Análise do Problema
Monitorar os, aproximadamente, 10.000 canais de leitura eletrônica do TileCal
é uma tarefa bastante complexa, dado o volume de dados produzido pelo experimento.
Ademais, o curto tempo permitido para que grupo DQ atualize a referência de canais
danificados, quando necessário, torna o processo de asserção de qualidade de dados ainda
25
mais difícil. As análises geralmente são realizadas separando-se os canais por áreas do
detector e dependem essencialmente do tipo de evento ocorrido durante a aquisição dos
dados.
A rápida identificação de PMTs que apresentam problemas de aquisição de dados
é fundamental para a garantia da qualidade das informações adquiridas. Como menci-
onado na seção 1.2, recentemente, cientistas do LHC anunciaram a descoberta de uma
nova partícula fundamental da matéria, cujos resultados são consistentes com o bóson
de Higgs. O modelo científico para explicar os fenômenos físicos foi verificado esse ano
de forma experimental. Portanto, os dados adquiridos pelo experimento precisam ter a
maior confiabilidade possível.
Além disso, as análises realizadas pelo grupo de qualidade de dados é de grande
importância para outras áreas de trabalho do TileCal, como a reconstrução dos dados,
onde canais com danos definidos como graves são desconsiderados durante a aquisição
de dados ou durante a análise propriamente dita, e também deve-se ter cautela ao utili-
zar uma informação adquirida por um PMT que foi definido como apresentando alguns
problemas, mesmo que estes não sejam considerados graves.
O procedimento para análise e monitoramento dos canais do TileCal é iniciado
separando-se um conjunto de resultados obtidos durante a análise offline: ao serem re-
construídos, o framework de qualidade de dados do ATLAS (DQMF) possui algoritmos
próprios que geram automaticamente índices de qualidade de dados associado a cada ca-
nal. O DQMF atribui automaticamente, para cada canal, um estado como bom, afetado
ou ruim. Nesta etapa, os PMTs com estado bom são excluídos da análise, enquanto os
restantes são detalhadamente analisados pelo grupo de qualidade de dados. O objetivo
é confirmar o resultado afetado ou ruim automaticamente. Por outro lado, quando um
canal é substituído ou consertado durante o período de manutenção do detector, deve-
se retirá-lo da referência de canais danificados, informando à colaboração que os dados
adquiridos pelo referido canal são novamente confiáveis. É válido lembrar que o experi-
mento em questão é altamente radioativo e esse é um dos motivos pelo qual tais períodos
26
de manutenção são esporádicos. Assim, identificar um conjunto de canais que precisam
ser reparados ou substituídos em tais períodos torna a manutenção mais eficiente.
As informações relacionadas aos estados dos PMTs encontram-se no banco de dados
de condicionamento do ATLAS, o COOL DB. O acesso a esse banco de dados dá-se
por intermédio de um conjunto de pacotes escritos, essencialmente, em C++ e Python,
conhecido como TileCalibBlob, que torna possível a análise do grupo de qualidade de dados
ao recuperar os estados dos canais de leitura eletrônica. Contudo, essa dependência exige
que o avaliador tenha conhecimentos em programação, além das funcionalidades que cada
pacote fornecido disponibiliza.
A ausência de uma plataforma comum, que ofereça ferramentas que permitam que
a colaboração realize diversos tipos de análises ou estenda tais ferramentas de maneira
simples e padronizada, faz com que cada colaborador desenvolva seus próprios algoritmos
para análises desejadas, sem obedecer um padrão de desenvolvimento ou instalá-lo em um
local central. Como resultado, em muitos casos, nem toda a colaboração tem conhecimento
de todas as ferramentas existentes, gerando retrabalho.
Outra exigência é o avaliador conhecer a estrutura do COOL DB, para localizar as
informações de interesse e escolher adequadamente a configuração necessária para extração
de dados conforme sua necessidade.
No caso de atualizações dos estados dos canais, a ferramenta utilizada é o Robot,
que é um pacote que possibilita escritas no COOL DB. Existe um grupo restrito, res-
ponsável pela validação das alterações enviadas pelos colaboradores, através de arquivos
SQLite [33], que então realizam as alterações dos dados no COOL DB (via Robot). En-
tretanto a comunicação com esse grupo ocorre através de trocas de e-mails.
4.2 Análise dos Requisitos
A partir da compreensão das atividades realizadas pelos diferentes grupos que com-
põem o TileCal e mais detalhadamente, do processo de análise offline realizado pelo grupo
de qualidade de dados do calorímetro, foi possível identificar as necessidades envolvidas,
27
listadas a seguir:
• Qualquer membro da colaboração deve ter acesso às informações independente de
sua localização física;
• O estado atual dos canais deve ser exibido para que os colaboradores possam iden-
tificar, de forma ágil, o estado geral do detector;
• O acesso a dados passados deve ser permitido, para que o avaliador possa consultar
a evolução dos canais ao longo do tempo;
• Os resultados gráficos devem ser gerados de tal forma que resumam o estado do
detector, com o objetivo de discuti-lo em reuniões;
• Disponibilizar uma interface que permita atualizar os canais danificados, restrita a
usuários autorizados, por se tratar de dados sensíveis, deve ser elaborada;
• O sistema proposto deve ser integrado a uma plataforma única Tile-in-ONE (Ca-
pítulo 6), permitindo que a colaboração estenda funcionalidades conforme haja ne-
cessidade.
O projeto desenvolvido permite que os colaboradores do TileCal tenham acesso
à lista de PMTs identificados como ruins e seus respectivos problemas, atualizem tais
informações e gerem resultados gráficos que podem ser compartilhados com a colaboração
em reuniões periódicas. Quanto mais rápido esse processo ocorrer, maior será a garantia
de qualidade dos dados que estão sendo adquiridos e posteriormente serão analisados.
4.3 Proposta
Como projeto final de graduação, o sistema Monitoring & Calibration Web Sys-
tem (MCWS) foi desenvolvido para apoiar a análise exaustiva dos milhares de canais de
leitura eletrônica do TileCal, permitindo a atualização dos estados destes canais atra-
vés de seleções apresentadas na interface. Esta referência é utilizada na configuração da
28
aquisição de novos dados. Durante o processo é possível atualizar o banco de dados de
condicionamento do ATLAS através do MCWS.
Figura 4.1: Ilustração das 3 fases que resumem o processo de análise do grupo DQ.
A análise da qualidade de dados dos canais de leitura eletrônica do TileCal consiste
em três etapas, ilustradas na figura 4.1: a primeira ocorre durante a aquisição do run.
Nesta fase, a lista de canais danificados é utilizada para configurar corretamente o pro-
cesso de reconstrução; uma vez que os dados foram reconstruídos, um membro do grupo
DQ analisa todas as informações dos canais obtidas, comparando-as com as informações
presentes no COOL DB (como os valores das constantes de calibração ou a própria lista
de canais danificados, por exemplo). Esta análise é necessária para identificação de novos
danos ou atualização de valores de constantes de calibração, caso for preciso. Por fim, os
membros do grupo de qualidade de dados reportam suas análises para o líder do grupo
DQ, que avalia os resultados e atualiza o banco de dados de condicionamento do ATLAS,
se julgar necessário.
A seguir, a arquitetura elaborada para o sistema proposto é apresentada em deta-
lhes.
29
Figura 4.2: Arquitetura do sistema proposto, MCWS.
4.3.1 Arquitetura do Sistema
A figura 4.2 ilustra a arquitetura do sistema MCWS. Cada canal do TileCal pode
possuir danos relacionados a alto ganho, baixo ganho, ou até mesmo ambos. Isto, no
mínimo, duplica a quantidade de variáveis que precisam ser monitoradas, totalizando pelo
menos cerca de 20.000 componentes. Esse tipo de informação encontra-se armazenada
no COOL DB. Acessar a quantidade de dados necessários para compôr uma interface
web é um processo pesado para o servidor. A alternativa adotada é a instalação de um
cronjob, que a cada 30 minutos recupera a lista de PMTs danificados e seus respectivos
problemas, armazenando-os em uma base de dados Oracle, reservada para os sistemas
desenvolvidos pelo grupo da UFRJ. Trinta minutos de atualização da base Oracle não
é um tempo considerado crítico, visto que atualizações no COOL DB não ocorrem com
esta frequência. Outra informação recuperada pelo cronjob é a definição de problemas
que são considerados como graves pela colaboração. Esta informação também encontra-se
no BD de condicionamento e pode ser alterada, dependendo dos resultados de análises da
30
colaboração. Cada atualização no COOL DB é seguida de um comentário, um autor e
uma data, que indicam o que está sendo alterado, quem é o responsável pela atualização
e quando ocorreu. Informações como essas devem ser apresentadas na interface para
sumariar o que ocorreu durante a última atualização da referência de canais danificados.
O banco de dados Oracle também armazena os resultados automáticos gerados pelo
DQMF após a reconstrução de dados. Através da tecnologia PHP, o Oracle é acessado e
suas informações são apresentadas no MCWS de maneira gráfica, conforme será descrito
no capítulo 5.
Com a lista de canais danificados carregada no sistema web, o colaborador pode
atualizar as informações de cada PMT ou de um módulo inteiro. Essas informações são
salvas no banco de dados Oracle, o que permite que o colaborador consiga realizar suas
análises de maneira descontínua, independente de sua localização física, sendo necessário
apenas executar um navegador.
O sistema proposto também gera resultados gráficos e estatísticos, a partir de
tecnologias próprias do CERN, como o ATHENA e o ROOT. O colaborador não precisa
ter conhecimento de tais tecnologias para gerar os resultados referidos. Ao acionar esta
funcionalidade, o sistema executa um programa em background no servidor (para não
sobrecarregar o cliente) e os armazena em diretórios locais. O colaborador é notificado
com o término da execução do programa citado.
Ao final da análise, o sistema proposto também permite a criação automática de
arquivos SQLite. Tais arquivos são utilizados como entrada pelo Robot, pacote responsável
por realizar operações de escrita no COOL DB. Note que esta funcionalidade também
funciona como uma camada de abstração de conhecimentos técnicos.
As tecnologias escolhidas para o sistema proposto são descritas na seção 5.3.
Capítulo 5
Sistema Web de Monitoração e
Calibração (MCWS)
O MCWS foi desenvolvido para auxiliar a monitoração e as análises dos aproxima-
damente 10.000 canais de leitura eletrônica do Calorímetro Hadrônico de Telhas (TileCal).
O sistema encontra-se em operação, está hospedado no servidor web do CERN
sendo acessível apenas para membros da colaboração.
O servidor web é baseado em tecnologia Apache [34] e opera sob o sistema opera-
cional Linux.
Ao longo deste capítulo, será detalhada a implementação do sistema, desenvolvido
a partir das especificações apresentadas no Capítulo 4.
5.1 Monitoração dos canais de leitura eletrônica
O processo de monitoração dos PMTs do TileCal através do MCWS inicia-se com
o acesso à lista de canais danificados que estão armazenadas no COOL DB. A funciona-
lidade Bad Channels Lists oferecida tem como objetivo auxiliar o analista do grupo DQ
a identificar novos canais defeituosos.
Uma das responsabilidades do grupo DQ é assegurar que os canais de aquisição de
dados não interfiram nas informações coletadas. Tais informações serão utilizadas poste-
32
riormente pela colaboração em atividades que envolvem análises físicas. É fundamental
identificar canais defeituosos antes que a reconstrução dos dados do run seguinte comece.
A figura 5.1 é um exemplo da funcionalidade que auxilia na monitoração dos 10.000
canais de leitura eletrônica do TileCal. Esta funcionalidade apresenta quatro círculos,
que correspondem às partições do calorímetro de telhas, divididas em 64 partes que re-
presentam seus respectivos módulos. Juntamente com os barris, são disponibilizados os
comentários que descrevem a última atualização juntamente com a data e o nome do
membro que inseriu o esclarecimento. A legenda de cores é representada na parte inferior
da figura. As partições do barril estendido (EBA e EBC) não estão ilustradas.
Figura 5.1: Funcionalidade Bad Channels Lists do MCWS.
A cada módulo é atribuída uma tonalidade de cor, presente gradualmente entre
o vermelho e o verde, dependendo da quantidade de canais danificados. Ao acessar um
módulo, o sistema desenvolvido exibe informações dos seus respectivos canais (figura 5.2),
descrevendo defeitos e gravidades: canais com a cor vermelha indicam existência de pelo
menos um problema considerado grave; a cor amarela indica que o canal apresenta pro-
blemas que afetam a sua performance, mas ele ainda é funcional; canais que apresentam
33
a cor verde não possuem defeitos; branco indica que o canal não está instalado enquanto
a cor preta indica que o canal foi selecionado.
Ao acessar um canal, o MCWS também exibe um quadro no qual é possível verificar
e atualizar a lista de problemas que podem ocorrer com os canais de leitura eletrônica do
calorímetro.
Figura 5.2: Funcionalidade Bad Channels Lists do MCWS - detalhes sobre os canais são
apresentados.
5.2 Atualização do banco de dados de condicionamento
do ATLAS
Caso novos danos sejam identificados, é necessário atualizar a lista de canais da-
nificados no COOL DB. A funcionalidade Generate SQLite, oferecida pelo MCWS, reúne
as atualizações feitas e gera um arquivo SQLite, que servirá de entrada para a ferramenta
ROBOT. Como mencionado na seção 4.1, é através do ROBOT que ações de escrita no
COOL DB são realizadas. Esta funcionalidade está disponível apenas para o líder do
34
grupo DQ, que é o responsável por avaliar as análises efetuadas pelo MCWS. Atualizar a
referência de canais danificados é uma ação sensível no processo de aquisição e análise de
dados e por isso, esta atividade se restringe apenas ao líder do grupo DQ.
Quando o MCWS identifica que uma nova atualização ocorreu no COOL DB, grá-
ficos e resumos com porcentagens dos canais danificados do TileCal são gerados. Tais
resultados podem ser acessados através da funcionalidade Last Results, como ilustrado na
figura 5.3. O sistema também permite que os resultados gerados sejam salvos e posteri-
ormente apresentado em reuniões
(a) Gráfico gerado pelo MCWS após atualização no
COOL DB.
(b) Tabela exibindo percentual de canais defei-
tuosos.
Figura 5.3: Resultados gerados pelo MCWS após atualização no COOL DB
O MCWS é protegido por senha a fim de evitar atualizações não autorizadas no
banco de dados do ATLAS. Através do sistema também é possível administrar usuários.
As contas do líder e dos coordenadores do grupo DQ são classificadas como administra-
doras do sistema e, portanto, podem realizar qualquer operação. As operações oferecidas
consistem em: trocas de senhas, disponível para todos os usuários; trocas do líder do
grupo, que ocorrem mensalmente e pode ser efetuada pelo líder em atuação; inclusão
de novos coordenadores e exclusão de coordenadores. As duas últimas operações estão
disponíveis apenas para os coordenadores do DQ group.
A figura 5.4 apresenta a interface da funcionalidade para administrar usuários do
35
sistema. Neste exemplo, é apresentada a inserção de um novo líder do grupo DQ.
Figura 5.4: Interface da funcionalidade para administração de usuários do MCWS
5.3 Tecnologias utilizadas
O MCWS faz uso de diversas tecnologias e bibliotecas de suporte para realizar suas
funções. Entre os aspectos considerados ao escolher as tecnologias são a manutenção do
sistema, o desempenho e a flexibilidade oferecida para determinada tarefa.
O acesso ao banco de dados de condicionamento do ATLAS faz-se por meio de
programas escritos na linguagem Python. Os dados recuperados são armazenados em
arquivos XML (eXtended Marked Language), posteriormente analisados por scripts em
PHP, que calculam a incidência de canais defeituosos no módulo, atribuindo-lhe uma
cor, variando entre o verde, amarelo, laranja e vermelho. Estes scripts são baseados
no algoritmo de análise SAX (Simple API for XML). O usuário do MCWS pode gerar
gráficos através da interface utilizando a tecnologia AJAX de execução remota. Para a
composição das interfaces, utiliza-se folhas de estilo CSS. Arquivos XML de configuração
definem menus e legendas. Para esses arquivos é utilizado o método DOM de análise,
que é integrado a programas Javascript. A atualização de informações no COOL DB
é realizada ao final de cada análise por intermédio de arquivos SQLite, que armazenam
36
localmente alterações necessárias e, posteriormente, efetuam as alterações solicitadas.
Essas tecnologias são descritas nas seções subsequentes.
5.3.1 Python
Python [29] é uma linguagem de programação de alto nível interpretada, interativa,
orientada a objetos e de tipagem dinâmica e forte, lançada em 1991. Atualmente possui um
modelo de desenvolvimento comunitário e aberto. Apesar de várias partes da linguagem
possuírem padrões e especificações formais, a linguagem como um todo não é formalmente
especificada.
A linguagem foi projetada com a filosofia de enfatizar a importância do esforço do
programador sobre o esforço computacional. Prioriza a legibilidade do código sobre a velo-
cidade ou expressividade. Combina uma sintaxe concisa e clara com os recursos poderosos
de sua biblioteca padrão e por módulos e frameworks desenvolvidos por terceiros.
Os programas que recuperam os dados armazenados no COOL DB e os geram resul-
tados gráficos (com a utilização do módulo matplotlib) pelo MCWS foram desenvolvidos
na linguagem Python.
5.3.2 XML
O XML (eXtensible Markup Language)[35] é uma linguagem de marcação de texto
simples, muito parecida com o HTML. Enquanto o HTML dá ênfase à apresentação de
dados, o XML permite descrever os dados concentrando-se na estrutura destes. Esta
linguagem é utilizada na troca de dados entre sistemas computacionais, já que permite
a formatação dos dados num padrão que pode ser entendido por qualquer sistema, e na
publicação de dados, com o auxílio de linguagens e programas que apresentam dados
armazenados em XML de maneira amigável ao usuário final.
O MCWS utiliza arquivos XML para armazenar todos os dados recuperados do
COOL DB que serão analisados posteriormente e aqueles que servem como referência.
Esses arquivos ainda são utilizados para guardar configurações das interfaces, como cores
37
dos alertas ou menus.
5.3.3 DOM
O Document Object Model (DOM)[36] é um padrão de análise de arquivos XML
definido pela World Wide Web Consortium (W3C). O método consiste em dividir o docu-
mento em uma árvore de elementos. Cada elemento pode conter uma série de atributos,
outros elementos, ou texto. A API do DOM permite o acesso e manipulação dos ele-
mentos e seus valores. Ao ler um arquivo XML, o analisador monta sua estrutura na
memória, que pode ser acessada e manipulada pela API. Com isso obtém-se uma grande
flexibilidade e facilidade de programação. O Monitoring and Calibration Web System usa
DOM para analisar a semântica dos arquivos de configuração.
5.3.4 Javascript
Trata-se de uma linguagem de programação do lado do cliente, porque é o na-
vegador que suporta a carga de processamento. Graças a sua compatibilidade com a
maioria dos navegadores modernos, é a linguagem de programação do lado do cliente
mais utilizado. Com Javascript[37] podemos criar efeitos especiais nas páginas e definir
interatividades com o usuário. O navegador do cliente é o encarregado de interpretar as
instruções Javascript e executá-las para realizar estes efeitos e interatividades, de modo
que o maior recurso, e talvez o único, com que conta esta linguagem é o próprio navegador.
5.3.5 Folhas de Estilo CSS
As folhas de estilo CSS (Cascading Style Sheets)[38] permitem definir o modo
de exibição de documentos HTML. Com a utilização de folhas CSS é possível mudar o
estilo de marcações HTML em todos os documentos que fazem referência às mesmas,
poupando-se trabalho de modificar diversos documentos, o que facilita a manutenção do
sistema. As alterações nos estilos de uma folha CSS refletem em todos os documentos
que a referenciam.
38
5.3.6 AJAX
AJAX (Asynchronous Javascript And XML) é o uso sistemático de tecnologias pro-
vidas por navegadores, como Javascript e XML, para tornar páginas mais interativas com
o usuário, se utilizando de solicitações assíncronas de informações. AJAX não é somente
um novo modelo, é também uma iniciativa na construção de aplicações web mais dinâmi-
cas e criativas. AJAX não é uma tecnologia, são realmente várias tecnologias conhecidas
trabalhando juntas, cada uma fazendo sua parte, oferecendo novas funcionalidades. AJAX
incorpora em seu modelo:
• Apresentação baseada em padrões, usando XHTML e CSS
• Exposição e interação dinâmica usando o DOM
• Intercâmbio e manipulação de dados usando XML e XLST
• Recuperação assíncrona de dados
• Javascript unindo todas elas em conjunto
O modelo clássico de aplicação web trabalha assim: a maioria das ações do usuário
na interface dispara uma solicitação HTTP para o servidor web. O servidor processa algo
recuperando dados, realizando cálculos, conversando com vários sistemas ligados - e então
retorna uma página HTML para o cliente.
No MCWS, quando o usuário solicita a criação de um gráfico via a interface, como
ocorre a cada atualização da lista de canais defeituosos no COOL DB, é utilizado o modelo
AJAX. Só assim foi possível a execução de programas sem que a navegabilidade do sistema
fosse alterada.
5.3.7 API Simples para XML
Um analisador baseado em SAX (Simple API for XML) [39] implementa uma API
orientada a eventos. O analisador lê o arquivo sequencialmente, e gera eventos cada vez
39
que encontra uma abertura ou encerramento de um elemento ou um bloco de texto. Esses
eventos são traduzidos em chamadas para os manipuladores de eventos, responsáveis por
processar as informações obtidas.
Apesar de não ser um padrão recomendado pela W3C, ele é muito utilizado [40].
Como o analisador provê o acesso serial do arquivo e não monta sua estrutura de elementos
na memória, esse tipo de análise é adequada para XMLs extensos. Essa característica foi
muito importante para este projeto, pois alguns dos arquivos manipulados chegam a
ordem da centena de megabytes. Exemplos da utilização do analisador SAX podem ser
encontrados em [41].
A principal desvantagem do SAX é a maior dificuldade na validação do mesmo. Em
certos casos só é realizada se o documento estiver integralmente na memória. Outro ponto
é a complexidade dos manipuladores de eventos e a interpretação dos dados, superior aos
realizados com o modelo DOM.
A extensão que gera o arquivo XML com informações sobre os valores de constantes
de calibração, canais defeituosos e seus respectivos problemas e o programa que analisa a
incidência desses canais atribuindo estados aos módulos é implementada com base de um
analisador SAX.
5.3.8 Hypertext Preprocessor (PHP)
PHP (Hypertext Preprocessor )[42] é uma linguagem de programação de computa-
dores interpretada, livre e muito utilizada para gerar conteúdo dinâmico na World Wide
Web. Apesar de ser uma linguagem de fácil aprendizagem e de utilização para pequenos
programas dinâmicos simples, o PHP é uma poderosa linguagem orientada a objetos.
As interfaces do MCWS, os analisadores dos arquivos XML e representação gráfica
dos barris foram implementados em PHP.
40
5.3.9 Biblioteca SQLite
SQLite é uma biblioteca que implementa automaticamente, sem necessidade de
servidor ou configuração prévia um banco de dados transacional SQL, por intermédio
de um arquivo binário. O formato do arquivo de banco de dados é multiplataforma e
sua biblioteca é compacta. Estas características tornam a escolha por SQLite popular.
O código para SQLite é do domínio público e é, portanto, livre para uso para qualquer
finalidade, comercial ou privada. SQLite é atualmente encontrado em mais aplicações do
que pode-se contar.
O MCWS faz uso da biblioteca SQLite para armazenar localmente atualizações
necessárias e ao final de cada processo de análise envia o arquivo local gerado para o
COOL DB, reduzindo o número de acessos para escrita no banco de dados oficial de
condicionamento do ATLAS.
Capítulo 6
Plataforma Tile-in-ONE
A característica heterogênea e geograficamente dispersa da colaboração ATLAS im-
põe um desafio na disponibilização de informações para seus membros. O desenvolvimento
de sistemas web permitiu uma maneira eficiente de monitoramento, gerência e avaliação
do desempenho nos mais diferentes aspectos do trabalho. Assim como o MCWS, que aju-
dou a colaboração TileCal a disponibilizar 99.6% dos dados com qualidade garantida [43],
diversas ferramentas e interfaces web foram implementadas com diferentes propósitos ao
longo das fases de comissionamento e operação do LHC.
A maioria destas ferramentas foi desenvolvida de forma independente, sem seguir as
mesmas diretrizes padrão e, algumas vezes, não seguiram uma infraestrutura de software
básico. Por terem sido projetadas para fins específicos, as ferramentas não apresentam
uma perspectiva global do calorímetro. Portanto, em muitos casos, elas se sobrepõem nos
objetivos e recursos.
No mais, a manutenção de tais ferramentas se torna complicada e muitas vezes o
projeto não tem continuidade. Sem o autor original dos sistemas, não existem garantias
de atualizações e possíveis correções. Essa é uma situação comum no CERN devido a alta
rotatividade de pesquisadores e o carácter sazonal de suas respectivas atividades.
Para o responsável pelas análises (sejam de calibração, controle, qualidade de dados
ou qualquer outro subsistema) a situação é desconfortável. A fim de executar uma única
tarefa, o colaborador precisa navegar através de diferentes ferramentas, bancos de dados e
42
softwares. Esta atividade pode ser demorada e suscetível a erros, dependendo do nível de
conhecimentos técnicos que cada colaborador possui. Para um membro recém chegado,
a situação é ainda mais complicada. A diversidade de opções dificulta o aprendizado e
limita a quantidade de ações independentes da ajuda de terceiros.
O cenário descrito indica ser fundamental possuir uma infraestrutura que permita o
desenvolvimento de funcionalidades comuns na colaboração. Centralizar ferramentas que
auxiliam os diferentes grupos no TileCal evita a duplicação de esforços além de facilitar
a entrada de novos membros, a medida que reduz o tempo necessário para a localização
dos recursos disponíveis. Ademais, a integração de tais recursos fornece uma visão global
do estado do detector, importante para toda colaboração. A plataforma Tile-in-ONE [44]
foi projetada para atender tais requisitos.
Atualmente, instalado no servidor web do CERN e em operação, o sistema Tile-
in-ONE pode ser acessado apenas por membros da colaboração.
Através da plataforma, são integrados todos os repositórios de dados e ferramentas
utilizadas pelo TileCal. As informações recuperadas são então disponibilizadas através
de serviços padronizados. O sistema também oferece uma API comum para o desen-
volvimento de extensões (ou plug-ins). Esses plug-ins são disponibilizados para toda a
colaboração e organizados no sistema por meio de painéis (ou dashboards).
Este capítulo descreve a arquitetura da plataforma proposta, suas funcionalidades,
e como a extensão de novas funcionalidades é realizada. Por fim, são apresentadas as
tecnologias utilizadas durante o desenvolvimento do Tile-in-ONE e os motivos de suas
escolhas.
6.1 Arquitetura da Plataforma
O Tile-in-ONE integra diferentes ferramentas do TileCal, compartilhando uma
mesma infraestrutura e disponibilizando serviços de maneira unificada, tais como:
• Acesso a diferentes banco de dados;
43
• Autenticação de usuários;
• Compartilhamento de bibliotecas e de programas;
• Possibilidade de integração de ferramentas desenvolvidas pelos próprios colaborado-
res, garantindo padronização no desenvolvimento de novas funcionalidades e reuti-
lização de programas;
A plataforma é composta por três módulos: núcleo, serviços e plug-ins, ilustrados
na figura 6.1.
O núcleo do sistema é constituído pelo código base, que gerencia usuários e carrega
as configurações e demais componentes em tempo de execução. É neste ambiente que
um pool de conexões é estabelecido, tornando o acesso a qualquer tipo de informação
disponível aos serviços e plug-ins. Essa componente também é responsável por mostrar a
estrutura básica das páginas e algum conteúdo especialista.
O conjunto de serviços provê o acesso unificado aos recursos disponibilizados pelo
núcleo. Essa tarefa é realizada de maneira desacoplada através de uma API base com
o intuito de manter o sistema modular. A comunicação realiza-se através do protocolo
SOAP [45]. Com a implantação dos serviços pretende-se:
1. facilitar o desenvolvimento de plug-ins, oferecendo recursos reutilizáveis
2. minimizar o impacto de múltiplos acessos a recursos comuns.
Existem três tipos de serviços no Tile-in-ONE : conectores, que disponibilizam o
acesso aos banco de dados e máquinas remotas; bibliotecas, que oferecem um conjunto
de funcionalidades para a interação com o usuário e a interface com sistemas externos.
Alguns exemplos de serviços são citados a seguir:
• Acesso ao servidor contendo os arquivos resultantes da análise de qualidade de dados
automática para rodadas de calibração;
• Acesso à base de dados de condicionamento do ATLAS, o COOL DB.
44
• Acesso ao banco de dados responsável por armazenar os dados de colisões e análises
físicas;
• Acesso e utilização do TUCS [46], software utilizado por especialistas para realizar
análises de proposta geral e monitorar dados das rodadas de calibração;
• Disponibilização de recursos tais como a criação de gráficos ou figuras: por exemplo,
a representação do corte setorial dos barris do TileCal.
A Figura 6.1 apresenta como os diferentes componentes da plataforma se relacionam e
como as informações circulam internamente.
Figura 6.1: Arquitetura da plataforma Tile-in-ONE
As informações recuperadas e exibidas no Tile-in-ONE são organizadas em painéis
de controle, separados de acordo com os diferentes grupos existentes no TileCal. Cada
painel de controle apresenta um conjunto de plug-ins, responsáveis por executar uma
tarefa distinta.
Por fim, uma interface que reúne todos os componentes disponíveis na plataforma
foi criada, para permitir que toda colaboração tenha acesso às ferramentas existentes.
Esta centralização permite que os membros do TileCal tenham acesso a todos os recur-
sos disponíveis e ainda minimiza o tempo necessário para um novo entrante inicie sua
colaboração.
45
6.2 Dashboards
A interação com os usuários acontece através dos diferentes painéis ou dashboards.
A plataforma permite que os usuários configurem visualizações próprias, a fim de apoiar
o processo de trabalho individualmente. Na Figura 6.2, observa-se um dashboard perso-
nalizado.
Figura 6.2: Painel personalizado para o usuário rdecatr.
O sistema também oferece um conjunto de painéis padrões, disponíveis para todos
os colaboradores, com propósitos bem específicos. As subseções a seguir são exemplos
de dashboards criadas especificamente para grupo de Qualidade de Dados e Calibração,
respectivamente.
6.2.1 Painel para monitoramento de qualidade de dados
Criado com o objetivo de auxiliar o líder (DQ Leader) e os analistas (DQ Valida-
tors) do grupo DQ durante as atividades relacionadas a validação da qualidade de dados,
este painel de controle reúne os seguintes plug-ins :
DQStatus Permite que os analistas atribuam, para cada módulo, um estado (de acordo
46
com as mesmas definições utilizadas pelo DQMF, descrito na seção 3.2), agrupando
os últimos cinco runs de um determinado tipo. Observações podem ser feitas pelos
colaboradores e são também apresentadas neste plug-in;
DQTests Apresenta o estado automaticamente atribuído pelo DQMF para cada teste
realizado em um determinado run e módulo;
DQPlots Exibe todos os gráficos de um determinado módulo gerados durante a recons-
trução dos dados ocorrida após ocorrência de um run;
DQAnalysis Apresenta as observações dos DQ Validators para um determinado módulo
durante um run. Estados podem ser atribuídos, apenas pelos analistas do grupo DQ
e comentários que podem ser editados, conforme necessidade;
DQReport Gera um resumo do processo de validação, permitindo que o DQ Validator
submeta-o diretamente ao E-log, ferramenta de registro de atividades oficial do
ATLAS;
DQHistory Apresenta um gráfico contendo o histórico para um determinado canal ba-
seado na análise de histogramas;
6.2.2 Painel para monitoramento de rodadas de calibração
Tem como objetivo auxiliar os especialistas em rodadas de calibração. Existem
atualmente três plug-ins :
Calibration Overlay Mostra as constantes de calibração em relação ao tempo. Oferece
ainda uma ferramenta de gerenciamento de gráficos, permitindo ao analista uma
série de ações interativas.
HV Changes Valida a diferença entre as medidas dos sistema de altas tensões e os
valores nominais, emitindo alertas conforme limiares escolhidos pelos analistas.
CalibRuns Apresenta a tabela com as últimas rodadas de runs de calibração.
47
6.3 Desenvolvimento de plug-ins
A extensão de funcionalidades da plataforma pode ser realizada através do desen-
volvimento de novos componentes. A plataforma deve ser capaz de prover um ambiente de
desenvolvimento a fim de padronizar e criar uma metodologia no processo de elaboração
de novas ferramentas de análise.
O colaborador cadastra o plug-in desenvolvido através da inserção de um nome,
descrição da extensão, linguagem de programação utilizada e categoria, onde categoria
indica para qual grupo no TileCal a ferramenta desenvolvida destina-se. Existem dois
tipos de extensões: gadgets e functions. Enquanto gadgets são relacionadas ao front-end,
as functions servem como fonte de informações processadas para outras extensões.
Para cada linguagem de programação existe uma API específica para desenvolver
funcionalidades novas. A Figura 6.3 apresenta, como exemplo, um plug-in desenvolvido
em Python. Observa-se que a classe herda um conjunto de métodos de uma classe-pai,
obedecendo o paradigma de OO [47].
Figura 6.3: Exemplo de plug-in implementado na linguagem Python.
A integração futura do MCWS na plataforma Tile-in-ONE se dará por meio do
desenvolvimento desses plug-ins com funcionalidades específicas.
48
6.4 Tecnologias utilizadas
O Tile-in-ONE faz uso de diversas tecnologias e bibliotecas de suporte para realizar
suas funções. Os aspectos considerados para a escolha de tais tecnologias são manutenção
do sistema, desempenho, e flexibilidade oferecida para execução de determinadas tarefas.
O sistema é desenvolvido através de uma plataforma web, o Django [48], feita a
partir da linguagem computacional Python [29]. Interações entre o sistema e o cliente são
realizadas através da biblioteca JQuery [49], em Javascript [37].
O servidor HTTP para Unix Gunicorn [50] é utilizado para prover os serviços for-
necidos pela plataforma Tile-in-ONE. O Apache [34] garante acessos através do protocolo
HTTPS e fornece arquivos estáticos tais como imagens, folhas de estilo ou rotinas em
Javascript.
6.4.1 Django
Django é um framework para aplicações web, escrito em Python, que utiliza o
padrão MTV (model - template - view). É um projeto de código aberto e foi publicado
sob a licença BSD em 2005.
Suas principais características são:
Mapeamento Objeto-Relacional (ORM) O ORM do Django permite definir a mo-
delagem de dados através de classes em Python. Com isso, é possível gerar tabelas
no banco de dados e manipulá-las sem necessidade de utilizar SQL (sendo sua uti-
lização também permitida).
Interface Administrativa É possível de gerar automaticamente uma interface para ad-
ministrar os modelos criados através do ORM.
Formulários Pode-se gerar formulários automaticamente a partir dos modelos de dados
descritos.
URLs Elegantes Não há limitações para criação de URLs elegantes e de maneira sim-
ples.
49
Sistema de Templates O Django tem uma linguagem de templates poderosa, extensí-
vel e amigável. Com ela é possível separar design, conteúdo e código em Python.
Sistema de Cache Possui um sistema de cache que se integra ao memcached [51] ou em
outros frameworks de cache.
Internacionalização O Django tem suporte para aplicações multi-idioma, bastando des-
crever dicionários de tradução. Termos específicos para funcionalidades desenvolvi-
das são contemplados.
6.4.2 JQuery
JQuery é uma biblioteca Javascript cross-browser desenvolvida para facilitar inte-
rações com o HTML no lado do cliente. Possui código aberto e faz uso da Licença MIT
ou da GNU General Public License versão 2.4. A sintaxe do jQuery foi desenvolvida para
tornar alguns recursos em Javascript mais simples, tais como: a navegação do documento
HTML, a seleção de elementos DOM, a criação de animações, a manipulação de eventos e
o desenvolvimento de aplicações AJAX [52]. A biblioteca também oferece a possibilidade
de criação de plug-ins para estendê-la. Fazendo uso de tais facilidades, os desenvolvedores
podem criar camadas de abstração para interações de mais baixo nível, simplificando o
desenvolvimento de aplicações web dinâmicas de grande complexidade.
Os principais motivos para a utilização do JQuery no Tile-in-ONE são:
• Resolução da incompatibilidade entre os navegadores;
• Redução de código;
• Reutilização de código através de plug-ins.
• Utilização de uma vasta quantidade de plug-ins criados por outros desenvolvedores.
• Possui aplicações para AJAX e DOM [36].
• Tem implementação segura de recursos do CSS [38], contemplando versões CSS1,
CSS2 e também CSS3.
50
6.4.3 Gunicorn
Gunicorn é um servidor WSGI [53] HTTP para UNIX implementado em Python.
As características apresentadas pelo Gunicorn que permitiram sua utilização no
projeto Tile-in-ONE são:
• Suporte a WSGI e Django em modo nativo;
• Gerência de processos automáticos;
• Compatibilidade com múltiplas plataformas web;
• Facilmente configurável através da linguagem de programação Python;
• Permite configuração para múltiplos processamentos;
6.4.4 Apache
O servidor Apache é o mais bem sucedido servidor web livre. Foi criado em 1995
por Rob McCool. Em uma pesquisa realizada em dezembro de 2007 [54], foi constatado
que a utilização do Apache representava cerca de 47,20% dos servidores ativos no mundo.
Em maio de 2010, o Apache serviu aproximadamente 54,68% de todos os sites e mais de
66% dos milhões de sites mais movimentados. É a principal tecnologia da Apache Software
Foundation, responsável por mais de uma dezena de projetos envolvendo tecnologias de
transmissão via web, processamento de dados e execução de aplicativos distribuídos.
6.4.5 Protocolo SOAP
A Arquitetura Orientada a Serviços provê a troca de informações em um ambiente
distribuído e descentralizado. Para tal, utiliza o paradigma request/reply para estabelecer
a comunicação entre os sistemas clientes e os sistemas que implementam os serviços [45].
SOAP é projetado para ser um protocolo que possibilita a comunicação sobre a
arquitetura SOA [55]. Pode ser usado para criar interações complexas ao utilizar o para-
digma do SOA quando combina as mensagens trocadas entre dois nós, as funcionalidades
51
oferecidas pelos protocolos de transmissão e as informações da aplicação. SOAP é um
protocolo que apresenta sobrecarga pequena em relação às informações funcionais trans-
mitidas, independente da plataforma, sistema operacional ou da forma de transmissão.
É implementado, por exemplo, usando protocolo HTTP. As mensagens SOAP são docu-
mentos XML padronizados, onde o elemento básico é a marcação envelope, que possui
dois elementos: header e body. O elemento body prove um simples mecanismo para trocar
informações obrigatórias. Nele estão inseridos dados de retorno ou argumentos de função,
ou mesmo, alguma mensagem de erro de segmentação. A formatação dá-se através de
XML. Por sua vez, o elemento header pode conter, ou não, marcações de configuração,
como identificadores de sessão ou chaves de segurança. Essas marcações são definidas por
aplicação, não havendo uma padronização, com o objetivo de deixar o protocolo flexível.
A seguir são listadas algumas das vantagens sobre o protocolo SOAP:
• É possível usar SOAP em ambientes heterogêneos em relação a plataformas, lo-
calização geográfica, sistemas operacionais, linguagem de programação e qualquer
protocolo.
• É baseado em documentos XML e por isso, apresenta formatação consolidada, es-
truturada, compreensível pelo homem (não somente pelo computador) e eficientes
mecanismos de leitura.
• A habilidade deste protocolo em trabalhar entre plataformas e sistemas operaci-
onais permite a total inter operacionalidade. Muitas corporações utilizam SOAP
para conectar sistemas legados, recuperando dados como mensagens que podem ser
enviadas e consumidas por outras aplicações.
• Apesar de simples, o SOAP é robusto quando comparado a outros sistemas baseados
em XML. O protocolo SOAP pode ser usado para aplicações de grande escala:
através de protocolos como HTTP para escalar de acordo com o tamanho da rede,
esquemas XML para definir tipos de dados e um header flexível para expandir o
protocolo de troca de mensagens.
52
Por estas vantagens, SOAP é padrão W3C [56].
Capítulo 7
Conclusão
É no CERN, o maior laboratório de Física de Partículas do mundo, que encontra-
se o acelerador de partículas LHC. Ao longo da circunferência do colisor estão instalados
detectores de partículas altamente especializados.
O ATLAS, maior detector do LHC, é composto por diversos subsistemas com
características específicas, que variam de acordo com suas funcionalidades.
O Calorímetro de Telhas do ATLAS (TileCal) tem como função medir a energia
das partículas geradas após uma colisão. A aquisição de dados físicos é realizada através
de aproximadamente 10.000 fotomultiplicadores.
Essencialmente, existem dois tipos de análises comum a todos os detectores do
LHC: análises online (que ocorrem enquanto partículas são aceleradas no LHC) e análises
offline (iniciadas assim que os eventos selecionados durante a análise online são armaze-
nados).
O processo de monitoração de Qualidade de Dados offline no TileCal é sistemático
e possui diversas ferramentas web de auxílio: o MCWS foi desenvolvido para auxiliar a
monitoração dos aproximadamente 10.000 canais de leitura eletrônica do calorímetro.
Atuando como um camada de abstração técnica, através de um navegador, a co-
laboração tem acesso à lista de canais danificados, fornecida pelo MCWS, sistema de-
senvolvido. De maneira gráfica, os membros são guiados por funcionalidades oferecidas
para atualizar tal referência, quando necessário. Resultados gráficos e estatísticos são
54
gerados e podem ser exportados, permitindo que a colaboração discuta-os em reuniões. O
sistema fornece ainda uma interface para administrar membros e é protegido por senha,
característica importante ao lidar com dados sensíveis para a colaboração.
Apesar de aplicado apenas para o Calorímetro de Telhas do ATLAS, o MCWS
pode ser estendido para outros detectores. O calorímetro de argônio líquido (LAr), por
exemplo, que também compõe o sistema de calorímetria do experimento, apresenta ca-
racterísticas físicas similares. Sendo o processo de monitoração de qualidade de dados
também semelhante ao utilizado no TileCal, o LAr é um bom candidato para aplica-
ção da solução elaborada e abordada neste projeto final de graduação. Fora do CERN,
considerando-se restrições relacionadas a infra estrutura oferecida por diferentes ambien-
tes, e sendo o MCWS um sistema de apoio a monitoração de qualidade de dados adqui-
ridos por sensores finamente segmentados, conclui-se que a solução desenvolvida poderia
ser aplicada em outros ambientes com características, tais como: aquisição de dados e
processo de monitoração de qualidade, que depende do contexto e especificação por parte
dos usuários.
Recentemente, um dos objetivos do LHC foi atingido: comprovar experimental-
mente a existência do bóson de Higgs. Neste contexto, destaca-se a importância em as-
segurar a qualidade dos dados adquiridos, sendo o principal foco do colaboração análises
físicas.
Inúmeras foram as ferramentas desenvolvidas para auxiliar as análises offline da
colaboração TileCal ao longo do tempo. Entretanto, a ausência de padronização ou des-
centralização no desenvolvimento aumenta a complexidade do processo de análise: prover
manutenção de diversos sistemas requer mão de obra especializada em múltiplas tecnolo-
gias; ou ainda, a diversidade de ferramentas dificulta o aprendizado de novos membros.
Essas características identificadas motivaram o desenvolvimento do Tile-in-ONE, uma pla-
taforma de integração cujo principal objetivo é reunir ferramentas de auxilio de análises
de dados dos grupos que compõem o TileCal. Por se tratar de um ambiente colaborativo,
as funcionalidades podem ser estendidas através de plug-ins pelo próprio usuário, guiado
55
por uma interface de desenvolvimento que será fornecida pela própria plataforma web.
Referências Bibliográficas
[1] “CDS - CERN Document Server”,
Acessado em outubro de 2013. cds.cern.ch.
[2] “ATLAS Photos”,
Acessado em dezembro de 2013. http://www.atlas.ch/photos/.
[3] TORRES, R., Sistema Online de Filtragem em um Ambiente com Alta Taxa de
Eventos e Fina Granularidade. Ph.D. dissertation, COPPE/UFRJ, Rio de Janeiro,
2010.
[4] The ATLAS Collaboration, “The ATLAS Experiment at the CERN Large Hadron
Collider”, Journal of Instrumentation, v. 3, n. 08, Agosto 2008.
[5] ATLAS/Tile Calorimeter Collaboration, Tile Calorimeter Calorimeter Technical De-
sign Report, Report, CERN, 1996. CERN/LHCC 96–42.
[6] LAST, M., Understanding the group development process in global software teams,
v. 3. Frontiers in Education, Novembro 2003.
[7] MOCKUS, A., HERBSLEB, J., “Challenges of global software development”. In:
Software Metrics Symposium, 2001.
[8] TAWEEL, A., DELANEY, B., ARVANITIS, T., et al., “Communication, Knowledge
and Co-ordination Management in Globally Distributed Software Development: In-
formed by a scientific Software Engineering Case Study”, Fourth IEEE International
Conference on Global Software Engineering, ICGSE, pp. 370–375, Julho 2009.
57
[9] PHUWANARTNURAK, A., “Interdisciplinary collaboration through wikis in soft-
ware development”, Workshop on Wikis for Software Engineering, pp. 82–90, Maio
2009.
[10] FAIER, J., Análise de Componentes Independentes para a Monitoração da Qualidade
de Dados em Séries Temporais. Ph.D. dissertation, COPPE/UFRJ, Rio de Janeiro,
2011.
[11] “The European Laboratory for Particle Physics”,
Acessado em dezembro de 2013. http://www.cern.ch.
[12] “The Large Hadron Collider”,
Acessado em dezembro de 2013. http://lhc.web.cern.ch.
[13] ATLAS Collaboration, ATLAS: Technical Proposal for a General-Purpose pp Expe-
riment at the Large Hadron Collider at CERN, Report, CERN, 1994. CERN/LHCC
94–43.
[14] “ATLAS Factsheet”,
Acessado em dezembro de 2013. http://www.atlas.ch/pdf/ATLAS_fact_sheets.pdf.
[15] ATLAS HLT/DAQ/DCS Group , ATLAS High-Level Trigger, Data Acquisition and
Controls Technical Design Report , Report, CERN , 2002. ATLAS TDR-016 .
[16] WIGMANS, R., “Advances in Hadron Calorimetry”, Annual Review of Nuclear and
Particle Science, , 1991.
[17] COLLABORATION, A., “Observation of a new particle in the search for the Standard
Model Higgs boson with the ATLAS detector at the LHC”, Physics Letters B, v. 716,
n. 1, pp. 1–29, 2012.
[18] GRIFFITHS, D., Introduction to elementary particles. E.U.A, Wiley-VCH, 2008.
[19] BAJKO, M., BERTINELLI, F., CATALAN-LASHERAS, N., et al., “Report of the
Task Force on the Incident of 19th September 2008 at the LHC”, , Março 2009.
[20] EVANS, L., BRYANT, P., “LHC Machine”, Journal of Instrumentation, v. 3, n. 08,
Aug. 2008.
58
[21] The ALICE Collaboration, “The ALICE experiment at the CERN LHC”, Journal of
Instrumentation, v. 3, n. 08, Aug. 2008.
[22] The CMS Collaboration, “The CMS experiment at the CERN LHC”, Journal of
Instrumentation, v. 3, n. 08, Ago 2008.
[23] SZUMLAK, T., “The LHCb experiment”, Acta Physica Polonica. Series B: Elemen-
tary Particle Physics, Nuclear Physics, Statistical Physics, Theory of Relativity, Field
Theory, v. 41, n. 7, pp. 1661–1668, 2010.
[24] The ATLAS Colaboration, “Technical Design Report”, , 1996.
[25] “The Nobel Prize in Physics 2013”,
http://www.nobelprize.org/nobel_prizes/physics/laureates/2013/press.pdf,
Outubro 2013.
[26] The ATLAS COLLABORATION, “Trigger Group ATLAS First-Level Trigger Tech-
nical Design Report ATLAS TDR-12”, , 1998.
[27] “ATLAS Offline ATHENA Framework, Twiki Page”,
Acessado em dezembro de 2013.
https://twiki.cern.ch/twiki/bin/viewauth/AtlasComputing/AthenaFramework.
[28] “C++ Programming Language”,
Acessado em dezembro de 2013. http://www.cplusplus.com/.
[29] “Python Programming Language”,
Acessado em dezembro de 2013. http://www.python.org/.
[30] VALASSI, A., BASSET, R., CLEMENCIC, M., et al., “COOL, LCG Conditions
Database for the LHC Experiments : Development and Deployment Status”, , n.
CERN-IT-Note-2008-019, pp. 8, Novembro 2008.
[31] KOLOS, S., CORSO-RADU, A., HADAVAND, H., et al., “A software framework for
Data Quality Monitoring in ATLAS”, v. 120, pp. 022033, 2007.
[32] “ROOT - A Data Analysis Framework ”,
Acessado em detembro de 2013. http://root.cern.ch/drupal/.
59
[33] “ SQLite Software Library ”,
Acessado em dezembro de 2013. http://www.sqlite.org/.
[34] “Servidor HTTP Apache”,
Acessado em dezembro de 2013. http://www.apache.org/.
[35] “Extensible Markup Language (XML), World Wide Web Consortium (W3C)”,
Acessado em dezembro de 2013. www.w3.org/XML/.
[36] “Document Object Model (DOM), World Wide Web Consortium (W3C)”,
Acessado em dezembro de 2013. www.w3.org/DOM/.
[37] FLANAGAN, D., JavaScript: the definitive guide. 5 ed. O’Reilly, 2006.
[38] “Cascading Style Sheets, World Wide Web Consortium (W3C)”,
Acessado em dezembro de 2013. www.w3.org/Style/CSS/.
[39] “SAX - Aplicação para interface de programação para XML.”,
Acessado em dezembro de 2013. www.saxproject.org.
[40] “Relação entre o método SAX e o método DOM, World Wide Web Consortium
(W3C)”,
Acessado em dezembro de 2013. http://www.w3.org/DOM/faq.html#SAXandDOM.
[41] GULBRANSEN, D., BARTLETT, K., BINGHAM, E. G., et al., Using XML. Que
Publishing, 2002.
[42] “Hypertext Preprocessor”,
Acessado em dezembro de 2013. http://www.php.net.
[43] FIASCARIS, M., “Tile Calorimeter Project Status Report”, ATLAS Week Outubro
de 2012, 2012.
[44] SIVOLELLA, A., FERREIRA, F., MAIDANTCHIK, C., et al., Tile-in-ONE, Report,
CERN, outubro 2013. ATL-TILECAL-SLIDE-2013-833.
[45] CURBERA, F., LEYMANN, F., STOREY, T., et al., Web Services Plataform Arch-
tecture. 4 ed. Paperback, 2005.
60
[46] WORDEN, M. V., Study of the response to isolated muons from collisions of the
ATLAS Tile Calorimeter’s gap/crack cells. Ph.D. dissertation, Universiteit van Ams-
terdam, Amsterdam, abril 2012.
[47] KINDLER, E., KRIVY, I., Object-oriented simulation of systems with sophisticated
control. International Journal of General Systems, 2011.
[48] “Django Web Development Framework”,
Acessado em dezembro de 2013. https://www.djangoproject.com/.
[49] “JQuery. Javascript Library”,
Acessado em dezembro de 2013. http://jquery.com/.
[50] “ Servidor HTTP para UNIX Gunicorn ”,
Acessado em dezembro de 2013. http://gunicorn.org/.
[51] “Memcached Cache Framework”,
Acessado em dezembro de 2013. http://memcached.org/.
[52] GARRETT, J. J., “Ajax: A New Approach to Web Applications”, Adaptive Path:
http://adaptivepath.com/ideas/essays/archives/000385.php, Fevereiro 2005.
[53] “WSGI Web Server Gateway Interface”,
Acessado em dezembro e 2013. http://wsgi.readthedocs.org/en/latest/.
[54] “Netcraft December 2007 Web Server Survey”,
Acessado em dezembro de 2013.
news.netcraft.com/archives/2007/12/29/december_2007_web_server_survey.html.
[55] KRAFZIG, D., BANKE, K., SLAMA, D., Enterprise SOA. Prentice Hall, 2005.
[56] “ Padrão W3C ”,
Acessado em dezembro de 2013. http://www.w3.org/standards/.
Apêndice A
Produção Bibliográfica
Três fases descrevem o funcionamento do LHC no CERN: comissionamento, quando
os institutos validaram o funcionamento do colisor de partículas recém montado em cola-
boração; operação, quando ocorreram colisões de partículas atingindo a energia de 14 TeV
projetada a priori; e atualização, fase em que o colisor encontra-se atualmente e corres-
ponde a estudos sobre o que ocorreu durante as fases anteriores que podem ser melhoradas
para o projeto do próximo colisor de partículas a ser montado.
No segundo semestre de 2007, a autora ingressou no Laboratório de Processamento
de Sinais (LPS) e iniciou sua colaboração com o projeto CERN no desenvolvimento e ma-
nutenção de soluções na área de engenharia de software, quando foram elaborados sistemas
para auxiliar a monitoração dos testes realizados durante a fase de comissionamento do
detector. Primeiramente foi necessário fazer um estudo sobre os processos de análise do
TileCal e as ferramentas já existentes, desenvolvidas por outros alunos no mesmo contexto
da colaboração do LPS e CERN: O TileComm Analysis armazena os histogramas gerados
após a etapa de reconstrução dos dados, analisa os resultados obtidos e fornece uma visu-
alização orientada aos equipamentos através de informações referentes a sua performance;
Já o Timeline fornece o histórico do estado dos equipamentos de maneira cronológica; O
Web Interface for Shifters (WIS) apoia as etapas de monitoramento através do gerenci-
amento de parâmetros dos testes efetuados com o colisor de partículas, da visualização
gráfica da performance do detector e das informações de todos os equipamentos que cada
teste utilizou; Resultados automáticos gerados por algoritmos próprios do experimento
ATLAS (DQMF) podem ser acompanhados pela colaboração através do DQM Viewer
62
de maneira gráfica; Ao final da fase de comissionamento, o DCS Web System foi outro
sistema desenvolvido com o objetivo de monitorar a eletrônica do calorímetro de telhas,
como fontes de baixa e alta tensão, placas mãe e também, o sistema de refrigeração do
detector.
Com o início da fase de operação a importância em se obter confiabilidade nos
dados adquiridos tornou-se parte do processo de análise do grupo de qualidade de dados do
TileCal. Monitorar os aproximadamente 10.000 canais de leitura eletrônica do calorímetro
a fim de identificar problemas durante a aquisição é uma etapa importante para garantia
de qualidade da informação que está sendo armazenada e será posteriormente analisada.
Além disso, as colisões ocorridas no LHC emitem alta radiação, e isso compromete a
leitura dos dados realizada pelos PMTs.
O reparo desses componentes pode ser feito, porém, somente nos períodos de ma-
nutenção, que ocorrem apenas uma vez ao ano, já que o colisor está instalado a 175 metros
de profundidade e emite alta radiação. Existe entretanto um sistema de calibração para
aplicar correções adequadas nas leituras dos canais afetados. As chamadas constantes
de calibração permitem compensar os desvios nas leituras dos canais, aplicando-as como
um fator de multiplicação sobre os sinais de resposta. Existem cerca de 10 constantes de
calibração para cada canal existente no TileCal. Sendo, portanto necessário monitorar
até 100.000 valores, outro sistema web foi desenvolvido.
Em 2008, a autora trabalhou fisicamente no centro europeu, no qual permane-
ceu até o primeiro semestre de 2009, retornando em curtos períodos em anos seguintes
para oferecer suporte e estender funcionalidades acerca das ferramentas desenvolvidas. A
proposta na ocasião foi elaborar e implementar uma solução computacional para a moni-
toração dos canais de leitura referentes a eletrônica de aquisição do TileCal, de acordo com
análise de requisitos, de maneira integrada com as ferramentas já existentes no cenário
descrito.
Os trabalhos com os quais esteve envolvida em colaboração com o CERN foram
apresentados no Encontro Nacional de Física de Partículas e Campos (ENFPC) em duas
ocasiões: agosto de 2010, em Passa Quatro, Minas Gerais; e junho de 2011, em Foz do
Iguaçu, Paraná; Como consequência, dois artigos foram publicados nos anais da Com-
puting High Energy Physics (CHEP): 2010, em Taiwan, China; e 2012, em Nova Iorque,
63
EUA.
Em 2012, Ao final da fase de operação, o gerente de aquisição de dados do TileCal
avaliou a grande quantidade de sistemas web existentes para apoiar a análise do grupo
de qualidade de dados do experimento e solicitou que esses sistemas fossem integrados
em uma plataforma única. Foi elaborado e desenvolvido, então, um ambiente capaz de
reunir os sistemas descritos anteriormente, sem alterar o processo de trabalho que os
pesquisadores já estão acostumados. Este trabalho gerou nova publicação de artigo para
o CHEP 2013, que está em fase de revisão e será publicado em 2014.
A seguir encontram-se os resumos das publicações.
1. The Monitoring and Calibration Web Systems for the ATLAS Tile Calorimeter Data
Quality Analysis, SIVOLELLA, A., MAIDANTCHIK, C., FERREIRA, F., Compu-
ting High Energy Physics, New York, USA, 2012
The Tile Calorimeter (TileCal), one of the ATLAS detectors, has four partitions,
where each one contains 64 modules and each module has up to 48 PhotoMulTipliers
(PMTs), totalizing more than 10,000 electronic channels. The Monitoring and Cali-
bration Web System (MCWS) supports data quality analyses at channels level. This
application was developed to assess the detector status and verify its performance,
presenting the problematic known channels list from the official database that stores
the detector conditions data (COOL). The bad channels list guides the data quality
validator during analyses in order to identify new problematic channels. Through the
system, it is also possible to update the channels list directly in the COOL database.
MCWS generates results, as eta-phi plots and comparative tables with masked chan-
nels percentage, which concerns TileCal status, and it is accessible by all ATLAS
collaboration. Annually, there is an intervention on LHC (Large Hadronic Collider)
when the detector equipments (PMTs, motherboards, voltages and cables, for exam-
ple) are fixed or replaced by new ones. When a channel needs to be repaired, the
calibration constants stored into COOL database must be updated, otherwise they
may negatively interfere in the data quality analyses. A MCWS functionality ma-
nages the calibration constants by updating their values in COOL database. The
64
development team foresees an integration with the Tile detector control Web system
(DCS) in order to identify voltage problems automatically, since the channels are
fed by high voltage sources. The MCWS has been used by the Tile community since
2008, during the commissioning phase, and was upgraded to respect the ATLAS
operation specifications.
2. Web System for Data Quality Assessment of Tile Calorimeter During the ATLAS
Operation, MAIDANTCHIK, C., FERREIRA, F., GRAEL, F., SIVOLELLA, A.,
BALABRAM, L., Computing High Energy Physics, Taipei, Taiwan, 2010
TileCal, the barrel hadronic calorimeter of the ATLAS experiment, gathers almost
about 10,000 electronic channels. The supervision of the detector behavior is very
important in order to ensure proper operation. Collaborators perform analysis over
reconstructed data of calibration runs for giving detailed considerations about the
equipment status. During the commissioning period, our group has developed seven
web systems to support the data quality (DQ) assessment task. Each system covers
a part of the process by providing information on the latest runs, displaying the DQ
status from the monitoring framework, giving details about power supplies opera-
tion, presenting the generated plots and storing the validation outcomes, assisting to
write logbook entries, creating and submitting the bad channels list to the conditions
database and publishing the equipment performance history. The ATLAS operation
increases amount of data that are retrieved, processed and stored by the web systems.
In order to accomplish the new requirements, an optimized data model was designed
to reduce the number of needed queries. The web systems were reassembled in a
unique system in order to provide an integrated view of the validating process. The
server load was minimized by using asynchronous requests from the browser.
3. The Tile Calorimeter Web Systems for Data Quality Analyses, MAIDANTCHIK,
C., GALVÃO, K. K. GRAEL, F. F., FERREIRA, F. G., GOMES, A. S., Computing
High Energy Physics, Praga, Rep. Tcheca, 2009
65
The ATLAS detector consists of four major components: inner tracker, calorime-
ter, muon spectrometer and magnet system. In the Tile Calorimeter (TileCal), there
are 4 partitions, each partition has 64 modules and each module has up to 48 chan-
nels. During the ATLAS commissioning phase, a group of physicists need to analyze
the Tile Calorimeter data quality, generate reports and update the official database,
when necessary. The Tile Commissioning Web Systems (TCWS) retrieves infor-
mation from different directories and databases, executes programs that generate
results, stores comments and verifies the calorimeter status. TCWS integrates dif-
ferent applications, each one presenting a unique data view. The Web Interface for
Shifters (WIS) supports monitoring tasks by managing test parameters and all the
calorimeter status. The TileComm Analysis stores plots, automatic analyses results
and comments concerning the tests. With the necessity of increasing granularity, a
new application was created: the Monitoring and Calibration Web System (MCWS).
This application supports data quality analyses at channels level by presenting the
automatic analyses results, the problematic known channels and the channels masked
by the shifters. Through the web system, it’s possible to generate plots and reports,
related to the channels, identify new bad channels and update the Bad Channels
List at the ATLAS official database (COOL DB). The Data Quality Monitoring Vi-
ewer (DQM Viewer) displays the data quality automatic results through an oriented
visualization.
4. The Monitoring & Calibration Web System of the ATLAS hadronic calorimeter,
MAIDANTCHIK, C., MARROQUIM, F., SIVOLELLA, A., Encontro Nacional de
Física 2011
The scintillator tiles hadronic calorimeter (TileCal) of the ATLAS detector mea-
sures the energy of resultant particles in a collision. The calorimetry system was
designed to absorb the energy of the particles that crosses the detector and is compo-
sed by three barres, each one equally divided into 64 modules. The ionizing particles
that cross the tiles induce the production of light, which intensity is proportional
to the energy deposited by the fragment. The produced light propagates through the
66
tiles towards the edges, where it is absorbed and displaced until reaching the photo-
multiplier tubes (PMTs), also known as electronic reading channels. Each module
combines till 45 PMTs. For each run, the recontruction process starts with a data
analysis that can comprises different levels of information granularity till arriving
to the PMTs level. Following this phase, the Data Quality Monitoring Framework
(DQMF) system automatically generates quality indicators associated to the chan-
nels. Depending on the configuration that is registered in the DQMF, the channel
status can be automatically defined as good, affected or bad. The status of each mo-
dule is defined by the percentage of existing good, affected or bad channels. At this
point, the analysis of modules allows the identification of the ones that are proble-
matic by the examination of graphics that are automatically generated during the
data reconstruction stage. Then, an analysis of a module performance by a time
period that encompasses different types of runs is performed. In this last step, the
list of problematic channels can be modified through the insertion or exclusion of
PTMs, as in the case when a channel is substituted. Additionally, during the whole
calorimeter operation, it is fundamental to identify the electronic channels that are
active, dead (nor working), noisy and the ones that presents saturation in the sig-
nal digitalization process. The Monitoring and Calibration Web System (MCWS)
was developed in collaboration with the TileCal and the UFRJ. MCWS provides the
bad PMTs list and respective problems, which can have different reasons, such as
signal transmission fault, defect on the channel power supply, laser calibration trou-
bles, among other dificulties. MCWS supports the arduous analysis of the thousands
electronic channels through the operation of simple functions in the interface. The
system accesses the oficial ATLAS database and generates graphical results that are
presented through the Web. The MCWS system also presents the TileCal general
status as a reference to other ATLAS subdetectores.
5. Monitoramento dos canais de leitura eletrônica do Calorímetro Hadrônico do ATLAS,
SIVOLELLA, A., MAIDANTCHIK, C., FERREIRA, F., SEIXAS, M., XXXI En-
contro Nacional de Física de Partículas e Campo, Passa Quatro (MG), 2010
67
O sistema de aquisição do calorímetro Hadrônico de Telhas (TileCal) do detector
ATLAS é constituído por aproximadamente 10.000 canais eletrônicos. As fotomul-
tiplicadoras (em inglês, photomultipliers ou PMTs) detectam a luz produzida pelas
colisões e a convertem em sinais de corrente elétrica proporcionais a energia deposi-
tada pela partícula. A alimentação da eletrônica de aquisição do TileCal é realizada
através de fontes de baixas e altas tensões e cada fotossensor possui uma carga
nominal específica. E fundamental identificar canais mortos ou ruidosos para cer-
tificação da qualidade dos dados gerados durante toda a operação. Alguns defeitos
podem invalidar uma PMT, como por exemplo, falhas em sua alimentação ou na
conversão da luz em sinais de corrente. Dois sistemas web foram desenvolvidos
para auxiliar a análise dos milhares de canais. O “Monitoring and Calibration Web
System” (MCWS) permite a atualização das condições dos canais e o “DCS Web
System” apoia o monitoramento das fontes de tensão para períodos de um dia e
um mês. O processo de análise se inicia logo após a aquisição de um determinado
número de eventos. A reconstrução é então realizada e os índices de qualidade as-
sociados a cada canal de leitura eletrônica são gerados automaticamente pelo “Data
Quality Monitoring Framework” (DQMF). Após esta etapa, os responsáveis avaliam
os gráficos gerados durante a reconstrução, que representam dados resultantes dos
diferentes tipos de eventos adquiridos. Através do MCWS, a colaboração tem acesso
a lista de PMTs conhecidamente ruins e seus respectivos problemas. O MCWS ofe-
rece funcionalidades que possibilitam a atualização desta lista, e a cada atualização
o sistema exige a inserção de comentários que descrevem sucintamente as altera-
ções realizadas no estados das PMTs. O histórico dessas atualizações também pode
ser acompanhado pelo sistema. Por sua vez, o DCS Web System apresenta uma
visão global do sistema de alimentação, onde são atribuídos estados a cada seção
alimentada. E possível detalhar as informações, podendo-se acompanhar corren-
tes, tensões e temperaturas por canal. Atualmente, a nossa equipe está integrando
os sistemas MCWS e DCS, de forma a permitir o detalhamento necessário para a
identificação de problemas nos canais provenientes das falhas nas fontes de alimen-
tação. Como projeto futuro, utilizaremos técnicas de Inteligência Computacional
para realizar uma análise preditiva dos equipamentos do calorímetro, a fim de di-
68
agnosticar defeitos e indicar a necessidade de substituição desses equipamentos nos
curtos períodos de abertura do colisor.
6. Tile-in-ONE, Cunha, R., Solans, C., Sivolella, A., Ferreira, F., Maidantchik, C.,
Publicação Técnica, Genebra, 2013.
The Tile calorimeter is one of the sub-detectors of ATLAS. In order to ensure its
proper operation and assess the quality of data, many tasks are to be performed by
means of many tools which were developed independently to satisfy different needs.
Thus, these systems are commonly implemented without a global perspective of the
detector and lack basic software features. Besides, in some cases they overlap in the
objectives and resources with another one. It is therefore evident the necessity of
an infrastructure to allow the implementation of any functionality without having
to duplicate the effort while being possible to integrate with an overall view of the
detector status. Tile-in-ONE is intended to meet these needs, by providing a unique
system, which integrates all the web systems and tools used by the Tile calorimeter,
with a standard development technology and documentation. It also intends to abs-
tract the user from knowing where and how to get the wanted data by providing a
user friendly interface. It is based in a server containing a core, which represents the
basic framework that loads the configuration, manages user settings and loads plu-
gins at run-time; a set of services, which provide common features to be used by the
plug-ins, such as connectors to different databases and resources; and the plug-ins
themselves which provide features at the top level layer for the users. Moreover, a
web environment is being designed to allow collaborators develop their own plug-ins,
test them and add them to the system. To make it possible, an API is used allowing
any kind of application to be interpreted and displayed in a standard way.
7. A Decision Support System Based on Artificial Neural Networks for Pulmonary Tu-
berculosis Diagnosis, MAIDANTCHIK, C., FERREIRA, F., GRAEL, F., SEIXAS,
J., SIVOLELLA, A., et. al., Publicação de Capítulo de Livro, DOI: 10.5772/19834,
2011
69
8. Sistema web para monitoramento de canais de leitura eletrônica em qualidade de
dados para o detector ATLAS, SIVOLELLA, A., Jornada Giulio Massarani de Ini-
ciação Científica, 2011
9. O Monitoramento de Canais de Leitura Eletrônica do Calorímetro de Telhas do
Experimento ATLAS no CERN, SIVOLELLA, A., Jornada Giulio Massarani de
Iniciação Científica, 2012
10. Plataforma web Tile-in-ONE, SIVOLELLA, A., Jornada Giulio Massarani de Inici-
ação Científica, 2013
