We build logging and flashing tools — as PC software, as a standalone device or both. Tools to read, record and safely apply software versions, for development, test bench and service. What gets written with them is the user’s decision — we do not supply the payload.
Depth of service
We build the tool, not the content: application software in customer ECUs and homologation are not part of our scope.
Tools for development, test bench, end-of-line programming and service. Built for continuous use, not lab improvisation.
Typical use: development, test bench, endurance runs and service — record and prove, not intervene.
Typical use: apply software versions safely and traceably. What gets written is supplied by the client.
Our tools work generically and content-neutrally. What is written to a control unit is the client’s decision and responsibility; we do not supply modification files or calibrations. We work only with the rights holder’s authorisation. Legal admissibility is clarified per project and recorded in writing before the project starts.
Contract development of logging and flashing tools: as a PC application, as a standalone device or as a combination of both. Device firmware in C and C++, bare-metal or RTOS-based, with drivers, bootloader and a bus and diagnostics stack. User interfaces, test automation and analysis in Python.
Message matrices, timing analysis and error handling on CAN and CAN-FD. Diagnostics and flash sequences to UDS.
First a working model made of developer and breakout boards: the setup exists early and can be measured before money goes into circuit boards. Then our own board — schematic, component selection, layout, bill of materials and production data in KiCad, including ordering fabrication and assembly.
Assembled boards come back to our own bench: initial commissioning, fault finding at signal level and a functional check of every delivered assembly before it goes into use.
Capturing requirements, structuring them and keeping them traceable: what the tool has to do, which interfaces apply, what has been verified. Including test specification and handover documentation that still holds up after the project.
We analyse a legacy system only as far as interoperability requires — that is where the statutory permission ends, and we do not go beyond it. The deliverable is a functional specification, never derived code. That is where our work ends; implementation happens separately, by your team, a third party or an implementation partner without access to the analysis material.
The legal basis is in particular sections 69d(3) and 69e of the German Copyright Act (UrhG) and section 3 of the Trade Secrets Act (GeschGehG). Before a project starts we check licence and confidentiality terms and record the authorisation in writing. The released specification is frozen and dated; analysis material stays in a separate, access-restricted area.
Clarify and record authorisation, licence and contract situation
Analysis: capture actual behaviour and bus communication
Write the functional specification — without code fragments
Review gate: specification released, separation on record
Implementation strictly from the released specification
Only the specification is handed over. Analysis material never leaves the protected area and feeds into no implementation.
We adapt to your toolchain where the project calls for it.
Specific tool names and licences are agreed per project — please raise it in the first conversation.
We provide certificates and proof of qualification in full on request or during a tender process.
For development, test bench, service or motorsport — we reply with an initial technical assessment.
