Schlagwortarchiv für: automobil software

Datensatzvergleich

IAV Macara

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.

Datensatzvergleich

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

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

Darstellung des Ergebnisses der Plausibilitätsprüfung

 

Fernsteuerung von DiagRA D und Silver Scan-Tool über die optionale Webservices-API

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)

Neues zu DiagRA D und Silver Scan-Tool

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

Schulung: DiagRA® D

Kommende DiagRA® D-Schulungen sind in Planung.

Die kostenpflichtigen Schulungen zu DiagRA® D finden in Bruchsal statt.

Anmeldung und weitere Informationen über info@rac.de

Diese ganztägige Schulung vermittelt den kompletten Funktionsumfang von DiagRA® D und bietet bei ausführlichen Übungen Gelegenheit, das vermittelte Wissen sofort anzuwenden und damit zu vertiefen.

Dauer: 8:30-16:00Uhr

Schulungsinhalte:

1) Allgemeine Einführung und Funktionsübersicht

– Installation, Registrierung von DiagRA® D
– Hardware Diagnosekabel/Interfaces
– Aufbau der Benutzeroberfläche
– Verwenden der Hilfefunktion

2) OBD Scan-Tool

– Auslesen der Carb-Modes
– Übersicht über das Gesamtsystem
– Speichermöglichkeiten von Daten, Konfigurationen und Messabläufen
– Praktischer Teil mit Übungsaufgaben
– Speichern aktueller Ansichten
– Kontinuierliches Speichern von Messwerten
– Konfiguration und Ausführen einer automatischen Messung
– Auswerten der Messungen im TXT, XML, CSV-Format
– SAE J2534 PassThru
– SAE J1699-3 Prüfablauf
– SAE J1699-3 Auswertung

3) Werkstattdiagnose

– Verwaltung von projektspezifischen Datensätzen, Diagnoseprotokollen und Steuergeräteadressen
– Konfigurationseinstellung
– Gemeinsame Nutzung von Daten und Einstellungen im DiagRA MCD Toolset
– Steuergeräteidentifikation
– Fehlerspeicher
– Normierte Messwerte/Grundeinstellung
– Stellgliedtest
– Anpassungskanäle
– Steuergerät kodieren
– Login-Request
– Zugriffsberechtigung
– Adressorientiertes Auslesen von Speicherbereichen
– Sonderfunktionen Kraftstoffsystembefüllung, Ventil- und Pumpenansteuerung
– Praktischer Teil mit Übungsaufgaben

4) Neue Steuergeräte mit ODX/UDS

– ODX Grundlagen
– ODX Unterstützung in DiagRA® D

5) Erweiterte Entwicklerfunktionen

– Cycle-Counter
– Statusbits
– Readiness-Code
– Interner Fehlerspeicher
– Reset-Monitor
– Ratio-Werte
– Ramzellen
– CAN-Botschaften
– Flashprogrammierung
– Praktischer Teil mit Übungsaufgaben

6) Bei Interesse und Zeit:

– Dateiformate interner Dateien
– Programmschnittstellen DDE, ASAP3 und Web Services
– Formate interner Dateien
– COD, FKT, DRA, DCF, INI-Dateien Aufbau
– Manuelle Bearbeitung von Dateien

Individualschulung

Wenn Sie Interesse an einer in-Haus Schulung durch unsere erfahrenen Schulungsleiter/innen vor Ort in Ihrem Unternehmen haben, können wir Ihnen unsere individuellen Schulungen weltweit anbieten. Kunden haben hier die Möglichkeit den Schwerpunkt der Schulung sowie die Art selbst festzulegen. Ob Sie lieber eine praktische Schulung im Fahrzeug oder eine theoretischere in einem Schulungsraum wünschen, wir freuen uns darauf, Ihnen eine Schulung gemäß Ihren Vorstellungen zusammenzustellen. Gerne beantworten wir Ihnen Ihre Fragen und erstellen Ihnen ein individuelles Angebot.

Bei Interesse nehmen Sie bitte Kontakt zu uns auf.

Schulung: ODX für Diagnoseentwickler

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

Schulungsinhalte:

  1. Einführung in die Diagnosebeschreibung
  2. Das ODX Format
  3. ODX im Diagnoselaufzeitsystem
  4. Services und Diagnose-Sessions in ODX
    • Request- und Response-Parameter, Umrechnungen
    • Messwerte
    • Codierungen
    • Anpasskanäle
    • Stellgliedtests
    • Fehlereinträge
    • Routinen
  5. ODX Laufzeitsicht
  6. Zusatzthema: Komplexe DOPs (Data-Object-Properties)
10 Jahre E-Mobil Diskussion

10 Jahre E-mobil Südwest

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.

Trotz Fehlern weiterfahren

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

Link zum Video: https://youtu.be/K8QbiSR347Q

Gefördert vom Bundesministerium für Wirtschaft und Energie aufgrund eines Beschlusses des Deutschen Bundestages.

Orignalartikel:
Caroline Schulke
Quelle: BoschPresse

Aktuelle News von unserem Kooperationspartner LiangDao

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.

Source:

http://global.chinadaily.com.cn/a/202009/12/WS5f5c264ea310f55b25a821d0.html

Schulung: OTX – Austauschformat für Testsequenzen

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.    Ein­lei­tung

  • Her­aus­for­de­rung Fahr­zeug­dia­gno­se – Stand der Tech­nik

2.    Stan­dar­di­sie­rung in der Fahr­zeug­dia­gno­se

  • Über­sicht der wich­tigs­ten Dia­gno­se­stan­dards
    • ISO/OSI-Schich­ten­mo­dell
    • Dia­gno­se­pro­to­koll UDS (ISO 14229, ISO 15756)
    • Dia­gno­se­lauf­zeit­sys­tem MVCI-Ser­ver (ISO 22900-3, 3D-Ser­ver)
    • Dia­gno­se­da­ten ODX (ISO 22901, ASAM MCD 2D)
    • Dia­gno­seab­läu­fe OTX (ISO13209)
  • OTX-Time­li­ne

3.    OTX-Ein­lei­tung

  • Hin­ter­grund und Anwen­dun­gen
  • Zie­le, Nut­zen und Gren­zen

4.    OTX-Daten­mo­dell

  • Haupt­kom­po­nen­ten und Grund­struk­tur
  • Basis­kon­zep­te
  • Gemein­sa­me Ele­men­te
  • OTX-Core
    • Über­sicht
    • Daten­ty­pen
    • Para­me­ter und Dekla­ra­tio­nen
    • Terms und Expres­si­ons
    • Nodes (Action, Loop, Bran­ch, Par­al­lel etc.)
    • Excep­tion-Hand­ling
  • OTX-Biblio­the­ken
    • Diag­Com (Dia­gno­se-Kom­mu­ni­ka­tion)
    • HMI (Benut­zerin­ter­ak­tion)
    • i18n (Loka­li­sie­rung = Mehr­spra­chig­keit)
    • Job, Flash
    • Mea­su­re
  • Erwei­te­rungs­me­cha­nis­mus

5.    An­wen­dung von OTX

  • Open Dia­gno­stic Fra­me­work
  • Ent­wi­ckeln einer Dia­gno­se­an­wen­dung mit OTX
© RA Consulting GmbH, 2024    USt.-Ident.-Nr.: DE143081464    HRB: 231127 ASAMAETAElektromobilität Süde-West
RA Consulting GmbH