Source-linked AI summary

autowerkstatt4null: An Off-Board-Diagnostics Ecosystem for Car-Workshops

Stephan Bökelman, Rene Glitza, Meihui Huang, Odin Holmes, Lukas Jakubczyk, Tabea Röthemeyer

arXiv:2608.26911v1eess.SP

TL;DR

Independent workshops face barriers to accessible oscilloscope-based diagnostics, including substantial expertise requirements. The project combines guided USB oscilloscope workflows, machine-learning-oriented signal analysis, and connected data services; its demonstrator proves technical feasibility and provides immediate sensor-data visualization, while broader fault classification remains dependent on training data.

  • Problem

    Oscilloscope diagnostics require electrical knowledge, probe-handling skills, and waveform-interpretation experience, creating a learning barrier for many general-purpose workshops.

  • Method

    The project combines GUI-guided USB oscilloscope measurements, automated data transmission and labeling, machine-learning signal interpretation, and REST/WebSocket-connected diagnostic services.

  • Results

    The demonstrator proves technical feasibility through oscilloscope-to-server transmission, local waveform visualization, data labeling, and attachment of VCDS scans for storage.

  • Takeaways & Limitations

    Immediate sensor-data reception and visualization gives technicians a live diagnostic dimension beyond static OBD fault codes and ECU status.

Abstract

from arXiv · show

This paper presents autowerkstatt4null, a three-year initiative to empower independent automotive workshops with AI-driven, federated diagnostics. The project was funded by the German Federal Ministry for Economic Affairs and Climate Action. The project enhanced the initial diagnostic workflow through newly developed technologies and architectural concepts, incorporating real user feedback. The resulting demonstrator showcases key outcomes: a modular measurement platform enabling flexible hardware integration, a secure data exchange hub for trusted collaboration, asynchronous online diagnostics that decouples analysis from workshop constraints, and a digital academy supporting technician upskilling. Together, these innovations demonstrate how independent workshops can access advanced diagnostic capabilities previously limited to manufacturer tools, strengthening competitiveness and sustainability in the sector. The project repository is available at: https://github.com/nabla-B/paper_aw4null-overview.

I. Introduction

Modern vehicles and their diagnostic requirements are increasingly complex, while workshops must balance tool capability, usability, robustness, training, and cost. Off-board tools complement legally required onboard diagnostics but add acquisition and coordination challenges.

  • Modern vehicles combine mechanical, electronic, and electromechanical subsystems that require diagnostics across diverse systems.
  • Design goals include interpretable error information, minimal controls and interaction, multilingual training, physical robustness, cost-effectiveness, and fewer repair errors.
  • OBD capabilities are legally integrated into every vehicle for certain faults, whereas off-board diagnostic systems are acquired and operated by workshops.
  • Workshop cost-benefit considerations differ for off-board tools because mechanics are paid for maintenance and repair rather than necessarily for diagnostics.
  • OBD tools connect through standardized vehicle interfaces to read fault codes, perform system tests, and monitor sensor data, but can be expensive and require frequent protocol updates.

B. Future Challenges in ICEV and BEV

Vehicle diversification and the transition between ICEVs and BEVs increase diagnostic complexity, although both vehicle types involve electrical signals alongside mechanical parts. Oscilloscopes provide detailed signal visibility but remain difficult for many general-purpose workshops to use.

  • Different vehicle models, manufacturers, and subsystem configurations require varied diagnostic tools, protocols, and specialist knowledge.
  • ICEVs and BEVs present different diagnostic challenges while both containing electrical signals and purely mechanical parts.
  • Oscilloscopes reveal real-time electrical behaviors such as voltage dropouts, transient glitches, and signal distortion that static diagnostic codes cannot reveal.
  • Dynamic voltage analysis can identify engine faults undetectable by current onboard and off-board systems, using a potentially brand-independent and cost-efficient tool.
  • Effective oscilloscope use requires electrical knowledge, correct probe handling, and waveform-interpretation experience, limiting practical deployment in many general-purpose workshops.
  • Microcontrollers, graphical interfaces, and machine-learning analysis are proposed to reduce oscilloscope learning curves and improve accessibility.

1) Machine Learning for Signal Clustering:

Machine learning is presented as a way to map electrical time-series signals to fault categories and reduce manual waveform interpretation. The approach depends on suitable training data and is paired with oscilloscope technology.

  • Poor and properly functioning compression-cycle waveforms illustrate signal variations that models could be trained to classify.
  • Machine-learning models could classify fault categories from multidimensional, time-dependent electrical signals.
  • Automated signal interpretation is intended to reduce manual waveform analysis, lower required expertise, and decrease technician training needs while improving reproducibility.
  • Traditional oscilloscopes integrate accurate analog front ends and delicate processing units in forms not designed for rough workshop environments.

2) Modern Microcontroller Technology:

Microcontrollers are proposed as a lower-cost basis for automotive oscilloscopes because recent devices can sample many relevant vehicle signals. Connecting these measurement devices to machine-learning systems remains a central challenge.

  • Ruggedized electronic oscilloscopes can cost multiple thousands of euros, motivating alternative hardware approaches.
  • Recent microcontrollers offer low- to mid-MHz sampling suitable for signals such as ignition pulses and 500 kHz CAN bus communication.
  • The RP2040 provides a 12-bit ADC at up to 500 kS/s, while STM32F7 ADC clocks can reach 50 MHz for multi-MS/s operation.
  • Sampling at 1–5 MHz with sufficient memory for millisecond-to-second captures could provide meaningful diagnostic data for many workshop use cases.
  • Connecting machine-learning capabilities with microcontroller-based oscilloscopes is identified as the next technical challenge.

3) REST API and Web Sockets:

The proposed ecosystem combines local oscilloscope acquisition with web-based communication and centralized analysis to support technician-facing diagnostics. It addresses workflow, privacy, model distribution, and the limitations of conventional fault-code interpretation.

  • Architecture: Oscilloscopes capture electrical time series locally, while centralized services analyze measurements and return diagnostic responses.The architecture connects an oscilloscope to a diagnostics computer via USB before sending structured measurements to an analysis service.
  • Communication: REST-based asynchronous communication decouples data submission from immediate shared timing between workshop clients and analysis services.HTTP requests carry recorded waveforms and metadata such as mileage, sensor type, and vehicle make-and-model.
  • Communication: WebSockets provide synchronous communication for collecting individual oscilloscope samples into structured blocks with a shared time reference.This complements REST communication in the proposed middleware architecture.
  • Implementation: The middleware between USB oscilloscopes and internet-connected analysis services can be implemented with off-the-shelf web frameworks.The paper presents this as a conclusion from the communication and integration design.
  • Technician workflow: The system targets clearer technician guidance by connecting oscilloscope measurements, centralized AI services, and a user interface.The proposed approach includes instructions for attaching channels, automatic recording, and service-based analysis.
  • Open design questions: The design must support privacy-preserving training data, model sharing, and efficient distribution across varied vehicle types.The stated research questions also include low-cost rugged hardware and GUI support for technician workflows.

B. Proof-of-Concepts

The proof-of-concept work evaluates the feasibility of autowerkstatt4null through practical experiments. Its scope is organized around hardware, GUI usability, data transport, and service provisioning, while considering data and model sharing requirements.

  • Experimental scope: The project uses proof-of-concept experiments to assess general feasibility and uncover more detailed questions.The experiments are framed as a practical investigation of the proposed system.
  • Experimental scope: The proposed system is compartmentalized into hardware, GUI usability, and data transport and service provisioning.These fields define the main experimental areas.
  • Deployment requirements: Productive deployment requires sharing workshop data with relevant metadata while preserving privacy within larger training datasets.The text also identifies model distribution as part of the deployment problem.

1) Data Transport and Provisioning:

The diagnostic architecture maps workshop measurements to analysis objects while separating measurement acquisition from model execution. It also emphasizes extensible, usable software for workshop deployment.

  • Data and models: An analytical model maps a d-dimensional time series measurement to an analysis object, optionally incorporating metadata.Analysis objects may include classes, scores, or structured diagnostic reports.
  • Data and models: Because workshops generally do not generate models, measurements and analysis services are stored on different machines.The measurement must either be sent to the service machine or the service transferred to the workshop machine.
  • Workshop deployment: The software targets time-pressured technicians with an efficient interface and an open-source design that supports extension and forking without refactoring.Ease of use and practical testing in real workshops are identified as deployment requirements.

2) GUI Usability:

The demonstrator combines established automotive diagnostic hardware with a prototype measurement and visualization workflow. Its design targets integration, practical workshop use, and eventual machine-learning-based fault classification.

  • Hardware and integration: The project evaluates automotive oscilloscopes against sturdiness, cost-benefit ratio, and integration possibilities in a saturated market.The evaluation addresses whether existing solutions meet independent workshop requirements.
  • Hardware and integration: The demonstrator integrates electrical signal analysis with machine-learning and AI capabilities as a foundation for next-generation off-board diagnostics.The project frames this as a proof of concept connecting three technological layers.
  • Demonstrator components: The measurement setup connects USB oscilloscopes to vehicle sensors through Banana-to-BNC adapters, with OmnAIView and VCDS supporting visualization and standard diagnostics.The demonstrator includes software, a VCDS tool, laboratory connectors, and instructional materials.
  • Measurement pipeline: Multiple USB oscilloscopes must share a root hub so their signals can be synchronized through common USB start-of-frame timing.A receiver service collects and aligns the signals based on the USB clock.
  • Measurement pipeline: Collected measurements move by HTTP from the local hub to a gateway server and then to central training-data storage for future analysis.The architecture separates local acquisition from centralized data storage.
  • Machine-learning scope: Real-time model-based fault feedback is not yet operational because the repository lacks sufficient training data.The intended future use is fault classification from stored signal patterns.

A. Technical Readiness

Initial testing demonstrates a functioning measurement-to-storage workflow with immediate visualization and labeling. The system streams multiple scope channels, but integration and training-data limitations remain.

  • Technical readiness: The demonstrator proves the technical feasibility of a physical data-driven diagnostic workflow for automotive workshops.Testing covered signal transmission, local visualization, labeling, and attachment of VCDS scans before storage.
  • Technical readiness: Multiple oscilloscope channels streamed and rendered without major delay during parallel operation.This result concerns throughput during initial testing.
  • Technician value: Immediate sensor-data reception and visualization provided technicians with a practical dimension beyond static VCDS status and diagnostic trouble codes.Hands-on use identified live waveform monitoring as the clearest value for technicians.
  • Remaining limitations: The current system requires manual coordination because its individually developed components have not yet been unified into one software platform.The stated next step is a cohesive architecture that abstracts complexity for end users.
  • Field deployment: The demonstrator was deployed in 51 workshop environments over six months, with hardware feedback rated good for usability and durability.Usage frequency varied across workshops, and some reported that the device dimensions were too compact.
  • Remaining limitations: Insufficient training-data volume restricts the machine-learning module’s ability to generate actionable feedback.This limits the transition from stored measurements to operational fault analysis.

C. Gathered Data

The project currently stores gathered data in a CephFS network at THGA in Bochum, but no extracted dataset is publicly available. It outlines plans to publicize fault-code, usage, and training-data access statistics while pursuing product development and open-source infrastructure.

  • Gathered data is currently stored in a CephFS storage network located at THGA in Bochum.
  • No publicly available dataset has yet been extracted, although statistics on fault codes, usage, and training-data access are intended for publication.
  • The project plans a future monetization roadmap and an early public-market derivative of its hardware to support sustainable product development.
  • Use cases, application software, and storage-and-analysis infrastructure are organized as independent development branches with intended public and open-source contributions.
  • The project received financial support from Auto-Intern GmbH, LMIS AG, Dekra, Verglöst, nabla-B UG, DMT-LB, and THGA.
Loading 2608.26911v1…