Embedded-Softwareentwicklung: Stack, Prozess und Kosten

Zwei Ingenieure, denen Sie vertrauen, geben Ihnen im selben Meeting gegensätzliche Antworten. Der eine will FreeRTOS auf dem vorhandenen Mikrocontroller und sagt, das Produkt werde in der halben Zeit ausgeliefert. Der andere will embedded Linux, argumentiert, dass die Konnektivitäts-Roadmap dies unvermeidlich mache, und sagt, es später zu tun werde mehr kosten als es jetzt zu tun. Beide haben in gewisser Hinsicht recht. Niemand im Raum kann den Unterschied beziffern, und die Entscheidung wird auf das nächste Meeting vertagt, wo sie nicht leichter sein wird.

Diese Entscheidung ist diejenige, die leise die Kosten, den Zeitplan und den Wartungsaufwand des gesamten Produkts festlegt. Sie wird früh getroffen, auf Basis unvollständiger Informationen, von Menschen, die nicht diejenigen sein werden, die im vierten Jahr damit leben müssen. Sie richtig zu treffen hängt weniger davon ab, die Optionen zu kennen – die meisten Teams kennen sie –, als vielmehr davon, zu wissen, welche vier oder fünf Fakten über das eigene Produkt sie tatsächlich bestimmen.

Dieser Artikel deckt den Bereich zwischen der Idee und der engeren Auswahl ab: was Entwicklung eingebetteter Software behandelt, wie die Stack-Auswahl getroffen wird, wie der Lieferprozess Schritt für Schritt aussieht, wo die Arbeit schiefläuft und was die Zahl im Angebot bestimmt. Wenn Sie bereits wissen, wie die Software gebaut werden soll, und gerade herausfinden, wer sie bauen soll, vergleicht die Top-Unternehmen für die Entwicklung eingebetteter Software Zusammenstellung elf Firmen anhand veröffentlichter, überprüfbarer Leistungsfähigkeit.

Was ist eingebettete Software?

Embedded-Software ist Software, die auf einem Gerät läuft, um dieses Gerät seine Aufgabe erfüllen zu lassen, statt auf einem Allzweckcomputer, um auszuführen, was auch immer der Benutzer öffnet. Sie befindet sich auf dem Prozessor im Inneren des Produkts – einem Mikrocontroller in einem Sensor, einem System-on-Chip in einer Fahrzeug-Haupteinheit, einem kleinen Anwendungsprozessor in einem industriellen Gateway – und sie ist für diese spezifische Hardware geschrieben, mit einem festen Speicherbudget und in der Regel mit Fristen, die sie in jedem Zyklus einhalten muss.

In der Praxis umfasst der Begriff ein viel breiteres Spektrum an Tätigkeiten als „Code für einen Chip schreiben“. Ein einzelnes Produkt kann die Initialisierung der Hardware beim Einschalten, das Schreiben von Treibern, damit der Prozessor mit seinen Sensoren und Funkmodulen kommunizieren kann, die Integration oder Konfiguration eines Betriebssystems, den Aufbau der Anwendungslogik, die Implementierung eines Kommunikationsstacks und die Konstruktion eines Mechanismus umfassen, um all dies noch Jahre später im Feld zu aktualisieren. Das sind unterschiedliche Disziplinen mit unterschiedlichen Spezialisten dahinter, weshalb Softwareteams für eingebettete Systeme anders aussehen als Anwendungsteams.

Was das Schreiben von Software für eingebettete Systeme schwierig macht, ist die Tatsache, dass die Einschränkungen physischer Natur und nicht verhandelbar sind. Einem Anwendungsserver unter Last kann mehr Speicher zugewiesen werden. Einem batteriebetriebenen Sensor nicht, und ebenso wenig einer Regelschleife, die 200 Mikrosekunden Zeit hat, um zu reagieren. Jede Designentscheidung in der Arbeit mit eingebetteten Systemen wird gegen eine Obergrenze getroffen, die jemand anderes festgelegt hat, und die meisten der interessanten Fehler sind Timing-Fehler, die nur dann auftreten, wenn die Hardware warm ist, der Bus ausgelastet ist oder die Batterie schwach ist.

Embedded Software vs. Firmware

Die Unterscheidung, nach der die Leute am häufigsten fragen, ist eingebettete Software vs Firmware, und die ehrliche Antwort lautet, dass es davon abhängt, wie groß das Produkt ist.

Firmware ist die Schicht, die der Hardware am nächsten liegt: der Bootloader, die Low-Level-Initialisierung, die vor allem anderen ausgeführt wird, und der Code, der Peripheriegeräte direkt ansteuert. Sie befindet sich typischerweise im nichtflüchtigen Speicher des Geräts und wird als komplettes Image aktualisiert und nicht als einzelne Komponenten.

Eingebettete Software ist der Oberbegriff. Er umfasst die Firmware und alles darüber, was noch auf dem Gerät läuft – ein RTOS oder ein eingebettetes Linux-System, Middleware, die Anwendungslogik und jede Schnittstelle, mit der der Benutzer in Berührung kommt.

Bei einem kleinen Mikrocontroller-Produkt gibt es nichts oberhalb der Firmware-Schicht, sodass die beiden Begriffe dasselbe beschreiben, und über sie zu streiten ist Zeitverschwendung. Der Unterschied zwischen Firmware und eingebetteter Software beginnt eine Rolle zu spielen, sobald ein Produkt ein Betriebssystem in der Mitte hat, denn dann gibt es Komponenten mit separaten Release-Zyklen, separaten Update-Mechanismen und separater Zuständigkeit – und ein Gespräch über das „Aktualisieren der Firmware“ wird tatsächlich mehrdeutig.

Eingebettete Software-Beispiele branchenübergreifend

Die nützlichen Beispiele für eingebettete Software sind diejenigen, die zeigen, wie unterschiedlich sich dieselbe Disziplin unter verschiedenen Einschränkungen verhält:

• Automotive. Engine and body control units running AUTOSAR-based software under functional safety requirements, alongside infotainment systems that are effectively Linux computers with a hard boot-time target.
• Medizinprodukte. Infusionspumpen, Patientenmonitore und Diagnosegeräte, bei denen der Software-Lebenszyklus selbst reguliert ist und jede Anforderung auf einen Test zurückführbar sein muss.
• Industriell. SPS, Motorsteuerungen und Maschinensicherheitssysteme, bei denen eine verpasste Frist ein physisches Ereignis ist und kein verlorenes Bild.
• Energie und Versorgung. Intelligente Zähler und Ladepunkte, bei denen die Einschränkung ein Jahrzehnt Feldlebensdauer für Hardware ist, die sicher und aus der Ferne aktualisierbar bleiben muss.
• Verbraucher. Wearables, Haushaltsgeräte und Audiogeräte, bei denen die bindenden Einschränkungen die Stückkosten, die Leistungsaufnahme und das Produktionsvolumen sind.

Warum die Entwicklung eingebetteter Software heute schwieriger ist

Zwei Dinge haben sich gleichzeitig geändert, und sie verstärken sich gegenseitig:

1. Der Produktwert ist in die Software gewandert. Die Hardware-Leistungsfähigkeit hat sich über die meisten Kategorien hinweg angenähert: Vergleichbare Silizium-Chips sind für jeden verfügbar, und der Unterschied zwischen zwei konkurrierenden Geräten liegt zunehmend darin, was die Software damit macht und wie lange sich das Produkt nach dem Kauf weiter verbessert. Das erhöht die Anforderungen daran, was Embedded-Teams liefern sollen — Konnektivität, Ferndiagnose, geräteinterne Intelligenz, Funktionsupdates für eine installierte Basis — auf denselben Prozessoren und mit denselben Energiebudgets wie zuvor.
2. Sicherheit wurde zu einer Voraussetzung für den Marktzugang. Aktualisierungsfähigkeit und der Umgang mit Schwachstellen waren früher technische Präferenzen. Nach dem EU-Cyberresilienzgesetz sind sie Verkaufsbedingungen: Secure Boot, Image-Signierung, ein funktionierender Over-the-Air-Pfad und ein Schwachstellenprozess werden nun zu Beginn eines Programms festgelegt, statt im zweiten Jahr von demjenigen nachgerüstet zu werden, der gerade Kapazität hat. Die drei Termine, die den Zeitplan bestimmen, und was jede Verpflichtung mit einer Firmware-Codebasis macht, sind dargelegt in den Anforderungen des Cyberresilienzgesetzes für Firmware-Teams. Sie nachzurüsten ist möglich, und es gehört durchgängig zu den teuersten Aufgaben, die einem Hardware-Team gestellt werden können.

Die sich summierenden Kosten des Stillstands sind eine einfache Rechenaufgabe. Ein Produkt, das ohne zuverlässigen Update-Pfad ausgeliefert wird, ist eine Flotte, die Sie nicht patchen können, und jede verkaufte Einheit vergrößert das Problem nur. Das macht ein komplettes Neuschreiben nicht zur richtigen Antwort – die meisten Produkte brauchen keines –, aber es verschiebt die Update-Architektur von der „Später“-Liste auf die „Vor der ersten Auslieferung“-Liste.

Bare Metal, RTOS oder Embedded Linux: Die drei Optionen

Geordnet nach Grad der Veränderung und Kosten:

1. Bare Metal. Kein Betriebssystem. Ihr Code läuft in einer Hauptschleife mit Interrupt-Handlern, und Sie steuern genau, was wann passiert. Kleinster Speicherbedarf, engste Timing-Kontrolle, geringster Overhead und die höchsten Kosten für das spätere Hinzufügen von Nebenläufigkeit.
2. Ein RTOS — FreeRTOS, Zephyr, ThreadX und andere. Ein Scheduler, Tasks und Synchronisationsprimitive auf einem Mikrocontroller. Man zahlt einen moderaten Preis an Speicher und Komplexität und erhält strukturierte Nebenläufigkeit, weshalb dies die Standardwahl für vernetzte Produkte ist, bei denen mehrere Dinge gleichzeitig passieren.
3. Embedded Linux. Ein vollständiges Betriebssystem mit einem Dateisystem, einem Netzwerkstack, Paketverwaltung und einem Grafikstack, das über ein Board-Support-Paket und üblicherweise ein Yocto- oder Buildroot-basiertes Image für Ihre Platine erstellt wird. Es benötigt einen Anwendungsprozessor und nennenswerten Arbeitsspeicher und bietet eine große Angriffsfläche für Konfiguration, Absicherung und Wartung — im Gegenzug für Fähigkeiten, deren Entwicklung andernfalls Jahre dauern würde. Die Softwareentwicklung für Embedded Linux ist zudem die Option mit der längsten Anlaufzeit, da das BSP vorhanden sein muss, bevor mit der Anwendungsentwicklung begonnen werden kann.

Echte Produkte kombinieren sie. Ein Fahrzeug-Kombiinstrument kann für die Anzeige ein eingebettetes Linux ausführen, während ein separater Mikrocontroller sicherheitsrelevante Funktionen bare metal ausführt, mit einer definierten Schnittstelle zwischen beiden. Ein Industrie-Gateway kombiniert häufig einen Linux-Anwendungsprozessor mit einem RTOS-basierten Echtzeit-Coprozessor. Die Aufteilung ist eine eigenständige Designentscheidung und oft ein besserer Ansatz, als einen einzigen Stack zu zwingen, beide Aufgaben zu erledigen.

Wie die Wahl tatsächlich getroffen wird

Vier Eingaben entscheiden darüber, und keine davon ist Präferenz:

• Worst-Case-Timing. Nicht die durchschnittliche Latenz — die Frist, die Sie niemals verpassen dürfen, und was physisch passiert, wenn Sie es doch tun.
• Speicher- und Leistungsbudget. Wie viel RAM und Flash der gewählte Baustein hat und was das Energiebudget einem inaktiven Scheduler zu verbrauchen erlaubt.
• Nebenläufigkeit und Konnektivität. Wie viele unabhängige Dinge gleichzeitig geschehen und wie umfangreich die Anforderungen an Vernetzung und Aktualisierung sind.
• Wer es pflegt. Ein dreiköpfiges Team, das im fünften Jahr eine Bare-Metal-Codebasis über vier Produktvarianten hinweg pflegt, ist ein realer Kostenfaktor, und es ist die Eingabegröße, die bei der Entscheidung am häufigsten außer Acht gelassen wird.

Dokumentieren Sie die Antwort und die Begründung gemeinsam. Die Entscheidung ist günstig zu treffen und teuer zu revidieren, und in drei Jahren ist es die Begründung, die dem nächsten Team sagt, ob die Einschränkung, die sie bestimmt hat, noch gilt.

Der Prozess der Embedded-Softwareentwicklung, Schritt für Schritt

Die folgende Abfolge zeigt, wie ein gut geführter Entwicklung eingebetteter Software Prozess aussieht. Jeder Schritt existiert, um ein bestimmtes Risiko zu verringern, und wenn man einen auslässt, verschiebt sich dieses Risiko nach hinten, wo es mehr kostet.

1. Bewertung von Hardware und Einschränkungen. Erfassen Sie den Prozessor, die Peripheriegeräte, die Timing-Anforderungen, das Leistungsbudget und die Integrationsabhängigkeiten, bevor irgendein Code geschrieben wird. Der Vorteil daran ist, dass Einschränkungen bereits in der Planung zutage treten und nicht erst mitten in der Entwicklung, wenn ein Kurswechsel einen Hardwarewechsel bedeutet.

2. Architektur- und Stack-Entscheidung. Wählen Sie Bare Metal, RTOS oder Linux anhand der vier oben genannten Eingaben, definieren Sie die Grenzen der Hardware-Abstraktion und legen Sie die Update- und Sicherheitsarchitektur jetzt fest, anstatt erst nachdem die Anwendung funktioniert. Geprüft und dokumentiert, ist dies das Artefakt, an dem der gesamte Aufbau gemessen wird.

3. Board-Inbetriebnahme und BSP. Bringen Sie das Board zum Booten, initialisieren Sie den Taktbaum und die Peripheriegeräte und erstellen Sie ein Board Support Package, auf dem die restliche Software aufgebaut werden kann. Auf einem Custom-Board der ersten Generation findet dieser Schritt auch die Hardware-Errata, wofür er genau gedacht ist.

4. Treiber- und Firmware-Entwicklung. Peripherietreiber, der Kommunikationsstack und die Anwendungslogik, aufgebaut anhand der in Schritt zwei festgelegten Abstraktionsgrenzen. Bei einem Automotive-Mensch-Maschine-Schnittstellenprojekt, das wir in C++, QML und Qt über CAN geliefert haben, wurden hier die mehrsprachige Unterstützung und eine Valet-Modus-Sicherheitsfunktion als trennbare Komponenten entwickelt, statt als Funktionen, die mit der Schnittstelle verflochten sind — weshalb das Hinzufügen der nächsten günstig blieb.

5. Verifizierung auf der Zielhardware. Unit-Tests, Hardware-in-the-Loop-Validierung und Randbedingungsanalysen laufen parallel zur Entwicklung und nicht als Phase am Ende. Dies ist der Schritt, der darüber entscheidet, ob das Produkt außerhalb des Labors funktioniert, und es ist derjenige, der am häufigsten komprimiert wird, wenn ein Zeitplan ins Rutschen gerät.

6. Produktionsübergang und Feldunterstützung. Produktions-Firmware-Varianten, Konfiguration der Geräteprogrammierung, Fertigungsprüfvorrichtungen und ein definiertes Überwachungsfenster nach der Bereitstellung. Produkte begegnen ihren realen Bedingungen erst nach der Auslieferung, und der Plan muss das überstehen.

Embedded Software Development Services

Herausforderungen, die in der Softwareentwicklung für eingebettete Systeme eine Planung wert sind

1. Hardware-Bereitschaft. Verspätete Platinen, Errata der ersten Fertigung und gemeinsam genutzte Prototyp-Hardware machen Software-Zeitpläne ungültig, unabhängig von der Qualität der Schätzungen. Planen Sie eine gestaffelte Hardware-Verfügbarkeit ein, sorgen Sie frühzeitig für eine Emulation oder ein Entwicklungsboard und formulieren Sie die Annahme ausdrücklich, damit jeder erkennen kann, wann sie nicht mehr zutrifft.
2. Timing-Fehler, die nur unter Last auftreten. Race Conditions, Prioritätsinversion und Interrupt-Latenzprobleme sind unter gutartigen Bedingungen häufig unsichtbar und nur dann reproduzierbar, wenn die Platine warm und der Bus ausgelastet ist. Hardware-in-the-Loop-Prüfstände und lang laufende Dauertests sind es, die sie aufspüren; Code-Reviews allein tun das nicht.
3. Toolchain und Reproduzierbarkeit von Builds. Embedded-Builds hängen von bestimmten Compiler-Versionen, Linker-Skripten und Hersteller-SDKs ab, und ein Build, der nur auf dem Rechner eines Ingenieurs funktioniert, ist ein Risiko, das im ungünstigsten Moment zutage tritt. Fixieren Sie die Toolchain, integrieren Sie sie in CI und behandeln Sie die Build-Umgebung als lieferbares Ergebnis.
4. Zertifizierungsumfang zu spät erkannt. Anforderungsrückverfolgbarkeit, dokumentierte Verifizierung und Designhistorie sind unter IEC 62304 oder ISO 26262 keine Papierarbeit, die am Ende hinzugefügt wird – sie verändern, wie Anforderungen und Tests vom ersten Tag an verwaltet werden. Dies im fünften Monat zu entdecken, ist eine der teuersten Entdeckungen, die es gibt.
5. Der Aktualisierungspfad als nachträglicher Gedanke. Sicheres Booten, Image-Signierung, Rollback-Verhalten und was passiert, wenn ein Over-the-Air-Update auf halbem Weg fehlschlägt, sind Architektur, keine Funktionen. Sie nachträglich in eine ausgelieferte Flotte einzubauen ist möglich, und es ist niemals günstig.
6. Wissen, das mit den Menschen verschwindet. Eingebettete Codebasen sind dicht, hardwarespezifisch und häufig unzureichend dokumentiert, und die ursprünglichen Autoren ziehen weiter. Dokumentierte Abstraktionsgrenzen und eine übertragbare Build-Umgebung sind das, was das Produkt wartbar hält, weshalb sie in das Leistungsverzeichnis gehören.

Embedded-Software-Entwicklungstools und wo KI hilft

Die Werkzeugkategorien sind stabil, und die spezifischen Namen sind weniger wichtig als die Abdeckung jeder Kategorie:

• Toolchains und IDEs — Hersteller- und offene Toolchains, Cross-Compiler und das Hersteller-SDK für die gewählte Silizium-Familie.
• Build-Systeme — Yocto oder Buildroot für Linux-Images, CMake und Abhängigkeitsverwaltung für Firmware.
• Debuggen und Tracen — JTAG- und SWD-Sonden, On-Target-Debugger, Logikanalysatoren und Oszilloskope. Die letzten beiden sind nach wie vor der Ort, an dem schwierige Timing-Probleme gelöst werden.
• RTOS und Middleware — der Scheduler und die darauf aufbauenden Komponenten für Kommunikation, Speicherung und Sicherheit.
• Testinfrastruktur — Unit-Test-Frameworks, Hardware-in-the-Loop-Prüfstände, statische Analyse und CI-Runner mit angeschlossenen echten Boards.
• Sicherheitstools — Signierinfrastruktur, CVE-Überwachung anhand Ihres Abhängigkeitssatzes und SBOM-Generierung.

KI ist in einem Teil dieser Liste wirklich nützlich geworden. In unserem eigenen KI-gestützte Entwicklung Modell erzeugen Agenten Boilerplate-Code für Treiber und Peripheriegeräte, erweitern die Testabdeckung im Hinblick auf Randbedingungen und halten die Dokumentation parallel zum Code aktuell — Arbeit, die real und repetitiv ist und zuvor Wochen in Anspruch nahm. Bei einem Fertigungsbetriebs-Projekt, das von einem KI-Pod umgesetzt wurde, lieferte dieses Modell ein MVP 63 % schneller mit einem 56 % kleineren Lieferteam als bei einem herkömmlichen Projekt gleichen Umfangs.

SAP‑Integrated Manufacturing App Built by an AI Pod

63% faster MVP delivery

56% smaller delivery team

See Our Work

Was es nicht komprimiert, ist der Teil, der Urteilsvermögen erfordert. Architekturentscheidungen, Worst-Case-Timing-Analysen, das Lesen einer Oszilloskop-Aufzeichnung, um herauszufinden, warum ein Bus auf einer warmen Platine Störimpulse zeigt, und die Entscheidung, ob ein Fehlermodus akzeptabel ist, sind nach wie vor Ingenieurarbeit, und das Ergebnis eines Agenten, das nicht von jemandem überprüft wurde, der diese Dinge beherrscht, ist plausible Firmware, was schlimmer ist als offensichtlich fehlerhafte Firmware. Die nützliche Frage zu KI in der Embedded-Arbeit ist nicht, ob ein Team sie einsetzt – die meisten tun es inzwischen – sondern wer für das, was sie produziert, verantwortlich ist.

Wie die Entwicklung eingebetteter Software in der Praxis aussieht

Eingebettete Arbeit wird daran gemessen, was nach dem ersten Release passiert, wenn das zweite und dritte Feature eintreffen und die früh gezogenen Grenzen entweder halten oder anfangen, Miete zu verlangen.

Ein Automobilzulieferer musste HMI-Funktionen schneller ausliefern, als es sein Release-Zyklus erlaubte. Hybrid- und Elektrofahrzeugprogramme fügten ständig neue Schnittstellenanforderungen hinzu — Text-to-Speech, Parkmodus, Handy-Projektion, Konfiguration am Bandende — und jede einzelne kam als Änderung an einer eng gekoppelten Schnittstelle, sodass jede mehr kostete als die vorherige. Ein fünfköpfiges Ingenieurteam, das mit C++, QML, Qt und Python über CAN, Wayland und CommonAPI arbeitete, baute die Funktionen als trennbare Komponenten gegen saubere Grenzen neu auf. Die Funktionsbereitstellung lief 2x schneller, die Nutzung des Freisprechsystems stieg um 30%, und die Schnittstelle wurde in 8 Sprachen.

Human‑machine integration project

2x faster feature deployment

30% increase in hands-free system usage

Read a case study

Der Erfolg entstand durch Struktur statt durch Cleverness. Als separierbare Komponenten entlang klarer Grenzen neu aufgebaut, hörten die Funktionen auf, miteinander zu konkurrieren, und die Bereitstellungsgeschwindigkeit, die Nutzungszahlen und die Lokalisierung ergaben sich alle daraus. Die früh festgelegten Grenzen sind es, die die Kosten jeder späteren Änderung bestimmen.

Trends in der Softwareentwicklung für eingebettete Systeme

Speichersichere Sprachen halten Einzug in die Produktions-Firmware. Rust hat sich in der Automobil- und Industriearbeit vom Argument zum ausgelieferten Code entwickelt, einschließlich der Migration zeitkritischer Komponenten in bestehenden AUTOSAR-Umgebungen — die Entwicklung eingebetteter Automobilsoftware ist der Bereich, in dem der Druck zur Speichersicherheit zuerst auftrat und in dem die Werkzeuge gereift sind, um ihm gerecht zu werden. Es ersetzt nicht C, und ausgereifte C-Codebasen rechtfertigen selten eine Neuentwicklung — aber für neue sicherheitsrelevante Komponenten hat sich die Rechnung geändert.

Intelligenz verlagert sich auf das Gerät. Inferenz am Edge ist jetzt auf Bauteilen möglich, die dies vor einigen Jahren nicht unterstützt hätten, was das Designproblem von der Modellgenauigkeit hin zu Leistung, Speicher und thermischem Rahmen verschiebt. Die Einschränkung liegt in der Hardware, nicht im Modell, und diese als IoT-Entwicklung Frage statt als Data-Science-Frage zu betrachten, führt zu besseren Antworten.

Softwaredefinierte Produkte ziehen die Architektur in Richtung Aktualisierbarkeit. Die Konsolidierung von Funktionen auf weniger, leistungsfähigere Prozessoren, die Trennung von sicherheitskritischen und funktionsbezogenen Workloads sowie die Auslegung für ein Jahrzehnt an Remote-Updates werden zu Standardannahmen statt zu fortgeschrittener Praxis — angetrieben ebenso sehr durch Regulierung wie durch Produktstrategie.

Fazit

Die meisten Embedded-Programme werden durch drei früh festgelegte Dinge bestimmt: den Stack, die Update-Architektur und die Frage, ob die Verifikation durchgehend auf echter Hardware oder nur am Ende stattfindet. Wenn man diese richtig macht, ist der Rest der Arbeit normale Ingenieurstätigkeit. Wenn man sie falsch macht, kann keine noch so große Liefertreue den Zeitplan retten.

Sobald der Ansatz feststeht, bleibt die Frage, wer die Arbeit erledigt – und das ist ein anderer Vergleich, der anhand veröffentlichter Fähigkeiten und nicht anhand von Absichten angestellt wird. Die führende Unternehmen für Embedded-Softwareentwicklung Übersicht ordnet elf Unternehmen in die drei Kategorien ein, die diesen Markt bedienen, mit den Kriterien, um sie an Ihre eigene Größenordnung anzupassen.