adt-kmr/detecting-ev-charger-cyberattacks-using-only-power-consumption-telemetry

This repository is a notebook-centric research workspace for detecting EV charger cyberattacks from power-consumption telemetry. The architecture is not a deployed application; it is an experiment-and-analysis environment built around Jupyter notebooks.

The repository has only four top-level artifacts:

• README.md as the project label,

• method1.ipynb and method2.ipynb as the two main experiment tracks,

• errored.ipynb as a failed or debugging notebook that likely captures an interrupted or broken workflow.

The primary boundary in the repo is between the notebooks and their external data/runtime dependencies. All substantive logic appears to live inside notebooks rather than in reusable packages, services, or scripts. That means the “system” is organized by experiment, not by application layer.

At a high level, the data flow is: power-consumption telemetry is loaded into a notebook, cleaned or transformed, used to train or evaluate detection logic, and then results are inspected in notebook outputs. The architecture likely centers on time-series analysis and classification/anomaly-detection style processing, since the goal is attack detection from telemetry only.

method1.ipynb and method2.ipynb are the two main branches of the analytical pipeline. They likely represent alternate detection strategies, feature sets, or modeling approaches. In diagram terms, these should be shown as parallel experimental paths rather than sequential production components.

errored.ipynb is important as a troubleshooting branch. It suggests an iterative workflow where exploratory code was executed interactively, and at least one notebook captured a failed attempt or a crash state. This indicates manual experimentation and ad hoc debugging are part of the repo’s workflow.

There is no evidence of a backend service, API, UI, database, or message broker in the repository tree. So the correct architecture diagram should not include deployment tiers or networked components unless they exist outside this repo. The execution environment is simply Jupyter + Python runtime.

Because the repo is notebook-based, dependencies and state are likely implicit: imported libraries, local datasets, and notebook cell order matter. This creates a loose coupling between experiments and a tight coupling to the notebook execution context. Reproducibility likely depends on rerunning cells in order with the same data and environment.

The external input of architectural significance is the telemetry dataset itself, probably recorded from EV charging equipment during normal and attack conditions. The primary output is not a service response but analytical results such as detection scores, plots, metrics, or model comparisons captured in notebook output cells.

For an architecture diagram, the cleanest representation is:

• external telemetry data source,

• notebook-based preprocessing/analysis,

• two parallel detection-method notebooks,

• evaluation/output artifacts,

• and a separate failed-experiment/debug notebook.

Overall, this is a research prototype repo with minimal structural separation. The meaningful architecture lies in the experimental workflow and the comparison of alternative detection methods, not in software components or infrastructure.