Business meets system architecture: Getting the big decisions right!
Our OfferingSystem architecture answers the difficult questions with big impact early in product development. Which SoM comes with a CRA-compliant Linux? Which components should manufacturers develop themselves, which outsource and which buy off the shelf? Which team structure leads to an architecture for the system that is upgradable for the next 10-15 years? How can manufacturers save costs by reducing the number of embedded systems in their machines?
39 posts
The CRA forces manufacturers to protect their embedded systems properly against cybersecurity threats. Otherwise, they face heavy penalties and sales bans. We provide practical tips, how to perform a risk assessment, which security measures are enough to satisfy the essential product requirements, how to tame the thousands of vulnerabilities, and whether it's worth to make an embedded system comply with the CRA at all.
26 posts
A typical embedded Linux system comprises 250+ software components under 75+ different licenses like BSD, Apache, LGPL, EPL and GPL. You must satisfy the license obligations for all components and ensure that license combinations are legal and desirable. A special focus is on using Qt under LGPL and on avoiding the hefty fees for commercial Qt licenses on embedded systems.
12 posts
Applications and services mediate between users and machines. They represent the core business. Embedded systems often start out as a single application, but typically end up as multiple applications and services. Our experience lead us to the adoption of a winning strategy. We organise applications and services as microservices and design them according to the ports-and-adapters architecture.
15 posts
Every SoM comes with a makeshift Linux system. Every manufacturer must add OTA updates, security measures, remote access, GUI frameworks and more. That's a lot of duplicated work. This would be much more efficient, if a SoM maker provides a Linux with all the features ready for use by manufacturers. Toradex does this with Torizon. We show how manufacturers can benefit from this groundwork with minimal effort. Torizon even runs on non-Toradex SoMs. SoM = Solutions on Module.
35 posts
Following the principles and practices of continuous delivery helps manufacturers provide better software faster. Continuous delivery is all about feedback within seconds, minutes, hours and days. The best way to gain this feedback is to run a continuous delivery pipeline, which enables your development team to work at a constant and fast pace - without sacrificing quality. Continuous delivery is the secret formula for high-performance teams.
24 posts
Newsletter: Better Built By Burkhard
Big architecture decisions have big business impact. Wardley maps help us identify money pits in product development. They show us the way how to save money by commoditising hardware and software that is not part of our core business.
The Yocto recipe gives GPL as the license of MariaDB. The Qt Sql library implements its MySQL driver with MariaDB. Hence, it would be under GPL - and so would be all applications linking Qt Sql. Businesses would have to open-source their code. A disaster! So, what's wrong?
A device violates essential CRA requirements. Although simple state-of-the-art security measures are available, the manufacturer mitigates the violations with legal disclaimers. This goes against the intention of the CRA: improving cybersecurity in real life and not just on paper.
Per definition, embedded devices are products with digital elements and, hence, must comply with the CRA. I'll give examples whether to classify devices as default, important or critical. The classification decides how expensive CRA compliance is. So, we better get it right.
Courts will do it! Cybersecurity experts throw a lot of security measures at the wall and see which ones stick. They seriously suggest that manufacturers must only do a "proper" risk assessment and all is fine. Manufacturers define what "proper" means. Isn't that circular reasoning?
If a machine sold in 2015 receives a feature update in 2028 or later, it must undergo full CRA compliance (Article 69.2). The best bet for the manufacturer might be to argue that the CRA violates legal certainty and non-retroactivity of law - constitutional rights in most EU countries.
Are you ready for the Cyber Resilience Act? If not sure, check out my new offering. In the CRA Survival Bootcamp, you'll learn how to do CRA compliance on your own. My related posts may help you as well.
What does the CRA require from you to avoid sales bans after 11 December 2027 and penalties threatening the existence of your company? Risk assessment, vulnerability handling and technical documentation. And tough decisions which products to retire.
Overview of my posts and talks about risk assessment of the essential product requirements of the EU Cyber Resilience Act (CRA).
The CRA requires manufactures to document the risk assessment. Architecture decision records (ADRs) are the ideal means for that. They also facilitate good discussions about different mitigation options.