Wichtige Überlegungen zum Master-Slave-Kommunikationsmodell Ihres Embedded Systems

Es kann einige Zeit dauern, bis ein funktionsfähiger Prototyp eines eingebetteten Systems konstruiert ist. Manchmal habe ich sogar tagelang an einem einzelnen Teil des Projektes gearbeitet. Wenn Ihr Chef jedoch jeden Tag nach Aktualisierungen verlangt, kann dies besonders ablenkend sein und Ihre Produktivität beeinträchtigen. Als ich meine Designfirma gründete, lernte ich, diese Fehler in meinem Team nicht zu wiederholen.

Wie bei Menschen, gibt es eingebettete Systeme in allen Formen und Größen. Was noch wichtiger ist, es gibt sie mit unterschiedlichen Funktionsweisen und Einsatzmöglichkeiten. Ein eingebettetes System muss nicht nur auf einen weiter oben in der Befehlskette befindlichen Controller reagieren, sondern auch seine eigenen Aufgaben effizient ausführen. Dazu gehören beispielsweise die Überwachung von Eingaben sowie die Berechnung und Konvertierung von Werten. Es muss auch zuverlässige Aktualisierungen oder Verarbeitungsbefehle bereitstellen. Wenn ein eingebettetes System jedoch ständig durch Anfragen eines anderen Controllers gestört wird, ist es folglich weniger effizient. In einigen Fällen kann dies sogar dazu führen, dass es ohne Vorwarnung abstürzt.

Wie funktioniert die Kommunikation in Master-Slave-Embedded-Systems

Die einfachste Art für eingebettete Systeme, miteinander zu kommunizieren, ist eine Master-Slave-Struktur. Hierbei wird zunächst ein einzelnes eingebettetes System als Master bestimmt. Dieser ist dafür verantwortlich, die Kommunikation mit den daran angeschlossenen eingebetteten Systemen zu initiieren. Die Master-Slave-Kommunikation hat ein vorhersagbares Muster, mit dem Nachrichten über eine Kommunikationsschnittstelle übertragen werden sollen. Slave-Controller selbst dürfen allerdings keine Datenpakete übertragen - außer sie werden vom Master-Controller dazu aufgefordert.

Eines meiner aktuellen Projekte, bei dem eine Master-Slave-Konfiguration verwendet wurde, ist ein Überwachungssystem für Maschinen zur Gummiherstellung. An jeder Maschine wurde ein Sensor-Monitoring-Controller angebracht, um die Betriebszyklen mit verschiedenen Sensoren zu überwachen. Ein Master-Controller wiederum war an alle Sensor-Controller angeschlossen. Der letztere verwendet non-volatile Memory zum Speichern der gesammelten Daten.

Wichtige Überlegungen zum Entwurf eines Master-Slave Embedded Systems

So einfach es auch zunächst erscheinen mag, wenn die folgenden Designüberlegungen nicht hinreichend beachtet werden, kann dies zu erheblichen Problemen nach der Implementierung führen.

1. Rechenleistung von Mikrocontrollern

Häufig werden Master- und Slave-Controller von Mikrocontrollern mit unterschiedlicher Rechenleistung betrieben. Ein Master-Controller wird zumeist von einem leistungsfähigeren Mikrocontroller betrieben. Slave-Controller führen in der Regel nur ganz spezifische Aufgaben aus, wie zum Beispiel die Überwachung von Sensoreingängen oder die Ansteuerung eines Motors. Deshalb kann es sinnvoll sein, Slave-Controller mit einem Mikrocontroller der mittleren oder unteren Leistungsklasse auszustatten.

Die Slave-Steuerung darf nicht zu häufig mit Anforderungen zur Statusaktualisierung unterbrochen werden - beispielsweise etwa durch Programmierer, die Code für die Master-Steuerung schreiben. Denn Slave-Controller haben nur eine begrenzte Verarbeitungsfähigkeit. Jede derartige Unterbrechung kann den Slave-Controller überfordern. Wenn ein Slave-Controller nicht für die Verarbeitung eines hohen Volumens von Anfragen ausgelegt ist, kann es schnell zu einem Speicher- oder Stapelüberlauf und letztlich sogar Absturz kommen.

Master- und Slave-Controller können mit sehr unterschiedlichen Geschwindigkeiten arbeiten.

2. Begrenzung der Anzahl der Slave-Controller

Theoretisch können Sie Ihren Master-Controller mit so vielen Slave-Controllern verbinden, wie es die Standards für Kommunikationsschnittstellen zulassen. Beispielsweise können bei RS458 bis zu 32 Geräte an eine einzige Verbindung angeschlossen werden. In der Praxis sollten Sie jedoch bedenken, welche Auswirkungen diese Art von Vernetzung auf die Geschwindigkeit der Informationsgewinnung haben kann. Beispielsweise benötigt ein Slave-Controller 10 Millisekunden, um auf eine Anfrage zu antworten. Bei 31 Slave-Controllern dauert es folglich 310 Millisekunden, bis im nächsten Zyklus Aktualisierungen von demselben Controller empfangen werden. Wenn der Master-Controller eine schnellere Aktualisierung von Updates anfordert, sollten Sie also die Anzahl der angeschlossenen Slave-Controller gegenüber eines einzelnen Kanals begrenzen.

3. Design für Redundanz

Konfigurierte eingebettete Systeme werden oft mit einem einzigen Kabel verbunden, das sich von einem Controller zum anderen windet. Diese Multipoint-Verdrahtungsmethode ist zwar einfach und kostengünstig, sie gefährdet aber potenziell das gesamte System. Denn sollte ein Kabel einmal beschädigt sein, beispielsweise zwischen dem fünften und sechsten Slave-Controller, reduziert dies erheblich die Kommunikation des Masters mit den ersten fünf Slave-Controllern.

In kritischen Anwendungen sollten Systementwickler und -designer daher erwägen, als Backup eine redundante Verbindung hinzuzufügen, und zwar innerhalb der Schleife zwischen Master- und letztem Slave-Controller. Sollte der Master-Controller nun eine mögliche Kabelunterbrechung bemerken, kann er diese Backup-Verbindung aktivieren und so die Kommunikation wiederherstellen.

Es zahlt sich aus, in kritischen Anwendungen redundant zu sein.

Unabhängig davon, ob Sie einen Master- oder Slave-Controller entwerfen, die Wahl des richtigen Mikro-Controllers und der zugehörigen Komponenten ist wichtig. PCB-Software wie Altium Designer^® ermöglicht Ihnen Zugang zu Bauteilbibliotheken. Dadurch lassen sich Ihre Prozesse vereinfachen.

Wenn Sie Zweifel an der Implementierung einer Master-Slave-Kommunikation haben, wenden Sie sich gerne an einen Experten von Altium.