ECoLAD: Deployment-Oriented Evaluation for Automotive Time-Series Anomaly Detection

O artigo apresenta o ECoLAD, um protocolo de avaliação orientado à implantação que demonstra como detectores de anomalias clássicos e leves mantêm viabilidade e desempenho sob restrições de CPU em telemetria automotiva, enquanto vários métodos profundos perdem a viabilidade antes de perderem a precisão.

O essencial

Imagine que você é o engenheiro chefe de uma montadora de carros. Você quer instalar um "sistema de segurança" nos carros novos. Esse sistema é um detector de anomalias: ele vigia os dados do motor, da direção e dos freios em tempo real para gritar "ALERTA!" se algo estranho acontecer antes de uma pane grave.

O problema é que os carros têm computadores limitados (o processador do carro não é um servidor gigante de data center) e precisam responder instantaneamente.

Aqui está a explicação do paper ECoLAD usando uma analogia simples:

1. O Problema: A "Corrida de F1" vs. O "Trânsito da Cidade"

Até hoje, os cientistas de dados testavam esses sistemas de segurança como se fosse uma corrida de Fórmula 1.

• Como funcionava: Eles rodavam os testes em computadores superpotentes de escritório, com processadores infinitos e sem limites de velocidade.
• O resultado: Eles criavam uma lista de "campeões" baseada apenas em quem tinha a maior precisão (quem acertava mais erros).
• A falha: Quando você leva esse "campeão de F1" para o trânsito real da cidade (o carro de verdade), ele falha. O carro não tem força para rodar aquele sistema pesado, o processador trava, e o sistema de segurança demora 5 segundos para gritar "ALERTA". Para um carro, 5 segundos é uma eternidade; o acidente já aconteceu.

A lição: Um sistema que é o "melhor" no laboratório pode ser inútil no mundo real se for muito lento ou pesado.

2. A Solução: O "ECoLAD" (A Escada de Eficiência)

Os autores criaram um novo método de teste chamado ECoLAD. Pense nele como um teste de resistência em uma escada, onde cada degrau representa um nível de dificuldade maior para o computador do carro.

Em vez de apenas perguntar "Quem é o mais inteligente?", o ECoLAD pergunta: "Quem consegue ser inteligente enquanto está correndo uma maratona com uma mochila pesada?"

A escada tem quatro degraus (níveis):

1. Degrau 1 (GPU): O computador superpotente (como o laboratório).
2. Degrau 2 (CPU Multi): O computador do carro rodando com todos os seus núcleos.
3. Degrau 3 (CPU Limitado): O computador do carro rodando com metade da força.
4. Degrau 4 (CPU 1T - O "Carro Real"): O computador rodando com apenas um núcleo (como se fosse um carro antigo ou um sistema muito limitado).

3. Como eles testaram? (A Regra do "Escalador Mecânico")

Para testar, eles não mudaram o código de cada sistema manualmente. Eles usaram uma "regra mecânica" (uma receita de bolo):

• Se o computador tem menos força, o sistema é obrigado a "diminuir o tamanho" da sua mente automaticamente.
• Se o sistema precisa de 1000 neurônios, e o computador é pequeno, ele é forçado a usar apenas 250.
• Eles mediram: Quanto a precisão caiu? E Quanto a velocidade aumentou?

4. O Que Eles Descobriram? (As Surpresas)

Os resultados foram fascinantes e mudaram o ranking dos "campeões":

• Os "Gigantes de Vidro" (Métodos Profundos/Deep Learning):
  Alguns sistemas muito complexos e inteligentes (como OmniAnomaly ou TimesNet) eram os melhores no laboratório. Mas, assim que foram colocados no "Degrau 4" (o carro real), eles quebraram.

  • Analogia: É como tentar correr uma maratona usando um terno de três peças. Você é elegante e inteligente, mas não consegue correr. Eles perderam a capacidade de funcionar antes mesmo de perderem a inteligência.

• Os "Pequenos e Rápidos" (Métodos Clássicos):
  Sistemas mais simples e antigos (como HBOS ou COPOD) não eram os mais inteligentes no laboratório, mas eram incrivelmente eficientes.

  • Analogia: São como uma bicicleta leve. Não é tão luxuosa quanto um carro de luxo, mas sobe a ladeira com facilidade e nunca fica sem bateria. Eles mantiveram a velocidade e a precisão mesmo com o computador limitado.

• O Fator "Tempo de Treino":
  Eles descobriram que alguns sistemas demoravam horas para "aprender" (treinar) antes de funcionar no carro. No teste de ECoLAD, eles separaram o tempo de "aprender" do tempo de "vigiar".

  • Descoberta: Um sistema pode ser ótimo para vigiar, mas se demorar 1 hora para aprender, ele não serve para um carro que precisa estar pronto em segundos.

5. A Conclusão para o Mundo Real

O paper diz que não basta olhar apenas para a precisão.

Se você vai colocar um sistema de segurança em um carro, você precisa olhar para a viabilidade:

1. Ele consegue rodar no processador fraco do carro?
2. Ele consegue dar o alerta em milissegundos?
3. Ele mantém uma precisão aceitável mesmo sendo "encolhido"?

Resumo da Ópera:
O ECoLAD é um novo "guia de compras" para engenheiros de carros. Ele diz: "Esqueça a lista de campeões de laboratório. Aqui está a lista de quem realmente sobreviveu ao teste de estresse no carro real."

Muitas vezes, a solução mais simples e "menos inteligente" no papel é a única que funciona de verdade dentro do carro. O ECoLAD ajuda a encontrar esses heróis práticos antes que o carro saia da fábrica.

Resumo técnico

Título: ECoLAD: Avaliação Orientada à Implantação para Detecção de Anomalias em Séries Temporais Automotivas

1. O Problema

A detecção de anomalias em séries temporais (TSAD) é crucial para a monitorização de veículos inteligentes (manutenção preditiva, segurança, diagnóstico de falhas). No entanto, a maioria das avaliações atuais é realizada em hardware de workstation sob condições de execução ilimitadas, focando apenas na precisão (ex: AUC-PR).

O artigo identifica uma lacuna crítica: a implantação em veículos (on-board) impõe restrições severas que os benchmarks tradicionais ignoram:

• Latência Previsível: O tempo de inferência deve ser estável e determinístico.
• Paralelismo Limitado: Os sistemas embarcados (ECUs) muitas vezes operam com poucos núcleos de CPU ou em modo de thread única, diferentemente dos servidores de backend.
• Orçamento Computacional Restrito: O hardware tem capacidade de processamento limitada.

O problema central é que rankings baseados apenas em precisão podem mascarar a inviabilidade de métodos complexos em ambientes reais. Um modelo pode ser preciso em um servidor GPU, mas falhar completamente em um ECU devido a sobrecarga de runtime, movimentação de dados ou dependência de paralelismo.

2. Metodologia: O Protocolo ECoLAD

Os autores propõem o ECoLAD (Efficiency Compute Ladder for Anomaly Detection), um protocolo de avaliação orientado à implantação. A metodologia baseia-se em três pilares principais:

• Escada de Redução Computacional Monotônica (Compute Ladder):
  O estudo define quatro "tiers" (níveis) de execução que simulam diferentes capacidades de hardware, reduzindo progressivamente o orçamento computacional:

  1. GPU: Referência de alto desempenho (sem limite de threads).
  2. CPU-MT: CPU multi-thread (14 threads).
  3. CPU-LT: CPU com threads limitadas (7 threads).
  4. CPU-1T: CPU de thread única (1 thread) – o cenário mais restritivo, simulando um ECU conservador.

• Regras de Escalonamento Mecânico:
  Para garantir reprodutibilidade e evitar tuning excessivo por nível, os hiperparâmetros dos modelos são ajustados mecanicamente com base em um fator de redução de computação ($s$). Regras inteiras e monotônicas são aplicadas para reduzir largura, profundidade e cabeças de atenção, garantindo que a arquitetura degrade de forma controlada sem colapsar.

• Análise Sob Restrições de Vazão (Throughput-Constrained):
  Em vez de apenas medir a precisão, o protocolo avalia a viabilidade sob metas de taxa de pontuação ($\tau$, em janelas/segundo).

  • Cobertura (Coverage): A fração de entidades (veículos/servidores) que conseguem atingir a meta de vazão.
  • Melhor AUC-PR Viável: A melhor precisão alcançável entre as configurações que atendem à meta de vazão.
  • Métricas de Tempo: Distinção clara entre tempo de inferência puro ($t_{inf}$) e tempo de execução total (incluindo treinamento), crucial para métodos que ajustam modelos por entidade.

3. Contribuições Principais

1. Protocolo Auditável: Definição explícita de tiers, limites de threads e regras de escalonamento, permitindo reprodutibilidade e comparação justa.
2. Análise Pareto de Qualidade-Custo: Avaliação conjunta de detecção e custo de runtime, mostrando como os rankings mudam sob restrições de hardware.
3. Mecanismo de Seleção de Ponto de Operação: Uma abordagem para selecionar modelos baseados em metas de vazão sem necessidade de retreinamento dependente de rótulos nos dados de avaliação.
4. Estudo Empírico: Aplicação do protocolo em dados proprietários de telemetria automotiva (com anomalias raras, ~0.022) e benchmarks públicos (SMD, SMAP).

4. Resultados Chave

O estudo benchmarkou 10 detectores (5 clássicos como IForest, LOF, HBOS, COPOD, PCA e 5 métodos profundos como OmniAnomaly, USAD, TranAD, GDN, TimesNet).

• Mudança de Ranking (Rank Drift): A precisão não é invariante entre os tiers. Métodos que performam bem em GPU podem degradar severamente em CPU-1T, e vice-versa.
• Comportamento dos Métodos Clássicos:
  • HBOS e COPOD: Demonstraram ser os mais robustos. Mantiveram alta vazão e precisão estável em todos os tiers. Curiosamente, a redução de computação aumentou a vazão do HBOS em alguns casos (menos bins de histograma).
  • LOF: Sofreu degradação significativa na precisão (AUC-PR caiu de 0.145 para 0.073 no SMD ao passar de GPU para CPU-1T), indicando sensibilidade à redução de capacidade, não apenas ao custo.
• Comportamento dos Métodos Profundos:
  • TimesNet: Sofreu de gargalos de backend. A precisão manteve-se estável, mas a vazão caiu drasticamente em CPU (de ~9.500 wps em GPU para ~1.500 wps em CPU-1T), tornando-o inviável para altas taxas de amostragem.
  • OmniAnomaly: Apresentou uma grande diferença entre tempo de inferência e tempo total devido ao ajuste de modelo por entidade (overhead de 55x em dados automotivos no CPU-1T).
• Viabilidade sob Restrições:
  • Em metas de vazão altas (ex: 500 Hz), métodos profundos frequentemente tornam-se inviáveis (cobertura < 50%), enquanto detectores clássicos leves mantêm a cobertura.
  • Métodos que se tornam inviáveis cedo não oferecem nenhum ponto de operação acima da linha de base aleatória em altas vazões.

5. Significado e Conclusão

O artigo conclui que a precisão isolada é insuficiente para a seleção de modelos em sistemas embarcados.

• Filtro de Viabilidade Primeiro: A seleção de detectores deve começar filtrando aqueles que atendem aos requisitos de latência e vazão do sistema-alvo (ex: CPU-1T), e só então otimizar a precisão.
• Gargalos Arquiteturais: A degradação de desempenho sob restrições é frequentemente impulsionada por gargalos de vazão (backend/overhead) e não apenas pela perda de precisão do modelo.
• Impacto na Indústria: O ECoLAD fornece um framework padronizado para comparar detectores sob condições de implantação real, evitando a adoção de modelos que falham em produção devido a restrições de recursos não consideradas nos benchmarks tradicionais.

Em suma, o trabalho desloca o foco da comunidade de "qual é o modelo mais preciso?" para "qual é o modelo mais viável e robusto para o meu hardware específico?".