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

Abstract

Eine Kommunikationsaufgabe in Form einer abstrakten Beschreibung wird automatisiert in ein Modell (1) umgewandelt, wobei die Relationen zwischen der Information in der abstrakten Beschreibung und den zielsystemunabhängigen Softwarekomponenten gespeichert werden, um Änderungen an einzelnen Softwarekomponenten des Modells (1) zu ermöglichen. Dazu erstellt ein Anwender (2) ein Modell (1) und greift auf z.B. in einer Bibliothek (5) vorhandene zielsystemunabhängige Softwarekomponenten zu. In einer Transformationseinheit (14) wird die abstrakte Beschreibung einer Kommunikationsstruktur (6) in ein Modell (1) oder einen Teil davon umgewandelt. In einer Speichereinheit (7) werden die Relationen zwischen den abstrakten Beschreibungen und den zielsystemunabhängigen Softwarekomponenten verwaltet. Aus diesem Modell (1) wird eine ablauffähige Konfiguration (3) erzeugt, die auf das Zielsystem (4) übertragen wird und dort ausgeführt wird.

Description

österreichisches Patentamt AT511 297 B1 2013-12-15

Beschreibung

VERFAHREN ZUR ERZEUGUNG EINES MODELLS EINER KOMMUNIKATIONSAUFGABE

[0001] 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 und die abstrakte Beschreibung in das Modell umgewandelt wird.

[0002] Die EP 2 068 214 A1 beschreibt eine grafische Programmerstellung anhand von definierten Grafikobjekten. Dabei erstellt ein Benutzer manuell einen technischen Prozess, indem er passende vordefinierte Grafikobjekte aus einer Datenbank auswählt und zusammenschaltet, wobei der Prozess zuerst durch Auswahl geeigneter Konstruktionselemente mechanisch festgelegt wird und danach den mechanischen Elementen Funktionen zugewiesen werden. Das danach durch Kompilieren erstellte Steuerprogramm kann dann in einer Steuerung ausgeführt werden. Eine solche manuelle Programmerstellung ist aber, insbesondere bei größeren Prozessen, sehr aufwendig.

[0003] 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 Paramet-rieren 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.

[0004] 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.

[0005] 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 z.B. Motorelektronik, Hybrid-Steuergerät, ABS System, usw., benötigt. Diese Datenkommunikation 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 Kommunikationsaufgaben durchgesetzt, beispielsweise FIBEX oder DBC. FIBEX (Field Bus Exchange Format) ist z.B. ein XML basiertes Datenformat zur Beschreibung komplexer, Nachrichtenorientierter Kommuni- 1 /7 österreichisches Patentamt AT 511 297 B1 2013-12-15 kationssysteme, 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 (Motorelektronik, 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.

[0006] 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 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.

[0007] In jedem Anwendungsfall ist es aber erforderlich, einen Teil der Softwarekomponenten der 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 2010 001 596 A1 bereits vorgeschlagen, aus Eingabedaten und Konfigurationsdaten in Form eines FIBEX-Files die Konfiguration eines Flexray-Kommunikationsbusses 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 ablauffähigen Konfiguration auf einem Zielsystem erheblich erleichtert. Ähnlich ist in der DE 10 2005 058 801 A1 Verfahren zur automatischen Erstellung von Software-Werkzeugen aus einer semantisch interpretierbaren Anlageninformation beschrieben.

[0008] 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 durchlaufen werden. Dazu muss aber das Bussystem gestoppt werden. Mit diesem Verfahren können somit keine punktuellen Änderungen am Bussystem vorgenommen werden, ohne das gesamte Bussystem zu stoppen.

[0009] 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 abstrakten Definition der Kommunikationsstruktur beschrieben ist, zu beheben.

[0010] Diese Aufgabe wird gelöst, indem bei der Modellerstellung 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.

[0011] 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 [0012] Fig.1 ein Verfahren zur Erzeugung einer ablauffähigen Konfiguration nach dem

Stand der Technik, [0013] Fig.2 ein Beispiel eines Modells aus zielsystemunabhängigen Softwarekompo nenten und [0014] Fig.3 ein erfindungsgemäßes Verfahren zur Erzeugung eines Modells.

[0015] Die gegenständliche Erfindung nutzt z.B. das Verfahren der EP 2 1 54 606 A1, um aus einem Modell 1 bestehend aus (mehr oder weniger) abstrakten, zielsystemunabhängigen Soft- 2/7 österreichisches Patentamt AT 511 297 B1 2013-12-15 warekomponenten 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 vorliegen. Die dazu notwendigen Abläufe sind ausführlich in der EP 2 154 606 A1 beschrieben und sind vereinfacht 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üfstands-oder Automatisierungsrechner oder eine Plattform wie z.B. dSpace® oder LabView™ auf einem Rechner, geladen wird und dort, z.B. zum Durchführen einer Automatisierungs- oder Kommunikationsaufgabe, ausgeführt wird.

[0016] 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, zusammengesetzt. Dazu 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 Mapping 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 z.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.

[0017] 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.

[0018] BO_ IDx TestMsg: 8 node_y [0019] SG_ Signal_B : 32|8@1+ (1,0) [0|0] [0020] SG_ Signal_A : 0|16@1- (1,0) [0|0] [0021] 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.

[0022] 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.

[0023] 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 abzuspeichern und zu verwalten, z.B. in einer Speichereinheit 7. Der Zusammenhang kann z.B. über eindeutige Identi-fier in der Kommunikationsstruktur 6 und im Modell 1 hergestellt werden, wie anhand des folgenden Beispiels erläutert. 3/7 österreichisches Patentamt AT511 297B1 2013-12-15 [0024] Jede Softwarekomponente im zielsystemunabhängigen Modell 1 hat eine eindeutige Identifikation. 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 eindeutig 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: [0025] [FIBEX „ProjektXYZ.VI23"].[Signal „aaa27"]. [Parameter „BIT-POSITION"].[Value=16] =>ergibt=> [Komponente GUID=XYZ].[Parameter „Startbit"].[Value=16] [0026] Das Signal aaa27 der Kommunikationstruktur „ProjektXYZ.VI 23" wird daher eindeutig auf eine Softwarekomponenten XYZ im Modell 1, mit den angeführten Parametern, gemappt.

[0027] 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 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.

[0028] Oder wenn die zugrunde liegende Kommunikationsstruktur nun z.B. kein Signal „aaa27" mehr enthält, kann die entsprechende Softwarekomponente (und möglicherweise weitere, 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.

[0029] Damit können bei einer Änderung, z.B. infolge einer Aktualisierung oder Änderung einer der 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) Softwarekomponentein) 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, die dabei die Kommunikationsstruktur 6 betreffen können nun ebenfalls über die gespeicherte Relation in der Kommunikationsstruktur 6 nachgezogen werden. 4/7

Claims (4)

1. österreichisches Patentamt AT511 297B1 2013-12-15 Patentansprüche 1. Verfahren zur Erzeugung eines Modells einer Kommunikationsaufgabe aus zielsystemunabhängigen Softwarekomponenten, wobei die Kommunikationsaufgabe in Form einer abstrakten Beschreibung vorgegeben ist und die abstrakte Beschreibung in das Modell (1) umgewandelt wird, dadurch gekennzeichnet, dass bei der Modellerstellung 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.
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 der abstrakten Beschreibung geändert wird. Hierzu 2 Blatt Zeichnungen 5/7