12-Week Educational R&D Mini ProjectE&C / ECE / EEE / EE Students

AegisCAN

Intelligent CAN Cybersecurity · EV · BMS · BESS · Aerospace · UAV

Build a simulated Battery/BMS system, communicate its data over CAN, validate normal and faulty behaviour, and develop AegisCAN to detect abnormal CAN/BMS activity.

12Weeks

4–6 hrsPer Week

3Milestone Demos

1Working Prototype

1Engineering Portfolio

Start the 12-Week Journey View Final Demo

AegisCAN is an educational and research prototype. Not a production BMS, commercial IDS, certified automotive/aerospace cybersecurity product, or safety-certified BESS controller. All fault-injection and cybersecurity exercises run only in controlled simulation/lab environments on systems the student is authorized to test.

Project Initiated & Led by Tanuja Jadhav — Lead Researcher · EV.ENGINEER™

Your 12-Week Mission

BatteryBMSBESSCANValidationFault InjectionCybersecurityAegisCAN

Learn the system, build the simulation, test failures, detect anomalies and demonstrate your engineering evidence.

Understand → Learn → Build → Demonstrate

Three Project Phases

The 12 weeks group into three phases, each ending with a clear, demonstrable outcome.

Phase 1

Foundation

Weeks 1–4

BatteryBMSBESSCAN

OutcomeI can generate battery/BMS data and communicate it over CAN.

Phase 2

Validation & Security

Weeks 5–8

CAN LoggingTestingFault InjectionThreat Analysis

OutcomeI can test the system, inject controlled faults and explain abnormal behaviour.

Phase 3

AegisCAN

Weeks 9–12

DetectionAnalyticsIntegrationQADemo

OutcomeI can detect CAN/BMS anomalies and demonstrate an integrated AegisCAN prototype.

Section · Every 4 Weeks

Engineering Milestone Reviews

Students demonstrate working engineering progress every four weeks — not just at the very end.

Milestone 1 · Week 4

Battery → BMS → CAN

Must Explain

What is Battery / BMS / BESS?
What are SOC and SOH?
Why CAN? What is a CAN ID and DLC?
How are BMS signals mapped into CAN?

Submit

Project Charter
Battery/BMS/BESS study
Architecture v1
CAN message map
Source code + sample CAN log
Week-4 demo evidence

Milestone 2 · Week 8

CAN Validation → Fault Injection → Cybersecurity

Must Explain

What was expected vs what actually happened?
How was the fault detected, with what evidence?
What is the likely root cause?
How would another engineer reproduce it?

Submit

Test Plan + Requirements Traceability Matrix
Functional test cases
CAN logs + fault catalogue
RCA worksheet
Threat Model + security dataset
Week-8 demo evidence

Milestone 3 · Week 12

AegisCAN Final Engineering Demo

Must Explain

How does the full pipeline fit together end-to-end?
How did AegisCAN detect each anomaly class?
What engineering evidence proves it?
What was your individual contribution?

Submit

Final Report + Final Test Report
Security Test Report + Traceability Matrix
Source code + demo video
Presentation + individual contribution
Career Skill Matrix

Section · Final Gate

What Will You Demonstrate at the End?

The target educational prototype — a conceptual dashboard, not a production application.

AegisCAN — Battery & CAN Security MonitorBUS: NORMAL

Battery / BMS

Pack Voltage352.4 V

Current-18.2 A

SOC74.5 %

SOH96.1 %

Max Temperature32.4 °C

CAN Network

Active CAN IDs6

Messages/sec60

Bus StateNORMAL

0x1010x1020x2010x2020x3010x7EE

Security / Validation Events

10:32:04NORMALOK

10:32:15UNKNOWN_CAN_IDMEDIUM

10:32:22MESSAGE_FREQUENCY_ANOMALYHIGH

10:32:40TEMPERATURE_ANOMALYHIGH

Selected Event

TypeMESSAGE_FREQUENCY_ANOMALY

SeverityHIGH

Expected Interval100 ms

Observed Interval5 ms

EvidenceMessage frequency exceeded configured baseline.

Final Demo Scenario

Eight scenarios, run in order, prove the whole pipeline works.

Start Healthy System

Start the Battery/BMS simulation and show voltage, current, temperature, SOC and SOH updating live.

STATUS: NORMAL

Show CAN Communication

Display CAN IDs, payload, timestamp, decoded BMS signals and messages/sec on the bus.

Sensor / BMS Anomaly

Inject an unrealistic temperature or abnormal SOC transition.

SIGNAL ANOMALY

Unknown CAN ID

Introduce an unexpected CAN ID onto the bus.

UNKNOWN CAN ID

Message Frequency Anomaly

Change the expected 100 ms message timing to an abnormal rate.

MESSAGE FREQUENCY ANOMALY

Missing / Stale Message

Stop one expected message and let AegisCAN notice it has gone silent.

MISSING / STALE MESSAGE

Engineering Evidence

Select one event and show its timestamp, CAN ID, expected vs observed behaviour, detection rule, severity and evidence.

Root Cause Analysis

Explain what happened, why it was abnormal, how it was detected, what evidence proves it, and what an engineer would investigate next.

Section · Execution Plan

12-Week Execution Plan

Discussion started 21 September 2026 · Target completion 21 December 2026 · ~4–6 hrs/week. Every week follows the same shape — Learn · Build · Demonstrate · Submit.

Week 1Project Orientation & Industry ContextPhase 1

Learn

What is EV / BESS / Battery / BMS / CAN?
What a BMS/Test/Validation engineer does
Why cybersecurity matters

Build

Git repository + project structure
Python environment
Documentation structure

Demonstrate

A working repo with README and an initial architecture diagram

Submit

Project Charter
Problem Statement + Learning Goals
Initial Architecture
Responsibility matrix

Week 2Battery FundamentalsPhase 1

Learn

Cell, module, pack; series/parallel
Voltage, current, capacity, energy
SOC, SOH, SOP introduction
Charging/discharging & battery safety

Build

Simple battery data simulator
(Optional) explore a PyBaMM example model

Demonstrate

Voltage/current/SOC/temperature changing over time

Submit

Battery Fundamentals Note
Parameter dictionary
Simulator source + sample dataset/plots

Week 3BMS + BESS FundamentalsPhase 1

Learn

BMS: sensing, protection, balancing, contactors, fault management
BESS: rack, BMS, PCS, EMS, thermal management, monitoring

Build

Simplified BMS model extending the simulator
(Optional) map a PyBaMM output to a BMS signal

Demonstrate

Normal BMS operation plus one simulated battery fault

Submit

BMS block diagram
BESS architecture diagram
Fault state definitions

Week 4CAN FundamentalsPhase 1

Learn

CAN bus, controller, transceiver, arbitration
CAN ID, DLC, payload, frame, message frequency
CAN FD & DBC concept introduction

Build

Encode selected BMS parameters as CAN messages

Demonstrate

BMS values becoming CAN frames — Milestone 1

Submit

CAN learning note + CAN message map
CAN ID / signal scaling definition
CAN generator source

Week 5CAN Monitoring & Data AcquisitionPhase 2

Learn

CAN logging, timestamps, message rates
Decoding and engineering data acquisition

Build

CAN logger and decoder

Demonstrate

Raw CAN → decoded BMS values

Submit

CAN logger + decoder source
CSV/JSON logs
Message frequency analysis

Week 6Validation EngineeringPhase 2

Learn

Requirements, verification, validation
Test plans, expected vs actual, traceability
Boundary and negative testing

Build

Automated tests for the simulated BMS/CAN system

Demonstrate

Test suite running with recorded evidence

Submit

Test Plan
Requirements Traceability Matrix
≥10 functional test cases + results

Week 7Fault Injection & Root Cause AnalysisPhase 2

Learn

Fault injection, diagnostics, debugging
Root-cause analysis, FMEA concept

Build

Controlled faults: voltage, temperature, invalid SOC, missing message, abnormal frequency

Demonstrate

Inject fault → observe → diagnose → explain root cause

Submit

Fault Catalogue
Fault injection module
RCA worksheet + evidence logs

Week 8CAN Cybersecurity FundamentalsPhase 2

Learn

Threat, vulnerability, risk, attack surface
Spoofing, replay, flooding, unauthorized message

Build

Controlled abnormal CAN scenarios (simulation-only)

Demonstrate

Normal CAN vs anomalous CAN — Milestone 2

Submit

Threat Model + attack surface diagram
Simulated security dataset
Security requirements

Week 9AegisCAN Detection EnginePhase 3

Learn

Baselines, thresholds, rules
Timing anomaly, payload anomaly

Build

Detection for unknown ID, rate anomaly, sensor range, sudden change, missing/stale message

Demonstrate

Inject anomaly → detect → generate alert

Submit

Detection Engine + rules
Alert schema
Security test results

Week 10Data Analytics + Optional AI/MLPhase 3

Learn

Feature engineering, baseline behaviour
False positive/negative, precision/recall concept

Build

Mandatory: statistical analysis. Optional: a simple ML anomaly-detection experiment

Demonstrate

Explain why a message was classified normal vs anomalous

Submit

Feature list + baseline analysis
Detection comparison
Short ML experiment (if attempted)

Week 11Integration, Dashboard & QAPhase 3

Learn

System integration practices
Regression testing, defect triage

Build

Integrate Battery→BMS→CAN→Logger→Fault Injection→AegisCAN→Dashboard

Demonstrate

End-to-end demonstration

Submit

Integrated prototype + dashboard
Regression tests + bug list
QA report

Week 12Industry Readiness & Final Engineering ReviewPhase 3

Learn

Presenting engineering work
Career framing of the project

Build

Finish requirements, architecture, testing, traceability and evidence

Demonstrate

Full pipeline demo — Milestone 3 / Final Gate

Submit

Final Report + Final/Security Test Report
Demo video + presentation
Individual Contribution + Career Skill Matrix

Why This Project?

Modern EVs and energy-storage systems run on electronics, sensors, embedded controllers, BMS software and communication networks. AegisCAN connects battery behaviour, BMS/BESS architecture, CAN communication, validation, fault injection and cybersecurity into one manageable project.

Business Goal

Develop engineering talent capable of understanding and validating intelligent battery and energy-storage systems — foundational skills relevant to EVs, BMS, BESS, automotive electronics, embedded systems, CAN networks, system validation, cybersecurity and UAV/aerospace systems. The emphasis is employability through engineering fundamentals and demonstrable evidence.

Problem Statement

Battery parameters (voltage, current, temperature, SOC, SOH, protection status, alarms) travel between controllers over CAN. Communication faults, incorrect messages or unauthorized traffic can affect monitoring and diagnostics. Students need an environment where they can understand:

How battery systems and BMS work

How BESS integrates a pack with supporting subsystems

How CAN carries system information

How engineers monitor CAN traffic

How faults can be injected safely

How abnormal behaviour is identified, tested and traced back to a root cause

Who Is This For?

Primary

5th-Semester E&C / ECE / EEE / EE Student

Starts with basic electronics, circuits, microcontrollers, programming and digital electronics. May not yet know batteries, BMS, BESS, CAN, DBC or embedded cybersecurity.

Needs

A structured, beginner-friendly weekly path
Simulation-first tools — no HV lab required
Evidence to show mentors and interviewers

Secondary

Faculty / Project Mentor

Guides and evaluates progress across the 12 weeks alongside the student's regular academic subjects.

Needs

Weekly progress visibility
Engineering evidence and test results
A reproducible final demonstration

Reviewer

Industry Reviewer

Assesses the finished project the way a hiring engineer would — for fundamentals, not polish.

Needs

What the student personally built and contributed
Whether fundamentals are understood
Whether results are reproducible

Technical Reference · BESS Fundamentals

Understanding BESS

BESS = Battery Energy Storage System. Students learn the data and communication layer through simulation — the project does not require building a real BESS.

Battery CellsModulesPacks / RacksBMSSensorsContactors / ProtectionDC BusPower Conversion System / InverterEnergy Management SystemThermal ManagementCommunicationMonitoring / SCADA

Term	What it means
Battery	The electrochemical energy-storage device — cells, modules and packs.
BMS	Electronics and software that sense, protect, balance and report on one battery pack.
BESS	The full system around one or more packs — BMS hierarchy, PCS, EMS, thermal management, protection and monitoring/SCADA.

Technical Reference

Epic & User Stories

Epic

“As an engineering student, I want to build and validate a simulated battery/BMS CAN network and develop an AegisCAN monitoring system so that I can understand battery systems, BMS, BESS, CAN communication, testing and cybersecurity using an industry-style engineering workflow.”

US-01

As a student, I want to simulate battery parameters so that I understand how battery operating data changes.

US-02

As a student, I want to monitor simulated battery signals so that I understand BMS functionality.

US-03

As a student, I want to encode BMS data into CAN messages so that I understand vehicle/network communication.

US-04

As a validation engineer, I want to record CAN messages so that system behaviour can be analysed.

US-05

As a validation engineer, I want to inject controlled faults so that I can verify expected system responses.

US-06

As a security engineer, I want to identify unusual CAN messages so that suspicious communication can be investigated.

US-07

As a test engineer, I want evidence around detected faults so that I can determine why the failure occurred.

US-08

As an engineering team, we want reproducible test evidence so that another engineer can verify our results.

Technical Reference

Functional & Non-Functional Requirements

Functional Requirements

ID	Requirement
`FR-01`	Simulate battery/BMS data.
`FR-02`	Generate CAN-like frames.
`FR-03`	Support timestamp.
`FR-04`	Support CAN ID.
`FR-05`	Support DLC.
`FR-06`	Support payload.
`FR-07`	Decode selected BMS signals.
`FR-08`	Display voltage.
`FR-09`	Display current.
`FR-10`	Display temperature.
`FR-11`	Display SOC.
`FR-12`	Display SOH.
`FR-13`	Log messages.
`FR-14`	Calculate message frequency.
`FR-15`	Identify unknown CAN IDs.
`FR-16`	Identify abnormal message frequency.
`FR-17`	Identify configurable out-of-range BMS values.
`FR-18`	Provide controlled replay simulation.
`FR-19`	Provide controlled spoofing simulation.
`FR-20`	Provide controlled flooding simulation.
`FR-21`	Generate alerts.
`FR-22`	Assign anomaly category.
`FR-23`	Provide severity.
`FR-24`	Retain evidence.
`FR-25`	Export or preserve test results.

Non-Functional Requirements

Beginner-friendly

Modular architecture

Reproducible simulation

Deterministic test scenarios where practical

Readable, documented, maintainable code

Clear error handling

No dependency on high-voltage equipment

Safe lab operation

Reasonable performance for student laptops

Traceable requirements and tests

UI/UX Requirements

Desktop, tablet and mobile are all first-class — verified at 360/390/430/768/1024/1280/1440/1920px

No horizontal page scroll, clipped headings, overflowing tables or overlapping buttons

The weekly plan and interview prep use native, keyboard-accessible <details> accordions

Wide tables collapse into per-row cards on narrow screens instead of forcing sideways scrolling

A sticky section nav lets a student jump the long page without losing their place

Acceptance Criteria

A student can run the battery/BMS simulator and see voltage, current, temperature, SOC and SOH change over time.

Simulated BMS signals are encoded into CAN-like frames carrying timestamp, CAN ID, DLC and payload.

The CAN logger records every frame to a log a decoder can replay.

Injecting an unknown CAN ID, an abnormal rate, or an out-of-range value produces an alert with category and severity.

Every functional requirement has at least one passing test case with recorded evidence.

The final dashboard shows pack voltage, current, SOC, SOH, temperature, CAN IDs, messages/sec, faults and anomalies together.

Technical Reference · Architecture Notes

System Architecture

Simulation-first pipeline — no physical CAN hardware required

Battery / BESS SimulatorBMS SimulatorCAN Message GeneratorVirtual CAN BusCAN LoggerAegisCAN MonitorFeature Extraction

Detection Layer

Rule Detection

Statistical Analysis

Optional ML

Threat / Fault ClassifierDashboardEngineering Evidence

Technical Reference

Sample Input & Output JSON

Sample Inputcan_frame.json

{
  "timestamp": "2026-11-16T10:15:30.250Z",
  "can_id": "0x101",
  "dlc": 8,
  "source": "BMS",
  "signals": {
    "pack_voltage_v": 352.4,
    "pack_current_a": -18.2,
    "soc_percent": 74.5,
    "soh_percent": 96.1,
    "max_cell_temp_c": 32.4
  }
}

Sample Outputalert.json

{
  "status": "ANOMALY_DETECTED",
  "timestamp": "2026-11-16T10:15:30.250Z",
  "can_id": "0x101",
  "category": "MESSAGE_FREQUENCY_ANOMALY",
  "severity": "HIGH",
  "expected_interval_ms": 100,
  "observed_interval_ms": 5,
  "evidence": [
    "Message frequency exceeded configured baseline"
  ]
}

Testing & Security

Positive & Negative Use Cases

All anomalous scenarios run only as controlled educational simulations

Positive Use Cases

Normal battery operation
Normal CAN traffic
Expected SOC change over a discharge cycle
Expected temperature variation under load
Expected message interval (e.g. 100 ms)
Known CAN IDs matching the message map

Negative / Anomalous Use Cases

Unknown CAN ID
Excessive message frequency (flooding)
Replayed message sequence
Spoofed sensor value
Unrealistic temperature or SOC transition
Invalid DLC / malformed payload
Missing or stale message

Security Requirements

ID	Requirement
`SEC-01`	Testing only on authorized simulation/lab systems.
`SEC-02`	No functionality intended for attacking real vehicles or deployed BESS systems.
`SEC-03`	Validate external inputs.
`SEC-04`	Protect logs from accidental modification where practical.
`SEC-05`	Clearly identify simulated attack data.
`SEC-06`	Do not expose secrets in source control.
`SEC-07`	Use dependency/version management.
`SEC-08`	Log security-relevant events.
`SEC-09`	Separate detection logic from simulation/fault-injection logic.
`SEC-10`	Maintain reproducible test evidence.

Functional & Security Test Cases

On narrow screens, each row becomes its own card — no sideways scrolling required to read one test case.

Functional Test Cases

Test ID	Requirement	Input	Expected Result
`TC-F-01`	Battery/BMS sim	Run simulator for 60s	Voltage/current/temp/SOC/SOH all update each tick
`TC-F-02`	CAN encoding	Encode one BMS sample	Frame carries valid timestamp, CAN ID, DLC=8, payload
`TC-F-03`	CAN decoding	Decode a logged frame	Decoded signals match the encoded values
`TC-F-04`	Message frequency	Send 20 frames of 0x101 in 2s	Computed frequency ≈ 10 msg/s (±1)
`TC-F-05`	Unknown ID detection	Send frame with CAN ID 0x9FF	Flagged UNKNOWN_CAN_ID
`TC-F-06`	Flood detection	Flood 0x101 at 200 msg/s (baseline 10)	Flagged MESSAGE_FREQUENCY_ANOMALY
`TC-F-07`	Sensor range	pack_voltage_v = 900 (valid 250–420)	Flagged SENSOR_RANGE_ANOMALY
`TC-F-08`	Alert schema	Trigger any anomaly above	Alert generated with category + severity

Security Test Cases

Test ID	Requirement	Precondition	Input	Steps	Expected	Actual	Pass/Fail	Evidence
`TC-SEC-01`	FR-15 / SEC-05	Message map has known IDs	Frame with CAN ID 0x7EE	Inject frame → observe monitor	UNKNOWN_CAN_ID, severity MEDIUM	UNKNOWN_CAN_ID raised, MEDIUM	PASS	`log_unknown_id_001.json`
`TC-SEC-02`	FR-16, FR-20	Baseline interval 100 ms	Flood 0x101 at 5 ms for 10s	Start flood → observe alert	MESSAGE_FREQUENCY_ANOMALY, HIGH	Raised, HIGH	PASS	`log_flood_002.json`
`TC-SEC-03`	FR-18	10s of normal traffic captured	Replay same 10s capture immediately	Replay → compare sequence/timestamps	REPLAY_PATTERN raised	Raised on duplicate sequence	PASS	`log_replay_003.json`
`TC-SEC-04`	FR-17	Valid temp range 0–60°C	max_cell_temp_c = 145	Inject spoofed value → observe	SENSOR_RANGE_ANOMALY, HIGH	Raised, HIGH	PASS	`log_sensor_range_004.json`
`TC-SEC-05`	FR-17	Previous SOC = 74.5%	Next SOC = 12.0% within 250 ms	Inject jump → observe	UNEXPECTED_SOC_TRANSITION raised	Raised	PASS	`log_soc_jump_005.json`
`TC-SEC-06`	FR-06	Expected DLC=8 for 0x101	Frame with DLC=3, truncated payload	Inject malformed frame	MALFORMED_FRAME, decoder survives	Raised, handled gracefully	PASS	`log_malformed_006.json`
`TC-SEC-07`	FR-16	0x101 expected every 100 ms	Withhold 0x101 for 2s	Stop generator → wait timeout	MISSING/STALE_SIGNAL raised	STALE_SIGNAL raised	PASS	`log_missing_007.json`
`TC-SEC-08`	SEC-03	Config file present	Corrupted JSON config	Start AegisCAN with bad config	Fails safely with clear error	Validation error on startup	PASS	`log_config_008.json`

Shown results are illustrative of the expected evidence format — each team records its own actual results and evidence files.

Section · What You Submit

Document Submission — 8 Packages

Engineering evidence groups into eight submission packages, not 21 separate reports.

Project Definition

Project Charter
Business Goal + Problem Statement
Scope, team & responsibilities
Learning objectives

Engineering Study

Battery, BMS, BESS notes
CAN study
Cybersecurity fundamentals
References

System Design

Architecture + module design
Interfaces
CAN message map + signal definitions
Threat model

Requirements & Traceability

Functional + non-functional requirements
Security requirements
Acceptance criteria
Traceability matrix

Test & Validation Report

Test plan + functional/negative tests
Fault injection + security tests
Results & defects
Root cause analysis

Engineering Evidence

CAN logs, datasets, screenshots, plots
Sample JSON + configuration
Demo-1, Demo-2 & final-demo evidence

Source Code

Git repository + README
Setup instructions + dependencies
Configuration
Release/tag + contribution history

Final Project Package

Final report + presentation
Final demo video
Individual contribution + lessons learned
Career skill matrix + résumé summary

01 — Project Definition

02 — Engineering Study

03 — System Design

04 — Requirements & Traceability

05 — Test & Validation Report

06 — Engineering Evidence

07 — Source Code

08 — Final Project Package

Final Readiness Checklist

Battery simulator works and BMS values are generated

CAN frames are generated, decoded and logged

Normal traffic is recognized as normal

Unknown ID, abnormal frequency, sensor anomaly and missing message are all detected

Dashboard works end-to-end

Functional and security tests pass, each mapped to a requirement

Requirement traceability is complete

Source code is version controlled with a README another student can follow

Final demonstration is reproducible

Student can explain the system without reading slides

QA Review & Architect Approval

QA Status: Pending

QA Review

Requirements are testable
Tests map to requirements
Expected results are defined
Evidence exists
Regression testing performed
Security scenarios tested

Architect Status: Pending

Architect Approval

System architecture
Module boundaries
CAN message design
Detection architecture
Safety/cybersecurity assumptions
Extensibility

Career Preparation

How AegisCAN Helps Your Engineering Career

Foundational skills relevant to these career paths — completion does not guarantee employment.

Battery & Energy

BMS EngineerBMS Test EngineerBMS Validation EngineerBattery Systems EngineerBattery Test EngineerBESS EngineerBESS Validation Engineer

Embedded & Communication

Embedded Systems EngineerEmbedded Test EngineerCAN Communication EngineerECU Test Engineer

Validation

Verification & Validation EngineerSystem Integration EngineerAutomotive Test EngineerAutomotive Validation EngineerTest Automation EngineerData Acquisition / Validation Engineer

Cybersecurity

Automotive Cybersecurity EngineerEmbedded Cybersecurity Engineer

Aerospace / UAV

UAV Embedded Systems EngineerAvionics Systems / Test Engineer

Industry-Ready Skills

Battery Engineering

Cell/module/packVoltage · Current · TempSOCSOHSOPCell balancingBattery safety

BMS Engineering

BMS architectureSensorsProtection functionsFault statesDiagnostics

BESS

BESS architectureRacks/packsPCS conceptEMS conceptThermal managementCommissioning

Communication

CANCAN IDDLCArbitrationCAN FDDBC conceptSPI/UART/Modbus (awareness)

Validation Engineering

TraceabilityTest planningFunctional testingFault injectionBoundary/negative testingRegression testing

Data Analysis

CAN logs & timestampsMessage frequencySensor trendsSOC/SOH dataAnomaly analysis

Cybersecurity

Threat modellingAttack surfaceSpoofingReplayFloodingDefensive monitoring

Automation (Python)

CAN simulationLog processingTest automationReporting

Engineering Skills

DebuggingRoot-cause analysisRequirements writingGitTechnical reports

Job-Readiness Skill Matrix

Industry Skill	AegisCAN Experience
Battery fundamentals	Weeks 2–3
BMS	Weeks 3–12
BESS	Weeks 3–12
SOC / SOH / SOP	Weeks 2–3
CAN	Weeks 4–12
Data acquisition	Week 5 onward
Functional testing	Week 6 onward
Fault injection	Week 7 onward
Root cause analysis	Week 7 onward
Cybersecurity	Week 8 onward
Test automation	Weeks 6–12
Python	Throughout
Requirements & traceability	Weeks 1, 6 & 4
Git	Throughout
System integration	Week 11

Can You Explain This in an Interview?

Answer using your own AegisCAN evidence — logs, results, diagrams and code you personally wrote — not a memorized script.

What is a battery cell/module/pack?