By Getting the Big Decisions Right - Early!
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?
43 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.
17 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.
37 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.
21 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.
35 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
Newsletter: Better Built By Burkhard
In less than 30 minutes, I can explain a pragmatic approach how to model the threats of an embedded system, assess the cybersecurity risks and document the risks in security decision records (SDRs). Here is the video from my talk at the Torizon CRA Summit in Munich.
Fixing 1000+ CVEs one by one is too costly. Filtering them is arbitrary and might miss important ones. Making the exploitation of hundreds of CVEs unlikely by multiple security measures in one go is nothing else but defence in depth!
Instead of fixing hundreds of CVEs, manufacturers can provide enough security measures to make the exploitation unlikely. The decrease of the CVSS metrics is a useful indicator how effective the security measures are. This post is about understanding the CVSS metrics.
From now on, I'll use heat pumps in private homes as the running example for my CRA articles.
WRONG: substantial modification => new placing on the market. Logical somersaults needed to avoid infinite support periods and full conformity assessment for all legacy products. --- RIGHT: substantial modification => update conformity assessment. No trickery needed.
Do suppliers of FOSS components like Qt LGPL, Weston/Wayland, Linux BSPs, containers and OTA update solutions have to perform no, light-touch or full CRA compliance? The answer affects how much due diligence machine and device manufacturers must exercise for these components in their CRA compliance.
The definitions for making available on the market, placing on the market, intended purpose and substantial modification are crucial for understanding the CRA. The CRA, Blue Guide and Commission guidance interpret them differently. I am trying to sort out this mess.
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.