Requisimus built STING, a Python CLI that reads CAN, LIN, FIBEX, PDF, and Excel signal databases and auto-generates production-ready ASPICE test cases in pytest and CAPL — cutting weeks of manual test scripting to a single command.
July 2026 · Requisimus · 8 min read
| 138 | SWE.5+6 | 5 | 4 |
| Test Cases Generated | ASPICE Coverage | Input Formats | Output Profiles |
The Challenge
Every automotive ECU project at SWE.5 and SWE.6 level requires hundreds of test cases — boundary checks, equivalence partitions, and timing validations — for every signal in the vehicle network. Signal definitions live in different formats across different project types: DBC and LDF files for CAN/LIN network databases, FIBEX for AUTOSAR network descriptions, PDF specifications from OEM signal catalogues, and Excel signal lists from system architects.
Manually transcribing signal ranges from any of these sources into test cases is error-prone, breaks silently when the source database changes, and applies the same three algorithmic patterns (Boundary Value Analysis, Equivalence Partitioning, Timeout) to every signal — work that should be automated, not hand-crafted.
Key Requirements
- Multi-format database reading — DBC (CAN), LDF (LIN), FIBEX, PDF specification sheets, Excel signal lists
- Systematic test strategies — apply BVA, EP, and Timeout to every signal automatically
- ASPICE-traceable test IDs — e.g. EngineSpeed__BVA_MIN aligned to SWE.5 / SWE.6
- pytest output for CI/CD pipeline integration (Jenkins, GitHub Actions)
- CAPL output for CANoe and CANalyzer bench testing
- AUTOSAR profiles for COM-layer and RTE-layer HIL tests via PCAN or XCP
STING — Signal Test Pipeline Architecture
Referring to the above architecture Diagram:
STING pipeline: Phase 1 inputs (DBC/LDF, solid boxes) are active; Phase 2 inputs (FIBEX/PDF/Excel, dashed boxes) are pluggable stubs ready for activation. All formats converge to a uniform BusSignal model, pass through three test strategies, and are written to four output formats — from a single CLI command.
Solution & Engineering Activities
01 — Signal Database Parsing — Five Input Formats
Designed a pluggable parser registry that dispatches each input file to the correct backend based on file extension. Phase 1 (active): the DBC parser wraps cantools for CAN signal databases; the LDF parser wraps ldfparser for LIN frames. Phase 2 (pluggable stubs): the FIBEX parser uses lxml for AUTOSAR network descriptions; the PDF parser uses pdfplumber for OEM signal specification sheets; the Excel parser uses openpyxl for signal list spreadsheets. All five parsers produce uniform BusSignal objects — the core currency of the pipeline — so no downstream code changes when a new parser is activated.
One key bug fixed: cantools’ NamedSignalValue explicitly sets __hash__ = None, making it unhashable as a dict key. Fixed by wrapping with str(v) before insertion.
02 — Signal Model Extraction (BusSignal)
Extracted a technology-neutral BusSignal dataclass from each parsed signal, normalising physical min/max, raw values, bit length, unit string, cycle time (period_ms), and the full enum dictionary. This decouples test strategies from any specific database format — activating Phase 2 parsers (FIBEX, PDF, Excel) requires zero changes to strategy or generator code. The signal model is the single contract between parsers and everything downstream.
03 — Test Strategy Application (BVA · EP · Timeout)
Three interchangeable test strategies as pluggable classes:
- Boundary Value Analysis — six cases per signal: min, max, min+1, max−1, below_min, above_max — covering both nominal and invalid ranges (ASPICE SWE.5).
- Equivalence Partitioning — nominal midpoint for numeric signals; one case per enum state for enumerated signals (e.g. ABSActive: INACTIVE, ACTIVE).
- Timeout Strategy — 3× period_ms stimulus for cyclic signals only, validating absence-of-frame handling at the ECU application layer.
04 — Multi-Level Test Generation (SWE.5 & SWE.6)
The SWE.5 Generator applies all three strategies to every signal, producing integration-level test cases with ASPICE-traceable IDs such as EngineSpeed__BVA_MIN and GearMode__EP_PARK. The SWE.6 Generator extends SWE.5 with an INIT_VALUE test per signal for qualification-level coverage. A single CLI invocation generates both levels in one pass.
| # 138 test cases from sample.dbc in one command python main.py –input sample_inputs/sample.dbc –level SWE.5 SWE.6 –format pytest # AUTOSAR COM layer with real PCAN hardware python main.py –input signals.dbc –level SWE.5 SWE.6 –profile autosar_pcan \ –pcan-channel PCAN_USBBUS1 –pcan-bitrate 500000 |
05 — Multi-Format Output Writers (pytest · CAPL · AUTOSAR Profiles)
A pluggable writer system generates four output formats from the same TestCase objects: pytest — grouped .py files per CAN frame with traceable docstrings, ready for Jenkins CI; CAPL — .can test modules for CANoe/CANalyzer benches; AUTOSAR PCAN — pytest with python-can bus stimulus targeting the AUTOSAR COM layer; AUTOSAR RTE CANalyzer — CAPL with XCPGetValue to read back RTE-layer signal values directly from the ECU under test.
Business Impact
138 Test Cases from One Command
A single DBC with 8 signals generates 65 SWE.5 and 73 SWE.6 test cases in under a second — replacing 1–2 days of manual scripting.
Traceability at Zero Cost
Every generated test carries a structured Test-ID, SWE level, and requirement tag, satisfying ASPICE traceability without a separate documentation step.
Portable to Any Toolchain
pytest for Jenkins CI, CAPL for CANoe benches, and AUTOSAR PCAN/XCP profiles for HIL — chosen at generation time with a single flag.
5 Input Formats, One Pipeline
DBC, LDF, FIBEX, PDF, and Excel all converge to the same BusSignal model. Activating Phase 2 parsers requires no changes to strategies, generators, or output writers.
Tech Stack
Python 3.11 • cantools • ldfparser • lxml (FIBEX) • pdfplumber (PDF) • openpyxl (Excel) • Jinja2 • pytest • CAPL • DBC (CAN) • LDF (LIN) • FIBEX • ASPICE SWE.5 • ASPICE SWE.6 • BVA • python-can / PCAN • XCP • AUTOSAR COM • CANoe / CANalyzer
Tool Facts
| Tool Name | STING |
| Language | Python 3.11 |
| Phase 1 Input | DBC · LDF |
| Phase 2 Input | FIBEX · PDF · Excel |
| Output Formats | pytest · CAPL |
| ASPICE Levels | SWE.5 · SWE.6 |
| Unit Tests | 18 / 18 pass |
Standards & Protocols
ASPICE SWE.5 · ASPICE SWE.6 · ISO 26262 · CAN Bus · LIN Bus · FIBEX · AUTOSAR · XCP/CCP
Sample Output (from sample.dbc, 8 signals)
| SWE.5 cases | 65 |
| SWE.6 cases | 73 |
| Total | 138 |
| Output files | 6 .py files |
Ready to Automate Your Signal Test Generation?
From DBC, LDF, FIBEX, PDF, or Excel to pytest in seconds — Requisimus can adapt STING to your signal database format, test toolchain, and ASPICE reporting requirements.
Contact: basavaraj.tarihalli@requisimus.com · www.requisimus.com
© 2026 Requisimus. All rights reserved. · Automotive & Embedded Engineering Experts