Project

General

Profile

Actions

Support Request #10007

closed

Communication between dSpace VEOS and ADTF 3.x

Added by hidden over 4 years ago. Updated about 4 years ago.

Status:
Closed
Priority:
Normal
Customer:
AUDI
Department:
EF
Requester's Priority:
Normal
Support Level:
3rd Level
Resolution:
Workaround Available
Product Issue Numbers:
Affected Products:
Platform:
Topic:
ADTF::MessageBus
FAQ Links:

Description

Supportanfrage

Wir betreiben aktuell eine Co-Simulation zwischen dSpace VEOS und ADTF 2.14. Für den Datenaustausch gibt es von dSpace ein Blockset, das den ADTF-Messagebus benutzt.
Wir möchten nun für künftige Simulationen auf ADTF 3 umstellen. Leider kann uns dSpace nicht sagen, ob die Kopplung dann auch noch funktionieren wird. Die Aussage war lediglich: Wenn der Message-Bus gleich funktioniert, wird es wahrscheinlich gehen.
Leider haben wir in ADTF 3 nicht die gleichen Konfigurationsmöglichkeiten wie in ADTF 2 gefunden. Daher würde uns interessieren: Gibt es den Messagebus überhaupt noch und er heißt nur anders? Wenn ja, wie wird er konfiguriert?
Wenn nein: Wie ist es in ADTF 3 angedacht Daten mit Simulink bzw. dSpace Simulatoren auszutauschen?

Lösung

Die ADTF3 Message Bus Implementierung ist genau aus der Anforderung entstanden die "alte" ADTF2 dSpace Autobox Anbindung wieder einsetzen zu können. Ich kenne dSpace VEOS jetzt selbst nicht, denke aber das sollte klappen.

Wenn es eine allgemeine UDP Verbindung von seitens dSpace gibt, solltet Ihr das auf jeden Fall auch mit unseren "Demo UDP Sender To Non-ADTF Application" und "Demo UDP Receiver From Non-ADTF Application" Filtern bedienen können: https://support.digitalwerk.net/adtf/v3/adtf_html/page_demo_non_adtf_application_udp_sender_receiver.html

Bzgl. ADTF ICP Sinks und Sourcen: Die Kommunikation darin werden wir aus verschiedenen Gründen nicht offenlegen, wir bieten aber eine C++Library zu Integration in nicht-ADTF Applikationen an. Diese basiert aber auf einem gekapselten ADTF3 Subsystem, sodass sie nur auf den von ADTF3 direkt unterstützen Platformen lauffähig ist: https://support.digitalwerk.net/adtf/v3/adtf_html/page_demo_adtf_ipc_integration.html


Files

message_bus_compatibility_adtf3.zip (14 MB) message_bus_compatibility_adtf3.zip hidden, 2020-01-27 15:07
image001.png (9.74 KB) image001.png hidden, 2020-01-28 14:15
adtf1.description (2.74 KB) adtf1.description hidden, 2020-01-28 14:15

Related issues

Related to Public Support - Support Request #10828: Timing behaviour in ADTF Message BusClosedActions
Actions #1

Updated by hidden over 4 years ago

  • Project changed from Public Support to 11
  • Status changed from New to In Progress
  • Topic set to ADTF::MessageBus
  • Affected Products ADTF 3.6.2 added
Actions #2

Updated by hidden over 4 years ago

  • Status changed from In Progress to Customer Feedback Required
  • Resolution set to Workaround Available
  • Customer set to AUDI
  • Department set to EF

Hallo Franz,

der aus ADTF 2.x bekannte Message Bus wurde in ADTF 3.x durch IPC angepasst, eine Übersicht über die Änderungen findest du u.a. hier:

Das macht vieles einfacher, bedeutet aber für Non-ADTF Applikationen, die mit ADTF 2.x Message Bus kommunzieren, muss eine neue Lösung geschaffen werden.
Das liegt in diesem Fall bei dSpace, dass sie das tun. Oder eine Schnittstelle bereitstellen, seitens ADTF sind uns hier die Hände gebunden.

Für diese Use Cases gibt es eine interne Open Source Beispiel Anbindung des Message Bus aus ADTF 2.x an ADTF 3.x, die ihr dazu verwenden könnt:

Ob ihr damit hinkommt, und mit UDP auskommt, kann ich nicht sagen.
Ihr könnt aber gern daran mitarbeiten, die saubere Lösung wäre eigentlich eine direkte ADTF 3.x Anbindung.

Ich hoffe das beantwortet deine Fragen, mehr kann ich dir an dieser Stelle leider nicht out of the box anbieten.

Actions #3

Updated by hidden over 4 years ago

Hallo Florian,

vielen Dank für die Infos und das Beispiel. Wir werden probieren, ob wir damit zurecht kommen.
Eine schnelle Lösung seitens dSpace ist hier leider auch nicht zu erwarten. Kannst du uns deshalb vielleicht ein paar mehr Informationen über IPC UDP zukommen lassen kannst. Vielleicht ist es ja mit verhältnismäßigem Aufwand implementierbar. Wenn nicht, brauchen wir langfristig ohnehin eine Lösung seitens dSpace.
Von der Verbindung her werden wir wohl erst mal bei UDP bleiben, da es für allgemeine UDP-Verbindungen definitiv ein Blockset von dSpace gibt.

Viele Grüße
Franz

Actions #4

Updated by hidden over 4 years ago

Hi Frank,

die ADTF3 Message Bus Implementierung ist genau aus der Anforderung entstanden die "alte" ADTF2 dSpace Autobox Anbindung wieder einsetzen zu können. Ich kenne dSpace VEOS jetzt selbst nicht, denke aber das sollte klappen.

Wenn es eine allgemeine UDP Verbindung von seitens dSpace gibt, solltet Ihr das auf jeden Fall auch mit unseren "Demo UDP Sender To Non-ADTF Application" und "Demo UDP Receiver From Non-ADTF Application" Filtern bedienen können: https://support.digitalwerk.net/adtf/v3/adtf_html/page_demo_non_adtf_application_udp_sender_receiver.html

Bzgl. ADTF ICP Sinks und Sourcen: Die Kommunikation darin werden wir aus verschiedenen Gründen nicht offenlegen, wir bieten aber eine C++Library zu Integration in nicht-ADTF Applikationen an. Diese basiert aber auf einem gekapselten ADTF3 Subsystem, sodass sie nur auf den von ADTF3 direkt unterstützen Platformen lauffähig ist: https://support.digitalwerk.net/adtf/v3/adtf_html/page_demo_adtf_ipc_integration.html

Grüße,

Martin

Actions #5

Updated by hidden over 4 years ago

Hallo,

vielen Dank für die Infos. Wenn es mit der Autobox klappt, sollte es mit VEOS auch gehen. Wir werden diesen Ansatz als erstes probieren.
Dazu haben wir uns auch schon die Demo angeschaut, die ihr uns gesagt habt:
https://www.cip.audi.de/bitbucket/projects/OPENDEV/repos/adtf_community/browse

Dazu hätten wir noch eine Frage: Wir haben in dem Beispiel die Plugin-Datei nicht gefunden. Muss man sich das selbst kompilieren? Oder liegt das wo anders schon fertig ab? Wir warten leider immer noch auf unsere Visual-Studio Installation. :-/

Außerdem habe ich in der Demo jetzt nur den Fall gefunden, dass ADTF etwas empfängt. Gibt es auch ein Beispiel zum Senden von Daten?

Viele Grüße
Franz

Actions #6

Updated by hidden over 4 years ago

Hallo Franz,

Wir haben in dem Beispiel die Plugin-Datei nicht gefunden. Muss man sich das selbst kompilieren? Oder liegt das wo anders schon fertig ab? Wir warten leider immer noch auf unsere Visual-Studio Installation.

Richtig, dass ist ein reines Git Repo, Source Code, keine Binaries.
Wir können sie euch gerne kompilieren, wenn ihr derzeit keine Build Umgebung habt.
Ich nehme an es geht um Windows ?

Außerdem habe ich in der Demo jetzt nur den Fall gefunden, dass ADTF etwas empfängt. Gibt es auch ein Beispiel zum Senden von Daten?

Es gehen beide Richtungen, im src Ordner findet ihr die beiden ADTF Streaming Services:
  • Source zum Empfang der Daten
  • Sink für die Senderichtung
Actions #7

Updated by hidden over 4 years ago

Hi,

das wäre super, wenn ihr uns die einmal kompilieren könntet!
Ja genau, wir nutzen momentan Windows. Danke!

Ok, dann schau ich mir das nochmal genauer an.

Viele Grüße
Franz

Actions #8

Updated by hidden over 4 years ago

Hallo Franz,

anbei die Binaries.

Actions #9

Updated by hidden over 4 years ago

Hallo Florian,

nochmal danke für die Binaries. Damit funktioniert die Demo jetzt wunderbar.
Leider aber nur, wenn wir sie so belassen, wie sie ist. Wir möchten nun gerne eine von dSpace generierte description-Datei einbinden. Wenn wir aber den Dateinamen in der „default_system.adtfproperties“ auf die neue Datei anpassen, stürzt ADTF bereits bei der Initialisierung ab. Ich habe dir einen Screenshot und das description-File angehängt.

Kann es sein, dass diese Dateien nicht mehr kompatibel sind? Oder muss man noch etwas anderes beachten?

Viele Grüße
Franz

Actions #10

Updated by hidden over 4 years ago

Hi Franz,

ich kanns nicht ganz nachvollziehen, bzw. bei mir klappts. Hier mein Vorgehen:

  • Ich hab das Beispiel ADTF3 Projekt geöffnet.
  • Beim Media Description Service in den Properties euer .description File angegeben (anstatt des bisherigen)
  • Bei der Source dann unter "struct_name" "tmy_adtf_message" eingetragen und das ganze laufen gelassen.

Dann läuft es bei mir, aber mangels Gegenstelle sehe ich natürlich keine Daten.

Kannst Du euren Absturz und euer Vorgehen noch genauer beschreiben?

Grüße,

Maritn

Actions #11

Updated by hidden over 4 years ago

Hallo Martin,

Ok, das wundert mich. Wir werden es nochmal probieren und es dir dann genauer beschreiben, wenn es wieder nicht geht. Die Kollegin ist nur heute leider krank.
Hast du beim stream_name auch etwas angepasst?

Viele Grüße
Franz

Actions #12

Updated by hidden over 4 years ago

Hast du beim stream_name auch etwas angepasst?

nein habe ich nicht. Das bestimmt "nur" den Namen der Messages auf dem Bus. Der sollte für jede Source/Sink eindeutig sein. Da weiß ich leider nicht genau, was die Autobox da schickt bzw was sie erwartet. Da muss man letztendlich den Namen das Ports des Subgraphen aus der entsprechenden ADTF2 Config eintragen.

Grüße,

Martin

Actions #13

Updated by hidden over 4 years ago

Hallo Martin,

danke für den Tipp. Damit läuft es jetzt endlich und wir können sogar auch senden. ☺
Ich hätte nun noch 3 Fragen zur best practise:
Muss man jetzt je Stream ein eigenes Decode-Plugin einbauen oder kann der auch mehrere Streams? Gilt das gleiche für die Sink?
Wie werden die Descripton-Files der Sink erstellt. In ADTF2 gab es da einen Editor. Gibt es hier auch etwas ähnliches, oder muss man sich die Dateien selbst schreiben?

Viele Grüße
Franz

Actions #14

Updated by hidden over 4 years ago

Muss man jetzt je Stream ein eigenes Decode-Plugin einbauen oder kann der auch mehrere Streams? Gilt das gleiche für die Sink?

Meinst Du mit Decode Plugin die Source?

Ja da braucht's für jeden Stream eine eigene. Dadurch gibts ein 1:1 mapping zwischen den Properties und den Datenströmen.
Channel können sich aber alle Sinks und Sources ein und dieselbe Instanz teilen.

Wie werden die Descripton-Files der Sink erstellt. In ADTF2 gab es da einen Editor. Gibt es hier auch etwas ähnliches, oder muss man sich die Dateien selbst schreiben?

in <adtf_dir>/3rdparty/ddl_editor/bin gibts wieder so einen Editor. Ihr könnt aber auch den von ADTF2 weiterverwenden.

Es gibt aber eigentlich keine Grund da neue Description Dateien zu erstellen. Die aus eurer ADTF2 Konfiguration könnt ihr unverändert übernehmen.

Grüße,

Martin

Actions #17

Updated by hidden over 4 years ago

  • Project changed from 11 to 4
  • Subject changed from Kopplung von dSpace VEOS mit ADTF 3 to Communication between dSpace VEOS and ADTF 3.x
  • Description updated (diff)
  • Status changed from Customer Feedback Required to To Be Closed
  • Private changed from Yes to No
Actions #18

Updated by hidden over 4 years ago

Actions #20

Updated by hidden about 4 years ago

  • Support Level changed from 2nd Level to 3rd Level
Actions #22

Updated by hidden about 4 years ago

  • Status changed from To Be Closed to Closed
Actions #23

Updated by hidden about 4 years ago

  • Project changed from 4 to Public Support
Actions

Also available in: Atom PDF