Alexandru (Ioan) Lotorosanu-Projektverantwortlicher/PM und Softwarearchitekt

Produkt: VC-EVCC-P (Electric Vehicle Communication Controller für Pantograph-Laden)

Wesentliche Aufgaben:

• Verantwortlich für den kompletten Projektlebenszyklus der Umsetzung des SAE J3105 Standby Mode (sequentielles Laden) auf dem Vector VC-EVCC-P, einem DC-Fast-Charging-Kommunikationscontroller für das Pantograph-Laden von Elektrobussen. Ich habe dabei sowohl die Projektmanagement- als auch die Softwarearchitektur-Rolle übernommen und in einem ASPICE-konformen Prozess (SWE.1-SWE.6) gearbeitet. Ich war der Hauptansprechpartner zwischen dem Endkunden (Cummins/Sensata), dem Softwarelieferanten (Vector Informatik) und dem Entwicklungspartner (Piaxo). Dazu gehörten die Definition des Projektumfangs, die Prüfung technischer und kommerzieller Angebote, die Verhandlung von Lieferumfängen sowie das Nachverfolgen von Issues und Change Requests über mehrere Releases hinweg.
• Das Projekt von Anfang bis Ende in einem strukturierten Work-Package-Ansatz gesteuert — Anforderungen, Architektur, Implementierung, Test, Release — und dabei den Projekt-Gantt-Plan gepflegt und die termingerechte Lieferung sichergestellt.

Auf der Architekturseite habe ich das zweimodige Standby-Verhalten nach SAE J3105-B entworfen:

• Modus 1: Standby wird vor Beginn des Ladens ausgelöst; der Controller läuft in einer Warteschleife, bis die Ladesäule die Bereitschaft signalisiert, während der Ready-to-Charge-Timer in der Zwischenzeit pausiert wird
• Modus 2: Standby wird während des aktiven Ladens ausgelöst; dabei wird die Sitzung kontrolliert beendet, die drahtlose Verbindung bleibt aktiv und eine neue Sitzung startet sofort ohne erneutes Pairing — dadurch sinkt die Verbindungszeit von 10–30 Sekunden auf unter 1 Sekunde
• Die V2G-Kommunikations-Statusmaschine (ISO 15118 / DIN 70121) um neue Standby-Teilzustände erweitert
• Neue CAN-Signale für die Fahrzeug-Schnittstelle entworfen, um den Standby-Status und Ladeunterbrechungsanforderungen zu kommunizieren
• Das Timeout-Verhalten für das Verlassen des Standbys definiert, mit automatischem Sitzungsabbruch und Fehlercode-Logging bei Ablauf
• Die Diagnoseschicht aktualisiert: neue Fehlercode-Definitionen, UDS-Service-Erweiterungen, aktualisierte Diagnosebeschreibungsdatei

Bevor ich mit der Architekturarbeit begonnen habe, habe ich eine tiefgehende Analyse der bestehenden VC-EVCC-P-Referenzimplementierung gemacht und dabei den V2G-Stack, die CAN-Datenbank, die Fehlerbehandlungsmuster, die drahtlose Kommunikationsschicht sowie die OppCharge- und RMP-Ladesequenzen untersucht. Außerdem habe ich das bestehende Cummins-Kundenprojekt geprüft, um sicherzustellen, dass die neue Funktion keine bestehenden Anpassungen beeinträchtigt.

Die komplette Dokumentationskette erstellt:

• SRS: 26 Systemanforderungen, direkt auf SAE J3105-B zurückverfolgt

• SWRS: Softwareanforderungen mit vollständiger bidirektionaler Rückverfolgbarkeit zum SRS

• SDD: Zustandsmaschine und Sequenzdiagramme, Details zur Interaktion der Komponenten für beide Modi

• Unterstützende Architektur-Analysedokumente zum V2G-Ablauf und zur Standby-Integration

• Den Testansatz definiert: Simulationserweiterungen in CANoe, Testfälle für alle Ein- und Austrittsszenarien in beiden Modi, Validierung des Erhalts der drahtlosen Verbindung sowie Abdeckung von Timeout-/Fehlerpfaden.

Technologien und Tools: SAE J3105-B, ISO 15118-2, DIN SPEC 70121, IEC 61851, AUTOSAR Classic (Vector MICROSAR, Flash Bootloader), SPC564B74L7 (PowerPC), CAN 2.0B, PLC / HomePlug Green PHY, CANoe 16 (Smart Charging), DaVinci Configurator / Developer, vFlash, vTESTstudio, VectorCAST, UDS (ISO 14229), PlantUML, STMicroelectronics MCAL

Wesentliche Aufgaben:

Verantwortlich für die Entwicklung, Integration und Validierung von Low-Level-MCAL- und BSW-Treibern für NXP-Automotive-Mikrocontroller-Plattformen, innerhalb eines AUTOSAR-Classic-Frameworks und unter Einhaltung der funktionalen Sicherheitsanforderungen nach ISO 26262. Ich habe eine Reihe von Embedded-Treibern für sicherheitskritische Automotive-ECUs implementiert und integriert, darunter:

• Internal Flash (InFIs): Treiberentwicklung für On-Chip-Flash-Lese-, Schreib- und Löschoperationen, einschließlich Sektormanagement und Fehlerbehandlung
• EEPROM-Emulation (EEP): Implementierung eines EEPROM-over-Flash-Treibers für nichtflüchtige Datenspeicherung mit Wear-Leveling-Unterstützung
• External Flash (ExFIs): SPI/QSPI-basierter externer Flash-Treiber für erweiterten Programm-/Datenspeicher auf Automotive-ECUs
• Ressourcenbereichszuordnung und Speicherschutz: Konfiguration des sicheren Zugriffs auf Peripherie und Verwaltung von Chip-Ressourcen über mehrere Sicherheitsdomänen hinweg
• PSIS (Peripheral Sensor Interface 5): Treiber für die Kommunikation mit Automotive-Sensoren, unterstützt schnelle und fehlertolerante Datenübertragung
• MRAM (Magnetic RAM): Treiber für nichtflüchtige Speicheroperationen mit schnellen Lese-/Schreibzyklen, passend für Automotive-Umgebungen
• Secure-Boot-Ablauf — beteiligt an der Integration und Konfiguration authentifizierter Firmware-Lademechanismen, um integritätsgeprüfte Startsequenzen auf NXP-basierten ECUs sicherzustellen

Ich habe mit einer großen Bandbreite von NXP-Automotive-Plattformfamilien gearbeitet:

• S32K1xx / S32K3xx — Mikrocontroller für Body-, Antriebs- und Sicherheitsanwendungen
• S32G2 / S32G3 — Gateway-Prozessoren für Fahrzeugnetzwerke und serviceorientierte Architektur
• S32R — Radar-Prozessoren für ADAS- und Sicherheits-Sensoranwendungen
• S32Z / S32E — Echtzeitprozessoren für Zonen- und Domain-Controller-Architekturen
• S32N — Netzwerkprozessoren für hochbandbreites In-Vehicle-Ethernet und domänenübergreifende Kommunikation

Den kompletten Software-Entwicklungszyklus für jedes Treibermodul abgedeckt — von der Anforderungsdefinition und Architektur/Design über Implementierung, Unit-Tests bis hin zur Integrationsvalidierung. Anforderungen und Designdokumentation aktualisiert, um Umfangsänderungen und Fehlerbehebungen abzubilden.

Technischen Support für externe Kunden geleistet, die NXP-MCAL-Treiber in ihre eigenen Plattformen integrieren — gemeldete Probleme analysiert, Fehler reproduziert, Root-Cause-Analysen geliefert und Fixes oder Workarounds bereitgestellt.

Debugging und Low-Level-Analysen mit Lauterbach-Trace-Tools durchgeführt und dabei S32 Design Studio und Tresos (Elektrobit) für die AUTOSAR-konforme Treiberkonfiguration und Codegenerierung genutzt.

In einem Agile/Scrum-Umfeld gearbeitet, an Sprint-Planung und Lieferung mitgewirkt und die vollständige Rückverfolgbarkeit in Jira/Confluence gepflegt.

Technologien und Tools: AUTOSAR Classic, ISO 26262, NXP S32 Design Studio, Tresos (Elektrobit), Lauterbach, Git, Sourcetree, Jira/Confluence, Agile/Scrum

Aktivitäten:

• Zwei Java-basierte Tools (Frontend und Backend) entwickelt, um die XML-Konfiguration zu automatisieren und das Issue-Management zu vereinfachen, wodurch die Effizienz des Integrationsteams verbessert wurde:
• Das erste Tool wurde entwickelt, um XML-Dateien automatisch basierend auf XDM-(Schema-)Dateien zu konfigurieren.
• Das zweite wurde für das Integrationsteam zur Verwaltung von Issues erstellt.
• Embedded-Softwareentwickler für die BSW-Traveo-II-Plattform mit folgenden Aufgaben:
• AUTOSAR-Module auf der uC-Traveo-II-Plattform integrieren und validieren.
• Komplexe Device Driver (CDD) innerhalb der I/O-Hardware-Abstraktionsschicht in C entwickelt und validiert, unter Nutzung automatisierter Tests (Funktions-, Modul- und Unit-Tests) für eine höhere Systemzuverlässigkeit.
• Code und Design prüfen.
• Schnittstelle zu Hardware-Design und -Entwicklung.
• Effizienz, Stabilität und Skalierbarkeit der Systemressourcen analysieren und verbessern.
• Designdokumente und Benutzerhandbücher für Treiber erstellen.
• Funktionale und nichtfunktionale Anforderungen sowie Design- und Integrationsanforderungen erstellen.
• In einem agilen, funktionsübergreifenden Team arbeiten.
• Neue Kollegen einarbeiten.
• Studenten koordinieren.
• Support nach der Produktion bereitstellen.
• Erfahrung mit I2C- und SPI-Protokollen.

Beispiele für entwickelte und validierte Treiber:

• Ausgabediagnose über externe Geräte.
• Ausgabesteuerung für direkte, demultiplexte und PWM-Signale.
• Eingangserfassung und Entprellung für direkte und multiplexte Signale (digital und analog).
• DMA-(Direct Memory Access)-Treiber.
• UART-Treiber.
• SPI-Treiber, der nur für den Empfang von Daten über DMA (Direct Memory Access) verwendet wird.

Verwendete Technologien:

• Jira/Confluence-Erfahrung
• Git-Erfahrung
• Agile - Scrum Master-Erfahrung
• AUTOSAR
• Tresos Elektrobit
• Jenkins
• C Embedded
• Python (Test-/Build-Skripte)
• IMS/MKS
• CAN Case
• WinIDEA
• Lauterbach