Handlungsoptionen f\u00fcr Embedded-Systeme in der Speicherkrise<\/strong><\/p>\n\n\n\n Speicher ist innerhalb weniger Quartale von einer Nebenposition in der St\u00fcckliste zu einem der gr\u00f6\u00dften Kostentreiber geworden. Der Grund ist nicht fehlende Fertigungskapazit\u00e4t, sondern deren Umverteilung: HBM und Server-DRAM f\u00fcr KI-Infrastruktur haben deutlich h\u00f6here Margen als klassische DDR-Bausteine, und die drei gro\u00dfen Hersteller verschieben ihre Wafer entsprechend.<\/p>\n\n\n\n F\u00fcr Serienprodukte mit abgeschlossener Qualifizierung, EMV-Freigabe und laufender Fertigung ist das besonders unangenehm, weil kurzfristige Wechsel dort am teuersten sind. Genau deshalb lohnt es sich, das Thema technisch anzugehen und nicht nur einkaufsseitig.<\/p>\n\n\n\n Der Reflex ist verst\u00e4ndlich, funktioniert als Strategie aber nicht. DDR3 ist bei den gro\u00dfen Herstellern l\u00e4ngst abgek\u00fcndigt: SK Hynix hat die Belieferung Ende 2023 eingestellt, Samsung die Produktion 2024 heruntergefahren. \u00dcbrig bleiben Micron und Nischenanbieter, die Langfristverf\u00fcgbarkeit zusagen und entsprechende Preise aufrufen.<\/p>\n\n\n\n Der tragf\u00e4higere Ansatz lautet: nicht billigeren Speicher suchen, sondern weniger Speicher brauchen.<\/strong><\/p>\n\n\n\n Dazu kommt der technische Punkt: DDR3 und DDR4 sind weder pinkompatibel noch elektrisch austauschbar. Ein Wechsel bedeutet neues Layout, einen SoC, der den \u00e4lteren Standard \u00fcberhaupt noch unterst\u00fctzt, ein neues DDR-Bring-up und eine erneute Validierung. Wer diesen Aufwand ohnehin betreibt, sollte ihn nicht in eine Technologie investieren, die noch schneller ausl\u00e4uft als die, aus der er kommt.<\/p>\n\n\n\n 1. Footprint-Analyse ohne Hardware\u00e4nderung<\/strong><\/p>\n\n\n\n In vielen Ger\u00e4ten ist die Speicherausstattung historisch gewachsen. Was das System real belegt, hat oft nie jemand gemessen. Wir erfassen RSS und PSS je Prozess, Page Cache, Fragmentierung \u00fcber Laufzeit und das Peak-Verhalten unter Last. Ergebnis ist eine belastbare Aussage, ob Ihr Produkt mit der halben Speichergr\u00f6\u00dfe l\u00e4uft. Falls ja, ist die n\u00e4chste Serie eine Best\u00fcckungsvariante und keine Neuentwicklung. Das ist der g\u00fcnstigste Hebel und wird am h\u00e4ufigsten \u00fcbersehen.<\/p>\n\n\n\n 2. Linux gezielt verschlanken<\/strong><\/p>\n\n\n\n Bleibt Linux gesetzt, l\u00e4sst sich der Fu\u00dfabdruck ohne Architektur\u00e4nderung deutlich reduzieren: zugeschnittenes Buildroot- oder Yocto-Image statt Distributionsbasis, musl statt glibc, Kernel-Konfiguration entlang der tats\u00e4chlichen Hardware, Read-only Root-Dateisystem als SquashFS, LVGL statt Qt bei \u00fcberschaubarer HMI, Abl\u00f6sung von Skriptsprachen in Dauerl\u00e4ufern. Realistisch sind Reduktionen um den Faktor zwei bis vier gegen\u00fcber einem gewachsenen Standardimage.<\/p>\n\n\n\n 3. Wechsel auf Zephyr oder ein klassisches RTOS<\/strong><\/p>\n\n\n\n Der gr\u00f6\u00dfte Sprung entsteht, wenn der MMU-basierte Linux-Ansatz entf\u00e4llt. Zephyr allokiert statisch zur Compilezeit und l\u00e4uft auf Cortex-M und Cortex-R. Vernetzte Anwendungen mit TCP\/IP, TLS, Dateisystem und Firmwareupdate bewegen sich je nach Umfang bei 64 bis 256 KB RAM. Damit verschwindet der externe DRAM h\u00e4ufig vollst\u00e4ndig aus der St\u00fcckliste.<\/p>\n\n\n\n Das passt gut bei klar umrissener Ger\u00e4tefunktion und schlecht, wenn Kamerabilder verarbeitet, gro\u00dfe Datenmengen gepuffert oder Applikationen von Dritten nachgeladen werden. Als Zwischenweg l\u00e4sst sich bei heterogenen SoCs wie i.MX 8M oder AM62 der zeitkritische Teil auf einen Cortex-M-Kern verlagern.<\/p>\n\n\n\n 4. Andere Speichertechnologie statt anderer Speichergr\u00f6\u00dfe<\/strong><\/p>\n\n\n\n Steht ein Redesign ohnehin an, lohnt der Blick \u00fcber DDR hinaus: Mikrocontroller mit gro\u00dfem internem SRAM, PSRAM oder HyperRAM am Octo-SPI-Interface ohne Hochgeschwindigkeits-Routing, LPDDR4 mit Mobilvolumen im R\u00fccken, Execute in Place aus NOR-Flash. Was dabei zu beachten ist: NAND und eMMC stehen unter demselben Druck, wer RAM in Flash auslagert, verschiebt das Problem unter Umst\u00e4nden nur.<\/p>\n\n\n\n 5. Second Source und DDR-Bring-up<\/strong><\/p>\n\n\n\n Manchmal ist der Weg ein anderer DRAM-Baustein desselben Standards. Das klingt nach Einkauf, ist aber Ingenieursarbeit: neue Timing-Parameter im SPL, neue Kalibrierung von Write Leveling und Read Gate, angepasste Terminierung, danach Stresstests \u00fcber den vollen Temperaturbereich und Betrachtung der Signalintegrit\u00e4t. Bei neuen Designs sehen wir von vornherein mehrere qualifizierte Quellen vor und bauen die Bootloader-Konfiguration so auf, dass sie die Speichervariante zur Laufzeit erkennt.<\/p>\n\n\n\n Speicher zu sparen kollidiert mit einer zweiten Entwicklung. Der Cyber Resilience Act verlangt sichere Update-Mechanismen \u00fcber den gesamten Supportzeitraum, in der Praxis also A\/B-Partitionierung, signierte Images und die F\u00e4higkeit, in einigen Jahren noch Patches einzuspielen, die gr\u00f6\u00dfer sind als das heutige Image.<\/p>\n\n\n\n Ein System, das exakt auf den heutigen Bedarf dimensioniert ist, kann diese Anforderung in drei Jahren nicht mehr erf\u00fcllen. Wir planen deshalb bei jeder Verkleinerung eine benannte Reserve f\u00fcr Update-Mechanismus und Sicherheitsfunktionen ein und dokumentieren diese Entscheidung, statt sie implizit wegzuoptimieren.<\/p>\n\n\n\n Mehr zum Cyber Resilience Act<\/strong><\/a><\/p>\n\n\n\n Welcher Weg f\u00fcr Ihr Produkt passt, l\u00e4sst sich aus der Ferne nicht seri\u00f6s beantworten. Das h\u00e4ngt an St\u00fcckzahl, Restlaufzeit, vorhandenem Applikationscode, Zertifizierungsstand und daran, wie viel Reserve Ihre Hardware noch hergibt. Deshalb steht am Anfang ein Gespr\u00e4ch mit unseren Entwicklern und keine Angebotskalkulation.<\/p>\n\n\n\n In diesem Erstgespr\u00e4ch kl\u00e4ren wir die Fragen, die den Rahmen setzen: Welche Funktionen muss Ihr Ger\u00e4t wirklich erf\u00fcllen, und welche sind historisch mitgewachsen? Wo liegen harte Anforderungen an Echtzeit, Kommunikation, Bedienoberfl\u00e4che und Update-F\u00e4higkeit? Wie sieht der Lebenszyklus aus, und wann steht die n\u00e4chste Serie an? Welche Bauteile sind konkret betroffen? Das ist meist in ein bis zwei Stunden zu machen.<\/p>\n\n\n\n Daraus entsteht eine erste Anforderungsanalyse. Sie ordnet die tats\u00e4chlichen technischen Anforderungen dem realen Ressourcenbedarf zu und benennt, welcher Weg in Frage kommt, mit welchem Aufwand und mit welcher Wirkung auf die St\u00fcckliste. Sie enth\u00e4lt auch die F\u00e4lle, in denen sich Handeln nicht lohnt.<\/p>\n\n\n\n Wir arbeiten an beiden Enden dieser Kette, an Embedded-Linux-Systemen ebenso wie an ressourcenbeschr\u00e4nkter Firmware, und wir kennen die Hardwareseite bis zum DDR-Layout und zur Signalintegrit\u00e4t. Das ist die Kombination, die dieses Thema braucht, weil Speichereinsparung selten rein softwareseitig und selten rein hardwareseitig funktioniert.<\/p>\n\n\n\n Was wir nicht leisten: Wir beschaffen keine Bauteile und beeinflussen keine Marktpreise. Auch die beste Optimierung ersetzt keine vorausschauende Allokation. Und wo ein Redesign technisch nicht sinnvoll ist, sagen wir das im Erstgespr\u00e4ch und nicht erst im Projekt.<\/p>\n\n\n\n Erstgespr\u00e4ch vereinbaren<\/a><\/strong><\/p>\n\n\n\n Sehen Sie auch:<\/p>\n\n\n\n
\n\n\n\nDie Lage in Zahlen<\/h2>\n\n\n\n
\n
\n\n\n\nWarum „wir nehmen einfach DDR3“ selten tr\u00e4gt<\/h2>\n\n\n\n
\n\n\n\nF\u00fcnf Wege, den Speicherbedarf zu senken<\/h2>\n\n\n\n
\n\n\n\nDer Konflikt mit dem Cyber Resilience Act<\/h2>\n\n\n\n
\n\n\n\nDer erste Schritt: reden, dann rechnen<\/h2>\n\n\n\n