Deep dive into the qdTec-Day 2026: cyber security, functional safety and automated board testing

The qdTec-Day on 5 March 2026 was a double premiere for querdenker engineering GmbH. It was the first technology day the company had organised, and the first time the generous event rooms in the new flow 1986 technology centre in Offenburg were used for a company event. More than 40 participants were offered three technical talks and a varied supporting programme.

“There are so many subjects in electronics development at the moment that call for change and for a new direction that we felt we should provide a few answers,” says managing director Florian Seibold of his team's thinking. With functional safety and cyber security, two central subjects were obvious choices: both have been ever-present in developers' working lives for some time.

On the day, the systems supplier for electronics development welcomed more than 40 clients, prospective clients and business partners. Together with the speakers and the querdenker engineering team, the conference rooms were completely full. Some participants had travelled several hundred kilometres to be there.

After accreditation and a get-together, Florian Seibold welcomed the participants and introduced the programme. Functional safety and the Cyber Resilience Act were covered in the two morning talks, while the afternoon was given to the architecture of the building and to the test adapter range from querdenker engineering.

The schedule was deliberately kept open so that, alongside the talks, there was room for discussion with the speakers and for a proper exchange of experience among the participants, and that room was used to the full.

Impressions of the qdTec-Day on 5 March 2026

Functional safety: guidelines and principles for compliant development

The first talk was given to functional safety and to systems engineering in the development of electronic systems. It fell into two closely connected parts. The first, presented by Stephan Neumann (BERNS Engineers GmbH), covered the regulatory and analytical groundwork. The second, given by Martin Heininger (HEICON), concentrated on putting it into practice in the development process, software development in particular. What holds the two together is the insight that functional safety comes only from the interplay of sound risk analysis (the “what”) and a strict, process-driven development culture (the “how”).

Stephan Neumann began from the proposition that safety means freedom from unacceptable risk, and explained how an acceptable level is set by society through law and standards. He gave an overview of the “jungle of standards” and explained the hierarchy of type A (basic), type B (safety group) and type C (product-specific) standards. For manufacturers, he said, it is decisive first to establish which EU directives apply and then to use existing type C standards in preference. A central point is risk analysis that accompanies development and provides evidence. At the start of a development, initial safety analyses such as FMECA (failure mode, effects and criticality analysis) or CCA (common cause analysis) should be applied, followed by design FMEAs to examine design faults. Evidence-providing analyses such as FMEDA serve to establish dangerous component failures and to calculate figures such as MTTFd (mean time to dangerous failure) and DCavg (average diagnostic coverage). In hardware development, Neumann said, principles apply such as minimising the number of components in safety functions and using reliable parts.

The second part of the talk, by Martin Heininger (Heicon – Global Engineering GmbH), built on that groundwork and translated it into the practice of system and software development. He stressed that functional safety rests on two pillars: minimising random hardware faults through architectural measures, and minimising systematic faults through strict process requirements. The foundation for both is the management of functional safety, with unbroken evidence required at every step. Heininger emphasised the immense importance of a lived safety culture, marked by open communication about anomalies, criticism of the matter rather than the person, and the four-eyes principle. Without that culture, he said, functional safety cannot be implemented efficiently.

In the development process itself, the classical V-model with consistent reviews at every stage serves well. A sensible documentation strategy is essential: documents should be precise (less is more) and should separate strictly between the problem space (the “what”, in textual requirements) and the solution space (the “how”, in graphical architectures).

For software development, Heininger recommends separating safety-relevant from non-safety-relevant software without interference between them, and applying coding standards. Since most of the effort often lies in diagnostic functions and fault handling, test automation and fault injection tests at integration level are of the highest relevance for safety. In the end the circle closed back to the first part of the talk: only those who follow law and standards, are aware of the risks, develop cleanly and document every decision without gaps can implement and assure functional safety.

Mastering the Cyber Resilience Act: one approach from device to cloud

After a long discussion and a coffee break, cyber resilience was next, presented by a team of speakers from querdenker engineering GmbH.

The talk covered the implementation of the Cyber Resilience Act (CRA), an EU regulation for assuring the cyber security of all products with digital elements. The aim of the law is to protect networks and other devices from the cyber risks that direct or indirect connections can create.

The presentation fell into three parts. The first covered the compliance requirements placed on the development team and on operations. A secure by design and default approach is called for, covering secure coding guidelines, strict CI pipelines, minimal privileges and secure update mechanisms. Documented threat analyses, code reviews, reproducible builds and strict role and rights management are essential as well. For operations, the focus lies on certificate management, automatic updates, incident response processes (PSIRT) and a well-considered end-of-life management.

The second part explained vulnerability analysis for embedded software. Under the CRA, manufacturers are obliged to monitor and remedy security risks across the whole product life cycle. A central element is the handling of CVEs (common vulnerabilities and exposures). The process calls for systematic triage, classifying vulnerabilities in context as false positive, not affected or exploitable. To keep the number of CVEs low, the advice is to switch off optional features and to minimise the variety of libraries used. The talk pointed out expressly that CVE monitoring offers no absolute guarantee, since it protects neither against zero-day exploits nor against design faults.

The third part gave a deep insight into the architecture of the qdCloud developed by querdenker engineering, an event-driven IoT platform for scalable fleet and update management. The platform supports the CRA process and offers functions such as updates at the press of a button, configurable alarms and remote access. Technically, the backbone of the cloud rests on NATS JetStream, which is optimised for microservices and offers high scalability at low latency. The architecture uses patterns such as event-driven architecture, command query responsibility segregation (CQRS) and scheduled controllers to create a robust, loosely coupled and scalable landscape that keeps every device monitored and up to date.

After that much technical input, the participants had earned a longer break. The fine early spring weather allowed lunch on the sunny roof terrace, and anyone wanting to test their skill could take on the table football regulars.

The afternoon began with a talk and an architectural tour of the flow building. The architect Peter Waibel explained the design and construction of the five-storey building, built entirely from timber, and led the participants through the house himself.

qdTest: an ICT and board test system for varied electronics production

Then it turned technical again, as another team from querdenker engineering presented qdTest, the adapter family for programming and testing circuit boards. qdTest is a compact in-circuit and board test system designed specifically for varied electronics production. It positions itself as a stand-alone end-of-line solution that can serve both as a firmware flasher and for board testing. At an entry price of around 5,600 euros it offers a cost-effective route to quality assurance. qdTest is available in different sizes and is characterised by a product-specific 3D-printed fixture, standardised electronics and test software supplied with it, which makes it simple and intuitive to operate.

The audience for qdTest is broad: engineers who want to test reliably themselves, results-oriented developers who prefer a simple process, and quality assurance staff who value retesting and unbroken traceability. The system is modular in construction, comprising the fixture for the device under test, a needle alignment plate, a needle board, a structural plate and the test electronics themselves. The whole test sequence is clearly legible and comprehensibly structured.

The process of finding out about the system and procuring it has been kept simple and clear. Through an online price calculator and configurator, clients can adapt the system to their needs, order it, and put it straight into production use on delivery. qdTest also encourages cooperation across departments, between development, production and product management. Integration into the qdCloud is planned, so that device states, test results and configurations can be managed centrally and updates provided. A move to the qdSOM and an extension of its use as a HIL/SIL tester (hardware/software-in-the-loop) are also envisaged.

At the close of the event, many guests took the chance to let the day wind down over a beer. The consistently positive feedback has already led the organiser to set a date for the next qdTec-Day.

👉 More: impressions of the first qdTec-Day on 5 March 2026