Principal Embedded Software Engineer

with years of automotive and leadership experience

Embedded software, complexity and efficiency in development are your keywords. 

You want to realize a creative idea and are looking for pragmatic solutions or you want an independent sparring partner for an architecture or efficiency review.

Then stay on this page and we should possibly get in touch so that your company can benefit from my knowledge and experience. Your ideas are my drive.

Development from the first assembler line to production

A technical idea has a long way to get to a product. Often you start from scratch and with certain company guidelines. And at this stage, fundamental decisions are made that determine the success of the product. Having relevant practical experience, I am able to steer this development in a foresighted and cost-efficient way from the very beginning.

Huge box of tricks about µC configuration of peripheral devices.

When a HW developer says: "The functionality should be done in SW", and when a SW developer says: "The functionality should be done by the HW", they often mean the sophisticated peripherals from the µC for autonomous and synchronous sampling and controlling in combination with memory operations. If your project/product does not have a detailed chapter on this topic, then we should definitely talk to each other, this would be a indication for optimization. Especially this appears in the automotive area when using Autosar µC Abstraction Layer (MCAL), which defines only a minimalistic interface for the microcontroller.

Building and leading an agile and efficient team

Over time the complexity and size of the tasks that a developer is expected to perform grows. And soon, the tasks exceed by far what can be solved by one person alone. So a team is formed and this team must be formed into a co-ordinated squad. The team should be capable to cover all necessary topics in sum. The "stronger" ones should run forward in a controlled way, but without leaving the rest behind. The "new ones" should be quickly trained and become full-fledged team members. The "weaker communicators" should be carefully pulled out of the reserve. And in doing so, it is important never to lose sight of the financial and time goals.

Safety-relevant applications up to ASIL D / SIL3

If a new project starts or if you are not sure whether the implementation of an existing project is designed according to safety "state of the art", then I can assist you in concept and decision making and help you through the safety assessments based on my many years of experience with safety-relevant systems in the automotive industry.

IT Security in Embedded Systems

Meanwhile, the issue of IT security is an integral part of a project, like safety. To design security in an embedded system, a specific combination of knowledge is needed: academic knowledge of cryptography, microcontrollers with security modules, chain of trust in software, trust centre for key management, build process with signature generation, understanding of problems in debugging secured devices with no debug capability, special tools for format conversion and signature validation, understanding of the production process. It is simply an advantage to have someone who has successfully created and implemented such a concept.

Bringing together different technologies to form a product and/or a tool environment

What is part of a project? Let's look at "autonomous driving" as an example. There are camera chips, GMSL, HDMI, CAN (FD), Ethernet, C/C++, Python, C#, Autosar, Linux, CUDA, safety microcontrollers, performance controllers with GPU support, git, Jira, Jenkins, FSM considerations, vehicle simulation, game engine and huge amounts of data. Algorithms and artificial intelligence have not been even mentioned yet. It requires special people being able to design a system on this technical level with such knowledge coverage and to take on architectural task with technical leading.

Realization-oriented A-SPICE process consulting

The two main motivations to work following the process are " verifiably not forgetting anything" and "documentation that is understandable for developers". The process should primarily support development and never become an objective in itself. The awareness and understanding of a "good process" comes first with experience and after self-made instructive mistakes, which allow to see the development in an abstract and formal way.