Startseite > Automotive > Software + Tools > Flexible Steuergeräteumgebung für thermodynamische Untersuchungen an Prototypenmotor

So offen wie möglich

Flexible Steuergeräteumgebung für thermodynamische Untersuchungen an Prototypenmotor

29. Oktober 2015, 11:33 Uhr | Von Knut Ackermann und Andreas Stark

▶ Diesen Artikel anhören

Fortsetzung des Artikels von Teil 1

Wie offen muss ein Prototypensteuergerät sein?

Grundsätzlich lässt sich bei der Steuergeräteentwicklung zwischen zwei Ansätzen unterscheiden:

limitierte Umgebungen, bei denen Soft- oder Hardware die Freiheitsgrade einschränkt, sowie unlimitierte Umgebungen, die je nach Leistungs- oder E/A-Anforderungen skaliert werden können.

Jobangebote+ passend zum Thema

Regional Key Account (m/w/d) für Elektronische Bauteile

KOA Europe GmbH, Dägeling

Alle Jobangebote im Elektroniknet Karrierebereich anzeigen

Woher kommen die Limitierungen bei Steuergeräten? Bild 4 zeigt den typischen Aufbau eines Motorsteuergeräts. Üblicherweise gibt es ein Multicore-Mikrocontrollersystem wie der Infineon TriCore, das Kommunikation, Einlesen der Ein-/Ausgänge, Regelung und Überwachung des Systems erledigt. Steuergeräte sind entweder mit einer vorkonfigurierten Applikation, die über eine Parametrierung an den Motor anpassbar ist, oder mit einer offenen Programmierschnittstelle verfügbar, über die eigene Algorithmen eingebracht werden können. Die Programmierung des Systems wird dann meist in C/C++ und/oder modellbasiert vorgenommen.

Das Bestimmen der Motorposition und die Erzeugung kurbelwellensynchroner Ereignisse wie das Ansteuern der Zündspulen und der Injektoren erfordert je nach Anwendung noch einen Timing-Chip, der Ereignisse mit einer Auflösung beim Kurbelwellenwinkel von bis zu 0,1° auslösen kann. Bei hohen Umdrehungen ist so eine zeitliche Auflösung von ca. 1 bis 2 µs nötig. Dazu kommen noch spezielle Hardware-Schnittstellen zu den im Verbrennungsmotor üblichen Sensoren und Aktoren wie Lambda-Sonde, induktive oder Hall-Effekt-Drehzahlsensoren sowie Einspritz-Endstufen, Zündtreiber, Leistungsendstufen und H-Brücken.

Aus dem Aufbau des Steuergeräts lassen sich die verschiedenen Limitierungen ableiten. Sind benötigte Hardware-Schnittstellen nicht oder nicht in der erforderlichen Anzahl vorhanden, lassen sich diese meist nur schwer nachrüsten oder auf ein Hilfssystem auslagern, weil dazu eine genaue zeitliche Synchronisation der Systeme nötig ist. In jedem Fall erfordert das Auslagern einen Eingriff in die Software, der auf dieser Ebene meist nicht möglich ist.

Sind genügend Hardware-Schnittstellen für die Aufgabenstellung verfügbar und die Funktionen des Timing-Chips abgestimmt, können die Anforderungen an die Prozessorleistung untersucht werden. Bei Systemen mit vorgegebenen Applikationen, die nur noch über Parameter angepasst werden können, hat der Hersteller der Applikation schon dafür Sorge zu tragen, dass in jedem Systemzustand ausreichend Prozessorleistung für zeitkritische Prozesse zur Verfügung steht. Insofern genügt es, die Möglichkeiten der vorgefertigten Applikation bei der Entscheidungsfindung zu betrachten. Wie bereits beschrieben, sind die Grenzen eines Steuergeräts, das nur appliziert werden kann, bei Prototypenanwendungen schnell erreicht.

Verfügt das Steuergerät über interne Freischnitte, zwischen denen eigene Algorithmen eingebracht werden können, eröffnet das neue Möglichkeiten für Regelstrategien. Allerdings besteht das Risiko, Echtzeitregelungen des Steuergeräts durch zu hohe Prozessorauslastung zu verletzen und so Schäden im Motor hervorzurufen. Dieses Risiko lässt sich entweder durch externe Überwachung des Motors oder ausgiebige Hardware-in-the-Loop-Tests in allen Betriebspunkten minimieren. Grenzen werden hier durch verschiedene Faktoren gesetzt. Neben den vorgesehenen Freischnitten sind das die Leistungsfähigkeit des Prozessors in Hinsicht auf Komplexität der (nicht optimierten) Algorithmen und auf die begrenzte zeitliche Auflösung des Chips von etwa 10 µs. Wie bereits herausgearbeitet, ist eine zeitliche Reaktion im Bereich von 1 µs nötig, um einen Kurbelwellenwinkel von 0,1° aufzulösen.

Das offene, skalierbare Steuergerät

Je nach Anwendung werden Freiheitsgrade benötigt, die kommerziell erhältliche Prototypensteuergeräte nicht bieten. Solche Anwendungen umfassen neue Einspritzverfahren beispielsweise eine Kombination aus Saugrohr- und Direkteinspritzung, den Einsatz nicht unterstützter Sensoren und Aktoren wie Piezo-Injektoren oder neuartige Motorenkonzepte. Größtmögliche Freiheit bieten ein modularer, in der Leistung skalierbarer Hardware-Aufbau und eine offene Software.

Welche Grundanforderungen sollte eine offene Entwicklungsumgebung mitbringen? Die Hardware-Schnittstellen sollten erweiterbar sein, wobei eine offene Hardware-Plattform, auf der die Schnittstellen wie ein Baukastensystem kombiniert werden können, größtmögliche Flexibilität bringt. Offenheit und Standardisierung der Schnittstellen ermöglichen eine Erweiterbarkeit der Plattform für Spezialfälle und die Plattform sollte alle im Antriebsstrang üblichen Sensoren und Aktoren sowie gängige Kommunikationsschnittstellen wie LIN, CAN und Ethernet abdecken. Für eine zeitliche Auflösung im Mikrosekundenbereich sowie zur Umsetzung von extrem schnellen Regelalgorithmen ist der Einsatz von FPGAs sinnvoll. Diese rekonfigurierbare Hardware bietet alle Vorteile eines angepassten Timing-Chips sowie zusätzlich eine Erweiterung der Hardware durch Firmware Upgrades. Zusätzlich kann das FPGA für die Sicherheitsüberwachung des Systems programmiert werden, weil er unabhängig vom Betriebszustand des Prozessorkerns und der Prozessorlast arbeitet. Nach oben skalierbare Multicore-Prozessoren erlauben eine nahezu uneingeschränkte Freiheit in Forschung und Vorentwicklung. Für die Plattform sollten idealerweise Open-Source-Motorapplikationen verfügbar sein, die eine gute Basis für die freie Erweiterung bieten. Die Kalibrierung und Messung des Steuergeräts über XCP erlaubt Anwendern, bei den vertrauten Software-Werkzeugen zu bleiben. Dadurch ist ein einfacher Übergang gewährleistet.

Lösung: Systembaukasten

National Instruments bietet mit seiner offenen Plattform eine gute Grundlage für eine solche Prototypenumgebung (Bild 5). Basis ist die Kombination von leistungsfähigen Multicore-Prozessoren, aktuellen FPGAs und modularen Hardware-Schnittstellen. Dieser Systembaukasten ermöglicht eine nahtlose Skalierung des Prototypensteuergeräts von kompakten Einplatinensystemen zu Hochleistungssystemen mit Octa-Core-Prozessoren, mehreren FPGAs und Online-Verbrennungsanalysen. Die Systeme sind zum einen mit LabVIEW Real-Time und LabVIEW FPGA basierend auf offenen Standardmotorapplikationen frei programmierbar, zum anderen können die Prozessoren mit C/C++ und modellbasierten Entwicklungsumgebungen programmiert werden.

Mit dem Partner LHP Software wurde der Ansatz um Software-Werkzeuge erweitert, die die Programmierung des Rapid-Prototyping-Systems mit Hilfe von MathWorks‘ Simulink ermöglichen. Die Panthera RCP Suite bietet ein einfaches Einbinden von CAN-Datenbanken mit direktem Zugriff auf Signale, die Kalibrierung und Messung über XCP over Ethernet sowie die direkte Kommunikation mit dem frei programmierbaren FPGA und ein einfaches Aufspielen auf NI-Hardware.

Die Autoren

Dipl.-Ing. (FH) Knut Ackermann
studierte Maschinenbau an der Fachhochschule Südwestfalen. Er startete seine Karriere 1996 als Entwicklungsingenieur bei der Porsche AG. Bevor er sich 2006 mit der agr engineering selbstständig machte, war er als Entwicklungsingenieur bei der Volkswagen AG und der Bugatti Engineering GmbH tätig.

info@agr-engineering.de

Dipl.-Ing. Andreas Stark
studierte Elektrotechnik an der Universität Ulm und der University of South Florida. Er ist seit 2008 bei National Instruments in München beschäftigt. Seit 2014 ist er dort als European Systems Engineer für Real-Time-Test und HiL tätig.

andreas.stark@ni.com