Embedded-Systeme

Was gehört zur Entwicklung von Embedded-Firmware für Industrieprodukte?

Wir übernehmen die Entwicklung von Embedded-Firmware für die Industrie, kundenspezifische BSPs und die Auswahl industrieller SoCs, für Gerätehersteller, Maschinenbauer und Chiphersteller.

Wir wählen den Chip, entwerfen die Baugruppe und nehmen sie in Betrieb (im Englischen „Bring-up“), schreiben das Board Support Package (BSP) für die Peripherie, die das Referenzdesign nicht abdeckt, und entwickeln die Firmware darauf. Unser Team hat diese Arbeit auf Xilinx Zynq, Altera Cyclone, TI Sitara und Renesas RZ/N ausgeliefert. Typische Ausgangslagen sind:

• Ein Gerät, das es noch nicht gibt. Entwicklung eines kundenspezifischen Geräts von der Chipauswahl über das Leiterplattendesign und die Inbetriebnahme bis zur ausgelieferten Firmware.
• Vorhandene Baugruppen in Betrieb nehmen. Inbetriebnahme und Hardware-Validierung auf vorhandener Hardware, einschließlich der Peripherie, die das Referenzdesign nicht dokumentiert.
• Ein BSP für einen neuen Baustein. Ein kundenspezifisches BSP für ein industrielles SoC, und das ist in der Praxis der größte Teil dessen, was „Linux portieren“ heißt.
• Firmware auf einen neuen Chip bringen. Die Anwendung ist erprobt, und die Plattform darunter hat sich geändert.
• Ein Referenzdesign für einen Chiphersteller. Referenzdesign und BSP, damit ein neuer Baustein mit etwas auf den Markt kommt, auf dem Kunden aufbauen können.
• Die Funktechnik. Industriegeräte mit BLE, Zigbee und WirelessHART, industrielles WLAN, HF-Frontends oder UHF-RFID-Lesegeräte.

Bei vielen Embedded-Projekten entstehen die Probleme unterhalb der Anwendungsschicht: ein Peripheriebaustein ohne Treiber, ein BSP, das bootet, aber Interrupts verliert, oder Firmware, die auf dem Labortisch funktioniert und im warmen Schaltschrank ihre Deadline verpasst. Diese Ebene übernehmen wir:

• Die Chipauswahl, die jede spätere Entscheidung begrenzt.
• Leiterplattendesign und Inbetriebnahme, bis das Software-Team die Hardware als funktionierend voraussetzen kann.
• Das BSP, einschließlich der Peripherie, die ein Referenzdesign weglässt.
• Die Firmware, über Bare Metal, RTOS und Embedded Linux.
• Die Integration der Peripheriebusse I²C, SPI und UART, dazu Speicherschnittstellen, Ethernet-PHYs und schnelle Signale, auf die ein großer Teil der Fehler und Nacharbeiten bei der Inbetriebnahme entfällt.

Die Inbetriebnahme kompletter Maschinen und Anlagen übernehmen wir nicht. Wir entwickeln das Gerät für Ihr Produkt und integrieren und testen es gemeinsam mit Ihren Ingenieuren.

Ein Referenz-BSP bringt die zugehörige Referenzplattform zum Laufen. Ihre Baugruppe hat vielleicht anderen Speicher, eine andere Einschaltreihenfolge, ein anderes Bootmedium und Peripherie, die das Referenzdesign gar nicht vorsieht. Jeder dieser Punkte muss auf Ihrer Hardware in Betrieb genommen und validiert werden, bevor man sich auf die Software darüber verlassen kann.

Die Build-Umgebung übergeben wir zusammen mit dem BSP, denn Industrieprodukte werden meist länger betreut, als die Toolchain lebt, mit der sie gebaut wurden.

Wann reicht Software für Echtzeitanforderungen nicht mehr aus?

Ist die geforderte Reaktionszeit enger, als ein Software-Scheduler sie einhalten kann, gehört der zeitkritische Ablauf in die Hardware.

Hier ist der Jitter wichtiger als der Durchsatz. Auf einem optimierten Echtzeit-Linux mit einem auf Determinismus ausgelegten Treiber liegt die praktische Grenze bei Jitter im Bereich einiger zehn Mikrosekunden, und dort liegt auch der Wert unseres ausgelieferten NIC-Treibers in den Fragen unten. Werden kleinere Jitterwerte gefordert, muss das Timing in die Hardware, und dafür gibt es mehr als einen Weg:

Welcher Weg passt, hängt von Stückzahlen, Protokoll und dem Budget für Timing und Rechenleistung ab. Aus demselben Grund laufen manche unserer Projekte auf hybriden Aufbauten, etwa einem x86-Host mit einem FPGA über PCIe, die als eine Plattform in Betrieb genommen werden.

Auf TI Sitara integriert unser Team die PRU-ICSS-Protokollfirmware von TI mit der Anwendung des Kunden, baut die Schnittstelle zwischen Arm- und PRU-Seite und testet das Zusammenspiel, bis die Fehler, die nur unter echtem Netzverkehr auftreten, eingegrenzt und behoben sind.

Was muss ein Low-Power-Design berücksichtigen?

Ein Low-Power-Design verändert die Architektur und die Bauteilauswahl und betrifft damit weit mehr als den Grad der Optimierung.

Es bestimmt, welche Chips überhaupt in Frage kommen, wie der Funkteil im Tastverhältnis arbeitet, ob ein Peripheriebaustein zwischen zwei Messungen am Bus enumeriert bleiben darf und was die Firmware tun darf, während nichts passiert. Drei Dinge müssen in die Hardware eingeplant werden und lassen sich nicht später ergänzen:

• Abschaltbare Spannungsbereiche, damit sich Peripherie und ganze Teile der Schaltung definiert ab- und wieder einschalten lassen, mit der nötigen Einschaltreihenfolge, dem Einschaltstrom und dem Anlauf der Oszillatoren.
• Eine Zeitbasis im Schlafmodus, meist eine stromsparende Echtzeituhr oder ein eigener, immer aktiver Timer-Bereich, weil der Hauptoszillator im Tiefschlaf in der Regel abgeschaltet ist.
• Reserve für Spitzenströme, weil eine schwächer werdende Batterie die Baugruppe im Ruhezustand noch versorgt und dann einbricht, wenn Funkteil oder Aktor ihren Spitzenstrom ziehen. Lokale Pufferkapazität oder ein gestaffeltes Einschalten fangen diese Spitze ab, damit eine kritische Funktion nicht als erste ausfällt.

Eine kleine Bauform verschärft dieselben Zusammenhänge noch einmal, weil bei dieser Größe wenig thermische Reserve bleibt. Beide Anforderungen bestimmen die Bausteinauswahl und die Schaltungstopologie.

Welche Komponenten eines Messumformers entwickeln Sie?

Wir entwickeln das Gerät selbst: die Baugruppe, das Sensor-Frontend, die Firmware, das Gehäuse und das Energiebudget.

Ein Messumformer-Projekt teilt sich in drei Bereiche, und die meisten brauchen mindestens zwei davon. Sein Kommunikationsstack gehört zu Feldbus und Gerätenetzen, und die Steuerungsanwendung, die den Messwert nutzt und darauf reagiert, zur Steuerungssoftware.