AT511297A2 - Verfahren zur Erzeugung eines Modells einer Kommunikationsaufgabe - Google Patents

Abstract

Um aus einer abstrakt definierten Kommunikationsstruktur automatisiert ein Modell erstellen zu können, wobei Änderungen an einzelnen Softwarekomponenten des Modells (1) möglich sein sollen, wird vorgeschlagen, die Relationen zwischen der Information in der abstrakten Beschreibung und den zielsystemunabhängigen Softwarekomponenten zu speichern.

Description

AV-3492 AT

Verfahren zur Erzeugung eines Modells einer Kommunikationsaufgabe

Die gegenständliche Erfindung betrifft ein Verfahren zur Erzeugung eines Modells einer Kommunikationsaufgabe aus zielsystemunabhängigen Softwarekomponenten, wobei die Kommunikationsaufgabe in Form einer abstrakten Beschreibung vorgegeben ist.

Es ist z.B. aus der EP 2 154 606 A1 bekannt, eine auf einem Zielsystem ablauffähige Konfiguration zur Umsetzung einer Automatisierungsaufgabe auf einem Prüfstand aus einer Bibliothek einer Anzahl von abstrahierten, zielsystemunabhängigen Softwarekomponenten zusammenzustellen und die gewählten zielsystemunabhängigen Softwarekomponenten über ihre Datenkanäle zur Realisierung einer Automatisierungsaufgabe zu einem Modell zusammenzuschalten. Dieses Modell wird von einem Anwender manuell durch die Auswahl, das Parametrieren und das über Datenkanäle Verschalten zielsystemunabhängiger Softwarekomponenten Schritt für Schritt gebildet, z.B. durch Zeichnen in entsprechender Software mit grafischer Oberfläche. Der nächste Schritt, aus diesem Modell durch Transformation in zielsystemabhängige Softwarekomponenten eine ablauffähiges Konfiguration (also im Wesentlichen ein ausführbares Computerprogramm) zu bilden, diese zu instanziieren und über deren Kommandointerface zu parametrisieren, kann dabei automatisch ablaufen. Ein solches Verfahren ist in der EP 2 154 606 A1 beschrieben.

Dieses Verfahren erlaubt es, auch noch zur Laufzeit der Konfiguration am Zielsystem Änderungen daran vorzunehmen, in dem nur einzelne Softwarekomponenten geändert, ergänzt oder ausgetauscht werden müssen, ohne dabei das Gesamtsystem stoppen zu müssen.

Typische Automatisierungsaufgaben für Prüfstands-Anwendungen können aber leicht mehrere tausend solcher verschalteter Softwarekomponenten enthalten. Das manuelle Erstellen eines solchen Modells ist dabei mit erheblichem Aufwand verbunden. Noch mehr Aufwand kann entstehen, wenn solche Konfigurationen, insbesondere über längere Zeiträume hinweg, gewartet werden müssen. Darunter fällt beispielsweise das Anpassen des Modells bzw. der Konfiguration an die sich stets weiter entwickelnden oder geänderten Anforderungen am Prüfstand, wie z.B. ein Motorprüfstand, Rollenprüfstand, etc. zum Testen bzw. Entwickeln von Fahrzeugen oder Komponenten davon (wie z.B. Verbrennungsmotor, Getriebe, Antriebsstrang, etc ). Das erfordert unter Umständen nur geringfügige Änderungen an der Konfiguration, wie z.B. das Hinzufügen neuer Datenkanäle, das Ändern bestimmter Parameter einzelner Komponenten, wie beispielsweise ein Verstärkungsfaktor, oder das Ändern von Nachrichten-Identifiern von Meldungen auf Kommunikationsbussen, usw.

In der Praxis wird ein nicht unbeträchtlicher Teil dieser Komponenten für Datenkommunikation zwischen dem Prüfstandsystem (Prüfstandssteuerung, Prüfstandsautomatisierung, Prüfstandsrechner, Datenerfassung, etc.) selbst und eingebetteten Systemen am Prüfling, wie cm-cs-au -1-

Printed: 26-07-2012 E014.1 10 2012/50289

AV-3492 AT z.B. Motorelektronik, Hybrid-Steuergerät, ABS System, usw., benötigt. Diese Datenkommu-nikation läuft heutzutage üblicherweise über Bussysteme wie CAN oder FlexRay. Um die Datenkommunikation auf diesen Bussen zu planen und abstrakt zu beschreiben, haben sich bestimmte Standards zur Beschreibungen der Kommunikationsstruktur und der Kommunika-5 tionsaufgaben durchgesetzt, beispielsweise FIBEX oder DBC. FIBEX (Field Bus Exchange Format) ist z.B. ein XML basiertes Datenformat zur Beschreibung komplexer, Nachrichtenorientierter Kommunikationssysteme, wie beispielsweise FlexRay oder CAN. Diese Beschreibungsfiles werden am Prüfstand üblicherweise vorgegeben, z.B. vom Fahrzeughersteller entwickelt und gewartet, um damit beispielsweise die Entwicklung der Subsysteme (Mo-10 torelektronik, Hybrid-Steuergerät, etc.) zu koordinieren. Da diese Beschreibungsfiles alle Details der Datenkommunikation am Bus enthalten, kann ihr Aufbau äußerst komplex und umfangreich sein.

Am Prüfstand besteht nun oft die Aufgabe, Teile dieser Datenkommunikation durch das Prüfstandsystem zu simulieren bzw. zu übernehmen, zum Beispiel weil das betreffende 15 Steuergerät in der momentanen Prüfphase selbst noch nicht zur Verfügung steht. Man spricht dann von Restbussimulation am Prüfstand. Eine andere Aufgabenstellung könnte beispielsweise erfordern, dass die Signale bestimmter Knoten am Bus aufgezeichnet, überwacht oder bewertet werden müssen.

In jedem Anwendungsfall ist es aber erforderlich, einen Teil der Softwarekomponenten der 20 ablauffähigen Konfiguration für die Übernahme solcher Kommunikationsaufgaben zu erstellen und zu parametrieren. Auch hier kann es schnell zu sehr vielen, z.B. hunderte bis tausende, solcher Signale und Softwarekomponenten kommen. Es ergibt sich also wieder ein erheblicher Aufwand, der vom Anwender vorweg manuell durchgeführt werden muss. Dazu wurde in der DE 10 2004 001 596 A1 bereits vorgeschlagen, aus Eingabedaten und Konfigu-25 rationsdaten in Form eines FIBEX-Files die Konfiguration eines Flexray-Kommunikations-busses automatisiert zu erstellen. Mit diesem Verfahren wird also ein Bussystem zur Abarbeitung von Kommunikationsaufgaben auf einem Zielsystem betrieben. Eine vorgegebene, abstrakt definierte Kommunikationsstruktur (z.B. als FIBEX File) kann daher automatisiert z.B. in einen FlexRay Bus-Knoten umgesetzt werden, was den Aufwand zur Erstellung einer 30 ablauffähigen Konfiguration auf einem Zielsystem erheblich erleichtert.

Das Problem dabei ist jedoch, dass Änderungen in der Definition der abstrakten Kommunikationsstruktur nicht ohne weiteres in eine Änderung des Modells und damit auch nicht in eine Änderung der ablauffähigen Konfiguration am Zielsystem gemappt werden kann. Bei solchen, auch nur kleinen, Änderungen muss vielmehr der gesamte Prozess nochmals durch-35 laufen werden. Dazu muss aber das Bussystem gestoppt werden. Mit diesem Verfahren -2-

Printed: 26-07-2012 E014.1

10 2012/50289 AV-3492 AT können somit keine punktuellen Änderungen am Bussystem vorgenommen werden, ohne das gesamte Bussystem zu stoppen.

Es ist daher eine Aufgabe der gegenständlichen Erfindung, die oben angeführten Nachteile der bekannten Verfahren zur Durchführung einer Kommunikationsaufgabe, die in einer abs-5 trakten Definition der Kommunikationsstruktur beschrieben ist, zu beheben.

Diese Aufgabe wird gelöst, indem die Relationen zwischen der Information in der abstrakten Beschreibung und den zielsystemunabhängigen Softwarekomponenten gespeichert werden.

Das ermöglicht es, einen direkten Zusammenhang auf Komponentenebene herzustellen und damit bei Änderungen nur einzelne Komponenten ändern zu müssen. io Die gegenständliche Erfindung wird nachfolgend unter Bezugnahme auf die Figuren 1 bis 3, die schematische und vorteilhafte Ausgestaltungen der Erfindung zeigen, näher erläutert.

Dabei zeigt

Fig.1 ein Verfahren zur Erzeugung einer ablauffähigen Konfiguration nach dem Stand der Technik, 15 Fig.2 ein Beispiel eines Modells aus zielsystemunabhängigen Softwarekomponenten und

Fig.3 ein erfindungsgemäßes Verfahren zur Erzeugung eines Modells.

Die gegenständliche Erfindung nutzt z.B. das Verfahren der EP 2 154 606 A1, um aus einem Modell 1 bestehend aus (mehr oder weniger) abstrakten, zielsystemunabhängigen Software-20 komponenten eine auf einem Zielsystem ablauffähige Konfiguration 3 zu erzeugen. Unter einer ablauffähigen Konfiguration wird im Wesentlichen ein ausführbares Programm verstanden. Je nachdem wo dieses Programm ablaufen soll (Zielsystem), wird die ablauffähige Konfiguration in unterschiedlichen Ausprägungen bzw. Programmcode vortiegen. Die dazu notwendigen Abläufe sind ausführlich in der EP 2 154 606 A1 beschrieben und sind vereinfacht 25 in Fig.1 dargestellt. Ein Anwender 2 erstellt ein Modell 1 und greift dabei z.B. auf eine Bibliothek 5 vorhandener zielsystemunabhängiger Softwarekomponenten zu. Aus diesem Modell 1 wird eine ablauffähige Konfiguration 3 erzeugt, die auf das Zielsystem 4, z.B. ein Prüfstandsoder Automatisierungsrechner oder eine Plattform wie z.B. dSpace® oder LabView™ auf einem Rechner, geladen wird und dort, z.B. zum Durchfuhren einer Automatisierungs- oder 30 Kommunikationsaufgabe, ausgeführt wird.

Erfindungsgemäß wird nun aus der abstrakten Beschreibung einer Kommunikationsstruktur, z.B. in Form eines bekannten FIBEX oder DBC-Files, das Modell 1 oder ein Teil des Modells 1 erstellt. Die abstrakte Kommunikationsstruktur wird folglich aus zielsystemunabhängigen Softwarekomponenten, die z.B. in der Bibliothek 5 abgelegt sind, zusammen gesetzt. Dazu 30 ’3- fc*Q7-201t

AV-3492 AT können die notwendigen Softwarekomponenten auch automatisch instanziiert und gegebenenfalls zur späteren Wiederverwendung auch in der Bibliothek 5 abgespeichert werden. Z.B. könnten dazu Vorschriften definiert sein, wie bestimmte Angaben in der abstrakten Kommunikationsstruktur, in Softwarekomponenten umgewandelt werden. Ein solches Map-ping ist an sich hinlänglich bekannt, weshalb hier nicht näher darauf eingegangen wird. Der Anwender wird dabei davon entlastet, aufwändig und fehleranfällig die Softwarekomponenten Stück für Stück selbst im Modell 1 zu erstellen und zusammenzuschalten, da dieser Schritt nun automatisch mit der in der Beschreibung einer Kommunikationsstruktur befindlichen Information ablaufen kann. Der Vorteil tritt besonders deutlich bei komplexen Bussystemen wie 2.B. FlexRay unter Verwendung einer FIBEX Beschreibungsdatei oder CAN unter Verwendung einer DBC-Datei, zu Tage. FIBEX und DBC sind dabei vorgegebene, bekannte Standards zur abstrakten Beschreibung einer Kommunikationsstruktur und werden folglich hier als bekannt vorausgesetzt und nicht näher erläutert. Im Folgenden wird das unter Bezugnahme auf die Fig.2 am Beispiel einer simplen CAN Kommunikation und deren Beschreibung in einer DBC-Datei beschrieben.

Eine CAN-Nachricht „TestMsg“ beinhaltet z.B. zwei Signale, Signal_A und Signal_B, was in einer Kommunikationsstruktur 6 in Form einer DBC-Datei folgendermaßen beschrieben sein kann. BO_ IDx TestMsg: 8 node_y SG_ Signal_B : 32|8@1+ (1,0) [0|0] SG_ Signal_A : 0|16@1- (1,0) [0|0]

Diese abstrakte Beschreibung wird in ein Modell 1 (bzw. Teilmodell) aus, hier vier, zielsystemunabhängigen Softwarekomponenten 10,11,12,13, wie in Fig.2 dargestellt, umgewandelt. Die CAN-Nachricht „TestMsg“ enthält zwei Signale bestimmter Länge und bestimmten Typs.

Auf diese Weise wird in einer Transformationseinheit 14, z.B. ein Computer, die gesamte abstrakte Beschreibung einer Kommunikationsstruktur 6, wie in Fig.3 gezeigt, in ein Modell 1 oder ein Teilmodell eines Modells 1 umgewandelt. Gegebenenfalls kann dabei auf bereits definierte Softwarekomponenten aus der Bibliothek 5 zurückgegriffen werden Der restliche Ablauf ist wie bisher, z.B. wie in der EP 2 154 606 A1 und oben unter Bezugnahme auf die Fig.1 beschrieben.

Weiters ist erfindungsgemäß vorgesehen, die Relationen zwischen der Information in der Beschreibungen der Kommunikationsstruktur 6 und den daraus automatisch erzeugten zielsystemunabhängigen Softwarekomponenten im Modell 1 separat abzuspeichem und zu -4-

Printed: 26-07-2012 E014.1 10 2012/50289

AV-3492 AT verwalten, z.B. in einer Speichereinheit 7. Der Zusammenhang kann z.B. über eindeutige Identifier in der Kommunikationsstruktur 6 und im Modell 1 hergestellt werden, wie anhand des folgendes Beispiels erläutert.

Jede Softwarekomponente im zielsystemunabhängigen Modell 1 hat eine eindeutige identifi-5 kation. Das betrifft im Wesentlichen die darin konfigurierten Komponenten und verbindende Kanäle. Subelemente wie Parameter der Komponente können über die Komponenten-ID und einem eindeutigen Namen ebenfalls unverwechselbar identifiziert sein. Andererseits sind in der Kommunikationsstruktur, also z.B. im FIBEX bzw. im DBC File, Signale oder Nachrichten über eindeutige Namen definiert. Nehmen wir an, das FIBEX (oder DBC) File selbst ist ein-10 deutig identifiziert, z.B. über primäre Identifikatoren wie über Projektname und Version, oder einer beliebigen anderen Konvention. Eine in der Speichereinheit 7 gespeicherte Relation könnte dann z.B. lauten: [FIBEX „ProjektXYZ.VI 23“].[Signal „aaa27“].[Parameter ,,BIT-P0SITI0N“].[Value=16] =>ergibt=> [Komponente GUID=XYZ],[Parameter ,,Startbit“3.[Value=16] 15 Das Signal aaa27 der Kommunikationstruktur „ProjektXYZ.VI23“ wird daher eindeutig auf eine Softwarekomponenten XYZ im Modell 1, mit den angeführten Parametern, gemappt.

Wird nun durch Vergleich zweier Kommunikationsstrukturen 6 erkannt dass die primäre Identifikationen gleich sind, es also z,B. das Signal „aaa27" wieder gibt, sich dort aber der Parameter Z von W1 auf W2 geändert hat, kann das in der ablauffähigen Konfiguration 3 20 punktgenau nachgezogen werden, indem also die Komponente GUID=XYZ, Parameter Z von W1 auf W2 geändert wird. Das kann nun wieder nur für diese Softwarekomponente gemacht werden, ohne dabei das Gesamtsystem am Zielsystem 4 zu stoppen.

Oder wenn die zugrunde liegende Kommunikationsstruktur nun z.B. kein Signal „aaa27" mehr enthält, kann die entsprechende Softwarekomponente (und möglicherweise weitere, 25 daraus entstandene Softwarekomponenten und davon gespeiste Kanäle) im Modell 1 gelöscht werden und die ablauffähigen Konfiguration 3 entsprechend zielgenau geändert werden. Auch das Hinzufügen von Elementen ist damit möglich. Das ist natürlich auch in die umgekehrte Richtung möglich.

Damit können bei einer Änderung, z.B. infolge einer Aktualisierung oder Änderung einer der 30 beiden Seiten, also entweder in der Beschreibungen der Kommunikationsstruktur 6 oder im Modell 1 aus zielsystemunabhängigen Softwarekomponenten, weiterhin beide Seiten durch Nachgenerieren der sich geänderten Teile konsistent gehalten werden. Wird z.B. die Kommunikationsstruktur 6 geändert, z.B. in dem ein Parameter geändert wird, kann über die gespeicherte Relation in der Speichereinheit 7 eindeutig und einfach die davon betroffene(n) m -5-

Printed; 26-07-2012 E014.1

10 2012/50289 AV-3492 AT

Softwarekomponente(n) im Modell 1 identifiziert und aktualisiert werden. Damit muss diese Änderung nur mehr auf die ablauffähige Konfiguration 3 am Zielsystem 4 übertragen werden, z.B. wie in der EP 2 154 606 A1 beschrieben, ohne dabei das Gesamtsystem stoppen zu müssen. Umgekehrt könnte auch der Anwender 2 in das Modell 1 eingreifen. Änderungen, 5 die dabei die Kommunikationsstruktur 6 betreffen können nun ebenfalls über die gespeicherte Relation in der Kommunikationsstruktur 6 nachgezogen werden. -6-

Claims (4)

1. Printed: 26-07-2012 E014.1 10 2012/50289 AV-3492 AT Patentansprüche 1. Verfahren zur Erzeugung eines Modells einer Kommunikationsaufgabe aus zielsystemunabhängigen Softwarekomponenten, wobei die Kommunikationsaufgabe in Form einer 5 abstrakten Beschreibung vorgegeben ist, dadurch gekennzeichnet, dass die Relationen zwischen der Information in der abstrakten Beschreibung und den zielsystemunabhängigen Softwarekomponenten gespeichert werden.
2. 2. Verfahren nach Anspruch 1, dadurch gekennzeichnet, dass das erzeugte Modell (1) in eine auf einem Zielsystem (4) ablauffähige Konfiguration (3) umgewandelt wird. io
3. 3. Verfahren nach Anspruch 1, dadurch gekennzeichnet, dass bei einer Änderung der Kommunikationsaufgabe in der abstrakten Beschreibung auch die über die gespeicherte Relation zugehörigen zielsystemunabhängigen Softwarekomponenten geändert werden.
4. 4. Verfahren nach Anspruch 1, dadurch gekennzeichnet, dass bei einer Änderung des Modells (1) auch die über die gespeicherte Relation zugehörige Kommunikationsaufgabe in 1 s der abstrakten Beschreibung geändert wird. -7-