Autarke Ad-hoc-Entwicklung einer mehrkanaligen PWM-Signalaufbereitung inklusive eines CANoe-basierten Konfigurations-Frontends für ein automobiles Hardware-in-the-Loop-System (HIL-System).

• Systemkonzeption: Auslegung der Signalwandlungsarchitektur zur hochgenauen Übersetzung strombasiert-modulierter Signale unter extremen Gleichtaktstörungen.
• Kaskadierbare Kommunikationsarchitektur: Design eines adressbasierten Protokolls über UART zur modularen Erweiterung mehrerer Signalaufbereitungsmodule via Jumper-Konfiguration.

• Analog- & Schaltungsdesign: Entwicklung einer Signalaufbereitung zur Wandlung eines strombasierten PWM-Signals im Milliampere-Bereich, dem eine PWM-modulierte Offset-Spannung von bis zu 80 V bei variabler Frequenz überlagert ist, in ein massebezogenes Spannungssignal.
• Störfestigkeit & Filterung: Schaltungstechnische Optimierung zur zuverlässigen Signalmessung durch das HIL-System trotz hochfrequenter Gleichtaktstörungen.
• Peripherieintegration: Einbindung eines dedizierten Analog-Digital-Umsetzers (ADC) pro PWM-Kanal zur automatischen Parametrierung und Strommessung sowie Integration der UART-Schnittstellen.
• Express-Prototyping: Steuerung eines Express-Bestückungsdienstleisters für die Vorbestückung der Leiterplatten sowie finales Löten der Prototypen im eigenen Reflow-Ofen.

• Firmware-Entwicklung: Programmierung des STM32-Mikrocontrollers zur hardwarenahen Konfiguration der Schwellenwerte für die Strom-zu-Spannungswandlung beim Systemstart.
• Automatisierte Parametrierung: Implementierung der ADC-Steuerungslogik zur Strommessung und dynamischen Parameteranpassung über die UART-Schnittstelle.

• Frontend-Entwicklung: Erstellung eines CANoe-basierten Konfigurations-Frontends zur interaktiven Steuerung und automatischen Parametrierung der Signalaufbereitungskanäle.
• Systemintegration: Verifikation der UART-Kommunikationskette zwischen dem STM32-Subsystem, dem CANoe-Frontend und dem übergeordneten HIL-System.

• Ad-hoc-Projektdurchführung: Vollständige Entwicklung und Prototypenfertigung innerhalb einer extrem kritischen Zeitspanne über die Jahreswende (Beauftragung direkt vor Heiligabend, erfolgreiche Auslieferung einsatzbereiter Baugruppen Anfang Januar) im eigenen Ingenieurbüro.
• Abrechnungsmodell: Aufgrund des spezifischen technologischen Entwicklungsrisikos erfolgte die monatliche Abrechnung flexibel nach tatsächlichem Zeit- und Materialaufwand nach erfolgreicher Inbetriebnahme.

Autarke Entwicklung der Elektronik für ein kompaktes Motorsteuerungs-Subsystem vollständig im eigenen Ingenieurbüro bei freier Zeiteinteilung. Das Subsystem wurde so konzipiert, dass es sowohl als Standalone-Einheit als auch integriert im Rahmen eines industriellen Thermodrucksystems eingesetzt werden kann.

• Hardware-Design: Vollständige Schaltungs- und Layoutentwicklung der Motorsteuerung unter Integration eines Stepper-Motorcontrollers, eines STM32-Mikrocontrollers sowie einer Schnittstelle zu einer externen SPS-Einheit.
• Schnittstellen & Peripherie: Optionale Erweiterbarkeit des Systems um einen externen Hall-Sensor sowie eine SPS-Erweiterungsbaugruppe. Galvanisch entkoppelte Ausführung des SPS-IO-Teils.
• Schutzbeschaltung: Gezielte Auslegung der gesamten Systemelektronik auf hohe Surge-Festigkeit.
• Labor & Fertigungstransfer: Eigenhändige Musterbestückung und Reflow-Löten der ersten Prototypen zur schnellen Hardware-Verifikation.

• Inbetriebnahme-Software: Entwicklung und Programmierung einer dedizierten Testsoftware auf dem STM32-Mikrocontroller zum Selbsttest der Hardware.
• Co-Engineering: Enge und direkte Abstimmung der Hardware-Architektur und der Testsoftware mit dem Zulieferer für die Firmware des Nominalbetriebs zur optimalen Aufteilung des Gesamtprojekts.

• Autarke Materiallogistik: Eigenverantwortliche Disposition, Beschaffung, Vorfinanzierung und Einlagerung des Materials für die ersten 100 Systembaugruppen zur Absicherung gegen globale Corona-Lieferengpässe. Dies erfolgte rollierend und ohne kundenseitige Freigabeprozesse zur maximalen Beschleunigung des Projekts.
• Die monatliche Abrechnung erfolgte flexibel nach tatsächlichem Zeit- und Materialaufwand.

Eigenentwicklung und Implementierung einer integrierten Assembler-Entwicklungsumgebung (IDE) für Soft-Core-Prozessoren in FPGAs, um bestehende Toolchain-Unzulänglichkeiten zu überwinden und eine verlässliche Simulationsumgebung für komplexe Firmware-Entwicklungen zu schaffen. Das Tool wird weltweit an Universitäten in der akademischen Ausbildung sowie in der Satellitentechnik eingesetzt.

Projektinhalte & Aufgaben nach Rollen:

• Architektur-Konzeption: Vollständige Konzeption und Implementierung der IDE-Architektur als modularer Software-Baukasten, der als Plattform für zahlreiche Folgeprogramme dient.
• Framework-Expertise: Aufbau einer tiefgreifenden C++-Architektur und Nutzung des Qt-Frameworks zur Umsetzung der gesamten GUI- und Applikationslogik.
• Workflow-Automatisierung: Einbindung externer Programme in den Build-Prozess sowie Entwicklung eines flexiblen Projektmanagements für umfangreiche Softwareprojekte.

• Code-Editor mit Navigator: Entwicklung eines Programmier-Editors mit Syntax-Highlighting, Autovervollständigung, Vorlagen-Einfügung (Template-Insertion) und Code-Navigation.
• Compiler-Design: Entwicklung eines Code-Parsers und Compilers zur Kompilierung eines generischen Assembler-Instruction-Sets für verschiedene Soft-Core-Prozessoren.
• Simulator & Debugger: Entwicklung eines echtzeitfähigen Simulators zur Visualisierung von benannten Registern, Port-Adressen und vorinitialisierten Speichern.

• Logisches Speichermanagement: Implementierung einer logischen Memory-Page-Verwaltung für Prozessoren ohne nativen Bank-Support, genutzt unter anderem zum dynamischen Nachladen von Programmteilen aus einem externen Speicher.
• Interaktive Hilfe & Diagnose: Integration eines Message-Viewers mit direkter Verknüpfung zur Online-Hilfe und den Prozessor-Handbüchern sowie eines Importfilters für Drittanbieter-Quellen.

Bei Videowänden erfolgt das Streaming von Video-Daten über einen Videocontroller, der einen Video-Datenstrom von Standard-Schnittstellen wie HDMI oder DisplayPort in einen Bildspeicher puffert und von dort über Ethernet in die Videowand streamt.

• An das CLI-Programm dockt über eine Bibliothek eine Qt-Anwendung an, die auf dem Embedded-Linux mit LXDE-Oberfläche läuft.
• Die Hardware des Videocontrollers ist ein Trägerboard mit 12 SFP+-Slots (4x 10G-Ethernet, 8x 1GEthernet), einem DisplayPort-Eingang und zwei DisplayPort-Ausgängen, ein SoM mit einem Arria10-SoC mit zwei getrennten DDR4-Speicherbänken (HPS und FPGA) zur maximierung der Bandbreite.
• Über einen DisplayPort-Eingang werden Video-Daten in den DDR4-Speicher gestreamt, der als Double-Buffer ausgelegt ist. Die Daten werden der Größe und Lagen der Video-Panels im Video-Bild entsprechend ausgelesen, in UDP-Pakete verpackt und via Ethernet in die Video-Wand gesendet. Der Video-Controller unterstützt Auflösungen bis zu 16k mit Farbtiefen bis zu 12 Bit.

Für einen High-Throughput-Videocontroller habe ich:

• das vollständige FPGA-Design (VHDL) für die 16k-Echtzeitverarbeitung geplant und implementiert.
• ein Embedded-Linux mit LXDE-Desktop from scratch mit Yocto aufgebaut (inkl. Kernel- und U-Boot-Anpassungen für das Arria10-SoC).
• mehrere Linux-Kernel-Treiber für FPGA-Registerzugriff, Ethernet, Framebuffer, Video4l und DisplayPort geschrieben (die Treiber-Skeletons in den Kernel-Quellen verwendet)
• ein CLI-Programm zum Konfigurieren und zum Statusmonitoring entwickelt.

Für den FPGA habe ich die folgenden Einheiten entwickelt und mit VHDL implementiert:

DisplayPort

• Für die Video-Schnittstellen habe ich drei Instanzen eines DisplayPort-IP-Cores integriert, wobei ich die Gigabit-Transceiver (PMA/PCS) und Reset-Controller manuell instanziieren musste.
  • Eingang (4 Gigabit Lanes) für den primären Video-Stream.
  • Ausgang (4 Gigabit Lanes) zum verlustfreien Duplizieren des Eingangs-Streams auf einen Monitor-Ausgang.
  • Ausgang (1 Gigabit Lane) für die grafische Bedienoberfläche.
• Die Konfiguration der Gigabit-Transceiver erfolgten über einen modifizierten Reconfiguration-Controller. Hierfür habe ich ein beigestelltes Verilog-Modul überarbeitet, um einen Mix aus Ein- und Ausgängen innerhalb einer Transceiver-Bank über einen gemeinsamen Avalon-Bus zu realisieren. Für den Video-Eingang (vier Pixel parallel) habe ich einen Kompressor entwickelt, der die Bilddaten je nach Farbtiefe ohne Stuffing-Bits verdichtet und für bei Bedarf die Farbtiefe reduziert.
• Zur Systemoptimierung und Ressourceneinsparung im FPGA habe ich die ursprüngliche NiosII-Firmware zur DisplayPort-Konfiguration in einen dedizierten Linux-Treiber portiert und auf das HPS-System (ARM) verschoben. Für die Benutzeroberfläche habe ich eine HVSync-Einheit implementiert, die Daten via DMA aus einem Framebuffer bezieht, für den ich ebenfalls den Linux-Treiber geschrieben habe.

TPG

• Ich habe einen Testpatterngenerator (TPG) entwickelt, um komplexe Video-Testdaten sowohl für die Simulation in der Testbench als auch für die Verifikation in der Hardware zu erzeugen.
• Die Einheit diente maßgeblich dem Debugging und der Validierung der beim Memory-Transfer sowie beim UDP-Encoding im Simulator und auf der Hardware. Sie vereinfachte die Fehlersuche bei der Paket-Analyse mit Wireshark (aus Testbenchfiles importiert oder gecaptured) bzw. durch Betrachtung eines Musters auf einem LED-Panel.

Memory-Transceiver

• Um den DDR4-Speicher an der physikalisch maximalen Datenrate zu betreiben, habe ich einen spezialisierten Memory-Transceiver entwickelt. Dieser mappt den Video/TPG-Eingang, einen Memory-Tester und sechs Ethernet-Transmitter auf einen EMIF-Memory-Controller. Der Transceiver ermöglicht das parallele Schreiben des Video-Eingangs bei zeitgleichem Lesen für alle sechs Ethernet- Transmitter.
• Ich habe ein Book-keeping-Verfahren implementiert, um die gelesenen Daten ?back-to-back? auf die anfordernden Transmitter zu verteilen. Um die Netto- Datenrate für den Video-Stream weiter zu steigern, habe ich die Refresh-Zyklen des DDR4-Speichers manuell gesteuert und geeigneten, anwendungsspezifischen Zeitpunkten angestoßen.

Ethernet - Transmitter

• Ich habe den Ethernet-Transmitter auf Basis mehrerer Finite State Machines (FSM) realisiert.
• Diese steuern die Datenanforderung vom Memory-Transceiver sowie die Erzeugung und Versand von IP/UDP-Headern und Video-Payload. 
• Zur Frame-Synchronisation innerhalb der Videowand habe ich einen Mechanismus implementiert, der spezifische Sync-Broadcast-Pakete zum Sync-Zeitpunkt nach den Video-Daten versendet. 
• Ein Transmitter-Modul habe ich so ausgelegt, dass es wahlweise einen 10G-Ethernet-Kanal direkt bedient oder über einen nachgeschalteten Demultiplexer acht 1G-Kanäle parallel ansteuert.

Ethernet - Infrastruktur

• Ich habe die Unterstützung für 4x 10G-Ethernet-Kanäle oder alternativ 16x 1GEthernet- Kanäle im FPGA implementiert (in der finalen Hardware auf 12 Kanäle reduziert). Dabei habe ich eine Redundanzschaltung für jeweils zwei Kanäle sowie das IP-, MAC-Adress- und VLAN-Tagging (kommen aus dem Linux-System) realisiert. Während ich für die 10G-Kanäle Intel-MAC-IP-Cores einsetzte, integrierte ich für die 1G-Kanäle beigestellte MAC-Implementierungen des Kunden (zu Beginn des Projektes mit einem Eval-Board den Triple-Speed-MAC von Intel).
• Um das HPS-System im Fall von Ringschleifen vor Video-Paketen zu schützen, habe ich einen Hardware-IP/UDP-Filter entwickelt, der auf Basis von Protokoll und VLAN-Tags filtert. Zusätzlich habe ich für den Versand von IP-Paketen aus dem HPS heraus pro Ethernet-Kanal einen Switch im FPGA implementiert, welcher die HPS-Pakete in den Video-Datenstrom einschleust.
• Ich habe alle 20 Ethernet-Kanäle via DMA an das HPS-System angebunden und den zugehörigen Linux-Treiber geschrieben. Der Treiber ist so ausgelegt, dass er im FPGA dynamisch ausliest, welche Kanalkonfiguration (10G- oder 1GVariante) aktuell vorliegt, um die Netzwerkschnittstellen im Betriebssystem automatisch korrekt bereitzustellen.

DMA & AXI-Bus-Architektur

• Die Anbindung des HPS (ARM-System) habe ich über einen eigenen AXI-Lite- Core zur Register-Kommunikation realisiert. Den Zugriff auf den DDR4-Speicher des HPS habe ich über zwei von mir entwickelte AXI-Master-Cores umgesetzt, die jeweils unabhängige Lese- und Schreib-Transaktionen parallel ausführen können. Dabei habe ich folgende Funktionen implementiert:
  • Load-Balancing: Ich habe zwei Steuerungsmodule entwickelt, die ein Video- Datenstrom und 16 Ethernet-Datenströme auf die AXI-Master mappen, um die Buslast optimal zu verteilen. Jeweils für Schreiben und Lesen.
  • Daten-Alignment: Die AXI-Master habe ich mit einer Barrelshifting-Logik für die Ethernet-Pakete ausgestattet.
  • Adressraum-Management: Ich habe die Logik so ausgelegt, dass Transaktionen automatisch an 4k-Adressraum-Grenzen zerlegt werden, um die Konformität mit der AXI-Spezifikation sicherzustellen.

Video preview

• Ich habe einen Vorschau-Pfad implementiert, der einen Ausschnitt des Eingangs - Video-Streams (linke obere Ecke, die Skalierung des Gesamtbildes wurde aufgrund des dafür benötigten Ressourcenbedarfs ausgesetzt) im FPGA auskoppelt.
• Den Transfer in den DDR4-Speicher des HPS habe ich via DMA realisiert und die Daten mittels eines von mir geschriebenen V4L2-Treibers in das Video-Subsystem von Linux eingespeist, damit der Video-Stream in der Qt-Oberfläche angezeigt werden kann. Die Anzeige habe ich mit dem Qt-Beispielprogram Camera getestet, welches ich von Yocto habe dazu bauen lassen.

• Das System nutzt Glasfaserkabel zur präzisen Temperaturmessung über lange Strecken durch die Auswertung von Stokes- und Anti-Stokes-Reflexionen im Lichtleiter. Die Steuerung der Laserpulse sowie die hochfrequente Erfassung und Vorverarbeitung der Messdaten wurden auf einer spezifischen Kundenhardware realisiert, wobei die Daten zur finalen Temperaturbestimmung via PCIe an einen System - Prozessor übertragen wurden.
• Ich habe das FPGA-Design vollständig geplant und implementiert. Die Laser-Ansteuerung erfolgte über eine via PCIe beschreibbare BRAM-Tabelle. Um eine präzise Phasenverschiebung des Lasers zu ermöglichen, war einen Schaltungsteil mit einer Timing-Anforderung von 1 GHz erforderlich.
• Die Messdaten wurden in einem DDR3-Speicher erfasst, der über einen Memory Interface Generator (MIG) angebunden wurde. Zur Minimierung von systematischen Speichergeräuschen habe ich eine Speicher-Shifting-Logik mit Averaging implementiert. Die finalen Messdaten wurden final über das PCIe-Interface zur Auswertung bereitgestellt, über welches die Logik auch Konfiguriert und gesteuert wurde.

• Der Extender ermöglicht die transparente Verlängerung von USB-Signalen (via ICRON), Ethernet  und einem proprietären Echtzeit-Steuerkanal über eine galvanisch getrennte Glasfaserstrecke von bis zu 400 m. Dabei werden die Datenströme mit unterschiedlichen Charakteristika im FPGA gemultiplext und deterministisch übertragen.
• Zum Einsatz kam ein Cyclone V SoC auf einer spezifisch entwickelten Kundenhardware sowie ein mit Yocto gebautes Embedded-Linux von Denx.
• Ich habe das FPGA-Design geplant und implementiert sowie einen Treiber zur Integration des Ethernet-Kanals (Anbindung via AXI-Master an das HPS) in den Linux-Kernel geschrieben.
• Während ich den Gigabit-Transceiver, Reset-Controller und Configuration-Controller als ipCore verwendete, habe ich die Link-State-Machine (LSM), die Kanalcodierung sowie die Multiplexer/Demultiplexer implementiert. Der Ethernet-Kanal wurde über einen eigenen AXI-Master an das HPS-System angebunden und über einen selbst geschriebenen Ethernet-Linux-Treiber in das Linux-System integriert.

• Beim Einsatz von LED-Scheinwerfern in Fahrzeugen wird jeder Scheinwerfer von einem eigenen Steuergerät betrieben, das die zahlreichen LEDs individuell regelt und überwacht.
• Ich habe einen Steuergerätetester für verschiedene LED-Scheinwerfer-Steuergeräte entwickelt. Dieser kann den Datenstrom zwischen Steuergerät und LED-Scheinwerfer aufzeichnen, auswerten und via Ethernet an ein HIL-System (Vector oder dSPACE) übertragen.
• Neben zahlreichen Manipulations-, Emulations- und Triggerfunktionen bietet der Tester weitere Mess- und Generatorfunktionen.
• Für die Steuerung und Datenvisualisierung habe ich eine Qt-basierte Anwendung entwickelt und zusätzlich eine Integration in CANoe mithilfe von CAPL-Skripten sowie C#-basierten Benutzeroberflächen umgesetzt. So kann der Tester auch ohne HIL standalone betrieben werden.
• Kernstück des Testers ist ein Enclustra-SoM Mars ZX3 mit einem Xilinx Zynq-7000. Die Elektronik, das FPGA-Design, der Linux-Treiber und ein Linux-CL-Program wurden von mir  entwickelt. Das Embedded-Linux war Yocto basiert und kam von Enclustra.
• Aufgrund der erfolgreichen Umsetzung dieses und weiterer Tester wurde die Fautronix GmbH als Daimler-Direktlieferant gelistet.