Kundenspezifische Systemintegration
Embedded Redesign
Board Support Package für Systemhäuser
Drei Beispielarchitekturen für zeitkritische Funktionen
Je nach Reaktionszeit, Peripherieanbindung und Systemaufbau kommen unterschiedliche Ansätze infrage. Die folgenden Beispiele zeigen, wie sich zeitkritische Funktionen in Embedded-Systemen gezielt von der Hauptlogik trennen lassen.
Interner Mikrocontroller-Kern im SoC
Externer Mikrocontroller über SPI
Dedizierter Controller über USBWarum Echtzeit in Embedded-Systemen eine Architekturfrage ist
Zeitkritische Reaktionen lassen sich nicht allein auf Ebene der allgemeinen Systemsoftware bewerten. Entscheidend ist, welche Signale innerhalb welcher Zeit verarbeitet werden müssen und wie direkt der Reaktionspfad ausgelegt ist.
Hauptsystem mit OS
Das Hauptsystem übernimmt typischerweise Aufgaben wie Kommunikation, Datenverarbeitung, Visualisierung oder übergeordnete Steuerlogik. Dort stehen Funktionsumfang und Integrationsfähigkeit im Vordergrund.
Zeitkritische Auslösung
Endschalter, Überlastsignale, Grenzwertverletzungen, Trigger oder schnelle Eingangssignale erfordern kurze und vorhersagbare Reaktionspfade und profitieren oft von einer hardwarenahen Ausführungsebene.
Architekturentscheidung
Zeitkritische Teilfunktionen werden gezielt auf geeignete Komponenten verlagert. So entstehen klar getrennte Verantwortlichkeiten und robustere Embedded-Systeme.
Für ein belastbares Systemverhalten ist daher nicht nur entscheidend, welche Software läuft, sondern welche Komponente die eigentliche Reaktion übernimmt.
Embedded Echtzeitsystem mit i.MX 8 und internem ARM Cortex-M4
Ein besonders kompakter Weg zur Trennung zeitkritischer Funktionen ist die Aufteilung innerhalb eines heterogenen SoC. In diesem Beispiel übernimmt ein i.MX8 mit integriertem ARM Cortex-M4 die hardwarenahe Reaktionslogik, während die leistungsstärkeren Cortex-A-Kerne parallel komplexe Applikationsfunktionen ausführen.
Vorteile:
- kurze Reaktionswege innerhalb desselben SoC
- Entlastung der Hauptplattform bei zeitkritischen Funktionen
- gut für Low-Power- und Wake-up-Szenarien
Geeignete Aufgaben:
- GPIO-Ereignisse
- Sensorverarbeitung
- Audio-nahe Steuerlogik
- Trigger- und Taktfunktionen
- Low-Power-Monitoring
- Wake-up-Mechanismen
So lassen sich übergeordnete Aufgaben wie Kommunikation, Datenverarbeitung oder Benutzeroberfläche von zeitkritischen Signalen und Reaktionen trennen. Gerade bei kurzen internen Kommunikationswegen und energiebezogenen Anforderungen ist dieser Ansatz besonders interessant.
Warum Sie zeitkritische Funktionen getrennt umsetzen sollten
Nicht in jedem Embedded-System muss die gesamte Software dieselben Anforderungen an Reaktionszeit und Vorhersagbarkeit erfüllen. Häufig ist es sinnvoller, zeitkritische Teilfunktionen gezielt von der Hauptlogik zu trennen, statt das komplette System auf dieselbe Reaktionslogik auszulegen.
Zeitkritische Signale werden dort verarbeitet, wo sie entstehen. Das reduziert unnötige Umwege und schafft besser beherrschbare Reaktionsketten.
Zeitkritische Funktionen laufen auf einer dafür geeigneten Komponente, während das Hauptsystem seine Ressourcen für übergeordnete Aufgaben nutzt.
Klarere Zuständigkeiten erleichtern die Auslegung des Systems und können Low-Power-, Wake-up- oder Peripherieszenarien gezielter unterstützen.
Echtzeitfähige Peripherie über SPI anbinden
Wenn ein Embedded-System um klar definierte zeitkritische Funktionen erweitert werden soll, ist ein externer Mikrocontroller über SPI häufig eine pragmatische Lösung. In dieser Beispiel-Architektur übernimmt ein i.MX6 die Hauptlogik, während ein ATmega als echtzeitnaher Coprozessor hardwarenahe Aufgaben lokal verarbeitet.
Typische Aufgaben des Mikrocontrollers
Ein ATmega kann analoge Sensorik über ADC-Eingänge erfassen, präzise PWM-Signale für Aktoren erzeugen, digitale I/Os überwachen oder als lokale Port-Erweiterung dienen. Auch Encoder-Signale, kleine Displays oder zusätzliche Schnittstellen lassen sich auf diese Weise anbinden.
Technischer Vorteil
Die lokale Verarbeitung reduziert Last auf dem Hauptsystem und ermöglicht kurze Reaktionspfade direkt an der Peripherie. Zeitkritische Signale werden dort verarbeitet, wo sie entstehen, während das Hauptsystem nur die relevanten Informationen oder Sollwerte übergibt.
Hardware-Aspekte
- unterschiedliche Logikpegel zwischen i.MX6 und ATmega
- i.MX6 arbeitet typischerweise mit 1,8 V oder 3,3 V
- ATmega-basierte Systeme häufig mit 5 V
- für die SPI-Kopplung ist eine geeignete Pegelwandlung erforderlich
Success Story: AUG Elektronik GmbH
WEC7-Gesamtsystem mit i.MX6 und SPI-Kopplung stabilisiert
SIGMA Chemnitz hat sehr kompetent und engagiert an der Stabilisierung des Gesamtsystems gearbeitet. Das Produkt ist somit deutlich robuster im Einsatz und die Kundenzufriedenheit wurde gesteigert.
Ing. Gerald Schloffer
Geschäftsführer AUG Elektronik GmbH
Ausgangssituation
Für ein bestehendes Embedded-System unterstützte SIGMA die AUG Elektronik GmbH bei der Stabilisierung und Optimierung des Gesamtsystems. Die Systembasis bestand aus WEC7, kundenspezifischen Treibern und einer Applikation. Im Projekt kam eine zeitkritische SPI-Kopplung zwischen einem ARM NXP i.MX6DL und einem ATmega zum Einsatz.
Technische Herausforderung
Die zentrale Herausforderung lag nicht in einer einzelnen Software-Komponente, sondern im Zusammenspiel der beteiligten Ebenen. Fehlerbilder entstehen in solchen Systemen häufig an den Übergängen zwischen Betriebssystem, Treiberlogik und Anwendung. Entsprechend lag der Fokus auf Timing, der Interaktion der Software-Schichten und der robusten Verarbeitung der Kommunikation über die SPI-Schnittstelle.
Unser Lösungsweg
- Systematische Analyse des Gesamtsystems
- Fokus auf das Zusammenspiel von Betriebssystem, kundenspezifischen Treibern und Applikation
- Untersuchung von Timing und Schichtinteraktion
- Stabilisierung der zeitkritischen SPI-Kopplung zwischen i.MX6DL und ATmega
- Optimierung der robusten Verarbeitung der Kommunikation über die SPI-Schnittstelle
Durch die Stabilisierung des Zusammenspiels von WEC7, kundenspezifischen Treibern, Applikation und SPI-Kommunikation wurde das Gesamtsystem deutlich robuster im Einsatz. Als wichtiges Ergebnis konnte so die Systemzuverlässigkeit verbessert werden. Das wirkte sich wiederum direkt auf die Kundenzufriedenheit aus.
Erfahren Sie im vollständigen Referenzbericht, wie die SIGMA bei einer Stabilisierung eines WEC7 Gesamtsystems mitgewirkt hat.
Download starten
Erfahren Sie im vollständigen Referenzbericht, wie die SIGMA bei einer Stabilisierung eines WEC7 Gesamtsystems mitgewirkt hat.
Download startenWelche Signale und Funktionen häufig getrennt betrachtet werden sollten
Nicht jede Funktion in einem Embedded-System stellt dieselben Anforderungen an Reaktionszeit und Vorhersagbarkeit. Besonders bei sicherheitskritischen Systemen, bei denen Sach- oder Personenwerte gefährdet sein können und wo Signale daher unmittelbar verarbeitet oder Reaktionen ohne unnötige Verzögerung ausgelöst werden müssen, ist eine getrennte Betrachtung von Hauptsystem und Reaktionslogik sinnvoll.
Wenn Zustandsänderungen unmittelbar erkannt und verarbeitet werden müssen, sollte der Reaktionspfad klar und kurz sein.
Bei kritischen Zuständen ist entscheidend, dass Auswertung und Reaktion nicht unnötig durch andere Systemaufgaben verzögert werden.
Schnelle Signale lassen sich lokal oft zuverlässiger erfassen und vorverarbeiten als auf einer stärker belasteten Hauptebene.
Aktoren benötigen häufig reproduzierbare Signalverläufe und definierte Reaktionsmuster.
Auch einfache Eingangssignale können zeitkritische Reaktionsketten auslösen und sollten entsprechend bewertet werden.
Wenn Sensordaten zyklisch, schnell oder vorverarbeitet erfasst werden müssen, kann eine getrennte Hardware-Ebene die Hauptplattform gezielt entlasten.
USB als Brücke zwischen Hauptsystem und zeitkritischem Controller
Neben SPI gibt es einen weiteren belastbaren Weg, um Hauptsystem und zeitkritische Steuerlogik zu kombinieren: die Kopplung eines Applikationsprozessors mit einem dedizierten Controller über USB. Ein Beispiel dafür ist die Verbindung eines i.MX6 mit einem TM4C129 auf Basis eines ARM Cortex-M4.
In dieser Architektur übernimmt der i.MX6 typischerweise die Rolle des USB-Hosts, während der TM4C129 als Device arbeitet. USB 2.0 bildet die standardisierte Kommunikationsbrücke zwischen beiden Rechendomänen. Das ist besonders dann sinnvoll, wenn die Controller-Seite nicht nur einzelne Signale verarbeiten, sondern eine umfangreichere Peripherie- und Steuerlogik abdecken soll.
Der TM4C129 bringt dafür eine breite Schnittstellen- und Peripherieausstattung mit. UART, I2C, SPI, CAN, ADC, PWM, QEI und weitere hardwarenahe Funktionen ermöglichen es, eine eigenständige Echtzeit- und Peripherieebene neben dem Hauptsystem aufzubauen. So können zeitkritische oder peripherienahe Funktionen klar getrennt und robust umgesetzt werden.
- i.MX6 als USB-Host
- TM4C129 als Device
- Hauptsystem für komplexe Systemfunktionen
- Controller für zeitkritische und peripherienahe Aufgaben
- umfangreichere Peripherieanbindung
- zusätzliche Kommunikationsschnittstellen
- klare Trennung zwischen Hauptsystem und Steuerlogik
- Projekte mit eigenständiger Controller-Ebene
Wie wir Echtzeit in Embedded-Systemen architektonisch bewerten
Echtzeit entsteht nicht dadurch, dass ein System pauschal als echtzeitfähig bezeichnet wird. Entscheidend ist, welche Funktionen ein Embedded-System tatsächlich in welcher Zeit verarbeiten, auslösen oder überwachen muss. Wir bewerten Betriebssysteme, Mikrocontroller-basierte Architekturen und dedizierte Controller-Lösungen daher nicht isoliert, sondern immer als Teil einer sauberen Systementscheidung.
Echtzeitanforderungen analysieren
Welche Reaktionszeiten sind tatsächlich kritisch? Wo entstehen Jitter, Interrupt-Last oder unklare Zuständigkeiten?
Aufgaben sauber trennen
Welche Funktionen verbleiben auf Embedded Linux, welche werden auf M4, RTOS-nahe Komponenten oder externe Controller ausgelagert?
Architektur festlegen
Je nach Ziel können vielfältige Kopplungen / Schnittstellen zwischen SoC und echtzeitfähigem Mikrocontroller sinnvoll sein.
Integration umsetzen
Die Qualität entscheidet sich in der Umsetzung. Schnittstellen, Kommunikationslogik, Treiber und hardwarenahe Software müssen konsistent zusammenspielen.
FAQ
Von Echtzeit spricht man dann, wenn nicht nur das korrekte Ergebnis zählt, sondern auch der Zeitpunkt der Reaktion. In Embedded-Systemen betrifft das vor allem Funktionen, die Signale innerhalb klar definierter Zeitgrenzen verarbeiten oder auslösen müssen.
Ein Echtzeitbetriebssystem ist dann sinnvoll, wenn Teilfunktionen mit klar planbarem Laufzeitverhalten, definierter Priorisierung und hoher zeitlicher Vorhersagbarkeit umgesetzt werden müssen. Das gilt vor allem dann, wenn Echtzeitanforderungen nicht nur einzelne I/O-Funktionen betreffen, sondern eine ganze Steuerdomäne prägen.
In vielen Embedded-Systemen ist jedoch nicht das Gesamtsystem in gleichem Maß zeitkritisch. Häufig betrifft der deterministische Teil nur klar abgegrenzte Funktionen. Dann ist eine Architektur mit getrennter Haupt- und Reaktionslogik oft die technisch sauberere und wirtschaftlichere Lösung. Welche Variante sinnvoll ist, hängt von Reaktionszeit, Signalpfad, Peripherie und Systemaufbau ab.
Nicht in jedem Fall. Entscheidend ist, wo die zeitkritische Funktion tatsächlich ausgeführt wird und wie kurz und robust der Reaktionspfad aufgebaut ist. Je nach System kann deshalb zusätzlich eine getrennte Hardware- oder Controller-Ebene sinnvoll sein.
Weil sich übergeordnete Aufgaben wie Kommunikation, Visualisierung oder Datenverarbeitung oft besser von hardwarenahen Reaktionsketten trennen lassen. Dadurch entstehen klarere Zuständigkeiten und besser beherrschbare Signalpfade.
Typische Aufgaben sind GPIO-Ereignisse, Wake-up-Funktionen, Sensorverarbeitung, Trigger- und Taktlogik, PWM, Encoder-Auswertung oder andere hardwarenahe Reaktionsketten.
Ja, sofern die Aufgaben sauber getrennt sind. SPI eignet sich sehr gut, um einen Mikrocontroller als echtzeitnahen Coprozessor an ein Hauptsystem anzubinden. Der Controller übernimmt die lokale Verarbeitung, während das Hauptsystem Steuerwerte oder Ergebnisse austauscht.
USB ist dann interessant, wenn eine standardisierte Verbindung zwischen Hauptsystem und eigenständiger Controller-Domäne benötigt wird. Das gilt vor allem bei umfangreicherer Peripherie, zusätzlichen Schnittstellen oder klar getrennten Steuerfunktionen.
Nicht zwingend. Ein integrierter Mikrocontroller-Kern ist ein möglicher Architekturansatz. Welche Lösung sinnvoll ist, hängt von Reaktionszeit, Peripherie, Energiebedarf, Kommunikationsaufwand und Systemaufbau ab.
Nein. Die gezeigten Beispiele sind mögliche Architekturansätze aus der Praxis. Welche Lösung geeignet ist, hängt immer von der konkreten Anwendung und den technischen Randbedingungen ab.
Lösungen für Ihre Branche und Ihre Prozesse stellen wir Ihnen gerne vor. Sprechen Sie mit den Spezialisten für den Mittelstand.
Jetzt anfragen
