← Home
Safety-Critical Embedded Development to Standard
Over 35 years of experience in functional safety, real-time systems and hardware-near development — familiar with the relevant standards for automotive, medical technology and industry.
Safety-critical embedded development is not a question of individual functions but of the overall approach: from requirements analysis through architecture and implementation to verification and documentation. Whoever places engagements in this area is looking not only for a good programmer but for someone who has understood the interplay of standard, method and code — and who can realistically estimate the effort that compliance entails.
The following three competence areas are the foundation of my work. They overlap in almost every project.
Experience
1. Experience
More than three decades of embedded development — from career start in engine development to current activity as an independent consultant. In the premium segment, experience is not a marketing argument but a precondition: anyone developing hardware-near real-time systems or safety-critical firmware needs the memory for failure modes that do not appear in textbooks.
- More than 35 years of embedded development (since 1990)
- Career start at Mercedes-Benz, Stuttgart-Untertuerkheim
- Projects for several major automotive manufacturers in Germany, the UK and the USA — and for their French and German suppliers
- International activity in Germany and France
- 2002 — founded Navimess Elektronik (later closed)
- 2012 — founded SCHMITT CONSULTING S.A.R.L. in France
- Graduate Computer Scientist (FH), focus Technical Computer Science
- Diploma thesis in control engineering with real-time hardware drivers in assembler
Standards
2. Standards
Familiar with the relevant standards for safety-critical development in automotive, medical technology and industry. ‘Familiar’ here means: I know the requirements, the methods and the typical pitfalls — and I can judge which standards effort fits your project and which would be overdone. In projects, I work as a developer within the compliance framework established by the client; I do not take on a separate audit role.
- ISO 26262 — Functional safety (automotive, ASIL A to D)
- IEC 61508 — Functional safety (industry, SIL 1 to 4)
- IEC 62304 — Software lifecycle (medical devices, classes A/B/C)
- IEC 60601-1 — Device safety (medical technology)
- RTCA/DO-178B — Aviation software (DAL A to E)
- Automotive SPICE — Process assessment in automotive projects
- MISRA-C / MISRA-C++ — Coding guidelines for safety-relevant C/C++ software
Project Mgmt
3. Project Management
Embedded projects rarely fail on technology, often on communication and steering. My project management is geared to what clients in the premium segment expect: traceable schedules, transparent costs, clear handovers. I do not work with bloated methodology but with what a project actually needs.
- Strict schedule and cost control
- Regular client coordination at agreed cadence
- Cost estimates with price guarantee for fixed-price contracts
- Knowledge transfer to client teams at project end
- Coordination of external suppliers and internal departments
- Technical documentation and traceable code handover
- NDA-readiness and confidential treatment of project content
Additional Technical Focus Areas
Beyond the three main fields, 35 years of practice have produced several content focus areas that often make the difference in projects:
- Real-Time Systems and Bare-Metal Development
- Hardware-near programming on tight microcontrollers, with or without a real-time operating system. Experience with deterministic timing, interrupt architectures and optimisation under memory and runtime constraints.
- FPGA Verification
- Development in VHDL and SystemVerilog, with testbenches and systematic verification. FPGA designs are not ‘software on a chip’ — they follow their own rules, and this is exactly where many projects fail.
- Code Takeover and Reverse Engineering
- Analysis of inherited software bases — assembler, C, C++, often without documentation — and their systematic preparation for the client team. The Stihl project (see references) is an example of this.
- Encryption and Secure Communication
- Development of cryptographic methods and secure bus communication in embedded contexts where standard libraries do not fit — from signed firmware updates through secure bootloaders to bespoke encryption solutions. Note: Above a certain encryption level, approval by the responsible supervisory authority may be required, since encryption technology may not be exported to all countries. We assess the approval requirement together before the project starts.
What These Competences Mean for You
If you have a project where standards conformance, real-time requirements or hardware-near complexity play a role — and at the same time you do not want to engage a whole team of specialists but a single person with overview and delivery commitment — then collaboration with me is probably a good fit.