The Cyber Resilience Act (CRA) is a major milestone in securing embedded systems against cyber threats. While most provisions must be implemented by 2027, reporting obligations take effect from 11 September 2026. As a manufacturer, what are your responsibilities, and which devices are affected?

As software touches every part of life, people expect higher standards for quality, security, and reliability. The Cyber Resilience Act (CRA) reflects this shift - a necessary response to past industry mistakes. Rather than resisting, we can use this regulation to improve our practices. Here’s why regulation is necessary, how we reached this point, and how we can use it to create better software.

The CRA mandates stringent cybersecurity requirements for digital products, ranging from vulnerability management and regular updates to security-by-design principles. Manufacturers are tasked with ensuring that their products remain secure throughout their lifecycle, providing ongoing updates, and managing vulnerabilities proactively. The agile development approach, characterized by iterative cycles, cross-functional collaboration, and continuous integration, is ideally suited to meet these requirements. Agile practices enable teams to quickly adapt to new regulatory demands, implement security measures efficiently, and deliver high-quality, secure software. This article outlines the key aspects of agile development that align with CRA compliance and demonstrates how organizations can leverage agility to meet their obligations under the CRA. For more information on how to transition your team to agile practices and ensure compliance with the CRA, feel free to reach out to me at urs.fassler@iqilio.ch.

Check out the Cyber Resilience Act overview. It shows the most important aspects of the upcoming regulation.

Download as pdf or png. Contact us for preparing the software development, questions and remarks.

Clean Code und Software Craftsmanship helfen, Embedded Systeme sicher zu machen (safety und security). Diese Botschaft hat uns Simon Künzli im aktuellen Kurs Security in Embedded Systems an der ZHAW School of Engineering vermittelt, und ich stimme absolut zu.

Es sind Methoden, Prinzipen und Praktiken welche ich seit bereits 10 Jahren anwende und sehr zu schätzen gelernt habe. Vielleicht tönt TDD, BDD, CI/CD, Review und was es alles gibt abschreckend. Persönlich gebe ich es nicht mehr her. Es gibt so viel Sicherheit das man das richtige entwickelt und die Qualität stimmt. Auch reduziert es die Bugs - dadurch ist der initial etwas höhere Aufwand nach kurzer Zeit amortisiert.

What to do with third party hardware components in your machine wrt. Cyber Resilience Act?

When working towards CRA compliance the focus is usually on the software you write. Especially devices based on Embedded Linux often have other hardware they control or interact with. In this context, one question came up from multiple customers: how do we work with third party hardware that contains software?

I thought about this and came to a quite simple solution with the realization of two key ideas:

Gestern war der Auftakt des Kurses Security in Embeeded Systems an der ZHAW Zürcher Hochschule für Angewandte Wissenschaften. Ich konnte durch den Input von Simon Künzli und den Diskussionen mit meinen Kommilitonen bereits einen differenzierteren Blick auf die kommenden Anforderungen des Cyber Resilience Act (CRA) der EU gewinnen.

Speziell interessiert mich, wie wir als Open Source Community im Embedded Linux Umfeld das Thema gemeinsam umsetzen können.

The Cyber Resilience Act (CRA) is a major milestone in securing embedded systems against cyber threats. While most provisions must be implemented by 2027, reporting obligations take effect from 11 September 2026. As a manufacturer, what are your responsibilities, and which devices are affected?

In embedded systems, the quality of code is crucial for long term reliability and efficiency. The Clean Code principles, as outlined in Robert C. Martin’s influential book Clean Code, are widely used in general software development and can significantly enhance embedded C development. This article explores how these principles can be applied to embedded C, drawing on extensive experience to improve code readability, reduce technical debt, and lower costs over the system’s lifetime. Whether you’re a developer or a manager, this guide offers practical insights into integrating Clean Code into your embedded systems projects.

The CRA mandates stringent cybersecurity requirements for digital products, ranging from vulnerability management and regular updates to security-by-design principles. Manufacturers are tasked with ensuring that their products remain secure throughout their lifecycle, providing ongoing updates, and managing vulnerabilities proactively. The agile development approach, characterized by iterative cycles, cross-functional collaboration, and continuous integration, is ideally suited to meet these requirements. Agile practices enable teams to quickly adapt to new regulatory demands, implement security measures efficiently, and deliver high-quality, secure software. This article outlines the key aspects of agile development that align with CRA compliance and demonstrates how organizations can leverage agility to meet their obligations under the CRA. For more information on how to transition your team to agile practices and ensure compliance with the CRA, feel free to reach out to me at urs.fassler@iqilio.ch.

In diesem Artikel teile ich die Erfahrungen bei der Implementierung einer CI/Build-Pipeline für mehrere C++-Applikationen und Yocto Linux Projekte. Die Firma stand vor Herausforderungen wie manuelle, nicht reproduzierbare Prozesse und ungleich verteiltes Wissen, was zu verspäteten oder fehlerhaften Auslieferungen führte. Durch einen iterativen und inkrementellen Ansatz und gezielte Unterstützung der Entwickler konnten die Prozesse nachhaltig verbessert und der Stress reduziert werden.

In the ever-evolving landscape of software development, maintaining high-quality and reliable software is paramount. To achieve this, rigorous testing practices and robust development methodologies are essential. This article delves into various testing strategies and tools specific to C++, emphasizing the importance of automated regression tests, test coverage, compiler warnings, code formatting, static code analysis, sanitizers, and continuous integration (CI). By adopting these practices, teams can ensure their software remains reliable, maintainable, and bug-free. We offer comprehensive support to help teams implement these tools and practices effectively, enabling them to achieve optimal results.

Very happy to announce that I founded my own company:

The go to place when you need - Quality Software - Embedded Linux Software and Systems - Open Source Specialists - Software Architecture - Shorter delivery and feedback cycles and any combination of it.

Heute starte ich in die Selbstständigkeit. Mein Angebot umfasst:

Es ist Zeit für ein neues Kapitel: Heute starte ich in die Selbstständigkeit.

Meine Karriere begann mit einer Elektronikerlehre, gefolgt von Jahren in der Berufswelt, die mich zur Software-Entwicklung führten. Ich studierte Systeminformatik an der ZHAW, erwarb meinen Master in Computer Science an der ETH, absolvierte ein Praktikum am CERN und verfasste meine Masterarbeit an der University of California in Irvine. Währenddessen entdeckte ich Freie Software/Open Source mit den Werten, welche ich bis heute teile.

Dieses paradoxe Phänomen tritt häufig in der Softwareentwicklung auf. Entwickler stehen unter Zeitdruck und sehen sich gezwungen, schnelle Lösungen zu implementieren, anstatt sich Zeit zu nehmen, diese zu planen und so zu implementieren, dass die Software nachhaltig erweiterbar ist. Dies führt zu schlechter Codequalität und unzureichender Testabdeckung, die später mehr Zeit und Ressourcen erfordern, um sie zu beheben. Der Versuch, Zeit zu sparen, indem man an der Qualität spart, endet in einem viel längeren Entwicklungszyklus.

In embedded systems, the quality of code is crucial for long term reliability and efficiency. The Clean Code principles, as outlined in Robert C. Martin’s influential book Clean Code, are widely used in general software development and can significantly enhance embedded C development. This article explores how these principles can be applied to embedded C, drawing on extensive experience to improve code readability, reduce technical debt, and lower costs over the system’s lifetime. Whether you’re a developer or a manager, this guide offers practical insights into integrating Clean Code into your embedded systems projects.

In embedded systems, the quality of code is crucial for long term reliability and efficiency. The Clean Code principles, as outlined in Robert C. Martin’s influential book Clean Code, are widely used in general software development and can significantly enhance embedded C development. This article explores how these principles can be applied to embedded C, drawing on extensive experience to improve code readability, reduce technical debt, and lower costs over the system’s lifetime. Whether you’re a developer or a manager, this guide offers practical insights into integrating Clean Code into your embedded systems projects.

In the ever-evolving landscape of software development, maintaining high-quality and reliable software is paramount. To achieve this, rigorous testing practices and robust development methodologies are essential. This article delves into various testing strategies and tools specific to C++, emphasizing the importance of automated regression tests, test coverage, compiler warnings, code formatting, static code analysis, sanitizers, and continuous integration (CI). By adopting these practices, teams can ensure their software remains reliable, maintainable, and bug-free. We offer comprehensive support to help teams implement these tools and practices effectively, enabling them to achieve optimal results.

In embedded systems, the quality of code is crucial for long term reliability and efficiency. The Clean Code principles, as outlined in Robert C. Martin’s influential book Clean Code, are widely used in general software development and can significantly enhance embedded C development. This article explores how these principles can be applied to embedded C, drawing on extensive experience to improve code readability, reduce technical debt, and lower costs over the system’s lifetime. Whether you’re a developer or a manager, this guide offers practical insights into integrating Clean Code into your embedded systems projects.

As software touches every part of life, people expect higher standards for quality, security, and reliability. The Cyber Resilience Act (CRA) reflects this shift - a necessary response to past industry mistakes. Rather than resisting, we can use this regulation to improve our practices. Here’s why regulation is necessary, how we reached this point, and how we can use it to create better software.

The CRA mandates stringent cybersecurity requirements for digital products, ranging from vulnerability management and regular updates to security-by-design principles. Manufacturers are tasked with ensuring that their products remain secure throughout their lifecycle, providing ongoing updates, and managing vulnerabilities proactively. The agile development approach, characterized by iterative cycles, cross-functional collaboration, and continuous integration, is ideally suited to meet these requirements. Agile practices enable teams to quickly adapt to new regulatory demands, implement security measures efficiently, and deliver high-quality, secure software. This article outlines the key aspects of agile development that align with CRA compliance and demonstrates how organizations can leverage agility to meet their obligations under the CRA. For more information on how to transition your team to agile practices and ensure compliance with the CRA, feel free to reach out to me at urs.fassler@iqilio.ch.

In diesem Artikel teile ich die Erfahrungen bei der Implementierung einer CI/Build-Pipeline für mehrere C++-Applikationen und Yocto Linux Projekte. Die Firma stand vor Herausforderungen wie manuelle, nicht reproduzierbare Prozesse und ungleich verteiltes Wissen, was zu verspäteten oder fehlerhaften Auslieferungen führte. Durch einen iterativen und inkrementellen Ansatz und gezielte Unterstützung der Entwickler konnten die Prozesse nachhaltig verbessert und der Stress reduziert werden.

Embedded Software Meetup Zürich ist zurück!

Nach längerer Pause des "Embedded GNU/Linux Developer Meetup" führen wir es als "Embedded Software Meetup" wieder durch. Es geht um:

und vieles mehr. Im Fokus steht der Austausch zwischen Entwicklern und anderen gleichgesinnten.

Den Anfang macht Urs Fässler mit seinem Erfahrungsbericht zu moderner Applikationsentwicklung für Embedded Linux.

Clean Code und Software Craftsmanship helfen, Embedded Systeme sicher zu machen (safety und security). Diese Botschaft hat uns Simon Künzli im aktuellen Kurs Security in Embedded Systems an der ZHAW School of Engineering vermittelt, und ich stimme absolut zu.

Es sind Methoden, Prinzipen und Praktiken welche ich seit bereits 10 Jahren anwende und sehr zu schätzen gelernt habe. Vielleicht tönt TDD, BDD, CI/CD, Review und was es alles gibt abschreckend. Persönlich gebe ich es nicht mehr her. Es gibt so viel Sicherheit das man das richtige entwickelt und die Qualität stimmt. Auch reduziert es die Bugs - dadurch ist der initial etwas höhere Aufwand nach kurzer Zeit amortisiert.

In embedded systems, the quality of code is crucial for long term reliability and efficiency. The Clean Code principles, as outlined in Robert C. Martin’s influential book Clean Code, are widely used in general software development and can significantly enhance embedded C development. This article explores how these principles can be applied to embedded C, drawing on extensive experience to improve code readability, reduce technical debt, and lower costs over the system’s lifetime. Whether you’re a developer or a manager, this guide offers practical insights into integrating Clean Code into your embedded systems projects.

Manchmal erreicht ein Software-Projekt einen Punkt, an dem die Weiterentwicklung fast zum Stillstand kommt. Features werden nur noch mühsam implementiert, und die Kosten für Änderungen explodieren. Genau an diesem Punkt stand unser Kunde, als er uns, Urs Fässler von iQiliO und Peter Gfader von Beyond Agility, mit einem Architektur-Review beauftragte. Ziel war es, den Zustand der Software objektiv zu bewerten und eine Empfehlung abzugeben: Soll die bestehende Software weiterentwickelt oder komplett neu geschrieben werden?

As software touches every part of life, people expect higher standards for quality, security, and reliability. The Cyber Resilience Act (CRA) reflects this shift - a necessary response to past industry mistakes. Rather than resisting, we can use this regulation to improve our practices. Here’s why regulation is necessary, how we reached this point, and how we can use it to create better software.

The CRA mandates stringent cybersecurity requirements for digital products, ranging from vulnerability management and regular updates to security-by-design principles. Manufacturers are tasked with ensuring that their products remain secure throughout their lifecycle, providing ongoing updates, and managing vulnerabilities proactively. The agile development approach, characterized by iterative cycles, cross-functional collaboration, and continuous integration, is ideally suited to meet these requirements. Agile practices enable teams to quickly adapt to new regulatory demands, implement security measures efficiently, and deliver high-quality, secure software. This article outlines the key aspects of agile development that align with CRA compliance and demonstrates how organizations can leverage agility to meet their obligations under the CRA. For more information on how to transition your team to agile practices and ensure compliance with the CRA, feel free to reach out to me at urs.fassler@iqilio.ch.

In the ever-evolving landscape of software development, maintaining high-quality and reliable software is paramount. To achieve this, rigorous testing practices and robust development methodologies are essential. This article delves into various testing strategies and tools specific to C++, emphasizing the importance of automated regression tests, test coverage, compiler warnings, code formatting, static code analysis, sanitizers, and continuous integration (CI). By adopting these practices, teams can ensure their software remains reliable, maintainable, and bug-free. We offer comprehensive support to help teams implement these tools and practices effectively, enabling them to achieve optimal results.

Check out the Cyber Resilience Act overview. It shows the most important aspects of the upcoming regulation.

Download as pdf or png. Contact us for preparing the software development, questions and remarks.

Embedded Software Meetup Zürich ist zurück!

Nach längerer Pause des "Embedded GNU/Linux Developer Meetup" führen wir es als "Embedded Software Meetup" wieder durch. Es geht um:

und vieles mehr. Im Fokus steht der Austausch zwischen Entwicklern und anderen gleichgesinnten.

Den Anfang macht Urs Fässler mit seinem Erfahrungsbericht zu moderner Applikationsentwicklung für Embedded Linux.

Clean Code und Software Craftsmanship helfen, Embedded Systeme sicher zu machen (safety und security). Diese Botschaft hat uns Simon Künzli im aktuellen Kurs Security in Embedded Systems an der ZHAW School of Engineering vermittelt, und ich stimme absolut zu.

Es sind Methoden, Prinzipen und Praktiken welche ich seit bereits 10 Jahren anwende und sehr zu schätzen gelernt habe. Vielleicht tönt TDD, BDD, CI/CD, Review und was es alles gibt abschreckend. Persönlich gebe ich es nicht mehr her. Es gibt so viel Sicherheit das man das richtige entwickelt und die Qualität stimmt. Auch reduziert es die Bugs - dadurch ist der initial etwas höhere Aufwand nach kurzer Zeit amortisiert.

Investigating Yocto issues can be challenging. Yocto employs Bitbake, which heavily relies on variables (lists) that are set, appended, prepended, and modified across several recipes. Other recipes reference these variables to make decisions and modify additional variables.

One particularly troublesome variable is DISTRO_FEATURES. Numerous recipes manipulate this variable, and any change typically triggers a rebuild of most packages. In our case a colleague was missing systemd within DISTRO_FEATURES, although it was present in my configuration.

Have you ever struggled with finding the right place to store your service’s configuration files on a Embedded Linux system?

I’ve observed numerous file storage and System Configuration practices, such as placing everything under /data, utilizing /opt/…​, or keeping operational data under /etc/…​, among others. While these methods are feasible, I would advise against them. The Filesystem Hierarchy Standard (FHS) specifies the appropriate locations for different types of files.

If you’re developing services for Embedded Linux, adhering to the FHS can significantly simplify software deployment and management. By following these standards, developers ensure their applications are more portable and easier to maintain. For instance, tools like Yocto automatically locate files expected in standard directories. Runtime behavior is as expected when you choose the correct location for temporary and log files.

Heute starte ich in die Selbstständigkeit. Mein Angebot umfasst:

Es ist Zeit für ein neues Kapitel: Heute starte ich in die Selbstständigkeit.

Meine Karriere begann mit einer Elektronikerlehre, gefolgt von Jahren in der Berufswelt, die mich zur Software-Entwicklung führten. Ich studierte Systeminformatik an der ZHAW, erwarb meinen Master in Computer Science an der ETH, absolvierte ein Praktikum am CERN und verfasste meine Masterarbeit an der University of California in Irvine. Währenddessen entdeckte ich Freie Software/Open Source mit den Werten, welche ich bis heute teile.

Dieses paradoxe Phänomen tritt häufig in der Softwareentwicklung auf. Entwickler stehen unter Zeitdruck und sehen sich gezwungen, schnelle Lösungen zu implementieren, anstatt sich Zeit zu nehmen, diese zu planen und so zu implementieren, dass die Software nachhaltig erweiterbar ist. Dies führt zu schlechter Codequalität und unzureichender Testabdeckung, die später mehr Zeit und Ressourcen erfordern, um sie zu beheben. Der Versuch, Zeit zu sparen, indem man an der Qualität spart, endet in einem viel längeren Entwicklungszyklus.

In embedded systems, the quality of code is crucial for long term reliability and efficiency. The Clean Code principles, as outlined in Robert C. Martin’s influential book Clean Code, are widely used in general software development and can significantly enhance embedded C development. This article explores how these principles can be applied to embedded C, drawing on extensive experience to improve code readability, reduce technical debt, and lower costs over the system’s lifetime. Whether you’re a developer or a manager, this guide offers practical insights into integrating Clean Code into your embedded systems projects.

Manchmal erreicht ein Software-Projekt einen Punkt, an dem die Weiterentwicklung fast zum Stillstand kommt. Features werden nur noch mühsam implementiert, und die Kosten für Änderungen explodieren. Genau an diesem Punkt stand unser Kunde, als er uns, Urs Fässler von iQiliO und Peter Gfader von Beyond Agility, mit einem Architektur-Review beauftragte. Ziel war es, den Zustand der Software objektiv zu bewerten und eine Empfehlung abzugeben: Soll die bestehende Software weiterentwickelt oder komplett neu geschrieben werden?

As software touches every part of life, people expect higher standards for quality, security, and reliability. The Cyber Resilience Act (CRA) reflects this shift - a necessary response to past industry mistakes. Rather than resisting, we can use this regulation to improve our practices. Here’s why regulation is necessary, how we reached this point, and how we can use it to create better software.

The CRA mandates stringent cybersecurity requirements for digital products, ranging from vulnerability management and regular updates to security-by-design principles. Manufacturers are tasked with ensuring that their products remain secure throughout their lifecycle, providing ongoing updates, and managing vulnerabilities proactively. The agile development approach, characterized by iterative cycles, cross-functional collaboration, and continuous integration, is ideally suited to meet these requirements. Agile practices enable teams to quickly adapt to new regulatory demands, implement security measures efficiently, and deliver high-quality, secure software. This article outlines the key aspects of agile development that align with CRA compliance and demonstrates how organizations can leverage agility to meet their obligations under the CRA. For more information on how to transition your team to agile practices and ensure compliance with the CRA, feel free to reach out to me at urs.fassler@iqilio.ch.

In diesem Artikel teile ich die Erfahrungen bei der Implementierung einer CI/Build-Pipeline für mehrere C++-Applikationen und Yocto Linux Projekte. Die Firma stand vor Herausforderungen wie manuelle, nicht reproduzierbare Prozesse und ungleich verteiltes Wissen, was zu verspäteten oder fehlerhaften Auslieferungen führte. Durch einen iterativen und inkrementellen Ansatz und gezielte Unterstützung der Entwickler konnten die Prozesse nachhaltig verbessert und der Stress reduziert werden.

In the ever-evolving landscape of software development, maintaining high-quality and reliable software is paramount. To achieve this, rigorous testing practices and robust development methodologies are essential. This article delves into various testing strategies and tools specific to C++, emphasizing the importance of automated regression tests, test coverage, compiler warnings, code formatting, static code analysis, sanitizers, and continuous integration (CI). By adopting these practices, teams can ensure their software remains reliable, maintainable, and bug-free. We offer comprehensive support to help teams implement these tools and practices effectively, enabling them to achieve optimal results.

Embedded Software Meetup Zürich ist zurück!

Nach längerer Pause des "Embedded GNU/Linux Developer Meetup" führen wir es als "Embedded Software Meetup" wieder durch. Es geht um:

und vieles mehr. Im Fokus steht der Austausch zwischen Entwicklern und anderen gleichgesinnten.

Den Anfang macht Urs Fässler mit seinem Erfahrungsbericht zu moderner Applikationsentwicklung für Embedded Linux.

Clean Code und Software Craftsmanship helfen, Embedded Systeme sicher zu machen (safety und security). Diese Botschaft hat uns Simon Künzli im aktuellen Kurs Security in Embedded Systems an der ZHAW School of Engineering vermittelt, und ich stimme absolut zu.

Es sind Methoden, Prinzipen und Praktiken welche ich seit bereits 10 Jahren anwende und sehr zu schätzen gelernt habe. Vielleicht tönt TDD, BDD, CI/CD, Review und was es alles gibt abschreckend. Persönlich gebe ich es nicht mehr her. Es gibt so viel Sicherheit das man das richtige entwickelt und die Qualität stimmt. Auch reduziert es die Bugs - dadurch ist der initial etwas höhere Aufwand nach kurzer Zeit amortisiert.

Very happy to announce that I founded my own company:

The go to place when you need - Quality Software - Embedded Linux Software and Systems - Open Source Specialists - Software Architecture - Shorter delivery and feedback cycles and any combination of it.

Um in der heutigen schnelllebigen Technologiewelt Embedded Systeme Nachhaltig zu gestalten ist es unerlässlich, dass Software fortlaufend aktualisiert wird. Es ist nicht mehr zeitgemäss, Embedded Software einmalig zu entwickeln und dann über Jahre unverändert zu lassen. Verschiedene Faktoren treiben diese Notwendigkeit an:

Heute starte ich in die Selbstständigkeit. Mein Angebot umfasst:

Es ist Zeit für ein neues Kapitel: Heute starte ich in die Selbstständigkeit.

Meine Karriere begann mit einer Elektronikerlehre, gefolgt von Jahren in der Berufswelt, die mich zur Software-Entwicklung führten. Ich studierte Systeminformatik an der ZHAW, erwarb meinen Master in Computer Science an der ETH, absolvierte ein Praktikum am CERN und verfasste meine Masterarbeit an der University of California in Irvine. Währenddessen entdeckte ich Freie Software/Open Source mit den Werten, welche ich bis heute teile.

Dieses paradoxe Phänomen tritt häufig in der Softwareentwicklung auf. Entwickler stehen unter Zeitdruck und sehen sich gezwungen, schnelle Lösungen zu implementieren, anstatt sich Zeit zu nehmen, diese zu planen und so zu implementieren, dass die Software nachhaltig erweiterbar ist. Dies führt zu schlechter Codequalität und unzureichender Testabdeckung, die später mehr Zeit und Ressourcen erfordern, um sie zu beheben. Der Versuch, Zeit zu sparen, indem man an der Qualität spart, endet in einem viel längeren Entwicklungszyklus.

In embedded systems, the quality of code is crucial for long term reliability and efficiency. The Clean Code principles, as outlined in Robert C. Martin’s influential book Clean Code, are widely used in general software development and can significantly enhance embedded C development. This article explores how these principles can be applied to embedded C, drawing on extensive experience to improve code readability, reduce technical debt, and lower costs over the system’s lifetime. Whether you’re a developer or a manager, this guide offers practical insights into integrating Clean Code into your embedded systems projects.

Manchmal erreicht ein Software-Projekt einen Punkt, an dem die Weiterentwicklung fast zum Stillstand kommt. Features werden nur noch mühsam implementiert, und die Kosten für Änderungen explodieren. Genau an diesem Punkt stand unser Kunde, als er uns, Urs Fässler von iQiliO und Peter Gfader von Beyond Agility, mit einem Architektur-Review beauftragte. Ziel war es, den Zustand der Software objektiv zu bewerten und eine Empfehlung abzugeben: Soll die bestehende Software weiterentwickelt oder komplett neu geschrieben werden?

As software touches every part of life, people expect higher standards for quality, security, and reliability. The Cyber Resilience Act (CRA) reflects this shift - a necessary response to past industry mistakes. Rather than resisting, we can use this regulation to improve our practices. Here’s why regulation is necessary, how we reached this point, and how we can use it to create better software.

The CRA mandates stringent cybersecurity requirements for digital products, ranging from vulnerability management and regular updates to security-by-design principles. Manufacturers are tasked with ensuring that their products remain secure throughout their lifecycle, providing ongoing updates, and managing vulnerabilities proactively. The agile development approach, characterized by iterative cycles, cross-functional collaboration, and continuous integration, is ideally suited to meet these requirements. Agile practices enable teams to quickly adapt to new regulatory demands, implement security measures efficiently, and deliver high-quality, secure software. This article outlines the key aspects of agile development that align with CRA compliance and demonstrates how organizations can leverage agility to meet their obligations under the CRA. For more information on how to transition your team to agile practices and ensure compliance with the CRA, feel free to reach out to me at urs.fassler@iqilio.ch.

Dieses paradoxe Phänomen tritt häufig in der Softwareentwicklung auf. Entwickler stehen unter Zeitdruck und sehen sich gezwungen, schnelle Lösungen zu implementieren, anstatt sich Zeit zu nehmen, diese zu planen und so zu implementieren, dass die Software nachhaltig erweiterbar ist. Dies führt zu schlechter Codequalität und unzureichender Testabdeckung, die später mehr Zeit und Ressourcen erfordern, um sie zu beheben. Der Versuch, Zeit zu sparen, indem man an der Qualität spart, endet in einem viel längeren Entwicklungszyklus.

Manchmal erreicht ein Software-Projekt einen Punkt, an dem die Weiterentwicklung fast zum Stillstand kommt. Features werden nur noch mühsam implementiert, und die Kosten für Änderungen explodieren. Genau an diesem Punkt stand unser Kunde, als er uns, Urs Fässler von iQiliO und Peter Gfader von Beyond Agility, mit einem Architektur-Review beauftragte. Ziel war es, den Zustand der Software objektiv zu bewerten und eine Empfehlung abzugeben: Soll die bestehende Software weiterentwickelt oder komplett neu geschrieben werden?

Very happy to announce that I founded my own company:

The go to place when you need - Quality Software - Embedded Linux Software and Systems - Open Source Specialists - Software Architecture - Shorter delivery and feedback cycles and any combination of it.

Heute starte ich in die Selbstständigkeit. Mein Angebot umfasst:

Es ist Zeit für ein neues Kapitel: Heute starte ich in die Selbstständigkeit.

Meine Karriere begann mit einer Elektronikerlehre, gefolgt von Jahren in der Berufswelt, die mich zur Software-Entwicklung führten. Ich studierte Systeminformatik an der ZHAW, erwarb meinen Master in Computer Science an der ETH, absolvierte ein Praktikum am CERN und verfasste meine Masterarbeit an der University of California in Irvine. Währenddessen entdeckte ich Freie Software/Open Source mit den Werten, welche ich bis heute teile.

In diesem Artikel teile ich die Erfahrungen bei der Implementierung einer CI/Build-Pipeline für mehrere C++-Applikationen und Yocto Linux Projekte. Die Firma stand vor Herausforderungen wie manuelle, nicht reproduzierbare Prozesse und ungleich verteiltes Wissen, was zu verspäteten oder fehlerhaften Auslieferungen führte. Durch einen iterativen und inkrementellen Ansatz und gezielte Unterstützung der Entwickler konnten die Prozesse nachhaltig verbessert und der Stress reduziert werden.

In this article, I share my initial impressions gathered from my first steps with Torizon, a Linux-based containerized embedded OS developed by Toradex. Torizon aims to simplify the user experience and customization process compared to alternatives like Yocto. It achieves this by running user applications within custom containers on a base OS, supported by an array of tools. While Torizon simplifies the setup and lowers the entry barrier for newcomers, I found it occasionally challenging as an experienced Embedded Linux and Yocto user.

Check out the Cyber Resilience Act overview. It shows the most important aspects of the upcoming regulation.

Download as pdf or png. Contact us for preparing the software development, questions and remarks.

Embedded Software Meetup Zürich ist zurück!

Nach längerer Pause des "Embedded GNU/Linux Developer Meetup" führen wir es als "Embedded Software Meetup" wieder durch. Es geht um:

und vieles mehr. Im Fokus steht der Austausch zwischen Entwicklern und anderen gleichgesinnten.

Den Anfang macht Urs Fässler mit seinem Erfahrungsbericht zu moderner Applikationsentwicklung für Embedded Linux.

Clean Code und Software Craftsmanship helfen, Embedded Systeme sicher zu machen (safety und security). Diese Botschaft hat uns Simon Künzli im aktuellen Kurs Security in Embedded Systems an der ZHAW School of Engineering vermittelt, und ich stimme absolut zu.

Es sind Methoden, Prinzipen und Praktiken welche ich seit bereits 10 Jahren anwende und sehr zu schätzen gelernt habe. Vielleicht tönt TDD, BDD, CI/CD, Review und was es alles gibt abschreckend. Persönlich gebe ich es nicht mehr her. Es gibt so viel Sicherheit das man das richtige entwickelt und die Qualität stimmt. Auch reduziert es die Bugs - dadurch ist der initial etwas höhere Aufwand nach kurzer Zeit amortisiert.

Very happy to announce that I founded my own company:

The go to place when you need - Quality Software - Embedded Linux Software and Systems - Open Source Specialists - Software Architecture - Shorter delivery and feedback cycles and any combination of it.

Investigating Yocto issues can be challenging. Yocto employs Bitbake, which heavily relies on variables (lists) that are set, appended, prepended, and modified across several recipes. Other recipes reference these variables to make decisions and modify additional variables.

One particularly troublesome variable is DISTRO_FEATURES. Numerous recipes manipulate this variable, and any change typically triggers a rebuild of most packages. In our case a colleague was missing systemd within DISTRO_FEATURES, although it was present in my configuration.

Have you ever struggled with finding the right place to store your service’s configuration files on a Embedded Linux system?

I’ve observed numerous file storage and System Configuration practices, such as placing everything under /data, utilizing /opt/…​, or keeping operational data under /etc/…​, among others. While these methods are feasible, I would advise against them. The Filesystem Hierarchy Standard (FHS) specifies the appropriate locations for different types of files.

If you’re developing services for Embedded Linux, adhering to the FHS can significantly simplify software deployment and management. By following these standards, developers ensure their applications are more portable and easier to maintain. For instance, tools like Yocto automatically locate files expected in standard directories. Runtime behavior is as expected when you choose the correct location for temporary and log files.

Um in der heutigen schnelllebigen Technologiewelt Embedded Systeme Nachhaltig zu gestalten ist es unerlässlich, dass Software fortlaufend aktualisiert wird. Es ist nicht mehr zeitgemäss, Embedded Software einmalig zu entwickeln und dann über Jahre unverändert zu lassen. Verschiedene Faktoren treiben diese Notwendigkeit an:

What to do with third party hardware components in your machine wrt. Cyber Resilience Act?

When working towards CRA compliance the focus is usually on the software you write. Especially devices based on Embedded Linux often have other hardware they control or interact with. In this context, one question came up from multiple customers: how do we work with third party hardware that contains software?

I thought about this and came to a quite simple solution with the realization of two key ideas:

Heute starte ich in die Selbstständigkeit. Mein Angebot umfasst:

Gestern war der Auftakt des Kurses Security in Embeeded Systems an der ZHAW Zürcher Hochschule für Angewandte Wissenschaften. Ich konnte durch den Input von Simon Künzli und den Diskussionen mit meinen Kommilitonen bereits einen differenzierteren Blick auf die kommenden Anforderungen des Cyber Resilience Act (CRA) der EU gewinnen.

Speziell interessiert mich, wie wir als Open Source Community im Embedded Linux Umfeld das Thema gemeinsam umsetzen können.

In this article, I share my initial impressions gathered from my first steps with Torizon, a Linux-based containerized embedded OS developed by Toradex. Torizon aims to simplify the user experience and customization process compared to alternatives like Yocto. It achieves this by running user applications within custom containers on a base OS, supported by an array of tools. While Torizon simplifies the setup and lowers the entry barrier for newcomers, I found it occasionally challenging as an experienced Embedded Linux and Yocto user.

In this article, I share my initial impressions gathered from my first steps with Torizon, a Linux-based containerized embedded OS developed by Toradex. Torizon aims to simplify the user experience and customization process compared to alternatives like Yocto. It achieves this by running user applications within custom containers on a base OS, supported by an array of tools. While Torizon simplifies the setup and lowers the entry barrier for newcomers, I found it occasionally challenging as an experienced Embedded Linux and Yocto user.

Public Money? Public Code! Wie have it in Switzerland.

See the talk from Matthias Stürmer at OpenSource at Siemens how he did it.

Very happy to announce that I founded my own company:

The go to place when you need - Quality Software - Embedded Linux Software and Systems - Open Source Specialists - Software Architecture - Shorter delivery and feedback cycles and any combination of it.

Um in der heutigen schnelllebigen Technologiewelt Embedded Systeme Nachhaltig zu gestalten ist es unerlässlich, dass Software fortlaufend aktualisiert wird. Es ist nicht mehr zeitgemäss, Embedded Software einmalig zu entwickeln und dann über Jahre unverändert zu lassen. Verschiedene Faktoren treiben diese Notwendigkeit an:

What to do with third party hardware components in your machine wrt. Cyber Resilience Act?

When working towards CRA compliance the focus is usually on the software you write. Especially devices based on Embedded Linux often have other hardware they control or interact with. In this context, one question came up from multiple customers: how do we work with third party hardware that contains software?

I thought about this and came to a quite simple solution with the realization of two key ideas:

Heute starte ich in die Selbstständigkeit. Mein Angebot umfasst:

Es ist Zeit für ein neues Kapitel: Heute starte ich in die Selbstständigkeit.

Meine Karriere begann mit einer Elektronikerlehre, gefolgt von Jahren in der Berufswelt, die mich zur Software-Entwicklung führten. Ich studierte Systeminformatik an der ZHAW, erwarb meinen Master in Computer Science an der ETH, absolvierte ein Praktikum am CERN und verfasste meine Masterarbeit an der University of California in Irvine. Währenddessen entdeckte ich Freie Software/Open Source mit den Werten, welche ich bis heute teile.

Gestern war der Auftakt des Kurses Security in Embeeded Systems an der ZHAW Zürcher Hochschule für Angewandte Wissenschaften. Ich konnte durch den Input von Simon Künzli und den Diskussionen mit meinen Kommilitonen bereits einen differenzierteren Blick auf die kommenden Anforderungen des Cyber Resilience Act (CRA) der EU gewinnen.

Speziell interessiert mich, wie wir als Open Source Community im Embedded Linux Umfeld das Thema gemeinsam umsetzen können.