Skip to main content
Back to List

Two Student Teams, Two Papers: Inside PopcornSAR–HCMUT Phase 2

2026-09-02PopcornSAR
Adaptive AUTOSARPAIOUniversity CollaborationEdge AICase Study

How graduate researchers at Ho Chi Minh City University of Technology built production-grade edge AI perception and diagnostics on Adaptive AUTOSAR — with a Claude-powered assistant embedded in the toolchain.

From Phase 1 to Phase 2

When PopcornSAR and Ho Chi Minh City University of Technology (HCMUT) began working together in September 2025, the goal was straightforward: give graduate students at the Advanced Computing Lab (ACLAB) access to the same Adaptive AUTOSAR toolchain that ships in production vehicle programmes, and see what they could build with it.

Phase 1 established the foundation. Phase 2, which ran from January to April 2026, is where the work matured — and where the results arrived.

Two student teams took on two very different problems in Software-Defined Vehicle engineering. Both shipped working systems on low-cost embedded hardware. Both produced papers accepted to IEEE SAS 2026. Both defended successfully.

A workshop session at HCMUT, with the ACLAB and PopcornSAR logos on screen.
Presenting the collaboration at the International Workshop on Sensor Informatics, held jointly by Kyoto Institute of Technology and HCMUT, 25–27 February 2026.

What PopcornSAR provided

Students received demo licenses for the full PopcornSAR toolchain, along with pre-configured Docker images from a private registry, the PARA SDK runtime libraries, complete AUTOSAR Adaptive documentation, and direct technical support from PopcornSAR engineers throughout the semester.

The centrepiece was PAIO — PopcornSAR's Claude-based AUTOSAR authoring tool.

PAIO is not a conventional modeling tool with a chatbot bolted on. AUTOSAR domain knowledge is built into the product as a structured ontology, and an LLM assistant is fine-tuned against that ontology so it reasons about ARXML, service interfaces, and machine topology as AUTOSAR constructs rather than as generic text. The assistant runs on a selectable LLM runtime — Claude Code, Codex, or Gemini CLI.

Both HCMUT teams ran the assistant on Claude Code, and used it across several stages of their work: system design, interface design, and verification. In practice that meant an assistant with a deep working understanding of the AUTOSAR standard sitting alongside students who were encountering that standard for the first time — during the modeling of machines and service interfaces, and again when checking that the resulting configuration was sound.

For teams working to a semester deadline, this mattered. Adaptive AUTOSAR has a steep initial learning curve, and the gap between understanding the specification and producing a valid, buildable system model is where student projects usually stall.

Team 1: Real-time traffic light detection at the sensor edge

The first team set out to run traffic light detection directly on an automotive edge node — no GPU, no NPU, no dedicated accelerator. The constraint was deliberate: sensor-class devices in real vehicles are cost, power, and thermally limited.

Their approach replaced the YOLO11 backbone with MobileNetV4-ConvSmall, then deployed the quantized model through a fully C++ Google LiteRT runtime. The perception pipeline was implemented as two Adaptive Applications communicating over SOME/IP — a ProviderSensor performing acquisition and inference, and a ClientSensor consuming the enriched detection results. Service interfaces and provider–consumer relationships were modeled in the PopcornSAR authoring tool, which generated the C++ service skeletons and proxies; the generated artifacts were then integrated with the PARA SDK runtime.

The results on a Raspberry Pi 5:

MetricBaseline YOLO11nYOLO11n–MobileNetV4
CPU inference>400 ms30–40 ms
Throughput2–3 FPS25–33 FPS
Speedup~10–13×

End-to-end latency, including pre-processing, inference, post-processing, and SOME/IP message preparation, averaged around 41 ms — real-time operation at 24–25 FPS. The lightweight model retained over 85% of baseline detection accuracy.

To the team's knowledge, this is one of the first end-to-end implementations combining a YOLO11–MobileNetV4 detector with a fully C++ LiteRT runtime for real-time inference on CPU-based sensor devices.

Team 2: Predictive engine fault diagnosis

The second team tackled predictive maintenance — detecting engine anomalies from time-series sensor signals before failure occurs.

Rather than classifying raw 1D signals, they encoded them as 2D images and applied computer vision techniques. Their model, TridentNet, is a triple-stream residual framework that processes three representations of the same signal simultaneously: Short-Time Fourier Transform, Continuous Wavelet Transform, and Recurrence Plot. This lets the network capture frequency, time-frequency, and structural features in parallel.

Benchmarked on the FordA and FordB automotive datasets, TridentNet matched the accuracy of industry-standard models such as ResNet while substantially reducing computational complexity and memory footprint — enough to run on a Raspberry Pi 4.

The system was deployed as a service-oriented machine on the Adaptive AUTOSAR platform, with C++ inference through ONNX Runtime and high-bandwidth data transport implemented over DDS using the PARA SDK.

Outcomes

Phase 2 closed with results that go beyond a passing grade.

  • Two papers accepted to IEEE SAS 2026 — one from each team
  • Both teams defended successfully, with strong marks from their committees
  • Joint workshop presentation with Kyoto Institute of Technology
  • Working demonstrations on Raspberry Pi 4 and 5, including CARLA simulation integration

Both papers credit PopcornSAR in their acknowledgments for the toolchain, licenses, and engineering mentorship that made the implementations possible.

Students and faculty together in the lecture room after the public defense.
Right after the public defense of the capstone projects — Faculty of Computer Science and Engineering, HCMUT.

What this says about the toolchain

There is a useful signal in a result like this. These were students, not automotive software engineers, working to a semester deadline on an unfamiliar standard. They produced AUTOSAR-compliant service-oriented applications, running in real time on hardware that costs less than a tank of fuel, and wrote them up to a standard that cleared IEEE peer review.

That outcome depended on removing the friction between understanding the AUTOSAR specification and producing a valid system model. An assistant that genuinely understands the standard — not one that pattern-matches on it — is what closes that gap, and it is the reason PAIO is built the way it is.

To the students of ACLAB and to Dr. Nhan: congratulations, and thank you for a genuinely impressive year of work.

Frequently Asked Questions

What is the PopcornSAR–HCMUT collaboration?+
A partnership between PopcornSAR and Ho Chi Minh City University of Technology that began in September 2025. Graduate students at the Advanced Computing Lab (ACLAB) work with the same Adaptive AUTOSAR toolchain used in production vehicle programmes. Phase 2 ran from January to April 2026.
What is PAIO?+
PopcornSAR's Claude-based AUTOSAR authoring tool. AUTOSAR domain knowledge is built into the product as a structured ontology, and the LLM assistant is fine-tuned against it so it reasons about ARXML, service interfaces, and machine topology as AUTOSAR constructs rather than as generic text. The assistant runs on a selectable runtime — Claude Code, Codex, or Gemini CLI.
What hardware did the teams use?+
Raspberry Pi 5 for real-time traffic light detection and Raspberry Pi 4 for predictive engine fault diagnosis. No GPU, NPU, or dedicated accelerator — the constraint was deliberate, since sensor-class devices in real vehicles are cost, power, and thermally limited.