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.
30 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
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.
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?