Wenn der Mikroprozessor abgekündigt wird

Retrofit von Hardware

Der bewährte Motorola 68HC12 lief Jahrzehnte in einfachen Industrieanwendungen. Nun ist er nicht mehr erhältlich und ein Ersatz muss her, denn in der Industrie, beispielsweise bei Werkzeugmaschinen, ist die Lebensdauer der Mechanik wesentlich länger als die der Elektronik. Die Kunden erwarten vom Hersteller, dass er Ersatzteile für die Elektronik liefert. Die Hersteller stehen deshalb vor der Frage: Wie ersetzen wir den abgekündigten Prozessor? Dies betrifft nicht nur den 68HC12 resp. 68HC08, sondern diverse Prozessoren wie die 8051 Derivate, den MSP430 oder den C167xR.

Die erste, pragmatische Reaktion von vielen Herstellern ist, den Prozessor und seine Funktion 1:1 mit einem aktuellen, günstigen Mikroprozessor zu ersetzen. Da die Software neu geschrieben und der Elektronikprint neu gelayoutet werden muss, folgen daraus Entwicklungskosten von einigen Hunderttausend Franken – ohne dass die Maschine danach neue Funktionen hätte. Im schlimmsten Fall wird auch der neue Prozessor 5 Jahre später abgekündigt.

System on Module, Minicomputer

System on Module

SCS schlägt deshalb vielen Herstellern vor, bei einem Retrofit nicht 1:1 den Prozessor zu ersetzen, sondern einen Miniaturrechner mit einem Linux-System einzusetzen, womit nicht nur die bestehenden Funktionen umgesetzt werden, sondern durch moderne Kommunikationsschnittstellen auch neue Feature für die Kunden möglich werden.

Solche Systems on Module (SoM) als Miniaturrechner sind weit verbreitet, ein typisches Beispiel ist der Raspberry Pi. Sie werden über standardisierte Schnittstellen auf die Elektronik aufgesteckt. Der Vorteil ist, dass sie bereits diverse Schnittstellen wie USB, Bluetooth, Ethernet und WLAN unterstützen und genug Rechenpower bereitstellen, um komplexere Aufgaben zu übernehmen.

Viele kompatible Alternativen

Dank der weiten Verbreitung von Raspberry Pi haben viele Hersteller schon Alternativen auf den Markt gebracht, die den Formfaktor und die Schnittstellenpositionen kopieren. Sogar der Raspberry Pi eigene Pin Header wird von den Herstellern zu Kompatibilitätszwecken übernommen, so dass man nicht an einen Hersteller gebunden ist. Während manche Hersteller dieser Konkurrenzprodukte sich darauf Konzentrieren, sich mit mehr Rechenleistung (bis zu 8-fach) vom Original abzuheben, setzen andere auf tiefere Preise (bis zu einem Fünftel). Dieser Kampf um Marktanteile hat zur Folge, dass der Endkunde eine breite Auswahl an Modulen hat und bei Lieferengpässen ohne Entwicklungskosten auf andere Module ausweichen kann. Das verringert die Abhängigkeit von spezifischen Lieferanten drastisch.

Das Linux-System läuft auf all diesen Produkten, die Applikation ist auf einer höheren Ebene abstrahiert und muss nicht angepasst werden. Um die physikalischen Schnittstellen kümmert sich das Linux-Betriebssystem.

Kosten überschaubar

Bezüglich Kosten ist ein SoM etwas teurer als ein einzelner Prozessor: Während ein Prozessor vielleicht CHF 8.- pro Stück kostet, sind es bei einem SoM eher CHF 13.-. Auch die Entwicklungskosten sind typischerweise rund 20% teurer. Dafür öffnen sich Möglichkeiten für neue Anwendungen. Maschinen können beispielsweise über einen nahegelegenen PC bedient werden (Ethernet) oder über ein App auf dem Tablet/Handy (Bluetoot, WLAN). Wenn das Display/Touch Panel an der Maschine verkleinert oder weggelassen werden kann, sind die etwas höheren Kosten für das SoM bereits wieder eingespart.

Serielle Schnitttelle RS-232

Retrofit von alten Schnittstellen

Bei Retrofits sind oft alte Schnittstellen eine Herausforderung: Dies können die verbreiteten seriellen und parallelen Schnittstellen sein (RS-232 resp. LPT), aber auch Geräte mit IDE- und ISA-Bus. Linux-Rechner können diese Schnittstellen emulieren, ohne dass ein Entwicklungsaufwand anfällt. Sie sind als Gerätetreiber bereits ins Linux Betriebssystem integriert.

Bei SCS werden auch immer wieder proprietäre Schnittstellen für Retrofits umgesetzt. Manchmal ist dazu ein Reverse Engineering notwendig, wenn die Dokumentation zur Schnittstelle fehlt. Das Umsetzen von solchen Spezialschnittstellen durch Software bringt Vorteile für die Zukunft: Zum einen stellt man die Rückwärtskompatibilität her, zum anderen erleichtert es die Integration von neuen Ideen und Möglichkeiten. Auch das Umsteigen auf neuere Schnittstellen wird stark vereinfacht, ohne die Rückwärtskompatibilität zu gefährden. So ist man nicht durch bestehende, alte Hardware-Schnittstellen eingeschränkt.

Industrie-Roboter

Harte Echtzeit

Es gibt Elektronik, die harte Echtzeit unterstützen und teilweise innerhalb von Mikrosekunden reagieren muss. Dafür ist ein Linux-Betriebssystem zu langsam, auch wenn die Software in „Echtzeit“ ausgeführt wird. Hier empfiehlt SCS, die entsprechenden Funktionen/Maschinenteile zu isolieren und die Echtzeitfähigkeiten von der Businesslogik zu trennen. Auch bei Maschinen, wo dieses Vorgehen nicht möglich scheint, lohnt sich eine genaue Analyse und gezielte Segmentierung der Funktionen. Somit können die Vorteile eines SoMs genutzt werden, während die Teile, die Echtzeitfähigkeiten unbedingt einhalten müssen, von traditionellen Mikroprozessoren abgedeckt werden können.

Dieses Vorgehen bringt auch Vorteile für Weiterentwicklungen: Für diesen abgegrenzten Bereich kann ein viel kleinerer Prozessor eingesetzt werden, wodurch die Produktions- und Entwicklungskosten reduziert werden. Es erhöht zudem die Maschinensicherheit, da der Echtzeitprozessor sich nicht mehr um Businesslogik oder externe Schnittstellen (Bluetooth, Ethernet, usw.) kümmern muss, wie es in traditionellen Designs oft der Fall ist. Und die Safety-Mechanismen können mit wenig Aufwand realisiert werden, ohne dass das SoM dazu genutzt werden muss. Bei einem Stromausfall oder anderen Ereignissen kann es einfach ausgeschaltet werden. Der Echtzeitprozessor, gestützt durch eine kleine Batterie oder Kondensatoren, kontrolliert währenddessen die Maschine weiter, bis sie zum Stillstand kommt.  

Retrofits eröffnen neue Möglichkeiten

Hersteller von Maschinen sollten sich bei einem Retrofit vor Augen halten, dass dies eine Chance ist, den Kunden neue Funktionen zur Verfügung zu stellen. Mit einer soliden Plattform ist man auch für zukünftige Standards/Kundenwünsche gut aufgestellt. Während bei Consumer-Elektronik jeder Rappen zählt, stehen bei den Maschinen die Lebensdauer und die Kundenbeziehung im Vordergrund. Wer beim Retrofit einen veralteten Mikroprozessor durch ein SoM und einem Linux-Betriebssystem ersetzt, hat künftig eine stabile Plattform, die nicht von der Hardware abhängig ist. Das erleichtert nicht nur die Weiterentwicklung der eigenen Produktlinie, sondern erlaubt es einfacher und schneller auf Kundenwünsche einzugehen. Dadurch ermöglichen sich neue Funktionen, an die man heute noch gar nicht denkt.

Ressourcen schonen

Retrofits sind nicht nur wirtschaftlich rentabel, sondern auch eine umweltfreundliche Lösung. Die SCS hat bereits zahlreiche Retrofits erfolgreich umgesetzt, insbesondere bei Ticketautomaten. Für ihre innovative und nachhaltige Herangehensweise wurde sie in den Jahren 2020 und 2023 mit dem Solar Impulse Efficient Solution Label ausgezeichnet.

Lademanagement für Parkanlagen

Projekteinblicke

Elektroautos laden mit bis zu 32 A bzw. 22 kW. In einem Mehrfamilienhaus ist der Hausanschluss typischerweise auf 500 A ausgelegt, wobei 400 A für das Gebäude reserviert sind. Die verbleibenden 100 A für die Ladeinfrastruktur sind bereits bei drei Elektroautos ausgelastet. Da viele Menschen einen ähnlichen Tagesablauf haben, laden sie ihre Fahrzeuge oft gleichzeitig zu Beginn der günstigeren Niedertarifzeiten.

Vorteile eines Lademanagements

Anstatt den teuren Ausbau des Hausanschlusses zu wählen, ist die Implementierung eines Lademanagements eine wirtschaftlichere Option. Die verfügbare Leistungskapazität wird so dynamisch auf die Lasten verteilt. Da ein Elektroauto durchschnittlich nur 8 kWh pro Tag benötigt, können sie reduziert oder abwechselnd laden. Um Ladeverluste zu minimieren, wird auf eine deutliche Reduzierung der Ladeleistung verzichtet und stattdessen früher mit dem abwechselnden Laden begonnen.

Universelles OCPP-Protokoll

Ein universelles und offenes Lademanagementsystem ist erforderlich, wenn unterschiedliche Ladestationen in der Parkanlage genutzt werden. SCS entwickelte zusammen mit EKZ Software für das herstellerunabhängige EKZ-Lademanagement, das auf dem offenen «Open Charge Point Protocol» (OCPP) basiert und von vielen Ladestationstypen unterstützt wird. So bleibt die Lösung zukunftssicher und flexibel erweiterbar, ohne von spezifischen Herstellern abhängig zu sein.

Edge Device mit Algorithmik

Herzstück des Systems ist das Edge Device, ein industrieller Single-Board-Computer, der in der Parkanlage als Gateway zwischen Ladestationen und Backend fungiert. Neben der Steuerung der Ladestationen erfasst er Messwerte der Stromzähler und berücksichtigt Signale vom Verteilnetzbetreiber, um den verfügbaren Strom optimiert zu verteilen.

Sicherheit und Zuverlässigkeit mit Yocto Linux

Auf dem Edge Device läuft Yocto Linux, eine schlanke, auf die Anwendung zugeschnittene Linux-Distribution. Die Verbindung zum Backend ist über ein VPN geschützt, während die Firewall nur notwendige Ports öffnet. Jedes Gerät nutzt ein individuelles Client-Zertifikat für den sicheren VPN-Zugang und das System ist gegen unbefugte Zugriffe robust abgesichert. Das Betriebssystem wird verschlüsselt und signiert per Over-the-Air (OTA) Updates aktualisiert. Dieser Prozess ist robust gegenüber Unterbrüchen und fehlerhaften Firmwaredateien. Das Gerät bootet in diesem Fall in das vorherige System, was eine Wartung vor Ort vermeidet.

Erfolgreiche Implementierung

Bis Mitte 2025 wurde das EKZ-Lademanagement in über 1’600 Parkanlagen mit rund 60’000 Parkplätzen installiert, ohne dass eine Erweiterung des Hausanschlusses erforderlich war. Durch die Überwachung der Ladestationen und Hausanschlusszählers in Echtzeit optimiert das Edge Device die Stromverteilung an die Ladestationen dynamisch und effizient.

(Quelle Titelbild: EKZ/Norbert Egli)

Einfacher Balisenleser für den Messzug

Projekteinblicke

Das Schienennetz ist ausgestattet mit Balisen, also magnetisch gekoppelten Transpondern, die zwischen den Schienen eines Gleises montiert sind. Jede davon trägt eine eindeutige Identifikationsnummer. Eine Antenne unter der Lokomotive regt die Balise mit einem 27 MHz RF-Feld an, worauf die Balise auf 4 MHz die Identifikationsnummer zurückgibt. Über die Identifikationsnummer wird der Zug sicher lokalisiert für das ETCS-Zugsicherungssystem.

Diagnosezug liest Balisen aus

Zur Überwachung und Instandhaltung der Infrastruktur setzt die SBB Diagnosezüge ein, die mit diversen Sensoren und Kameras den Zustand der Gleise erfassen. Für die Verortung der Diagnosedaten auf der Topologie der Infrastruktur werden, neben Odometrie und GPS, auch die Balisen als fixe Objekte verwendet, da diese in der Datenbank mit Position eingepflegt sind. Dafür hat die SBB eine Handvoll nicht-sicherheitsrelevanter Balisenleser im Einsatz, die nicht mit dem Zugsicherungssystem verbunden sind.

Die heute genutzten Balisenleser können nicht nachbestellt werden, da die beiden aktuellen Hersteller dieser Geräte keinen Support mehr anbieten und die Geräte nicht mehr produziert werden. Aus Gründen der Wirtschaftlichkeit und Verfügbarkeit sollte ein neuer Balisenleser entwickelt werden, der in einer kleinen Serie zu einem tiefen Preis hergestellt werden kann.

Reverse Engineering

Von den bestehenden Balisenlesern existiert keine Dokumentation, weshalb der Typ eines Lieferanten per Reverse Engineering analysiert und mit der Spezifikation der Eurobalisen abgeglichen wurde. Die Schlüsselkomponenten sind:

  • ein TX Sender bei 27.095 MHz als Telepower Source, die genaue Leistung ist unbekannt, liegt aber aufgrund der Leistungsaufnahme bei rund 3 bis 5 Watt.
  • ein RX Verstärker mit einem Tiefpassfilter (DC bis 5MHz) mit einer Attenuation von -50dB bei 27MHz.
  • ein Duplexer, um Sender und Empfänger zu trennen bei der Antenne.
  • ein Software Defined Radio (SDR), um den Sender einzuschalten und das Signal der Balise zu demodulieren.
  • ein Industrie-PC, der das Signal decodiert.

Retrofit: Nicht nur eine Kopie

Bei einem Retrofit soll nicht nur eine Kopie hergestellt, sondern auch aus dem bestehenden System gelernt werden. Im bestehenden Balisenleser wird der Sender beispielsweise über ein USB-attached Relais aus der Software ein- und ausgeschaltet, könnte aber auch direkt über das SDR-Board gesteuert werden. Zudem wird das SDR-Board nur fürs Sampling (und Demodulation) der empfangenen Signale genutzt – die Daten werden danach auf dem integrierten PC decodiert. Auch werden viele verschiedene Speisespannungen (+5V, +15V, -15V, 24V) eingesetzt. Die System-Architektur ist recht komplex und belegt wertvollen Platz im Messzug (4U Höheneinheiten im 19-Zoll Rack).

Das neue System soll deutlich vereinfacht werden:

  • TX Kontrolle direkt auf dem SDR-Board
  • reduzierte Anzahl Speisespannungen (Amplifier nicht symmetrisch versorgt)
  • Decoding direkt auf dem SDR Board, ohne separaten PC

Ohne relevante Abstriche bei der Funktionalität konnte das neue Design um einen Faktor 4 verkleinert werden (auf eine Höheneinheit im 19-Zoll Rack). Weniger Komplexität bringt zudem höhere Zuverlässigkeit und bessere Wartbarkeit.

Neues Systemdesign

Das 27 MHz Signal wird im neuen Balisenleser direkt im SDR-Board erzeugt und vom RF-Modul nur verstärkt. Da das SDR-Board mit einer Taktfrequenz von 125 MHz arbeitet, werden die Oberwellen für ein sauberes Ausgangssignal nach dem Verstärker herausgefiltert.
Das Empfangssignal wird direkt im SDR-Board decodiert. Damit besteht das neue System nur noch aus drei wesentlichen Elementen: einem Netzgerät zur Speisung, dem SDR-Board und dem RF-Frontend. Letzteres wurde kundenspezifisch für den Balisenleser entwickelt.

RF-Frontend

Im RF-Frontend sind sowohl der TX- als auch RX- und Duplexer-Pfad integriert. Auf dem Bild (unten) sieht man unten den TX- und oben den RX-Pfad. Rechts ist der Anschluss für die Antenne. Die Ausgangsleistung von 35dBm (3.2W) reicht zuverlässig, um die Balisen auszulesen. Die Leistungsaufnahme des RF-Moduls liegt bei 700mA/12V.

Software Defined Radio (SDR)

Die SDR-Plattform basiert auf einem Red Pitaya Board mit 125MHz Takt und einer Auflösung von 14bit. Es ist bestückt mit einem Xilinx Zynq 7010 FPGA. Als Betriebssystem wurde ein Yocto-basiertes Linux mit einem U-Boot Bootloader aufgesetzt. Sichere Software-Updates sind jederzeit über das Webinterface möglich. Die Applikation (Decoder) ist in Python3 geschrieben.
Während der frühen Entwicklungsphase wurden verschiedene Algorithmen für Demodulation und Decoding mit Hilfe von GNU Radio und einem Hardware-in-the-Loop Setup evaluiert. Im fertigen Produkt übernimmt das FPGA die rechenintensive Demodulation, das anschliessende Decoding geschieht in der Python-Applikation.

Websocket Applikation

Die Applikation ist als Websocket-Server ausgestaltet. Im Vergleich zu einem HTTP-Server kann ein Websocket bei einer geöffneten Verbindung auch von sich aus Daten schicken, ohne auf eine neue Verbindung des Clients zu warten. Sobald eine Balise erkannt wird, sendet der Server die Identifikationsnummer und einen Zeitstempel. Weil die Balise bei der Überfahrt mehrfach erkannt wird, kann sehr genau bestimmt werden, wann sich die Balise mittig unter dem Leser befindet. Die Genauigkeit (Jitter) des Zeitstempels ist besser als 200 Mikrosekunden, wenn die Zeitsynchronisation mittels Network Time Protocol geschieht.

Der neue Balisenleser wurde für die SBB umgesetzt und im Diagnosefahrzeug in die OpenTLS Messapplikation integriert. Täglich werden damit tausende Balisen zuverlässig ausgelesen. Über ein Web-Interface kann der Status oder das Live Log abgerufen werden. Und dank offenem Quellcode, Produktionsdaten und IP-Rechten ist die Verfügbarkeit von Balisenlesern für die SBB nun gesichert.