Integrierte, universelle Entwicklungsplattform für die fahrzeugbezogene Applikationsentwicklung mit Schnittstellen für FlexRay, CAN, LIN und K-Line

Größe: px

Ab Seite anzeigen:

Download "Integrierte, universelle Entwicklungsplattform für die fahrzeugbezogene Applikationsentwicklung mit Schnittstellen für FlexRay, CAN, LIN und K-Line"

Brigitte Fromm
vor 8 Jahren
Abrufe

1 Integrierte, universelle Entwicklungsplattform für die fahrzeugbezogene Applikationsentwicklung mit Schnittstellen für FlexRay, CAN, LIN und K-Line In zunehmendem Maße finden heute PC-basierte Entwicklungs- und Testplattformen Verwendung für fahrzeugbezogene Test-, Diagnose- und Visualisierungsanwendungen bis hin zur prototypischen Realisierung von Steuergeräten. Wegen der komfortablen Entwicklungsumgebung werden hierfür oft Windows basierte Standard Laptops oder Car-PCs eingesetzt. Da bei diesen Systemen aber oft zusätzliche, externe Erweiterungen erforderlich sind, stoßen diese oftmals schnell an ihre systembedingten Grenzen. Eine integrierte und dennoch universelle Entwicklungsplattform, die auch alle erforderlichen Schnittstellen enthält, bietet hier viele Vorteile. Der Standard PC - die suboptimale Entwicklungsplattform Der Vorteil PC-basierter Lösungen besteht vor allem in der hohen Leistungsfähigkeit sowie der Verfügbarkeit eingeführter Entwicklungsumgebungen und Softwarelösungen. Die für die Anwendung im Fahrzeug erforderlichen Schnittstellen zu den Kommunikationsbussen (CAN, FlexRay, LIN, MOST) sind aber in diesen Systemen oft nicht integriert und müssen daher aufwendig intern oder extern nachgerüstet werden. In Verbindung zu den oftmals ebenfalls erforderlichen Stromversorgungskomponenten führt dies schnell zu einem komplexen Aufbau der nur noch bedingt - zum Beispiel aufgrund von Sicherheitsbedenken - im Fahrzeug einzusetzen ist. Großflächige Displays und die hohe Rechenleistung haben häufig auch einen

Wegen der komfortablen Entwicklungsumgebung werden hierfür oft Windows basierte Standard Laptops oder Car-PCs eingesetzt.

2 erhöhten Strombedarf zur Folge. Insgesamt führt der große Unterschied zu der dann später im Fahrzeug verbauten Lösung oftmals dazu, dass Aussagen über z.b. Bedienbarkeit oder Anwendbarkeit nur bedingt getroffen werden können. Dies wiederum hat zur Folge, dass die Applikation früh auf die eigentliche Zielhardware portiert werden muss, um dann mit deren Hilfe und mehreren Iterationszyklen zur endgültigen Implementierung zu finden. Eine integrierte Lösung mit ausreichend Rechenleistung, geringem Stromverbrauch, einem für die Anwendung im Fahrzeug optimierten HMI-Konzept bei gleichzeitig verfügbarer, komfortabler Entwicklungsumgebung und Softwarelösungen bietet hier viele Vorteile in Bezug auf die "Time to Market". Die ideale Hardware - die Basis für eine integrierte Lösung Kernbestandteil einer integrierten Lösung ist der eigentliche Applikationsprozessor. Für eine schnelle Umsetzung der Applikationsentwicklung ist ein gebräuchliches Betriebssystem mit der Möglichkeit zur Reduktion des Implementierungsaufwands durch Integration kommerziell verfügbarer Lösungen ein klarer Zeit- und Kostenvorteil. Ein Standard-PC Betriebssystem wäre rein aus Sicht der Applikationsentwicklung die optimale Lösung, stellt aber in Bezug auf Prozessorleistung und Speicherbedarf zu hohe Anforderungen an die Ziel-Hardware. Als guter Kompromiss bietet sich hier Windows CE an. Die Systemanforderungen sind relativ gering bei gleichzeitig guter Unterstützung der Applikationsentwicklung. Embedded-PCs welche diese Anforderungen unterstützen sind in Form von Modulen verfügbar. Über die austauschbaren Module ist gleichzeitig auch noch eine Skalierbarkeit und Bezug auf die Performance gegeben. Deterministik - ein Muss bei der Fahrzeugkommunikation Ein Nachteil einer Einprozessorarchitektur auf Basis von Windows CE ist allerdings, dass dieses Konzept nicht zwingend echtzeitfähig sein muss. Eine ungeschickte oder auch unbedachte Programmierung, eine kurzfristige Systemüberlast oder auch Unterbrechungen in der Applikationsausführung aufgrund von Breakpoints während der Debug-Phase können zu ungewollten Problemen im Gesamtsystem führen. Kritisch ist dies vor allem bei modernen Kommunikationssystemen wie z.b. FlexRay, bei denen über die Zykluszeit vorgegebene Zeitfenster eingehalten werden müssen. Bei einer Entwicklungsplattform kann dieser Zielkonflikt relativ einfach durch eine Zweiprozessorarchitektur gelöst werden. Der zweite Prozessor - der Kommunikations-Controller - ist dabei idealerweise fertig konfiguriert und bedient alle angeschlossenen Kommunikationsbusse in Echtzeit.

3 Bild 1: IXXAT ATP Hardware Architektur Die Kommunikationsbusse - am "Puls" des Fahrzeugs Neben einer ausreichenden Anzahl der im Fahrzeug sehr gebräuchlichen CAN-, LIN- und K- Line - Schnittstellen, sollte eine universelle Entwicklungsplattform auch zukunftssicher mit einem FlexRay-Interface ausgestattet sein. Analog/Digital-IOs, serielle Schnittstellen, USB und Ethernet komplettieren die in 95% aller Fälle verwendbare Hardware. Die restlichen 5% der Anwendungsfälle sind meistens sehr spezifisch und können daher oftmals nicht mit der Standard-Hardware abgebildet werden. Eine Erweiterungsmöglichkeit in Form von internen Modulen kann dieses Problem aber lösen. Bild 1 zeigt die Architektur einer universell anwendbaren Hardware für eine Entwicklungsplattform. Die Applikationsschnittstelle - Konzentration auf das Wesentliche Der Entwickler einer Applikation im Umfeld eines Fahrzeugs sollte sich auf seine eigentliche Aufgabe konzentrieren und sich nicht mit Problemen außerhalb seiner Kernkompetenz beschäftigen müssen. Die Initialisierungssequenzen von Kommunikationsbussen und die beim Empfangen bzw. Senden von Nachrichten erforderlichen Abläufe gehören meistens nicht dazu. Das im vorherigen Abschnitt vorgestellte HW-Konzept erleichtert die Umsetzung der zur Lösung dieses Zielkonfliktes erforderlichen Software-Konzepts: Die strikte Trennung von Applikations- und Kommunikations-Software. Ein entsprechendes Applikation Programming Interface (API) kann bei der vorgegebenen HW-Architektur sehr komfortabel als fertige DLL zur Ausführung auf dem Applikationsprozessor dargestellt werden. Die Funktionen der Kommunikationsbusse werden dabei soweit abstrahiert, dass der User lediglich einfache Primitives zur Initialisierung, dem Starten/Stoppen sowie zum Senden/Empfangen anwenden muss. Bild 2 zeigt beispielhaft einen Satz entsprechender Primitives.

Analog/Digital-IOs, serielle Schnittstellen, USB und Ethernet komplettieren die in 95% aller Fälle verwendbare Hardware.

4 Bild 2: IXXAT ATP API-Objekte Die Protokolle - der einfache Zugang zum Steuergerät Die bis hierher dargestellte Funktionalität ist ausreichend, um auf Nachrichtenebene mit dem Fahrzeug bzw. seinen Steuergeräten zu kommunizieren. Allerdings werden häufig standardisierte Transport- bzw. Diagnoseprotokolle verwendet um einen einheitlichen Zugang zu bestimmten Daten zu gewährleisten. Über eine weitere Abstraktionsschicht oberhalb des Kommunikations-APIs kann der Anwender hier ebenfalls entlastet werden. Erneut über das Konzept einer eigenständigen DLL können so vorgefertigte, getestete und bereits in vielen Anwendungen bewährte Protokolle als optionale Software angeboten werden. Der Umfang, die Komplexität und das Risiko der eigenen Applikationsentwicklung kann so weiter reduziert werden. Bild 3 zeigt die Software-Architektur einer idealen, universellen, skalierbaren Entwicklungsplattform.

Über eine weitere Abstraktionsschicht oberhalb des Kommunikations-APIs kann der Anwender hier ebenfalls entlastet werden.

5 Bild 3: IXXAT ATP Software Architektur Das SDK - eine optimal angepasste Entwicklungsumgebung Viele Entwickler für Applikations-Software auf dem PC benutzen heute Microsoft Visual Studio. Das Know-How welches sie sich in diesem Bereich angeeignet haben, sollte sinnvollerweise auch für die Entwicklung von Fahrzeugapplikationen wiederverwendet werden. Über ein Software Development Kit (Bild 4) wird dabei die vorhandene Entwicklungsumgebung auf die spezifischen Bedürfnisse der neuen Zielplattform angepasst. Diese kann dann als Target ausgewählt und danach der Code produziert, auf die Hardware geladen und getestet werden. Mitgelieferte Demo-Applikationen sind wichtige Elemente um den Einstieg in das neue Konzept noch weiter zu erleichtern. Im optimalen Fall kann so durch "Umschalten" des Targets einer bestehenden Windows-Applikation auf die Entwicklungsplattform der Code durch einfache Re-Compilation auf der neuen Ziel-Hardware lauffähig gemacht werden. Das Debugging beschränkt sich dann lediglich auf das "Fine- Tuning" der Applikation auf der neuen Hardware.

Über ein Software Development Kit (Bild 4) wird dabei die vorhandene Entwicklungsumgebung auf die spezifischen Bedürfnisse der neuen Zielplattform angepasst.

6 Bild 4: Software Development Kit Die Zukunft - heute schon verfügbar Die Automotive Testplattform von IXXAT (ATP) setzt dieses Konzept konsequent um. Mit diesem Produkt wird eine Entwicklungsplattform zur Verfügung gestellt, mit deren Unterstützung sehr schnell Lösungen umgesetzt werden können, die im automotiven Umfeld mit FlexRay, vier CANs, LIN und K-Line kommunizieren. Mit dem optionalen Touchscreen können zudem grafische HMI-Funktionen umgesetzt werden. Der Schritt von der Implementierung auf der Testplattform zum kostengünstigen Serienprodukt wird durch den einfach durchzuführenden Design-Shrink ebenfalls erleichtert. Aktuell noch nicht verfügbare Protokollimplementierungen können ebenfalls leicht nachgerüstet werden, so dass in letzter Konsequenz auf Basis eines Baukastenprinzips sehr einfach und mit wenig Aufwand komplette, kundenspezifische Implementierungen realisiert werden können.

und K-Line kommunizieren. Mit dem optionalen Touchscreen können zudem grafische HMI-Funktionen umgesetzt werden.

Ähnliche Dokumente

Agile Vorgehensmodelle in der Softwareentwicklung: Scrum

C A R L V O N O S S I E T Z K Y Agile Vorgehensmodelle in der Softwareentwicklung: Scrum Johannes Diemke Vortrag im Rahmen der Projektgruppe Oldenburger Robot Soccer Team im Wintersemester 2009/2010 Was