Work in progress. README to be written when the project stabilizes.
Online anomaly detection on a concurrent embedded system: how does jitter from periodic acquisition threads degrade detector accuracy and end-to-end alarm latency, and how do synchronization primitives modulate this trade-off?
Recent surveys on real-time ML for embedded anomaly detection point to a saturated literature on novel algorithms, but most detectors are evaluated on workstation-class hardware without contention from concurrent system tasks. Real-time systems literature, in turn, studies how scheduler design affects periodic-thread jitter, but rarely measures how that jitter propagates into ML algorithms running on top.
This project sits at the intersection of two literatures that rarely talk to each other. We build a multi-threaded embedded server that streams sensor data from the 3W Dataset (Petrobras), runs an online anomaly detector under controlled concurrent load, and reports a Qt client over TCP. On top of this system we run a partial factorial experiment that varies (i) the detector — sliding Z-score, EWMA, Half-Space Trees, LSTM, GRU; (ii) the concurrent CPU load injected by an adversarial thread; and (iii) the synchronization primitive guarding the shared sensor buffer. The contributions are threefold: empirical, characterizing how detector ranking shifts under contention; methodological, proposing a small reproducible protocol that reports detection accuracy jointly with jitter and end-to-end alarm latency; and systemic, quantifying the impact of mutex choice on detector performance — a dimension typically ignored by the ML community.
The work is grounded in the 3W Dataset (Vargas et al., 2019; Petrobras, 2025) for ecological validity, and is positioned against recent deployment-oriented evaluation efforts such as ECoLAD (2025) and surveys on real-time ML for embedded anomaly detection (arXiv 2512.19383, 2025).
[1 parágrafo + 1 diagrama ASCII simples. Mostre os três blocos: servidor multithread, cliente Qt, pipeline ML offline. Não detalhe nada — é só o panorama.]
[Cole aqui a árvore de pastas que construímos juntos, com 1 linha de comentário em cada. Quem chega no repo precisa saber em 30s "onde mora o quê".]
[Liste por bloco:
- Server: g++ ≥ 11, CMake ≥ 3.20, pthreads
- Client: Qt 6 (Widgets, Network, Charts)
- ML/Analysis: Python ≥ 3.10, ver ml/requirements.txt Versões exatas importam para reprodutibilidade — qualquer revisor do seu paper vai pedir.]
[Comandos em blocos de código, copiáveis. Ex.:
# Build server
cmake -B build -S .
cmake --build build
# Run server
./build/server/server --port 9000Faça uma seção dessas para cada bloco (server, client, ml). HOJE você não sabe os comandos exatos ainda — escreva placeholders que vamos preencher conforme construirmos.]
[Lista de fases do seu plano com checkboxes. Atualize conforme avança. Ex.:
- Fase 0: Estrutura do repositório
- Fase 1: Esqueleto funcional do servidor
- Fase 2: Detectores plugáveis ... Isso é mais útil do que parece — é o seu termômetro pessoal e sinaliza progresso para um orientador que olhe o repo.]
[Placeholder para a citação do paper quando ele sair. Por enquanto deixe "TBD".]
[Decisão a tomar — vou explicar abaixo.]
[Crédito ao 3W Dataset (Petrobras) conforme licença CC-BY 4.0]