Startseite > Embedded > Entwicklungstools > Generierung von Produktions-Codes früher und heute #####

Generierung von Produktions-Codes früher und heute #####

17. Februar 2009, 13:23 Uhr | Tom Erkkinen

▶ Diesen Artikel anhören

Fortsetzung des Artikels von Teil 1

Generierung von Produktions-Codes früher und heute

Code-Integration und -Verifikation

Jobangebote+ passend zum Thema

MACNICA ATD EUROPE - Ihre berufliche Zukunft

MACNICA ATD Europe GmbH, Ingolstadt

Alle Jobangebote im Elektroniknet Karrierebereich anzeigen

Zur Erleichterung der Integration wurde der Real-Time-Workshop Embedded-Coder um die Möglichkeit zur Definition eines Funktionsprototypen erweitert. Modellentwickler können damit einen Code erzeugen, der eindeutig definierte Schnittstellen für die Model-Step-Funktion und die Modell-Referenz-Funktionen enthält. Ein externer Scheduler kann den für diese Funktionen generierten Code auf einfache Weise aufrufen (Bild 3).

Die Verifikation und Validierung ist ein weiteres Gebiet, auf dem immer neue Funktionen und Fähigkeiten geschaffen werden. Hier hat man sich insbesondere um eine Verbesserung der Rückverfolgbarkeit bemüht.

Im ersten Release des Real-Time-Workshop-Embedded-Coder konnte automatisch vom generierten Code zurück zum Simulink-Modell navigiert werden. In R2008a kann dagegen von Simulink-, Stateflow- und Embedded Matlab zum generierten Code und zurück navigiert werden.

Hier wurden verschiedene Möglichkeiten zur Software-Entwicklung erläutert, die die Grundlage für eine erfolgreiche modellorientierte Entwicklung sowie die Erzeugung, Integration und Verifikation von Produktions-Code bilden. Entscheidende Weiterentwicklungen treten im Software-Bereich nur dann ein, wenn alle für die Software-Entwicklung erforderlichen Aufgaben unterstützt werden – die bloße Verbesserung einzelner Details ist nicht ausreichend.

Tom Erkkinen
ist technischer Vertriebsleiter für Embedded-Systeme. Vor MathWorks entwickelte er Kontrollsysteme und Software unter anderem für das Johnson Space Center. In kleineren Firmen widmete er sich sicherheitskritischer Code-Generierung und entwickelte HiL-Systeme (Hardware in the Loop). Er studierte Luft- und Raumfahrttechnik an der Boston University sowie Maschinenbau an der Santa Clara University.
tom.erkkinen@mathworks.com

Die Modellierung und Simulation auf einem Host-Computer allein kann aber nicht den ganzen Weg zur Produktion hin zurechtlegen. Der Grund dafür sind ungenaue Umgebungsmodelle, schwer zu simulierende Timing-Effekte und andere, nur in der realen Welt auftretende Effekte. Letztere müssen jedoch berücksichtigt werden, um das Verhalten eines Algorithmus wirklich zu verstehen. Zur Überwindung dieser Beschränkungen eignet sich besonders gut das Rapid Prototyping. Hierbei wird zum Testen der ECU statt des Umgebungs-Modells die tatsächliche Anlagen-Hardware in die Regelschleife eingebaut. Beim Rapid Prototyping unterscheidet man zwei prinzipielle Arbeitsweisen:

Das Funktionale Prototyping mit Simulink war bereits in den frühen 1990ern verfügbar. Es wurde mit leistungsfähigen Echtzeit-Rechnern durchgeführt und konnte sicherstellen, dass die ECU das Fahrzeug mit der gewünschten Funktionalität steuert.
Beim On-Target Rapid Prototyping (Bild 2) wird die automatisch generierte Software für die gleiche oder eine sehr ähnliche Umgebung implementiert, wie sie später in der Serienproduktion zum Einsatz kommt. Dabei wird ermittelt, ob die Regelstrategie für die tatsächlich verwendete Produktions-Hardware geeignet ist. Beim On-Target Rapid Prototyping wird der Code auf den Embedded-Prozessor heruntergeladen, wodurch die Möglichkeit besteht, Tests schnell und mit der tatsächlichen Umgebung oder mit einem Serienfahrzeug durchzuführen. Wenn der Regel-Algorithmus auf dem Target eine akzeptable Leistung liefert, ist er für den Produktionseinsatz geeignet.