Design einer flexiblen Integrationsschnittstelle für PIL

1
Design einer flexiblen Integrationsschnittstelle für PIL-Tests
Kurzfassung. Dieser Artikel stellt ein Konzept für eine
Integrationsschnittstelle zur Simulation mit Processorin-the-Loop (PIL) vor. PIL ist ein wichtiges Werkzeug der
modellbasierten Softwareentwicklung. Diese erlaubt eine
frühzeitige Verifizierung der Implementierung. Die Konzeption für die Integrationsschnittstelle erweitert bisherige Ansätze um eine automatische Schnittstellenanalyse
auf der Quellcodeebene und setzt auf die Weiterverwendung der bereits vorhandenen Entwicklungsumgebung.
Hierdurch wird eine hohe Portabilität und Skalierbarkeit
dieser Lösung erzielt. Zur Umsetzung des Konzepts wurde ein Prototyp für Simulink erstellt und anhand eines
Testszenarios verifiziert.
1 Einleitung
Im Laufe der letzten Jahre hat der Einsatz modellbasierter Methoden für die Softwareentwicklung stetig an
Bedeutung gewonnen. Modellbasierte Verfahren bieten
den großen Vorteil, dass sich das Softwaredesign bereits sehr früh und kontinuierlich verifizieren lässt [1].
Sicherheitsstandards aus den verschiedensten Industriebereichen tragen dieser Entwicklung Rechnung, indem
sie modellbasierte Methoden berücksichtigen. Zwei
wichtige Beispiele sind:
• die ISO 26262 [2] für sicherheitsrelevante elektrische/
elektronische Systeme in Kraftfahrzeugen
• die DO-178C [3] zur Softwareentwicklung im sicher heitskritischen Bereich der Luftfahrt
Obwohl die Vorteile modellbasierter Methoden für alle
Beteiligten klar zu erkennen sind, zeigen Fallstudien bei
deren Umsetzung in der Praxis noch eine Reihe von
Hürden [4]. Wie so oft, funktioniert die Softwareentwicklung mittels modellbasierter Methoden dann reibungslos,
wenn die gesamte Toolkette vom Hersteller der Modellierungsumgebung durchgängig unterstützt wird.
Diese Toolkette umfasst:
• Codegenerator
• Build-Umgebung
• Zielplattformen
Modellierungsumgebungen bieten aktuell keine einheitlichen Austauschformate, sodass sich Daten nur sehr
schwer auf ein Fremdtool transferieren lassen. Eine weitere Schwierigkeit ist der Einsatz von manuell erstelltem
Code, da verfügbare Toolketten vor allem auf die automatische Codegenerierung mittels Codegeneratoren
ausgelegt sind.
Processor-in-the-Loop (PIL) wird in der modellbasierten
Entwicklung eingesetzt, um einen Algorithmus, der aus
einem Modell abgeleitet wurde, auf einer Hardwareplattform oder einem Instruction-Set-Simulator zu testen.
Mit Hilfe eines Codegenerators lässt sich ein Modell in
Quellcode überführen, sodass daraus eine in der Zielumgebung lauffähige Applikation erstellt werden kann.
Im Rahmen dieses Artikels wird ein Vorschlag für eine
skalierbare Integrationsschnittstelle für PIL-Simulationen
in Simulink vorgestellt. Im Vergleich mit bisherigen Implementierungen wird eine deutlich höhere Flexibilität dadurch erzielt, dass die Struktur des Quellcodes
nach der Generierung analysiert und anhand dieser
Daten eine passende Schnittstelle zur Durchführung
eines PIL-Tests dynamisch erzeugt wird. Des Weiteren
wird ein Debugger für die Kommunikation mit der Zielplattform eingesetzt, sodass nahezu jede Zielplattform
ohne zusätzliche Anpassungen unterstützt werden kann.
Im weiteren Verlauf gibt dieser Artikel eine kurze Übersicht über modellbasierte Entwicklungsmethoden im Rahmen von ISO 26262 und PIL-Simulationen mit Simulink.
Es werden die Einschränkungen des bisherigen Ansatzes
diskutiert und dessen Weiterentwicklung vorgestellt.
Zum Abschluss wird der neue Ansatz anhand eines Beispielszenarios demonstriert.
2 Modellbasierte Entwicklung nach ISO 26262
Um die Anforderungen diverser Sicherheitsstandards
erfüllen zu können, hat sich ein Referenzablauf (Abb. 1)
für den Einsatz modellbasierter Entwicklungsverfahren
etabliert.
ANFORDERUNSVERIFIZIERUNG
ANFORDERUNGEN
MODELLIERUNG
BACK-TO-BACK-TESTS
MODELL
CODEGENERIERUNG
QUELLCODE
BUILD-PROZESS
APPLIKATION
Abbildung 1: Referenzablauf für modellbasierte Entwicklung [5]
1 • Tel. +49 8102 9876-0 • [email protected] • www.lauterbach.com
Lauterbach GmbH • Altlaufstraße 40 • D-85635 Höhenkirchen-Siegertsbrunn
2
SAFETY REQUIREMENTS
REQUIREMENTS VERIFICATION
SOFTWARE ARCHITECTURE
SOFTWARE INTEGRATION TESTING
HIL
SE
SOFTWARE UNIT TESTING
SOFTWARE IMPLEMENTATION
TE
A
PH
MIL
ST
PH
AS
E
GN
SI
DE
SOFTWARE UNITS
PIL
SIL
Abbildung 2: Softwareentwicklung nach ISO 26262
Identisch zum konventionellen Entwicklungsansatz werden im ersten Schritt Anforderungen ausgearbeitet,
die das Verhalten der zu erstellenden Software mit allen
notwendigen Details beschreiben. Der Einsatz modellbasierter Verfahren bietet nun die Möglichkeit, dass sich
die Anforderungen sehr leicht in Form grafischer Modelle
umsetzen lassen. Im Unterschied zu rein textuellen Anforderungen haben Modelle den großen Vorteil, dass sie in
der Lage sind, das Verhalten eines Systems eindeutig zu
beschreiben. Mit Hilfe einer Modellierungsumgebung lassen sich Modelle für Software-in-the-Loop (SIL) einsetzen.
Damit können die zugrundeliegenden Anforderungen frühzeitig verifiziert werden [6].
Die Generierung von Quellcode gestaltet sich beim Einsatz modellbasierter Verfahren sehr einfach, da eine Reihe
von Codegeneratoren kommerziell verfügbar sind, die aus
einem ausführbaren Modell automatisiert eine äquivalente
Quellcoderepräsentation erstellen können. Mit Hilfe dieses
Quellcodes lassen sich Applikationen erzeugen, die auf einer Hardwareplattform oder einem Instruction-Set-Simulator getestet werden können.
Der Ablauf des Softwareentwicklungsprozesses bei ISO
26262 (Abb. 2), orientiert sich sehr stark am bekannten
V-Modell. Dieses legt fest, dass im Anschluss an Softwaredesign und -implementierung ein mehrphasiger Verifikationsprozess durchlaufen werden muss. Die Verfügbarkeit
ausführbarer Modelle eröffnet dabei zusätzliche Möglichkeiten, die Arbeitsergebnisse der einzelnen Teilprozesse
zu verifizieren. Die Korrektheit eines Modells lässt sich
zudem durch Simulationen in Kombination mit anforderungsbasierten Testfällen ermitteln. Eine Applikationen,
die auf Grundlage eines Modells erstellt worden ist, lässt
sich mit Hilfe von Back-to-Back-Testverfahren überprüfen,
die das Verhalten von Modell und Applikation miteinander
vergleichen.
Zur Verifizierung und Validierung lassen sich Modelle
für eine Reihe unterschiedlicher Simulationsmodi ein-
setzen [7]. Mit dem Begriff SIL wird das Ausführen einer auf einem Modell basierenden Applikation innerhalb der Host-Umgebung bezeichnet. Im Laufe der Simulation wird die Applikation mit Teststimuli beaufschlagt
und die Rückgabewerte werden gemessen und verifiziert.
Eine direkte Erweiterung dieses Vorgehens sind PIL-Simulationen. Hierbei wird eine Applikation für den Einsatz
in der späteren Zielumgebung kompiliert und auf einer
Hardwareplattform oder einem Simulator ausgeführt. Die
letzte Stufe des modellbasierten Testens ist Hardware-inthe-Loop (HIL), bei der die Applikation innerhalb einer komplexen Hardwareumgebung getestet wird. Alle Modi bieten
die Möglichkeit zum Back-to-Back-Testen, bei dem parallel
das Modell mit denselben Teststimuli beaufschlagt und im
Anschluss ein Abgleich der Ausgangswerte durchgeführt
wird. Wird für die Simulation ein ausführbares Modell verwendet, so trägt dieses Verfahren die Bezeichnung Modelin-the-Loop (MIL).
Ein entscheidendes Kriterium für die Signifikanz der
Testergebnisse ist eine möglichst hohe Übereinstimmung zwischen Testumgebung und der späteren Zielplattform. Um eine Erhöhung des Testaufwands aufgrund
einer zu großen Abweichung zwischen beiden Umgebungen zu vermeiden, sollte es die Zielsetzung sein, PIL-Simulation so früh wie mögliche in den Testablauf zu integrieren. Als einfach zugängliche Hardwarelösungen bieten
sich hier Evaluation-Boards an.
3 PIL-Simulation mit Simulink
Die Modellierungsumgebung Simulink erlaubt es dem
Anwender ausführbare Modelle mit Hilfe einer grafischen
Oberfläche zu erstellen und mit Hilfe diverser Simulationsmodi zu testen. Im Falle von PIL muss ein spezieller Block
in das vorhandene Modell integriert werden.
Der PIL-Block hat die Aufgabe, die Zielumgebung an Simulink anzubinden und die Ausführung des zu verifizierenden Algorithmus auf der Zielplattform zu steuern [8].
Die Funktionalität des PIL-Blocks wird von einer modifizierbaren S-Funktion bestimmt. Sie besitzt einen Satz von Call-
2 • Tel. +49 8102 9876-0 • [email protected] • www.lauterbach.com
Lauterbach GmbH • Altlaufstraße 40 • D-85635 Höhenkirchen-Siegertsbrunn
3
Simulink
Callbacks
PIL-Block
Teststimuli
Ausgangswerte
Zielplattform
Abbildung 3: PIL mit Simulink
backs, die dazu verwendet werden, mit der Zielumgebung
zu interagieren (Abb. 3). Dazu wird jeder Callback vorab
mit bestimmten Simulationsereignissen verknüpft und bei
Eintreten dieser Ereignisse aufgerufen. Jeder Aufruf löst
dann die ihm vorher zugeordnete Aktion in der Zielumgebung aus. Diese zusätzliche Abstraktionsebene erlaubt es,
eine Vielzahl unterschiedlicher Zielplattformen an Simulink
anzubinden. Ob es sich um eine echte Hardwareplattform
oder eine Simulationsumgebung handelt, spielt dabei letztendlich nur eine untergeordnete Rolle. Allerdings ist es
erforderlich, dass jede Zielplattform sowohl die Kommunikation mit Simulink als auch die Steuerung über Callbacks
unterstützt. Hierbei erleichtern es dem Anwender vor allem
Codegeneratoren, eine kompatible Schnittstelle für die notwendigen Callbacks zu generieren.
5 Weiterentwicklung der Integrationsschnittstelle
Um die Nachteile bisheriger Lösungen zur Durchführung von PIL-Simulationen auszugleichen, wurde
ein neues Konzept für eine flexible Integrationsschnittstelle erarbeitet. Die Zielsetzung war es einen universellen Ansatz zu entwickeln, der zum einen
unabhängig vom eingesetzten Codegenerierungsprozess ist, und zum anderen sehr einfach auf neue
Zielplattformen portiert werden kann.
4 Einschränkungen
Die bisherige Umsetzung von PIL-Simulationen mit Simulink weist in der Praxis eine Reihe von Nachteilen auf:
Damit der neue Ansatz flexibel mit automatisch
oder manuell erstelltem Quellcode kombiniert werden kann, wird die Schnittstelle für die Callbacks der
S-Funktion dynamisch erzeugt. Hierzu ist es erforderlich, die Struktur des Quellcodes bei Generierung
der PIL-Infrastruktur zu analysieren. Außerdem wird
ein Debugger als neues Bindeglied für die Kommunikation zwischen Simulink und Zielplattform in die
Toolkette integriert. Aus Sicht von Simulink stellt der
Debugger eine einheitliche Schnittstelle für die Anbindung
verschiedener Zielplattformen zur Verfügung. So können
Entwicklungsumgebungen, die bereits während der Softwaredesignphase eingesetzt werden, auch nahtlos zur
Durchführung von PIL-Simulationen weiterverwendet werden. Eine schematische Darstellung der vorgeschlagenen
Integrationsschnittstelle ist in Abb. 4 zu sehen.
• Treiber für die Kommunikation mit Simulink müssen
an die Konfiguration der jeweiligen Zielplattform
angepasst werden.
• Toolketten sind nur auf den Einsatz von automatisch generiertem Quellcode hin ausgelegt.
• Keine Unterstützung bei der Migration von Legacy Modulen mit bereits vorhandenem Quellcode.
• Beim Einsatz von Schnittstellen der Zielplattform für die Kommunikation mit Simulink, die nicht
funktional von der Applikationsschicht entkoppelt
sind, können Belegungskonflikte auftreten.
• Begrenzung der gleichzeitig zulässigen PIL-Blöcke
auf Modellebene [10] schränkt die Skalierbarkeit ein.
5.1 Analyse der Quellcodestruktur
Der Anwender hat die Möglichkeit, die Schnittstelle zwischen Simulink und der Applikation eigenständig zu konfigurieren. Hierzu wird die Struktur des Quellcodes analysiert und grafisch aufbereitet. Über einen Dialog kann der
Anwender eine Abbildungsvorschrift zwischen den Callbacks der S-Funktion und den Funktionen des Quellcodes
definieren. Im nächsten Schritt können dann die Parameter auf Modellebene mit ihrer Entsprechung auf Quellcodeebene verknüpft werden. Nachdem der Anwender die
Konfiguration der Schnittstelle abgeschlossen hat, werden
automatisch passende Wrapper als Bindeglied zwischen
S-Funktion und Quellcode für die Zielumgebung generiert
Im Falle von PIL wird der Algorithmus in der Zielumgebung in der Regel nicht in Echtzeit ausgeführt,
sondern inkrementell für jedes Simulationsintervall [9].
Pro Intervall müssen alle notwendigen Parameter initialisiert, die Eingangswerte an die Zielumgebung übergeben
und die resultierenden Ausgangswerte abgeholt werden.
3 • Tel. +49 8102 9876-0 • [email protected] • www.lauterbach.com
Lauterbach GmbH • Altlaufstraße 40 • D-85635 Höhenkirchen-Siegertsbrunn
4
ANFORDERUNGEN
MODELLIERUNG
MODELL
BACK-TO-BACK TEST
CODEGENERIERUNG
QUELLCODE
ANALYSE DER QUELLCODESTRUKTUR
BUILD-PROZESS
API
APPLIKATION
DEBUGGER
DEBUGSCHNITTSTELLE
ZIELUMGEBUNG
PIL-SIMULATION
Abbildung 4: Konzept der Integrationsschnittstelle
(Abb. 5). Die Wrapper haben während der Simulation die
Aufgabe, Callbacks, die vom PIL-Block ausgegeben werden, so umzusetzen, dass die zugeordneten Funktionen
aufgerufen und Variablen mit den korrekten Werten belegt
werden. Des Weiteren wird auf Basis der Schnittstellenkonfiguration Quellcode für die Erstellung der S-Funktion
des PIL-Blocks erzeugt.
Das beschriebene Verfahren weist eine hohe Portierbarkeit auf, da es sowohl in Kombination mit Codegeneratoren als auch bei manuell erstelltem Quellcode
verwendet werden kann. Strukturelle Unterschiede,
verursacht durch unterschiedliche Codegenerierungsprozesse, können bei der Schnittstellenkonfiguration berücksichtigt werden. Damit die neue Integrationsschnittstelle in zahlreichen Umgebungen wirkungsvoll eingesetzt
werden kann, muss der Entwicklungsschwerpunkt auf diese automatische Analyse der Codestruktur gelegt werden.
1. Konfiguration
S-Funktion
Initialisiere
Modellparameter
Berechne
Ausgangswerte
Quellcode
5.2 Uniforme Anbindung der Zielumgebung
Der zweite wichtige Faktor für die leichte Portierbarkeit
der Integrationsschnittstelle ist der Einsatz eines Debuggers mit API-Schnittstelle. Diese erlaubt es, unterschiedliche Zielplattformen über eine generische Schnittstelle an die Modellierungsumgebung anzubinden. Weitere Softwareanpassungen sind hierzu nicht erforderlich.
Über spezielle Schnittstellen, wie z.B. JTAG, kann der
Debugger dann die Programmausführung in der Zielumgebung steuern und auf Modellparameter zugreifen.
Es kann bereits während der Softwaredesignphase sichergestellt werden, dass der Debugger diese grundsätzliche
Unterstützung für die Zielumgebung anbietet.
5.3 Design eines Prototypen der Integrationsschnittstelle
Zur Umsetzung des vorgeschlagenen Konzepts in der Praxis wurde ein Prototyp der Integrationsschnittstelle entwickelt. Dieser besteht aus einem Framework mit grafischer
Oberfläche (Abb. 6) für die Generierung der PIL-Infrastruktur. Der Anwender kann damit schrittweise alle notwendigen
Einstellungen vornehmen, um einen Block des Modells in
einen PIL-Block umzuwandeln. Sind nicht alle Schritte not-
Funktion Step
Callback 1
Funktion Init
Callback 2
2. Generierung
S-Funktion
Callbacks
PIL-Block
Abbildung 5: Analyse der Quellcodestruktur
Quellcode
Wrapper
Applikation
wendig, so lassen sie sich einzeln deaktivieren. Ein Start
der Simulation führt nun automatisch eine PIL-Simulation
mit Hilfe der Zielumgebung aus. Der Prototyp ist in der Lage,
Quellcode der Programmiersprache C zu analysieren und
Funktionen mit skalaren Argumenten zu verarbeiten. Zur
Durchführung der PIL-Simulation wurde eine Unterstützung für die API-Schnittstelle von TRACE32 implementiert.
Außerdem kann der Build-Prozess modifiziert werden,
um auch die automatisch generierten Wrapper zu integrieren und die Applikation anschließend in die Zielumgebung
zu laden.
4 • Tel. +49 8102 9876-0 • [email protected] • www.lauterbach.com
Lauterbach GmbH • Altlaufstraße 40 • D-85635 Höhenkirchen-Siegertsbrunn
5
Aufgrund seiner modularen Struktur wird mit dem vorgeschlagenen Ansatz eine hohe Skalierbarkeit erreicht.
PIL-Blöcke können flexibel mit den übrigen Elementen der Modellierungsumgebung kombiniert werden,
sodass die leichte Erweiterbarkeit bestehender bzw.
die einfache Integration in neue Modelle gegeben ist.
Des Weiteren erlaubt der Rückgriff auf die API-Schnittstelle des Debuggers die gleichzeitige Anbindung multipler
Zielumgebungen.
viert bzw. deaktiviert. Mit Hilfe eines Testframeworks wer
den die Eingänge des Steuerungsmodells im Laufe der
Simulation mit Teststimuli beaufschlagt und der Ausgang mit den zulässigen Referenzwerten abgeglichen
LighTs Control (LTC)
This controller allows following light modes: manual On/OFF, automatic ON/FF (based on external light intensity).
LightOfF State (LOF)
2
<light_intensity>
light_intensity
<[0 100]>
REQ: LTC_UC2_REQ3
>
reset
reset
MinLightOff
ctr_out
<ctr_out>
>=
CTR
intensity_isOff
Driver Intention Switch (DIS)
HysteresisStepsOff
.
REQ: LTC_UC2_REQ4
1
States in AUTO Mode (SAM)
LightON State (LON)
<light_switch>
light_switch
<[0 2]>
REQ: LTC_UC2_REQ3
false
<light_intensity>
<
reset
reset
MinLightOn
ctr_out
headlight
>=
CTR1
1
OR
headlight_auto
intensity_isOn
HysteresisStepsOn
headlight_auto_old
true
.
<u2 ~= 0>
REQ: LTC_UC2_REQ5
.
REQ: LTC_UC2_REQ1
Initial Headlight State (IHS)
<light_intensity>
MinLightOff
0
headlight_manualOff
<ctr_out>
.
headlight_manualOn
1
headlight
<[0 1]; held>
*
REQ: LTC_UC1_REQ1
<=
initial_headlight_state
false
1
z
<X0: 1; Ts: -1>
REQ: LTC_UC2_REQ2
.
<u2 ~= 0>
1
z
<X0: 0; Ts: -1>
Abildung 7: Modell der Lichtsteuerung
(Abb. 7).
Der zugehörige C-Quellcode wurde bereits im Rahmen
der SIL-Simulation aus dem Modell der Lichtsteuerung
abgeleitet. Somit konnte dieser auch unverändert für
die PIL-Simulation übernommen werden.
Abbildung 6: Graphische Benutzeroberfläche
6 Beispielszenario
Zur Verifizierung des Prototypen wurde er für die Adaption eines existierenden Testszenarios eingesetzt.
Das Testszenario umfasst den Back-to-Back-Test einer Lichtsteuerung mittels SIL. Durch Einsatz der
neuen Integrationsschnittstelle war es das Ziel, das
Szenario auf eine Hardwareplattform mit TriCoreProzessor zu portieren. Für die Umsetzung wurden die
folgenden Komponenten verwendet:
Unter Verwendung der grafischen Benutzeroberfläche
des Prototypen wurde eine Analyse und Konfiguration der Schnittstelle durchgeführt. Für die Anbindung
an die Callbacks der S-Funktion enthält der Quellcode
eine Funktion für die Initialisierung aller Modellparameter und die Bestimmung des Modellausgangs nach
Ablauf eines Simulationsschritts. Bei der strukturellen
Analyse des Quellcodes wurden beide Funktionen
erfolgreich detektiert, sodass eine passende Konfiguration für die zugeordneten Callbacks erzeugt werden konnte (Abb. 8). Auf Basis dieser Schnittstellenkonfiguration konnte sowohl die S-Funktion als auch
die Wrapper in den Build-Prozess integriert werden.
Während der Simulation konnte die Hardwareplattform
erfolgreich über die API-Schnittstelle des Debuggers
• Simulink R2014b
• EZTEST
• TASKING VX-toolset for TriCore v4.3r3
• TRACE32
• TriBoard TC297TF
Das Ausgangssignal der Lichtsteuerung ist das Signal
zum Ein- bzw. Ausschalten des Lichts. Dieses Signal wird
auf Grundlage der angelegten Eingangsparameter akti-
Abbildung 8: Schnittstellenkonfiguration
5 • Tel. +49 8102 9876-0 • [email protected] • www.lauterbach.com
Lauterbach GmbH • Altlaufstraße 40 • D-85635 Höhenkirchen-Siegertsbrunn
6
Abbildung 9: Auswertung Back-to-Back-Test
gesteuert werden. Die Auswertung des Back-to-BackTests nach Abschluss des Tests zeigte die Übereinstimmung der Simulationsergebnisse für PIL und MIL (Abb. 9).
7 Zusammenfassung und Ausblick
Dieser Artikel stellt ein Konzept für eine flexible Integrationsschnittstelle zur Durchführung von PIL-Simulationen
vor, die in Zukunft dazu beitragen soll, die Hürden für
den praktischen Einsatz von PIL abzubauen. Mit dem
Konzept werden die folgenden Ziele realisiert:
[1] E. Dillaber, et al. Pragmatic Strategies for Adopting Model-Based
Design for Embedded Applications. SAE Technical Paper. 2010.
[2] ISO 26262. Road vehicles - Functional Safety. 2011.
[3] RTCA/EUROCAE. DO-331/ED-216 - Model-Based Development
and Verification Supplement to DO-178C [ED-12C] and DO-278A [ED109A]. 2011.
[4] S. Kirstan, and J. Zimmermann. Evaluating Costs and Benefits of
Model-Based Development of Embedded Software Systems in the Car
Industry – Results of a Qualitative Case Study. In Proceedings Workshop C2M: EEMDD - From Code Centric to Model Centric: Evaluating
the Effectiveness of MDD. ECMFA. 2010.
[5] M. Beine. A Model-Based Reference Workflow for the Development of
Safety-Critical Software. Embedded Real Time Software and Systems.
2010.
[6] S. Lillwitz, D. Krob. Model-Based Development of Safety-Critical
Software: Safe and Efficient. MEDengineering. 2012. Available online
at http://www.dspace.com [09/2015].
[7] S. A. A. Samie. Towards a Model Driven Approach in the Development and Validation of Real-Time Embedded Systems. International
Journal of Advances in Engineering and Technology. 2015.
[8] T. Erkkinen, and M. Conrad. Verification, Validation, and Test with
Model-Based Design. SAE Technical Paper. 2008.
[9] S. Lentijo, et al. A New Testing Tool for Power Electronic Digital
Control. In Proceedings of the IEEE 34th Annual Power Electronics
Specialists Conference. 2003.
[10] D. Divakar, and K. G. Ashwini. A Processor in Loop Test Method for
Life Critical Systems. In Proceedings of the International Colloquiums
on Computer Electronics Electrical Mechanical and Civil. 2011.
• Flexible Unterstützung für Codegeneratoren und
manuell erstellten Code
• Leichte Portierbarkeit auf unterschiedliche
Zielplattformen
• Nahtlose Integration in bestehende
Entwicklungsprozesse
• Kostenneutralität durch Weiterverwendung der
bestehenden Entwicklungsumgebung
Die Umsetzung der Integrationsschnittstelle als Prototyp
konnte außerdem bereits anhand eines konkreten Testfalls verifiziert werden.
In Zukunft muss die Robustheit des Prototypen in
Zusammenspiel mit verschiedenen Toolketten, Programmiersprachen und Testkonzepten untersucht und bei Bedarf erweitert werden. Des Weiteren muss die Skalierbarkeit der Lösung anhand weiterer Szenarien erprobt
werden.
Literaturverzeichnis
6 • Tel. +49 8102 9876-0 • [email protected] • www.lauterbach.com
Lauterbach GmbH • Altlaufstraße 40 • D-85635 Höhenkirchen-Siegertsbrunn