Project

General

Profile

Support Request #10909

Base support to receive ethernet bus data from vehicle

Added by hidden over 1 year ago. Updated about 1 year ago.

Status:
Closed
Priority:
Normal
Requester's Priority:
Normal
Topic:
DeviceTB::Ethernet
Resolution:
No Customer Feedback
Product Issue Numbers:
Platform:
FAQ Links:

Description

Supportanfragen

wir sind momentan dabei unsere Messtechnik zu optimieren und fragen uns, ob und wenn ja welche Möglichkeiten es gibt Ethernet-Traces (TCP BroadReach, PDU gemultiplext) aus dem Fahrzeug aufzunehmen und auf gleichem Wege auch Daten zu schreiben.

Ich hätte mal angenommen, dass es dafür schon Lösungen in Form von Codec-Filtern analog CAN-Config-Codec gibt.

Vielleicht könnt ihr mir ja spontan helfen, oder einen Wiki-Link dazu schicken?

Lösung

Der aktuelle Stand seitens ADTF schaut folgendermaßen aus:

Die aktuelle DeviceToolbox (3.1) Unterstützt passives Capturing von Ethernet-Frames von einem Netzwerkadapter mittels PCAP.
Ob klassisches Ethernet oder BroadR-Reach ist ein Detail des physischen Layers und für ADTF transparent.

Es gibt einen SOME/IP-Filter, der aus den Ethernet-Frames SOME/IP-Nachrichten extrahiert und als ADTF-Samples ausgibt.
Der Filter unterstützt aktuell SOME/IP (inkl. SOME/IP-TP) über UDP. IPv4 und IPv6 sowie VLANs werden unterstützt.
TCP wird aktuell noch nicht unterstützt, wird aber mit einem der kommenden Releases nachgereicht.

Es gibt ein SOME/IP-TraceView, welches u.a. folgende Informationen anzeigt:
  • Quell- und Ziel-Endpoint
  • die einzelnen Felder des SOME/IP-Header
  • Service Discovery Informationen (Options, Entries, usw.) bei SD-Nachrichten
  • Vorschau der rohen SOME/IP-Payload als Hex-String

Mit der DeviceToolbox 3.2 (steht kurz vorm Release) ist es möglich, die dekodierte Payload und damit die einzelnen Signale anzuzeigen.
Dafür ist allerdings eine Parser-Bibliothek nötig, welche die relevanten Informationen aus der ARXML-/FIBEX-/...-Datenbank bereitstellt.
Ein solcher Parser wird nicht mitgeliefert sondern muss selbst bereitgestellt werden.
Ob wir in Zukunft mal einen Parser mitliefern werden bzw. als gesonderte Leistung anbieten kann ich gerade nicht beantworten.

Unterstützung von Multiplexed PDUs ist nach meinem aktuellem Kenntnisstand Sache des Datenbank-Parsers und ansonsten für ADTF transparent.

Zum Schreiben/Manipulieren von Ethernet und SOME/IP-Samples gibts es aktuell keine Convenience-Funktionen seitens ADTF.
Ebenso gibt es noch keine En-/Decoder-Filter um die enthaltenen Signale gesondert auf Pins bereitzustellen.

Grundsätzlich können Samples natürlich manipuliert werden - "händisch" oder mithilfe eines ddl::Codec.
Es ist beispielsweise denkbar, neue SOME/IP-Samples zu erzeugen (oder ein vorhandenes zu manipulieren) und die enthalte Nachricht dann per UDP-Sink an eine bestimmte IP zu schicken.

Die aktive Teilnahme am SOME/IP-Netzwerk inkl. ServiceDiscovery ist aktuell noch nicht möglich, jedoch für ein künftigen Release vorgesehen.

Wie Tobi bereits erwähnt hat: unabhängig von SOME/IP gibt es noch den Anwendungsfall, wo die Signale direkt per UDP übertragen werden - ohne SOME/IP drumherum.

Sollte sich dieser UseCase großer Beliebtheit erfreuen, ist auch entsprechende Unterstützung in ADTF gut vorstellbar.


Files

pcap.zip (5.24 KB) pcap.zip hidden, 2020-03-27 09:34
SomeIP_DML_Services.zip (113 KB) SomeIP_DML_Services.zip hidden, 2020-03-31 07:30

Related issues

Related to Public Support - Support Request #12109: Filter for capturing Ethernet data and datatype to handle ethernet frames inside ADTFClosedActions
#1

Updated by hidden over 1 year ago

  • Project changed from Public Support to 11
  • Topic set to ADTF::CE
#2

Updated by hidden over 1 year ago

Hallo Steffi,

interessantes Thema, das ihr da habt.
Aktuell arbeiten wir gerade genau an so etwas. In der Device-Toolbox 3.1.0 ist zumindest eine Möglichkeit zum Darstellen der Messwerte vorhanden.
Beim aktuellen Stand der Entwicklung muss ich auf meinen Kollegen Wolfgang Wallner verweisen, der kann da mehr zu sagen.

Habt ihr bereits aufgenommene pcap-Traces, die ihr uns ggf. zur Verfügung stellen könntet?
Im Anhang habe ich eine kleine Beispielkonfiguration aus der Device-Toolbox 3.1.0 hinzugefügt. Bitte beachtet hierbei, dass die Device Toolbox als Ordner devicetoolbox im Unterordner addons der ADTF Installation liegen muss.

#3

Updated by hidden over 1 year ago

  • Status changed from New to In Progress
#5

Updated by hidden over 1 year ago

Benedict Hartmann wrote:

Hallo Steffi,

interessantes Thema, das ihr da habt.
Aktuell arbeiten wir gerade genau an so etwas. In der Device-Toolbox 3.1.0 ist zumindest eine Möglichkeit zum Darstellen der Messwerte vorhanden.
Beim aktuellen Stand der Entwicklung muss ich auf meinen Kollegen Wolfgang Wallner verweisen, der kann da mehr zu sagen.

Habt ihr bereits aufgenommene pcap-Traces, die ihr uns ggf. zur Verfügung stellen könntet?
Im Anhang habe ich eine kleine Beispielkonfiguration aus der Device-Toolbox 3.1.0 hinzugefügt. Bitte beachtet hierbei, dass die Device Toolbox als Ordner devicetoolbox im Unterordner addons der ADTF Installation liegen muss.

Das ist aber nur gültig, sofern es sich um SOME/IP Traffic handelt, bzw. wenn das Protokoll verwendet wird

#6

Updated by hidden over 1 year ago

Ja, Some/IP over TCP wird verwendet, aber eben auch PDU-Multiplexing. Die Datenbeschreibung habe ich hier mal angehangen.

Geh ich recht in der Annahme, dass ich für die Beispiel.Konfig eine ADTF 3 Installation brauche? Ich muss mal schauen, ob ich das bei uns im Fahrzeug zum Laufen bekomme und einen Trace ziehen kann…

Die Anbindung würde doch dann an ADTF via VN-5610A passieren, oder wäre da noch irgendeine andere Hardware nötig?

Können wir vielleicht auch mal zu dem Thema telefonieren um die Abstimmung ggf. zu verkürzen?

Beste Grüße

Steffi

#7

Updated by hidden over 1 year ago

Hallo Steffi,

zu dem Thema würde ich mich auch gerne einklinken. Wir arbeiten hier an verschiedenen aber verwandten Baustellen und müssen priorisieren. Daher wäre es super, wenn du deinen Use Case Möglichst genau beschreibst, dann können wir die Implementierung in die richtige Richtung lenken. Die folgenden Fragen kommen mir dabei in den Sinn (und bitte entschuldige die penetrante Frage nach SOME/IP, oft ist der Unterschied ggü. "PDUs über UDP" nicht klar):

  1. Service orientiert: Werden wirklich SOME/IP-*Dienste* benutzt (Publish/Subscribe/Service Discovery)?
    1. In welchem Format wird die Kommunikation beschrieben/definiert/modelliert?
      1. ARXML?
      2. Excel?
      3. was anderes?
  2. Botschaftenorientiert: Werden nur UDP Pakete verschickt, die PDUs enthalten (ähnlich wie CAN)?
    1. In welchem Format werden die Botschaften definiert?
      1. DBC?
      2. FIBEX?
      3. ARXML?
      4. Excel?
      5. was anderes?
  3. Gibt es fixe Adressen in der Vernetzung?
    1. fixe Sender-MAC?
    2. fixe Empfänger-MAC?
    3. fixe Sender-IP?
    4. fixe Empfänger-IP?

Es wäre sehr sehr hilfreich für uns, wenn du dir die Zeit nehmen und die Fragen, soweit möglich, beantworten könntest!

Danke!
Tobi

#8

Updated by hidden over 1 year ago

  • Status changed from In Progress to Customer Feedback Required
#9

Updated by hidden over 1 year ago

Hallo Steffi,

Danke für dein Interesse!

Der aktuelle Stand seitens ADTF schaut folgendermaßen aus:

Die aktuelle DeviceToolbox (3.1) Unterstützt passives Capturing von Ethernet-Frames von einem Netzwerkadapter mittels PCAP.
Ob klassisches Ethernet oder BroadR-Reach ist ein Detail des physischen Layers und für ADTF transparent.

Es gibt einen SOME/IP-Filter, der aus den Ethernet-Frames SOME/IP-Nachrichten extrahiert und als ADTF-Samples ausgibt.
Der Filter unterstützt aktuell SOME/IP (inkl. SOME/IP-TP) über UDP. IPv4 und IPv6 sowie VLANs werden unterstützt.
TCP wird aktuell noch nicht unterstützt, wird aber mit einem der kommenden Releases nachgereicht.

Es gibt ein SOME/IP-TraceView, welches u.a. folgende Informationen anzeigt:
  • Quell- und Ziel-Endpoint
  • die einzelnen Felder des SOME/IP-Header
  • Service Discovery Informationen (Options, Entries, usw.) bei SD-Nachrichten
  • Vorschau der rohen SOME/IP-Payload als Hex-String

Mit der DeviceToolbox 3.2 (steht kurz vorm Release) ist es möglich, die dekodierte Payload und damit die einzelnen Signale anzuzeigen.
Dafür ist allerdings eine Parser-Bibliothek nötig, welche die relevanten Informationen aus der ARXML-/FIBEX-/...-Datenbank bereitstellt.
Ein solcher Parser wird nicht mitgeliefert sondern muss selbst bereitgestellt werden.
Ob wir in Zukunft mal einen Parser mitliefern werden bzw. als gesonderte Leistung anbieten kann ich gerade nicht beantworten.

Unterstützung von Multiplexed PDUs ist nach meinem aktuellem Kenntnisstand Sache des Datenbank-Parsers und ansonsten für ADTF transparent.

Zum Schreiben/Manipulieren von Ethernet und SOME/IP-Samples gibts es aktuell keine Convenience-Funktionen seitens ADTF.
Ebenso gibt es noch keine En-/Decoder-Filter um die enthaltenen Signale gesondert auf Pins bereitzustellen.

Grundsätzlich können Samples natürlich manipuliert werden - "händisch" oder mithilfe eines ddl::Codec.
Es ist beispielsweise denkbar, neue SOME/IP-Samples zu erzeugen (oder ein vorhandenes zu manipulieren) und die enthalte Nachricht dann per UDP-Sink an eine bestimmte IP zu schicken.

Die aktive Teilnahme am SOME/IP-Netzwerk inkl. ServiceDiscovery ist aktuell noch nicht möglich, jedoch für ein künftigen Release vorgesehen.

Wie Tobi bereits erwähnt hat: unabhängig von SOME/IP gibt es noch den Anwendungsfall, wo die Signale direkt per UDP übertragen werden - ohne SOME/IP drumherum.

Sollte sich dieser UseCase großer Beliebtheit erfreuen, ist auch entsprechende Unterstützung in ADTF gut vorstellbar.

Hilft dir das schon weiter?
Wir können uns auch gerne per Telko weiter austauschen.

Viele Grüße

Wolfgang

#10

Updated by hidden over 1 year ago

  • Topic changed from ADTF::CE to DeviceTB::Ethernet
#11

Updated by hidden over 1 year ago

  • Project changed from 11 to Public Support
  • Subject changed from Ethernet-Traces im Fahrzeug to Base support to receive ethernet bus data from vehicle
  • Description updated (diff)
  • Status changed from Customer Feedback Required to To Be Closed
  • Private changed from Yes to No
  • Resolution set to No Customer Feedback
  • Affected Products ADTF Device Toolbox 3.1.0, ADTF Device Toolbox 3.2.0 added
#12

Updated by hidden over 1 year ago

Hallo Digitalwerk,

ich würde gerne noch auf die oben stehenden Fragen eingehen:

1.1 Unsere Serviceorientierte Kommunikation ist über ARXML beschrieben.

2.1 Die gemultiplexten Flexray-PDUs sind definiert über Excel und Fibex (müsste jedoch erst bei den Vernetzungskollegen angefragt werden)

3.1 Die Sender und Empfänger-IPs sind statisch / fix.

Die Serviceorientierte Kommunikation erfolgt via TCP. Die Verbindung wird einmalig aufgebaut und bleibt bestehen. Die PDU-Kommunikation erfolgt über UDP.

Die Kommunikationsbeziehung sieht folgendermaßen aus:
ZFAS –(SomeIP via TCP)--> GATEWAY –(SomeIP via TCP)--> ZDML
GATEWAY –(PDUs via UDP)--> ZDML

wobei das Gateway nur Routet

Ich hätte auch noch einige Fragen:

· Unterstützt die DeviceToolbox 3.2 bereits SomeIP via TCP?

· Wann erscheint die Device-Toolbox 3.2?

· Unterstützen die DeviceToolbox z.B. eine VN5610A direkt, oder werden die Ethernet-Frames per 100BaseT-Ethernet empfangen und müssen vorher über eine Bridge von BroadR-Reach umgewandelt werden?

· Unterstützt die Toolbox ADTF 2 oder ADTF 3?

Technisch (im Entwicklungsfahrzeug) wir das Thema von unserer Seite Herr Neuroth betreuen.
Ich könnte mir vorstellen - wie Sie vorgeschlagen haben - einen eigenen Parser zu verwenden um die Inhalte zu decodieren. Großes Interesse hätten wir daran auch schreibend auf die ETH-Schnittstelle zuzugreifen.

Unser (Wunsch-)Usecase wäre folgender:
Um Erprobungsfahrten zu Tracen soll im Fahrzeug aufgezeichnt werden. Am Platz sollen dann die Traces dann analysiert werden UND ins Zielsteuergerät eingespielt werden.

Viele Grüße
Johannes Reim

#13

Updated by hidden over 1 year ago

Hallo Johannes,

1.1 Unsere Serviceorientierte Kommunikation ist über ARXML beschrieben.

2.1 Die gemultiplexten Flexray-PDUs sind definiert über Excel und Fibex (müsste jedoch erst bei den Vernetzungskollegen angefragt werden)

3.1 Die Sender und Empfänger-IPs sind statisch / fix.

Die Serviceorientierte Kommunikation erfolgt via TCP. Die Verbindung wird einmalig aufgebaut und bleibt bestehen. Die PDU-Kommunikation erfolgt über UDP.

Die Kommunikationsbeziehung sieht folgendermaßen aus:
ZFAS –(SomeIP via TCP)--> GATEWAY –(SomeIP via TCP)--> ZDML
GATEWAY –(PDUs via UDP)--> ZDML

wobei das Gateway nur Routet

danke für das Feedback !
@Tobi: fyi

Technisch (im Entwicklungsfahrzeug) wir das Thema von unserer Seite Herr Neuroth betreuen.
Ich könnte mir vorstellen - wie Sie vorgeschlagen haben - einen eigenen Parser zu verwenden um die Inhalte zu decodieren. Großes Interesse hätten wir daran auch schreibend auf die ETH-Schnittstelle zuzugreifen.

Unser (Wunsch-)Usecase wäre folgender:
Um Erprobungsfahrten zu Tracen soll im Fahrzeug aufgezeichnt werden. Am Platz sollen dann die Traces dann analysiert werden UND ins Zielsteuergerät eingespielt werden

@Wolfi/Tobi: Könnt ihr hierzu eine Telko organisieren, um den Use Case genau zu erfassen, wo wir unetrstützen können bzw. was ggf. noch fehlt oder gesondert zugesteuert werden muss ? Danke !

Unterstützt die DeviceToolbox 3.2 bereits SomeIP via TCP?

Aktuell ist nur UDP angefragt und umgesetzt.
Eine TCP Unterstützung wird im Laufe der nächsten Releases kommen.

Wann erscheint die Device-Toolbox 3.2?

In den kommenden Wochen werden wir den finalen Stand abschließen können.
Ggf. bekommen wir im Vorfeld einen Preview Stand als BETA geliefert, sofern der Zustand der Funktionalitäten integriert und stimmig ist.

Unterstützen die DeviceToolbox z.B. eine VN5610A direkt, oder werden die Ethernet-Frames per 100BaseT-Ethernet empfangen und müssen vorher über eine Bridge von BroadR-Reach umgewandelt werden?

Der Ethernet Support der Devices basiert nicht auf der Vector API o.ä. Device Support, wir arbeiten analog zu Wireshark mit einer PCap Anbindung, sprich wir haben eine Streaming Source, die Daten von sämtlichen Ethernet Adaptern aufgreift. Im Nachgang extrahiert ein Filter die SOME/IP relevanten Daten. Hier ist es auch vorstellbar, einen zweiten Filter zu implementieren, der zb andere Protokolle spricht.

Ebenso kann die PCap Source gegen andere Devices (EB, Vector, ...) ausgetauscht werden, sofern sie diese Strukturen bereitstellen.
Eine Implementierung in ADTF / Device TB ist dazu aber derzeit nicht geplant und Geräteherstellern oder Dienstleistern aktuell überlassen.

Unterstützt die Toolbox ADTF 2 oder ADTF 3?

Die SOME/IP Unterstützung findet in Device TB 3.x statt und kann ausschließlich in ADTF 3.x verwendet werden.
ADTF 2.x ist abgekündigt und erfährt keine neuen Features, EOL ist Ende 2021.
Grundsätzlich empfehlen wir dringend, auch was Support, 3rd Party Abhängigkeiten und Platformunterstützung betrifft, zeitnah auf ADTF 3.x umzusteigen, Neuimplementierungen sollten ohnehin dort stattfinden.
Bei Fragen oder Unterstützung zur Migrierung oder ADTF 3.x allgemein (Support, Schulung) bitte jederzeit an uns wenden.
Wichtigste Infos zu dem Thema:

ADTF: ADTF 2.x vs ADTF 3.x Roadmap:
#16

Updated by hidden about 1 year ago

  • Status changed from To Be Closed to Closed
#17

Updated by hidden about 1 year ago

  • Related to Support Request #12109: Filter for capturing Ethernet data and datatype to handle ethernet frames inside ADTF added

Also available in: Atom PDF