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

Dit paper introduceert ECoLAD, een evaluatieprotocol voor tijdsreeks-anomaliedetectie in voertuigen dat prestaties evalueert onder realistische, beperkte rekenkracht om aan te tonen dat lichtgewicht klassieke methoden vaak robuuster zijn dan diepe leermodellen voor daadwerkelijke implementatie.

De kern

Stel je voor dat je een auto bouwt die zichzelf kan controleren. Deze auto heeft honderden sensoren die constant data sturen: hoe snel de motor draait, hoe hard de remmen werken, of de stuurinrichting goed reageert. Het doel is om direct te zien als er iets misgaat, nog voordat de auto echt kapot gaat.

Dit klinkt geweldig, maar er is een groot probleem: de computer in de auto is niet zo sterk als de supercomputer in een laboratorium.

Dit artikel introduceert een nieuwe manier om te testen of deze "slimme detectoren" (software die fouten opspoort) echt werken in de echte wereld. Ze noemen hun methode ECoLAD.

Hier is de uitleg in simpele taal, met een paar creatieve vergelijkingen:

1. Het Probleem: De "Gymnastiekzaal" vs. De "Fiets"

Tot nu toe testten onderzoekers deze slimme software vaak op krachtige werkplek-computers (zoals een zware laptop of server). Dat is alsof je een olympische gymnast test in een professionele gymnastiekzaal met de beste apparatuur. De gymnast presteert fantastisch.

Maar in een auto zit de software op een kleine, beperkte chip (zoals een fiets met één versnelling). Als die gymnast nu op die fiets moet springen, valt hij misschien wel, of hij kan gewoon niet meer doen wat hij in de zaal kon.

De conclusie van het artikel: Een lijst met de "beste" software, gebaseerd alleen op nauwkeurigheid in een krachtige computer, is misleidend. Het zegt niets over of die software ook werkt in de krappe ruimte van een auto.

2. De Oplossing: ECoLAD (De "Ladder van Beperkingen")

De auteurs hebben een nieuwe testmethode bedacht, ECoLAD. In plaats van alleen te kijken naar "hoe goed is het?", kijken ze ook naar "hoeveel moeite kost het?".

Stel je voor dat je een sporter test met een ladder:

• De bovenste sport: De sporter mag rennen met een rugzak vol gewichten (de krachtige computer).
• De middelste sporten: Je haalt steeds gewichten weg (minder rekenkracht, minder processorkernen).
• De onderste sport: De sporter moet rennen met alleen zijn eigen lichaamsgewicht, op een smal pad (de beperkte auto-chip, slechts één "hersencel" actief).

ECoLAD dwingt de software om deze ladder af te dalen. Ze kijken niet alleen of de software de fouten nog vindt, maar ook of het snel genoeg blijft terwijl de "musculatuur" (rekenkracht) afneemt.

3. Wat Vonden Ze? (De Verassingen)

Toen ze dit deden, zagen ze drie interessante dingen:

• De "Zware Jongens" vallen af: Sommige zeer geavanceerde, complexe software (diep leren / Deep Learning) deed het perfect in de gymzaal. Maar zodra ze op de "fiets" (de auto) moesten, werden ze traag en onbetrouwbaar. Ze waren te zwaar voor de auto.
• De "Oude Krijgers" winnen: Simpele, klassieke methoden (zoals HBOS of COPOD) deden het misschien iets minder perfect in de gymzaal, maar ze bleven razendsnel en betrouwbaar op de fiets. Ze waren lichtgewicht en efficiënt.
• Snelheid is net zo belangrijk als nauwkeurigheid: Als een software 99% van de fouten vindt, maar het duurt 10 seconden om die te vinden, is het nutteloos in een auto die met 100 km/u rijdt. Je wilt het antwoord in milliseconden.

4. De Belangrijkste Les

Het artikel zegt eigenlijk: "Stop met alleen kijken naar wie de hoogste score haalt in de theorie."

In de echte wereld (zoals in een auto) moet je kiezen voor een oplossing die:

1. Snel genoeg is om mee te gaan met de snelheid van de auto.
2. Niet te veel energie verbruikt (zodat de batterij van de auto niet leegloopt).
3. Stabiel blijft, zelfs als de computer het druk heeft.

Samenvattend met een Metafoor

Stel je voor dat je een detective zoekt om een moord op te lossen.

• De oude test: Je kijkt alleen naar wie het slimste brein heeft. Je kiest de professor die alles kan oplossen, maar die heeft een uur nodig om een briefje te lezen.
• De ECoLAD test: Je kijkt ook naar wie het snelste is. Je kiest misschien een agent die iets minder slim is, maar die het antwoord binnen 5 seconden heeft.

Voor een auto die in beweging is, heb je de agent nodig die snel is, niet de professor die te langzaam is. ECoLAD helpt ons precies die agent te vinden.

Technische samenvatting

Hier is een gedetailleerde technische samenvatting van het paper "ECoLAD: Deployment-Oriented Evaluation for Automotive Time-Series Anomaly Detection" in het Nederlands.

Titel

ECoLAD: Implementatie-gerichte Evaluatie voor Anomalie-detectie in Tijdreeksen voor de Automobielindustrie

1. Het Probleem

Bestaande methoden voor anomalie-detectie in tijdreeksen (TSAD) worden doorgaans geëvalueerd op werkstation-hardware onder onbeperkte uitvoeringscondities. Dit leidt tot "leaderboards" die puur op nauwkeurigheid (accuracy) zijn gebaseerd. Voor de implementatie in voertuigen (on-board monitoring) zijn deze resultaten echter misleidend om de volgende redenen:

• Beperkte resources: In-vehicle systemen hebben te maken met strikte CPU-beperkingen en vaak beperkte parallelisatie (soms bijna single-thread).
• Voorspelbare latentie: De detectie moet een voorspelbare latency hebben om te voldoen aan real-time eisen.
• Overhead: Runtime-overhead (zoals data-overdracht en framework-setup), die op versnelde backends (GPU) onzichtbaar is, kan de haalbaarheid op embedded systemen volledig blokkeren.
• Ranking-drift: Methodes die goed presteren op een GPU, kunnen onder geconstraineerde omstandigheden onbruikbaar blijken, terwijl lichtere klassieke methoden juist robuust zijn.

2. Methodologie: Het ECoLAD-protocol

De auteurs introduceren ECoLAD (Efficiency Compute Ladder for Anomaly Detection), een evaluatieprotocol dat gericht is op implementatie-eisen. Het protocol bestaat uit de volgende kerncomponenten:

• Compute-reductieladder (The Ladder): Er wordt een monotoon afnemende reeks van computerniveaus (tiers) gedefinieerd:
  • GPU: Onbeperkt (referentie).
  • CPU-MT: Multi-thread (14 cores).
  • CPU-LT: Beperkt multi-thread (7 cores).
  • CPU-1T: Single-thread (1 core) – dit simuleert de meest strikte implementatieomgeving (zoals een ECU).
• Mechanische schaalregels: Hyperparameters worden niet handmatig hertraint per tier, maar mechanisch geschaald op basis van een reductiefactor $s$.
  • Werkomvang (work) schaalt lineair met $s$.
  • Breedte (width) en heads schalen met $\sqrt{s}$.
  • Diepte (depth) schalen met $s^{1/4}$.
  • Dit zorgt voor een voorspelbare afname van de modelcapaciteit zonder de semantiek van de beslissingen te veranderen.
• Doorvoer-constraints (Throughput Targets): In plaats van alleen naar nauwkeurigheid te kijken, wordt gekeken naar de haalbaarheid bij een specifieke doorvoer ($\tau$, in windows per seconde).
  • Coverage: Het percentage entiteiten dat de doorvoer-doelstelling haalt.
  • Beste AUC-PR: De beste haalbare prestatie onder de doorvoer-constraint.
• Datasets:
  • Telemetry: Propriëtaire auto-data (80k datapunten, 19 features, anomalie-ratio ~0,022).
  • SMD & SMAP: Publieke benchmarks voor server- en ruimteschepen-data om generalisatie te testen.
• Hardware: Experimenten uitgevoerd op een Apple MacBook Pro (M3 Max), waarbij thread-caps expliciet worden ingesteld via PyTorch en OMP-variabelen.

3. Belangrijkste Bijdragen

1. Auditabel Protocol: Een gestructureerde, reproduceerbare ladder voor het reduceren van compute en het beperken van threads, met gedetailleerde logging van configuratieverschillen.
2. Gecombineerde Evaluatie: Rapportage van detectiekwaliteit (AUC-PR) samen met runtime en doorvoer, inclusief Pareto-analyses per tier.
3. Operationalisatie: Een mechanisme voor het selecteren van een werkpunt (operating point) op basis van doorvoer-constraints zonder label-afhankelijke hertraining tijdens de evaluatie.

4. Resultaten en Bevindingen

De studie beantwoordt drie onderzoeksvragen (RQ) en levert de volgende inzichten op:

• RQ1: Verandering in ranking: De rangschikking van methodes verandert drastisch bij het overstappen van GPU naar single-thread CPU.
  • Voorbeeld: LOF (Local Outlier Factor) heeft een hoge doorvoer, maar zijn nauwkeurigheid daalt sterk onder reductie. OmniAnomaly behoudt zijn nauwkeurigheid, maar wordt onbruikbaar door hoge runtime.
  • HBOS en COPOD (klassieke methodes) behouden zowel hoge doorvoer als stabiele nauwkeurigheid over alle tiers.
• RQ2: Degradatiepatronen: Er worden drie degradatiemodes geïdentificeerd:
  1. Backend/Overhead-gelimiteerd: Methodes zoals TimesNet verliezen hun haalbaarheid door CPU-bottlenecks, niet door nauwkeurigheidsverlies.
  2. Kwaliteits-drift: Methodes zoals LOF behouden snelheid maar verliezen detectiekwaliteit bij capaciteitsreductie.
  3. Gracieuze degraders: HBOS en COPOD blijven robuust; bij HBOS neemt de doorvoer zelfs toe bij lagere schaal (minder histogram-bins).
• RQ3: Doorvoer-constraints:
  • Op de CPU-1T tier (single-thread) blijven klassieke methoden (HBOS, COPOD) haalbaar zelfs bij hoge doorvoer-doelen (bijv. 500 Hz).
  • Veel diepe methoden (Deep Learning) worden onhaalbaar voordat ze hun nauwkeurigheid verliezen. Bijvoorbeeld, bij een doel van 500 windows/s zijn veel neurale netwerken niet meer inzetbaar, terwijl klassieke methoden nog steeds boven de random-baseline presteren.
  • De "inference-only" doorvoer is cruciaal: voor methodes met dure training (zoals OmniAnomaly) is de online scoringssnelheid veel hoger dan de full-run snelheid suggereert, maar op single-thread blijft dit een bottleneck.

5. Betekenis en Conclusie

Het paper concludeert dat nauwkeurigheid alleen onvoldoende is voor de selectie van anomalie-detectoren in de automobielindustrie.

• Haalbaarheid eerst: Methodes moeten eerst worden gefilterd op basis van doorvoer- en resource-eisen voordat ze worden beoordeeld op nauwkeurigheid.
• Architecturale gevoeligheid: Diepe methodes zijn vaak gevoelig voor hardware-keuze (GPU vs. CPU) en parallelisatie, terwijl klassieke methoden (zoals histogram-based) vaak beter presteren op beperkte embedded hardware.
• ECoLAD als standaard: Het protocol biedt een gestandaardiseerde manier om de trade-off tussen kwaliteit en kosten (compute) te evalueren, wat essentieel is voor het kiezen van modellen die daadwerkelijk op een voertuig kunnen draaien zonder de real-time eisen te schenden.

Kortom, ECoLAD verschuift de focus van "welk model is het nauwkeurigst?" naar "welk model is haalbaar en robuust onder de specifieke implementatiebeperkingen van een voertuig?".