Ziel dieser Studie ist die Evaluierung der AUTOSAR-Entwicklungsumgebung der schwedischen Firma ArcCore AB: Arctic Studio, welches auf dem Eclipse-basierten Framework Artop aufsetzt. Dieses Software-Werkzeug soll für die ITK Engineering AG auf seine Einsatzfähigkeit und Eignung im Rahmen von AUTOSAR-Projekten mit Kunden und Partnern der Automobilbranche geprüft werden. Kontext der Studie ist das von der ITK Engineering AG geleitete Innovationsprojekt IM_ARC_CORE. Zur Evaluierung der Entwicklungsumgebung Arctic Studio werden exemplarische Funktionalitäten nach dem AUTOSAR-Standard modellbasiert realisiert. Evaluierungskriterien sind hauptsächlich die von AUTOSAR definierten Spezifikationen und die von der ITK Engineering AG festgelegten Anforderungen, die im Rahmen dieses Projektes geprüft werden. Bestandteil dieser Arbeit ist des Weiteren eine ausführliche Einführung in die Thematik AUTOSAR. Dieser aktuell an Bedeutung gewinnende Automotive Embedded Software Standard wird vor dem Hauptteil vorgestellt.

Textprobe: Kapitel 4.2.3, Erstellung einer AUTOSAR-basierten Funktionalität und Interaktion mit modellbasierten Code-Generatoren: Bei der Erstellung einer Embedded Funktionalität wurde bei der ITK Engineering AG intern ein Bezug zu einer anderen Studie hergestellt. Um an dieser Stelle nur die wichtigsten Eckdaten dieser Arbeit zu nennen, soll gesagt werden, dass es sich um eine Drehmoment-Regelung für einen BLDC (Brushless Direct Current)-Motor handelt. Auf Applikationsebene soll eine SWC mit einem Runnable den notwendigen Regler-Algorithmus enthalten. Für die Regelung soll die SWC des Weiteren vier Eingänge für gemessene Spannungswerte – zum Zeitpunkt dieser Bearbeitung standen vier statt wie letzten Endens festgelegt fünf Eingänge fest – und sechs Ausgänge für PWMs bieten. Der Entwurf von Regelungen, wie sie beispielsweise hier angesprochen werden, betrifft in der AUTOSAR-Terminologie die SWC-Implementierung. Für eine innovative Ingenieursarbeit ist zum Entwurf solcher komplexen Algorithmen die Modellbasierte Entwicklung unumgänglich. Bei der ITK Engineering AG werden zu diesem Zwecke in erster Linie zwei leistungsfähige Produkte genutzt: TargetLink der Firma dSPACE GmbH und Embedded Coder von The MathWorks, Inc. Dienen als modellbasierte Entwicklungswerkzeuge und Code-Generatoren. Beide basieren auf MATLAB/Simulink. Im Zusammenhang mit der hier angesprochenen Funktionalität wurde der Embedded Coder genutzt. Es soll daher anfangs der für die Entwicklung eines Embedded Systems relevante Punkt der Interaktion zwischen einem AUTOSAR-Tool und einem BMT betrachtet werden. AUTOSAR bezeichnet Tools wie TargetLink und Embedded Coder wie schon erwähnt als Behaviour Modeling Tools. Interaktion mit TargetLink: Bevor die vorgestellte Funktionalität und der Bezug zu Embedded Coder vertieft werden, gilt es an dieser Stelle auch das Zusammenwirken von Arctic Studio und TargetLink zu thematisieren. Es soll hier anhand des vorherigen Beispiels auf das grundsätzliche Vorgehen eingegangen werden. Wurde bei den Konfigurationen im Arctic Studio mit dem SWC Builder der gewünschte Rahmen für eine SWC erstellt, so kann die erstellte ARXML-Datei in TargetLink importiert werden. Im Anhang soll hierzu die ARXML-Datei des vorherigen Beispiels betrachtet werden, wobei die SWC in diesem Fall eine einzige Schnittstelle nutzt. Es wird ausschließlich die LED angesprochen. Für den Import eines ARXML-Files bietet TargetLink eine spezielle Funktion, die aus dem MATLAB Command Window heraus aufgerufen wird. Dazu wird der Aufruf ‘tl_generate_swc_model’ genutzt. Dieser Aufruf kann mit einer Vielzahl an Eingabewerten erfolgen, wobei immer in der Aufruf-Klammer folgende Semantik zu beachten ist ('Parameter1','Parameter1_Wert','Parameter2',…). Die Parameter-Liste kann in dem Buch ‘Virtuelle Integration modellbasierter Fahrzeugfunktionen unter Autosar’ von Dipl. Inform. Alexander Michailidis u.a. eingesehen werden. Es handelt sich um eine Funktion mit zahlreichen Optionen. Ausgelassene Parameter nehmen default-Werte an. Ein exemplarischer Aufruf würde hier lauten: ‘tl_generate_swc_model('Model','MyModel','DestSubsystem','MyModel/SWC','SwcDescFileNames', {'led_rte_system.arxml', 'ArcCore_Services_IoHwAb.arxml'}) ’ Besonders wichtig ist es, bei der Interaktion von beiden Software-Tools zu beachten, dass man jeweils auf der gleichen Release des Standards AUTOSAR arbeitet, damit die ARXML-Files kompatibel sind. Mit dem Aufruf des Beispiels soll auf einen wichtigen Aspekt, im Umgang mit der Import-Funktion hingewiesen werden. Dabei beeinflussen die ersten zwei Parameter ausschließlich die Hierarchie des TargetLink-Modells und die hierfür verwendete Namensgebung. Dem Parameter 'SwcDescFileNames' kommt die Hauptrolle zu. Für diesen Parameter wurden in dem Beispiel bewusst zwei Werte in einem Cell Array übergeben: Es handelt sich zum einen um das ARXML-File ‘led_rte_system.arxml’, indem die Information über die Applikationsebene enthalten ist und zum anderen um das ARXML-File ‘ArcCore_Services_IoHwAb.arxml’. Zum Verständnis muss darauf hingewiesen werden, dass für den Port der SWC ein Interface genutzt wird, das zuvor in der Konfiguration speziell für das Modul IoHwAb geladen wurde. Dies kann per Rechts-Klick auf ein Projekt in der Option ‘Properties’ erfolgen. Um den Rahmen der Applikation fehlerfrei in TargetLink importieren zu können, muss daher auch diese Zusatz-Information übergeben werden. Das geladene ARXML-File muss zuvor im ArcCore-Repository ausfindig gemacht und in das von TargetLink verwendete Arbeitsverzeichnis gespeichert werden. Nach einem erfolgreichen Import, kann in TargetLink die Modellbasierte Entwicklung der gewünschten Funktionalität auf Basis der im SWC Builder angefertigten Grundstrukturen erfolgen und der zugehörige Quell-Code generiert werden. Im Anhang kann die Datei ‘led_rte_system.arxml’ eingesehen werden. In der XML-Struktur verweisen die Elemente mit ‘/ArcCore/Services/IoHwAb/Interfaces/…’ auf das hinzuzufügende ARXML-File ‘ArcCore_Services_IoHwAb.arxml’. Um den Durchlauf einer exemplarischen Interaktion mit einem Code-Generator zu vervollständigen soll hier noch auf den generierten Code hingewiesen werden. Es wurde modelbasiert die gleiche Invertierungslogik wie im vorherigen Beispiel, diesmal in TargetLink, erstellt. Neben der Hauptdatei, die TargetLink am Name der SWC orientiert ‘Blinker.c’ nennt erstellt der Code-Generator noch RTE-Dateien und Header-Dateien. Die von TargetLink generierte ‘Blinker.c’ kann im Anhang eingesehen werden zu beachten sind die verwendeten Schnittstellen. Es müssen je nach Art der erstellten Funktion neben den Hauptdateien zusätzliche Dateien, die generiert wurden, mit in das Arctic Studio-Projekt eingebunden werden. So können z.B. bestimmte Datentypen der Applikation in zusätzlichen C-Dateien und Header-Files vom Code-Generator gespeichert werden. Interaktion mit Embedded Coder: Die am Anfang dieses Unterkapitels angesprochene Motorregelung, die in einem Runnable integriert werden soll, erfordert insgesamt elf Schnittstellen. Es müssen vier Eingänge mit Rports für die ADC-Werte, sechs Ausgänge mit Rports für die PWM-Werte und ein Timing Event für die zyklische Aktivierung vorgesehen werden. Auf topologische Überlegungen – Strukturierung der Applikation in SWCs und Runnables – wird hier der Einfachheit halber nicht eingegangen. Wie schon in den Ausführungen zur AUTOSAR Methodology erläutert, spielt die Implementierung der Applikation bei der Erstellung eines Embedded Systems eine eigene Rolle. AUTOSAR sieht vor, dass die Implementierung parallel zur Konfiguration der BSW erfolgt. Es gilt also den Verantwortlichen für diese Activity eine Basis für ihre Tätigkeit bereitzustellen. Der Schritt Implement Component wird auf Basis von Component related templates durchgeführt. Bei der Arbeit mit dem Arctic Studio, wird hierfür das mit dem SWC-Builder bearbeitete SWC Template, ähnlich wie in den vorherigen Beschreibungen zu TargetLink, in den Embedded Coder importiert. Der Regelungsalgorithmus kann dann auf dieser Basis, einer Art SWC-Rahmen, entworfen werden und der hierzu generierte Code vor dem Build-Prozess im Workflow des Arctic Studio zurückimportiert werden. Parallel zur Implementierung der Applikation muss die BSW konfiguriert werden. Der entscheidende Punkt bei diesem Vorgehen besteht darin die Schnittstellen-Kompatibilität zu gewährleisten. Das soll heißen, dass die im SWC Builder definierten Schnittstellen und ihre zugewiesenen Interfaces, so wie sie im zugrundeliegenden ARXML-File abgespeichert werden, von dem Code-Generierungs-Tool für die Applikation – in diesem Fall Embedded Coder – korrekt entschlüsselt werden. Nur dann ist es mit Blick auf komplexere Applikationsstrukturen mit einer Vielzahl von SWCs, Runnables und eventuell Inter-Runnable-Kommunikationen, sinnvoll die Interaktion von Arctic Studio als AUTOSAR Tool mit einem modellbasierten Code-Generator zu nutzen. Es gilt also hier in einem verhältnismäßig simplen Beispiel dieses Zusammenwirken zu prüfen. Im Folgenden soll ein Abriss des gewählten Vorgehens gegeben werden. Im SWC Builder werden folgende Schritte durchgeführt: Es wird eine SWC des Typs ApplicationSoftwareComponentType angelegt und für diese werden zehn Rports erstellt. Es wird ein Runnable für diese SWC angelegt, dem wiederum zehn SynchronousServerCallPoints mit jeweils einer ServerCallPointOperation hinzugefügt werden. Jeder dieser ServerCallPointOperations wird dann einem der angelegten Rports zugewiesen. Dem Runnable wird auf der gleichen Gliederungsebene ein TimingEvent zugeordnet. Nachdem das Mapping der SWC im Extract Builder vollzogen und die für das IoHwAb-Modul relevanten Interfaces geladen wurden, werden über den BSW Builder im Modul IoHwAb vier Signale der Kategorie ‘Analog Signal’ und sechs Signale der Kategorie ‘PWM Signal’ angelegt. Es soll nicht weiter auf Details der BSW-Konfiguration eingegangen werden, da die relevanten Aspekte für diese Betrachtung auf der Applikationsebene liegen. Trotzdem sei darauf hingewiesen, dass für die Signale der Kategorie ‘PWM Signal’ der Typ ‘IOHWAB_PWM_DUTY’ spezifiziert werden sollte. Für die Motorregelung ist es relevant, dass einstellbare Tastverhältnisse für die PWMs übergeben werden. Im Anschluss ist es nun elementar im SWC Builder den angelegten Ports die für das IoHwAb-Modul geladenen Interfaces zuzuweisen. Die vier Rports für die ADCs benötigen jeweils das Interface ‘VoltageInput’, während die sechs Rports für die PWMs jeweils ein ‘PWMDutyOutput’-Interface erfordern. Die im Runnable angelegten ServerCallPointOperations werden für die ADCs auf ‘Get’ und für die PWMs auf ‘Set’ gesetzt. Der im Arctic Studio weiter vorgesehene Workflow wurde bereits erklärt. Für die Interaktion mit dem Embedded Coder ist aber vorerst das erstellte SWC Template, das mit dem SWC Builder konfiguriert wurde, relevant. Um grundsätzlich das Zusammenwirken mit dem Embedded Coder zu evaluieren, gilt es zu prüfen, ob das erstellte ARXML von letzterem eingelesen werden kann, bevor eine Probe-Applikation mit diesem Code-Generator erstellt und in das Arctic-Studio Projekt eingebunden wird. Es muss betont werden, dass für eine erfolgreiche Erstellung des Embedded Systems mit der gewünschten Applikation noch zahlreiche andere Gesichtspunkte untersucht werden müssen. So ist z.B. in diesem Fall die Anforderung, dass der Regler-Algorithmus alle 100 µs aufgerufen werden sollte, eine besondere Herausforderung für das AUTOSAR OS: Hier müsste höchstwahrscheinlich aufgrund der sehr kurzen Task-Zykluszeit eine andere Möglichkeit zur zyklischen Aktivierung der SWC geprüft werden. Diese Aspekte können hier nicht weiter untersucht werden. Es steht wie gesagt die grundsätzliche Kompatibilität im Vordergrund. Wie TargetLink bietet auch Embedded Coder Import-Funktionen für ARXML-Dateien, die aus MATLAB heraus aufgerufen werden. Die ARXML-Datei, die wie es eben beschrieben wurde, mit dem SWC Builder, erstellt wurde, kann im Anhang eingesehen werden: Um den Umfang des ARXML-File auf das Nötigste zu reduzieren, wurden die gleichartigen Schnittstellen dort nur jeweils doppelt, statt vierfach und sechsfach aufgelistet. Das ARXML ist also nicht vollständig. Die ausgelassenen Abschnitte sind mit ‘… …’ gekennzeichnet. Die ARXML-Funktionen, die für den Import in den Embedded Coder genutzt werden, lauten in diesem Fall der Reihe nach: ‘importerObject = arxml.importer('MOTOR_BSW_Konfig_1_SWC.arxml') importerObject.setDependencies('ArcCore_Services_IoHwAb.arxml') importerObject.createComponentAsSubsystem('/Motor_ASCT') ’. Wie man sehen kann, weicht das Vorgehen mit dem Embedded Coder hier von dem mit TargetLink ab. Es muss eine Reihe von Aufrufen getätigt werden, die Stück für Stück zum Ziel führen. Der Name ‘importerObject’ ist hier willkürlich für das Objekt gewählt, in den der Import stattfinden soll. Über den zweiten Aufruf ‘….setDependencies(…’ wird wieder ein Bezug zu dem ARXML-File erstellt, das Informationen zu den genutzten Interfaces enthält. Dieses File sollte im Arbeitsverzeichnis liegen. Der letzte Aufruf ‘….createComponentAsSubsystem(…’ veranlasst dann auf Grundlage der beiden vorherigen Befehle das Erstellen einer AUTOSAR atomic software component als Simulink atomic subsystem. Wie auch bei TargetLink verläuft der erprobte Import für das Beispiel mit dem Embedded Coder bei dem geschilderten Vorgehen problemlos. Ein Modell kann mit der üblichen Ansicht im Embedded Coder geöffnet werden. Es weist die passenden Schnittstellen mit der modellbasierten Darstellung auf. Nachdem die Erstellung des Rahmens für eine Applikation im Zusammenspiel von Arctic Studio und Embedded Coder vorerst erfolgreich verlaufen ist, wurde aus Planungsgründen im Projekt beschlossen, in einem nächsten Schritt die Ansteuerung der PWM-Ausgänge aus der Applikationsebene in die BSW näher zu untersuchen. Die ADCs werden in dieser Arbeit nicht mehr angesprochen.

• Steuergerät

• Arctic Studio

• AUTOSAR

• Software

Ferdinand Schäfer absolvierte von 2009-2013 ein Bachelor-Studium der Fahrzeugtechnologie an der Hochschule Karlsruhe -Technik und Wirtschaft. Die vorliegende Studie fertigte er im siebten Semester seines Studiums bei der ITK Engineering AG an.