Alle diejenigen, die oft Applikationsdatensätze miteinander vergleichen müssen, wissen, dass dies eine mühselige Aufgabe sein kann. Wie schön wäre es, wenn man einfach eine A2L-Beschreibungsdatei und mehrere Datensatzdateien in eine Software laden könnte und diese dann automatisch alle miteinander vergleicht. Wenn dann das Ergebnis noch übersichtlich dargestellt wird und man sich mittels starker Filter leicht auf die für einen selbst interessanten Variablen fokussieren könnte, wäre das ein großer Gewinn.
Das leistet IAV Macara.
Automatischer Datensatzvergleich und einen neu angelegten Datensatz mit manueller Datenübernahme und Schnellfilter.
Und IAV Macara kann noch viel mehr. Der Nutzer kann Daten aus mehreren Datensätzen zu einem neuen Datensatz zusammenführen und hier auch Änderungen vornehmen, also Einzelwerte aber auch Kennlinien und Kennfelder und deren Stützstellen editieren. Natürlich unter Einhaltung der in der A2L beschriebenen Regeln wie harte und weiche Grenzen oder Stützstellenmonotonie. Beim Ändern von Werten helfen jeweils passende Editoren und grafische Anzeigen. Die erstellten Datensätze können dann in den Formaten DCM, CDFX oder PaCo exportiert und auch wieder geladen werden.
Datenansicht im Kennfeld und die Überschreitung harter Grenzen aus der A2L
Für die Nutzung verschiedener Datenquellen stellt die Cloud-Funktionalität den Zugriff auf das Dateisystem und auf Schnittstellen z.B. zu AVL Creta und Etas INCA-Datenbank bereit. Interessiert? Dann kontaktieren Sie uns am besten per email über info@rac.de. RA Consulting ist exklusiver Wiederverkäufer für IAV Macara.
Hinweis: IAV Macara ist zurzeit nur für die Verwendung in der Europäischen Union freigegeben.
Darstellung des Ergebnisses der Plausibilitätsprüfung
Immer mehr Nutzer von DiagRA D und Silver Scan-Tool nutzen die Fernsteuermöglichkeit über die Webservices API. Über die Schnittstelle können externe Anwendungen auf demselben Rechner oder im lokalen Netzwerk nahezu die komplette Funktionalität der beiden Anwendungen nutzen. So lassen sich beispielsweise über ein Python-Skript Flash-Abläufe mit anschließenden Diagnosetests automatisieren oder ganz gezielt spezielle Diagnosetests an HiLs oder Prüfständen in die Experimente integrieren. Natürlich können auch immer wiederkehrende OBD-Tests sehr einfach automatisiert werden.
Technischer Hintergrund: Das Interface der Web Services wird dabei durch ein maschinell verarbeitbares Format gegeben, typischerweise durch WSDL (Web Services Description Language). Dabei wird das Netzwerkprotokoll SOAP (Simple Object Access Protocol) zur Kommunikation verwendet. Hierbei wird XML als Nachrichtenformat und das HTTP-Protokoll zur Kommunikation innerhalb des Netzwerks verwendet. Im Fall von DiagRA D/Silver Scan-Tool findet die Kommunikation zwischen einem Client-Programm und DiagRA D/Silver Scan-Tool statt, wobei DiagRA D/Silver Scan-Tool als Server-Anwendung dient. Die Webservices sind als API für SOAP implementiert, sodass der Nutzer sich weder um die Erstellung der XML-Nachrichten noch die HTTP-Kommunikation kümmern muss.
Das untenstehende Beispiel zeigt, wie mittels Python-Skript über DiagRA D erst die Kommunikation eingeleitet, dann von allen OBD-Steuergeräten alle Werte vom Mode $01, dann gezielt die Steuergeräteversorgungsspannung PID $42 und im Anschluss noch der MIL Status aus dem Mode $03 ausgelesen wird. Zum Abschluss wird die Kommunikation mit dem OBD-System wieder beendet. Als SOAP Client kommt im Beispiel ZEEP zum Einsatz. Eine Dokumentation der Kommandos findet sich direkt in bestehenden Installationen von DiagRA D oder Silver Scan-Tool im Ordner Samples.
Das Webservices-Plugin ist eine optionale Erweiterung einer DiagRA D oder Silver Scan-Tool Lizenz und kann entweder mit einer Lizenz mitbestellt oder nachträglich hinzugefügt werden.
Bei Interesse kontaktieren Sie uns bitte über info@rac.de.
Beispiel Python-Skript:
#!/usr/bin/python3
# -*- coding: utf-8 -*-
import sys
import time
# PLEASE NOTE:
# This script uses the third party package Zeep ("A fast and modern Python SOAP client").
# Find Zeep in the Python package index: https://pypi.org/project/zeep/
# Find its documentation here: https://docs.python-zeep.org/en/master/
# Should you be interested in logging, this might help you: https://docs.python-zeep.org/en/master/plugins.html
# Zeep project and sources on GitHub: https://github.com/mvantellingen/python-zeep
from zeep import Client, Transport, __version__ as zeep_version
# Configure web service connection.
# PLEASE NOTE:
# If web service is not running on local machine (localhost/127.0.0.1),
# you will have to call the login method at first, before being able to use any other method.
IP_ADDRESS = "localhost"
PORT = 1024
# Set 'INTRANET_ONLY', if an internet connection is not available.
# PLEASE NOTE:
# This requires the 'soapencoding.xsd' to reside in './resources' subfolder.
# It can be downloaded, here: http://schemas.xmlsoap.org/soap/encoding/
INTRANET_ONLY = False
# Web service constants
RETURN_CODE_SUCCESS = 0
COMMUNICATION_STARTED = 0
COMMUNICATION_STOPPED = 1
COMMUNICATION_ESTABLISHED = 2
class TransportIntranetOnly(Transport):
def load(self, url):
# See https://stackoverflow.com/a/40280341
if (url == "http://schemas.xmlsoap.org/soap/encoding/"):
url = "resources/soapencoding.xsd"
# print(url)
return super(TransportIntranetOnly, self).load(url)
def wait_for_communication(get_status):
result = False
while True:
communication_status = get_status()
print(f"Communication status: {communication_status}")
if (communication_status == COMMUNICATION_ESTABLISHED):
result = True
break
# Also leave loop if communcation has unexpectedly been stopped.
if (communication_status == COMMUNICATION_STOPPED):
print("Communication has been stopped.")
break
time.sleep(1) # Wait before next poll.
return result
def main(intranetonly):
print("Web service OBD sample | RA Consulting GmbH 2021 | www.rac.de")
print("")
# PLEASE NOTE:
# DiagRA D or Silver Scan-Tool needs to be running and web service needs to be activated.
wsdl = f"http://{IP_ADDRESS}:{PORT}/wsdl/IDiagRAWebservice"
if intranetonly:
client = Client(wsdl, transport=TransportIntranetOnly())
else:
client = Client(wsdl)
webservice = client.service
# factory = client.type_factory("ns0") # Needed to handle non-primitive argument and return types.
# Perform login.
# PLEASE NOTE:
# This is required if web service is not running on local machine (localhost/127.0.0.1).
# webservice.Login("Example python script")
try:
# Temporarily increase log level of the web service. Possible values are 1 to 7.
# The log file is very helpful if things don't work out as expected. It contains all the called methods, the given arguments, the results and the return codes.
# It is written to '%LocalAppData%\RA Consulting\DiagRA D\Log' or '%LocalAppData%\RA Consulting\Silver Scan-Tool\Log', respectively,
# and is called 'DiagRA_RemoteControl_*.log'.
# You can also set a permanent log level in the Windows registry. Have a look into DiagRA D's/Silver Scan-Tool's help file to find out how this is done.
webservice.Configure("LOGLEVEL", "5")
# Print versions.
webservice_version = webservice.GetVersion("")
print("Versions:")
print(f"- Python {sys.version}")
print(f"- Zeep {zeep_version}")
print(f"- Web service {webservice_version}")
print()
# Set addressword for OBD and obtain its index.
# PLEASE NOTE:
# If you like to communicate with a distinct ECU/addressword instead, you need to use 'GetECUIndex'
# and the web service's non-OBD methods (the ones not containing 'OBD' in their names).
# For a list of all available methods, see web service reference PDF that resides in
# subfolder '.\Samples\WebServices\Doc' of the installation directory.
obd_index = webservice.GetOBDIndex("33", "")
print(f"OBD index: {obd_index}")
if (obd_index < RETURN_CODE_SUCCESS):
print(webservice.GetLastErrorText())
else:
# OBD addressword has been successfully set.
# Now set protocol.
webservice.Configure("PROTOCOL", "ISO 15765-4 (CAN)")
# Try to start communication.
return_code = webservice.StartOBDCommunication(obd_index)
print(f"Start communication: {return_code}")
if (return_code == RETURN_CODE_SUCCESS):
# Communication could be started.
try:
# Wait until communication has fully been established, before requesting data.
communication_established = wait_for_communication(lambda: webservice.GetOBDCommunicationStatus(obd_index))
if communication_established:
# Read current data.
result = webservice.GetOBDAllCurrentData(obd_index)
print("Current Data: ")
for item in result:
print(item)
# Read module voltage.
result = webservice.GetOBDSingleCurrentData(obd_index, "42")
print("Control Module Voltage: ")
for item in result:
print(item)
# Get MIL status.
result = webservice.GetOBDMILStatus(obd_index)
print("Mode 3: ")
for item in result:
print(item)
finally:
# Stop communication.
return_code = webservice.StopOBDCommunication(obd_index)
print(f"Stop communication: {return_code}")
finally:
# Perform logout.
# webservice.Logout()
pass
if (__name__ == "__main__"):
main(INTRANET_ONLY)
https://www.rac.de/wp-content/uploads/2021/06/Webservices_Example3.jpg7221184Oliver Klinghttps://www.rac.de/wp-content/uploads/2019/07/logo-300x138.pngOliver Kling2021-06-18 07:38:512023-12-06 12:16:37Fernsteuerung von DiagRA D und Silver Scan-Tool über die optionale Webservices-API
Aktuelle Versionen Stand 9. Dezember 2020: 7.45.40
neues Aufzeichnungsformat MDF4 mit wählbarer MDF Version 4.2.0, 4.1.1, 4.1.0 oder 4.0.0
Wir haben den DiagRA X Viewer auf unserem Download-Server hinzugefügt. Es handelt sich dabei um ein Zusatztool, das die mit der Aufzeichnungsfunktion von DiagRA D erstellten MDF4-Dateien öffnen kann. Wir haben es für die Nutzung mit DiagRA D aus unserem Applikationstool DiagRA X ausgekoppelt. Für den Viewer benötigen Sie keine zusätzliche Lizenz (genauso wie bei XML-Convert und XML-to-Excel).
Das Hilfstool XML-to-PDF wurde durch das Tool „XML-Convert“ ersetzt. Die XML-zu-PDF-Konvertierungsfunktion ist wieder in diesem neuen Tool implementiert und zusätzlich gibt es eine Funktion XML-zu-HTML. Der Grund dafür ist, dass es immer mehr Probleme gibt, wenn Browser XML-Dateien unter Verwendung eines Stylesheets öffnen sollen. Installieren Sie das Tool einfach. Es entfernt das XML-zu-PDF-Tool und bietet die gleiche Funktionalität plus die HTML-Konvertierungsfunktion.
Mit XML-to-Excel lassen sich die OBD-Daten aus XML-Ausgaben der DiagRA D Messabläufe nach Excel konvertieren. Man kann mehrere XML-Dateien in ein Excel-File konvertieren, gleichzeitig oder auch nacheinander, um diese zu vergleichen.
Anpassungsarbeiten für die neue SAE J1979-2 sind gestartet. Wir erwarten eine erste Version in der Mitte des 1. Quartals 2021 bereitstellen zu können.
Umfangreiche Erweiterungen für NOx Binning und Green House Gas in SAE J1939 und in SAE J1979 Mode $09
Nur DiagRA D
Unterstützung für CAN FD. Es werden bereits viele Interfacetypen unterstützt. Die Kommunikation mit Steuergeräten, die CAN FD unterstützen ist um einiges schneller – vor allem die Flashprogrammierung über das DiagRA D Flash Plugin.
Autosar XML für die Parametrierung der FlexRay-Kommunikation
https://www.rac.de/wp-content/uploads/2020/12/Symbilbild.gif12801920Oliver Klinghttps://www.rac.de/wp-content/uploads/2019/07/logo-300x138.pngOliver Kling2020-12-16 10:08:062023-12-06 14:43:38Neues zu DiagRA D und Silver Scan-Tool
Das eintägige Training vermittelt DiagRA® D Usern einen umfassenden Einblick in die Funktionalitäten dieser Software, die bei der Entwicklung von Fahrzeugsteuergeräten zur Erfassung von Diagnosedaten eingesetzt wird. In ausführlichen Übungseinheiten haben die Teilnehmer die Möglichkeit, das erlernte Wissen unmmittelbar anzuwenden und zu vertiefen.
Dauer: 8:30 – 16:00 Uhr
Veranstaltungsort: RA Headquarters, Bruchsal (Deutschland)
Sie haben Interesse an einer Individualschulung in Ihrem eigenen Unternehmen? Unser erfahrenes Schulungsteam bietet weltweit individuelle Trainings, die speziell auf Ihre Anforderungen zugeschnitten sind.
Je nachdem, ob Sie praktische Schulungen im Fahrzeug bevorzugen oder theoretische Einheiten wünschen, wir sind darauf spezialisiert, ein Programm nach Ihren Vorstellungen zusammenzustellen.
Für weitere Fragen oder ein maßgeschneidertes Angebot stehen wir Ihnen gerne zur Verfügung.
Diese Schulung vermittelt dem Teilnehmer die nötigen Grundlagen, um die Inhalte von ODX-Beschreibungsdatensätzen deuten zu können. Sie vermittelt Wissen zum Aufbau von PDX Dateien und zu Zusammenhängen, Diagnosediensten, Diagnoseobjekten (Messwerte, Ereignisspeicher, Routinen, Stellgliedtests), Parametern und Umrechnungen innerhalb der ODX-Beschreibung.
Dauer: 8:30 – 16:00Uhr
Ort: Bruchsal
Kosten: Auf Anfrage
Anmeldung und weitere Informationen über info@rac.de
Am 05.03.2020 feiert die E-mobil Südwest ihr 10 Jähriges Jubiläum im Neckar Forum Esslingen. Die Feier eröffnete Franz Loogen, Geschäftsführer der e-mobil BW. Zu Beginn sprach der Ministerpräsident Winfried Kretschmann ein Grußwort vor dem Publikum.
10 Jahre E-Mobil Diskussion
In den beiden Podiumsdiskussionen „Mobilität im Wandel – Gemeinsam Chancen ergreifen“ und „Innovation & Klimaschutz – Baden-Württemberg unter Strom“ wurden die bisherigen Aktivitäten der emobil bw, die aktuellen Entwicklungen und die zukünftigen Trends diskutiert.
https://www.rac.de/wp-content/uploads/2021/01/10_Jahre_e-mobil-Diskussion.gif5041000Oliver Klinghttps://www.rac.de/wp-content/uploads/2019/07/logo-300x138.pngOliver Kling2020-11-12 15:15:512023-12-06 15:00:1010 Jahre E-mobil Südwest
Wie fahrerlose Shuttle-Fahrzeuge sicher von A nach B kommen:
Projekt 3F stellt Ergebnisse für automatisiertes Fahren im Niedergeschwindigkeitsbereich vor.
Auf Kurs: Fahrzeug kann Fahrt trotz Abweichungen auf der vorgegebenen Strecke und technischen Ausfällen im System fortsetzen
An Bord: Transport von Personen und Gütern auf Teststrecken in Renningen und Aachen erprobt
Im Team: Sechs Partner an dem öffentlich geförderten Projekt beteiligt
(Fotograf: Martin Stollberg)
Renningen – Besucher von der Straßenbahnhaltestelle zum Messegelände befördern, den öffentlichen Nahverkehr ergänzen, Container mit Paketen im Logistikzentrum transportieren: All das sind mögliche Einsatzgebiete für fahrerlose Shuttle-Fahrzeuge. Voraussetzung ist, dass sie sicher von A nach B kommen – im doppelten Wortsinn: gefahrlos und zuverlässig. Hier hat das Projekt 3F „Fahrerlose und fehlertolerante Fahrzeuge im Niedriggeschwindig-keitsbereich“ angesetzt und den Fokus auf Ausfallsicherheit gelegt. „Ziel war, Lösungen zu erarbeiten, damit automatisierte Shuttle-Fahrzeuge sicher unterwegs sind, auch wenn es zu einer technischen Störung kommt oder plötzlich Hindernisse auftauchen“, sagt Steffen Knoop, Projektleiter in der Forschung und Vorausentwicklung der Robert Bosch GmbH.
Konkret ging es darum, dass im Falle eines Fehlers das System nicht komplett ausfällt, sondern das Fahrzeug weiterfahren kann. An dem vom Bundeswirtschaftsministerium mit 4,3 Millionen Euro geförderten Projekt waren neben Bosch als Konsortialführer drei weitere Unternehmen, eine Hochschule und eine Forschungseinrichtung beteiligt: die StreetScooter GmbH, RA Consulting GmbH, das FZI Forschungszentrum Informatik, die Finepower GmbH und die RWTH Aachen.
Doppelt hält besser: Redundante Energieversorgung und Sensorik
„Fahrerlose Shuttle-Busse müssen andere Voraussetzungen erfüllen als beispielsweise hochautomatisierte Pkw“, erläutert Bosch-Projektkoordinator Thomas Schamm. Shuttle-Fahrzeuge können nur dann ohne (Sicherheits-)
Fahrer zum Einsatz kommen, wenn sie selbstständig ihr System überwachen – also Diagnoseaufgaben durchführen – und erkannte technische Störungen bewältigen und weiterfahren können. Zugleich müssen sie bei kritischen Fehlern das System in einen sicheren Zustand überführen und beispielsweise stoppen. Wie die Anforderungen im Einzelnen aussehen, wie die Systeme davon ausgehend ausgelegt werden müssen und wie das Zusammenspiel der Einzelkomponenten optimiert werden kann, daran hat das Projekt 3F gearbeitet.
(Fotograf: Martin Stollberg)
Ein Lösungsansatz: Redundanz, also das Vorhandensein sicherheitsrelevanter Funktionen in doppelter Ausführung. So haben die Forscher beispielsweise redundante Systeme zur Stromversorgung entwickelt, damit Elektroantrieb und Bordnetz zuverlässig abgesichert sind und die Sensorik auf die Bauform der Fahrzeuge abgestimmt und verfeinert. Um Hindernisse zuverlässig erkennen zu können, wurden mehrere Lidar- und Radarsensoren an unterschiedlichen Fahrzeugstellen positioniert. Das ermöglicht, das Umfeld aus verschiedenen Positionen zu beobachten, eine 360-Grad-Rundumsicht zu erreichen, tote Winkel zu vermeiden und so gewissermaßen ein 3D Schutzfeld zu erzeugen. Nicht nur Hindernisse auf der Straße wie Schranken werden so erkannt, sondern auch herabhängende Äste.
Erkennen, einordnen, Fahrverhalten anpassen
Ein weiterer Lösungsansatz: Fehlertoleranz, also die zumindest stückweise Kompensation eines Teilsystemausfalls durch andere Funktionen. Das funktioniert ähnlich wie bei Menschen: Wenn in einem geschlossenen Raum plötzlich das Licht ausgeht, tasten sie sich langsam weiter statt in Starre zu verfallen. Vergleichbar verhält sich das Shuttle-Fahrzeug: Ist es in einem Teilbereich blind, weil Blätter vor dem Sensor kleben oder ein großes Objekt wie ein Müllcontainer die Sicht in eine Richtung komplett versperrt, verlangsamt es seine Fahrt oder spart die nicht mehr erkennbaren Bereiche auf der Route aus.
Zudem hat das Projekt daran gearbeitet, dass Shuttle-Busse im Rahmen ihrer festgelegten Strecke auch auf Abweichungen im Umfeld reagieren. Die Fahrzeuge sollen langsamer werden, wenn sich bewegliche Objekte nähern oder unbekannte Gegenstände im Zweifel großzügig umfahren. Bei wiederkehrenden Wegmarken wie Laternen wiederum setzen sie die Fahrt in unverminderter Geschwindigkeit fort. Ist Gefahr im Verzug, verordnet sich das Shuttle sicherheitshalber einen Stopp. Das Ziel: Das Fahrzeug passt sein Fahrverhalten in Echtzeit den Gegebenheiten an, setzt aber seinen Weg nach Möglichkeit auch bei Störungen im System oder trotz Hindernissen auf der Strecke selbsttätig fort.
Telemetrie hoch drei, Anwendung hoch zwei
Daten über die aktuelle Fahrt und den technischen Zustand können aus dem Fahrzeug heraus und an das Fahrzeug zurück übertragen werden. Dabei gehen Informationen hinsichtlich drei Funktionen hin und her: Diagnose, Überwachung, Steuerung. Telemetrie, also Übertragung von Messwerten, hoch drei sozusagen, und deshalb: Teletrimetrie. Auf der Basis kann künftig per Leitstelle ein ganzer Fuhrpark an automatisierten Shuttle-Bussen aus der Ferne kontrolliert, bei Bedarf repariert oder gesteuert werden, um beispielsweise Türen zu öffnen. So lassen sich die Fahrzeuge unterstützen, falls sie in Sachen Fehlererkennung und Fehlerkompensation doch einmal an ihre Grenzen kommen oder auch ganz planmäßig eine Wartung benötigen.
(Fotograf: Martin Stollberg)
Die im Projekt erarbeiteten Lösungen lassen sich nicht nur in fahrerlosen Shuttle-Bussen einsetzen, sondern ermöglichen auch die robuste Unterstützung von Logistikprozessen. Es wurde ein Assistenzsystem im Zusammenspiel zwischen Fahrer und Fahrzeug entwickelt, welches eine hochgenaue Positionierung von Wechselbrückenhubwagen – Spezialfahrzeuge zum Versetzen von Containern in Logistikzentren – ermöglicht. Ziel war, die Fahrzeuge zentimetergenau unter Containerbrücken zu bewegen, um so die Transportbehälter schnell aufzunehmen. Dazu sind eine genaue Lokalisierung und eine Art automatisiertes Einparken unter der Brücke notwendig. In der Praxis ermöglicht dieses automatisierte Manöver ein fehlerfreies Aufnehmen und Positionieren der Container.
Erprobt wurden die Entwicklungen auf mehreren Testrecken: Mit zwei Shuttle-Bussen auf dem Bosch-Forschungscampus in Renningen wurde die Beförderung von Personen auf einem Gelände getestet, auf dem auch Fußgänger unterwegs sind. Auf einem Innovationspark bei Aachen sowie im Umfeld eines Paketzentrums der Deutschen Post/DHL wurde mit einem Logistikfahrzeug das Zusammenspiel von Fahrer und automatisiertem Fahrzeug untersucht.
Weitere Informationen im Internet unter: www.3f-projekt.de
Seit 2019 kooperiert RA Consulting GmbH (RAC) im Bereich der Forschung für Hochautomatisierten Fahrfunktionen (HAF) und Autonomen Fahren (AD) mit der LiangDao GmbH München. In 2020 veröffentlicht RAC eine OpenSCENARIO 1.0 API als Open Source Software in Kooperation mit dem ASAM e.V.
Diese Schulung wird von unserem Partner, der emotive GmbH &Co.KG, durchgeführt.
Der neue Standard OTX (Open Test sequence eXchange – ISO 13209) ist nicht nur ein einheitliches, wiederverwendbares Austauschformat für Prüfsequenzen in der Off-Board-Diagnose, er leistet auch einen wesentlichen Beitrag zur Beherrschung der heute allgegenwärtigen Komplexität. Dabei ist OTX nicht auf die Fahrzeugdiagnose begrenzt. Durch die Verwendung geeigneter Bibliotheken reichen seine möglichen Anwendungsgebiete über die Testautomatisierung bis hin zur HIL-Simulation. Das Seminar gibt eine umfassende und systematische Übersicht über das Austauschformat für Testsequenzen. Die Teilnehmer lernen den Aufbau und den Umgang mit OTX-Daten sowie die Möglichkeiten und Grenzen des Standards kennen. Durch Beispiele aus der Praxis, kleine Übungen und Live-Vorführungen werden die Inhalte veranschaulicht und konsolidiert.
Zielgruppe:
Das Seminar wendet sich an Ingenieure der Automobil- und Zulieferindustrie. Allgemeine Kenntnisse über Fahrzeugdiagnose und Diagnoseprozesse werden vorausgesetzt.
Datum: Bitte erfragen Sie unsere Planungen bezüglich eines Termins.
Dauer: 9:00 – 17:00Uhr
Ort: Bruchsal
Anmeldung und weitere Informationen über info@rac.de
Bitte nutzen Sie auch die Möglichkeit, sich direkt bei emotive näher zu informieren bzw. sich anzumelden.
Diese Schulung ist kostenpflichtig.
Schulungsinhalte:
1. Einleitung
Herausforderung Fahrzeugdiagnose – Stand der Technik
2. Standardisierung in der Fahrzeugdiagnose
Übersicht der wichtigsten Diagnosestandards
ISO/OSI-Schichtenmodell
Diagnoseprotokoll UDS (ISO 14229, ISO 15756)
Diagnoselaufzeitsystem MVCI-Server (ISO 22900-3, 3D-Server)
Diagnosedaten ODX (ISO 22901, ASAM MCD 2D)
Diagnoseabläufe OTX (ISO13209)
OTX-Timeline
3. OTX-Einleitung
Hintergrund und Anwendungen
Ziele, Nutzen und Grenzen
4. OTX-Datenmodell
Hauptkomponenten und Grundstruktur
Basiskonzepte
Gemeinsame Elemente
OTX-Core
Übersicht
Datentypen
Parameter und Deklarationen
Terms und Expressions
Nodes (Action, Loop, Branch, Parallel etc.)
Exception-Handling
OTX-Bibliotheken
DiagCom (Diagnose-Kommunikation)
HMI (Benutzerinteraktion)
i18n (Lokalisierung = Mehrsprachigkeit)
Job, Flash
Measure
Erweiterungsmechanismus
5. Anwendung von OTX
Open Diagnostic Framework
Entwickeln einer Diagnoseanwendung mit OTX
https://www.rac.de/wp-content/uploads/2020/12/Symbolbild_Schulung.gif12801920Oliver Klinghttps://www.rac.de/wp-content/uploads/2019/07/logo-300x138.pngOliver Kling2019-10-12 08:19:202024-02-23 15:18:41Schulung: OTX – Austauschformat für Testsequenzen
