Autor: Firma KPIT Technologies

Adaptive AUTOSAR – Eine neue Art des Arbeitens

Adaptive AUTOSAR – Eine neue Art des Arbeitens

Im vorliegenden Beitrag werden einige Themen vorgestellt, die beim Umgang mit der neuen serviceorientierten Architektur (SOA) zu beachten sind. Eine auf Adaptive AUTOSAR basierende SOA ersetzt die klassische AUTOSAR-Plattform nicht 1:1. Es soll hier lediglich gezeigt werden, dass sowohl im technischen Bereich als auch hinsichtlich der Arbeitsprozesse neue Herausforderungen entstehen.

Die Softwareplattformen, die heute in der Automobilindustrie vorwiegend genutzt werden, bauen auf Firmware auf. Die Firmware ist ein binär laufender Build für Bare-Metal in einem bestimmten Mikrocontroller. Es wird ein Anforderungskatalog erstellt und als Firmware-Implementierung oder -Konfiguration realisiert. Sie wird bei der Produktion, einer regelmäßigen Wartung in einer Werkstatt oder im ungünstigsten Fall bei einem Rückruf aufgrund von enthaltenen Fehlern heruntergeladen. Das ursprüngliche Ziel besteht jedoch darin, dass der Hersteller nach dem Download niemals einen Software-Update während der Lebensdauer des Fahrzeugs vornehmen muss.

Diese Vorgabe passt nicht sehr gut zu Software. Nicht weil die Automobilindustrie schlechte Softwareingenieure hätte. Aber die Funktionen und Aufgaben, die elektronische Steuergeräte heute übernehmen müssen, sind so komplex, dass sich kontinuierliche Funktionsupdates sowie auch Softwarefehler nicht vermeiden lassen. Je komplexer ein Projekt ist, desto stärker steigt die Zahl der Fehler pro Codezeile an [Code2], d. h. die Anzahl der Fehler ist nicht nur eine lineare Funktion der Codezeilen. Es können natürlich größere Investitionen in Überprüfung und Validierung vorgenommen werden, aber dem Funktionswachstum wird oft Vorrang vor der Modul- und Integrationserprobung gegeben. Zusätzlich verlangt eine typische Überprüfung das gleiche Expertenniveau wie bei der Implementierung. Der Systemtest ist teuer und schwierig zu koordinieren. Außerdem sind die Anforderungen nicht in allen Fällen von Beginn an klar, was die Validierung des Systems erschwert.

Die neue Generation der Fahrzeugeigentümer erwartet neueste und moderne Merkmale im Auto. Die meisten dieser Funktionen stehen in Verbindung mit der Software. Smartphones sind heute weit effizienter in der Anpassung an die Benutzeranforderungen. Sie sind permanent mit dem Internet verbunden und lösen viele Aufgaben, die als normaler Bestandteil der heutigen Lebensweise betrachtet werden.

Bei Infotainment- und Telematikprojekten wurden schon früh komplexe Funktionsimplementierung und ein agiler Arbeitsprozess eingeführt. Üblicherweise handelt es sich dabei um aktualisierbare Systeme mit einem Dateisysteme unterstützenden komplexen Betriebssystem wie Linux. Leider stellen diese Projekte in vielen Fällen eine Integration zahlreicher Module dar, wodurch eine Softwareplattformintegration entsteht, die sich nur wenig oder garnicht zur Wiederverwendung eignet. Jede Generation eines Projekts ist im Grunde ein Neubeginn. Darüber hinaus sind Linux-basierte Plattformen nicht sehr gut darin, Sicherheits- und anspruchsvolle Echtzeitanforderungen zu erfüllen.

Adaptive AUTOSAR

Vor diesem Hintergrund ist Adaptive AUTOSAR ein neuer Standard, der die oben erwähnten Probleme löst und eine teilweise service-orientierte Architektur (SOA) schafft.

Classic AUTOSAR ist eine eigenständige Firmware-Plattform, während Adaptive AUTOSAR nicht versucht, in diesem Sinne vollständig zu sein, um eine komplette SOA zu bilden. Eine SOA ist eine Softwareplattform, bei der Dienstleistungen im Mittelpunkt stehen. Eine Dienstleistung wird von einem Dienstleister erbracht und von einem Dienstleistungsnutzer in Anspruch genommen. Die Verbindung zwischen einem Dienstleister und einem Dienstleistungsnutzer wird von einem Service-Broker dynamisch zur Laufzeit hergestellt. Der Dienstleistungsnutzer muss nicht unbedingt wissen, wo sich der Dienstleister befindet. Daher ist die Softwareplattform dynamisch und kann teilweise ohne Auswirkungen auf das System aktualisiert werden.

Wie oben erwähnt, beansprucht Adaptive AUTOSAR nicht, eine komplette SOA zu schaffen. Das Betriebssystem ist nur verknüpft und nicht spezifiziert [AUTOSAR OS]. Hier verbindet sich eine Adaptive AUTOSAR-Anwendung mit einem Betriebssystem, das die API-Untergruppe PSE51 des POSIX-Standards bereitstellt [POSIX]. Dies bedeutet nicht, dass das Betriebssystem nur PSE51 sein kann, sondern dass die Adaptive AUTOSAR-Anwendung nur diese API verwenden kann. Das Betriebssystem kann immer noch ein vollständiges PSE54-System sein (z. B. das PSE54-basierte Linux).

Dieses Konzept hat den Vorteil, dass alle POSIX-konformen Anwendungen und Bibliotheken modelliert werden können.

Zudem können sie auf einer beliebigen AUTOSAR-Softwareplattform wiederverwendet und eingesetzt werden. In anderen Worten, AUTOSAR versucht nicht, POSIX neu zu definieren. Nur zur Klärung sei daran erinnert, dass POSIX eine Standardschnittstelle für eine Programmieroberfläche ist. Es ist weder eine implementierte Anwendung noch ein Betriebssystem (Bild 1).

Es gibt eine Nachfrage nach alter zuverlässiger Software, die schon lange angeboten wird, da befürchtet wird, dass eine neue Software immer Fehler enthält. Warum nicht also einfach den alten Code verwenden und einige kleinere Erweiterungen vornehmen? Die heute in der Software verlangten Funktionen entwickeln sich sehr stark weiter. Es ist sehr schwer, eine gute Architektur zu schaffen, die es ermöglicht, alle Arten von künftigen Merkmalen hinzuzufügen, die nicht von Anfang an bekannt sind. Ein Refactoring der Software ist von Zeit zu Zeit erforderlich, um die Software effizient pflegen und überprüfen zu können. In vielen Fällen wird so in Bezug auf das klassische AUTOSAR argumentiert. Der Vorzug von Adaptive AUTOSAR liegt darin, dass POSIX-konforme Software wiederverwendet werden kann, nach der Philosophie „Einmal schreiben, überall anpassen“. Es besteht kein Zwang, etwas umzuschreiben und können von bestehender offener Software profitieren, oder ein Software-Unternehmen kann Anwendungen für unterschiedliche Kunden wiederverwenden.

Die Entscheidung für eine service-orientierte Architektur (unter Verwendung von Adaptive AUTOSAR) beseitigt nicht alle Hindernisse auf dem Weg. Der Umstieg von einem firmwarebasierten Ansatz (d. h. Classic AUTOSAR) auf SOA bedeutet, dass man vor neuen Herausforderungen steht, die bisher nicht bekannt waren oder in erster Linie manuell gelöst wurden. Einige davon werden hier behandelt.

Eine aktualisierbare SOA impliziert, dass sich der Arbeitsprozess der Projekte verändern muss. Das klassische Wasserfallmodell, bei dem ein Lieferant eine Anforderungsliste erhält und diese umsetzt und testet, funktioniert dann nicht mehr wirklich. Stattdessen ist eine agile Arbeitsweise auf der Grundlage eines Continuous Integration (CI)-Konzepts erforderlich (Bild 2), nämlich eine CI, die kontinuierlich neue Software überprüft und freigibt. Zusätzlich verbinden sich der OEM und Lieferanten mit der CI, und die Lieferanten haben eine eigene CI für ihre Anwendungen oder Softwareplattformen. Um einem solchen CI-Ökosystem gerecht zu werden, müssen die CIs von OEM und Lieferanten automatisch interagieren. CIs, die automatisch Versionen für die CI anderer Unternehmen (OEMs) erstellen, sind für IT- und Rechtsabteilungen eine schwer zu knackende Nuss. Man muss die Eigentumsstruktur verstehen und wissen, wie sich solche Interaktionen sicher durchführen lassen.

Wiederverwendbarkeit

Ein weiteres wichtiges Thema ist es, eine Softwareplattform für verschiedene Projekte wiederverwendbar zu machen, ohne jedes Mal von Null zu beginnen. Hier erweist sich der Adaptive AUTOSAR-Standard als sehr hilfreich. Einerseits gibt es genau umrissene AUTOSAR-Basisdienste wie Diagnostic Manager für spezifische im Fahrzeug erforderliche Funktionen und andererseits eine klare Methodik und ein Austauschformat zur Verwendung durch OEMs und Lieferanten im Arbeitsprozess. Die Existenz eines solchen Standards ermöglicht die Entwicklung und Wiederverwendung von Anwendungen für unterschiedliche Projekte und Kunden.

Der Vorteil eines Firmware-Konzepts besteht darin, dass Updates einmalige Vorgänge sind. Bei einem aktualisierbaren System werden hingegen räumlich und zeitlich unterschiedliche Teil-Updates vorgenommen. Das Basis-Image wird implementiert, und verschiedene Organisationen (und Unternehmen) führen zu unterschiedlichen Zeiten Updates am System durch. Dies stellt hohe Anforderungen an die Bereitstellung von Offline-Tools. Das Update muss vor der Implementierung auf Kompatibilität überprüft werden. Das Update ist so zu verifizieren, dass es zu keinerlei Ausfällen im Fahrzeug führen wird. Auch müssen Updates orchestriert werden, wenn z. B. zwei elektronische Steuereinheiten aktualisiert werden müssen und eine ausfällt, muss die Software in beiden ECUs auf die Vorgängerversion zurückgesetzt werden.

Service-orientierte Architektur

Der POSIX-Standard definiert verschiedene Merkmale, wobei die Feature-Ebene von den PES51-54-Profilen gesteuert wird. In jedem Profil sind die meisten Merkmale optional [POSIX]. Im klassischen AUTOSAR ist der Funktionsinhalt klar umrissen und wird meist von den Skalierbarkeitsklassen gesteuert. Zwei verschiedene POSIX-Betriebssysteme können sich in ihrem Funktionsinhalt sehr stark unterscheiden. Es ist wichtig, die benötigten Merkmale eines POSIX-Betriebssystems in einer frühen Projektphase festzulegen und zusätzlich sicherzustellen, dass das gewählte POSIX-Betriebssystem mit weiteren Merkmalen erweiterbar ist, wenn das Projektwachstum dies erfordert.

SOA wird oft mit dynamischem Verhalten in Verbindung gebracht. Aber um die Software der nächsten Generation in Fahrzeugen steuern und verwalten zu können, muss der Arbeitsprozess stringent und automatisiert sein. Außerdem muss die Software im Fahrzeug gesteuert werden, um Verifizierung und Sicherheit zu erreichen. Lieferanten und OEMs für Fahrzeuge werden enger zusammenarbeiten und dabei automatisierte kontinuierliche Integrationssysteme nutzen. Die statische Prüfung ist durch eine dynamische Prüfung im Fahrzeug zu erweitern (z. B. durch Hinzufügen von Metadaten). Unterschiedliche Lieferanten im Ökosystem der Softwareplattform müssen effizient zusammenarbeiten. Dazu ist ein vertragsbasiertes Entwicklungskonzept vonnöten.

Dies sind einige Themen, die beim Umgang mit dem neuen SOA-Modell zu beachten sind. Eine auf Adaptive AUTOSAR basierende SOA ersetzt die klassische AUTOSAR-Plattform nicht 1:1. Es sollte hier nur gezeigt werden, dass es sowohl im technischen Bereich als auch hinsichtlich der Arbeitsprozesse neue Herausforderungen zu bestehen gibt. Der Vorteil des Konzepts von Adaptive AUTOSAR ist die Angleichung an einen bestehenden Standard wie POSIX. Daher ist es möglich, Software und Erfahrungen aus verschiedenen Projekten (auch aus anderen Bereichen als der Automobiltechnik) wiederzuverwenden.

 

 

Firmenkontakt und Herausgeber der Meldung:

KPIT Technologies GmbH
Adams-Lehman-Str. 109
80797 München
Telefon: +49 (89) 3229966-0
Telefax: +49 (89) 3229966-99
http://www.kpit.com

Ansprechpartner:
Stefanie Köhler
Telefon: +49 (89) 3229966-140
Fax: +49 (89) 3229966-999
E-Mail: stefanie.koehler@kpit.com
Für die oben stehende Pressemitteilung ist allein der jeweils angegebene Herausgeber (siehe Firmenkontakt oben) verantwortlich. Dieser ist in der Regel auch Urheber des Pressetextes, sowie der angehängten Bild-, Ton-, Video-, Medien- und Informationsmaterialien. Die United News Network GmbH übernimmt keine Haftung für die Korrektheit oder Vollständigkeit der dargestellten Meldung. Auch bei Übertragungsfehlern oder anderen Störungen haftet sie nur im Fall von Vorsatz oder grober Fahrlässigkeit. Die Nutzung von hier archivierten Informationen zur Eigeninformation und redaktionellen Weiterverarbeitung ist in der Regel kostenfrei. Bitte klären Sie vor einer Weiterverwendung urheberrechtliche Fragen mit dem angegebenen Herausgeber. Eine systematische Speicherung dieser Daten sowie die Verwendung auch von Teilen dieses Datenbankwerks sind nur mit schriftlicher Genehmigung durch die United News Network GmbH gestattet.
Eingebettete Fahrzeugdiagnose

Eingebettete Fahrzeugdiagnose

Der hier vorgestellte Embedded-Diagnostic-Ansatz basiert auf den in den ISO-Standards spezifizierten Infrastrukturkomponenten (z. B. ODX, OTX) und ebnet damit den Weg für eine datengetriebene Architektur. Die im Fahrzeug verbauten Diagnose-Infrastrukturkomponenten ermöglichen eine nahtlose Kommunikation mit dem ECU-Netzwerk und arbeiten in ähnlicher Weise wie das Service-Tool. So wird die Ausführung aller diagnostischen Anwendungsfälle aus entfernten Standorten ermöglicht.

Je moderner die Fahrzeuge werden, desto mehr sind sie auf die eingebettete Elektronik und Software angewiesen.

Da diese immer umfangreicher und komplexer werden, wächst auch die Fahrzeugkomplexität. Die heutigen Servicetechniker in den Autohäusern, die Zugang zu herkömmlichen Servicetester haben, sind durch die Tatsache eingeschränkt, dass sie sich beim Fahrzeug befinden müssen, um die Ursache des Problems diagnostizieren und beheben zu können. Dies erhöht die Servicezeiten, die Reparaturkosten und senkt wiederum die Kundenzufriedenheit.

Dieser Artikel stellt einen fortschrittlichen Ansatz zur Fahrzeugdiagnose vor und unterstreicht die Notwendigkeit, Servicetechniker mit Diagnosewerkzeugen der nächsten Generation auszustatten, um für die kommenden Kommunikationsanforderungen zwischen Mensch und Maschine gewappnet zu sein.

Die Fähigkeit zur Fahrzeugdiagnose ist ein überaus wichtiger Aspekt der Fahrzeugarchitektur. Die gebräuchlichste Methode in der Automobilindustrie ist der Zugriff auf die Gesamtheit der Diagnosedaten (DTC, Messwerte etc.) über den OBD-II-Port des Fahrzeugs. Es gibt auf dem Markt verfügbare Tools (von OEMs oder unabhängigen Aftermarket- Anbietern) welchen den Servicetechnikern helfen, den Status der verschiedenen Fahrzeugsubsysteme abzurufen, die erkannten Probleme zu beheben und Reparaturverfahren nach Vorgaben anzuwenden. Der auf dem Service Tool basierende Ansatz kann das Problem jedoch nur beheben, wenn der Techniker beim Fahrzeug anwesend ist.

Heute gibt es bereits zahlreiche Lösungen auf dem Markt, die von sich behaupten, eine kompetente Ferndiagnose mit OBD-II-Dongles vorzunehmen.

Tatsache ist jedoch, dass diese Lösungen nur die für die Emissionsnormen relevanten Diagnoseinformationen auslesen können und somit den Mehrwert für den Servicetechniker auf Abgaswerte begrenzt bleibt.

Ökosystemvisualisierung

Die gesamte in Bild 1 gezeigte Lösung besteht aus den folgenden fünf Hauptkomponenten: Telematics Control Unit (TCU), Diagnoselaufzeitsystem, OTXSequenzen, ODX-Daten und dem Diagnoseserver zur Unterstützung von Diagnosefunktionen.

Die TCU stellt die Umgebung und die notwendigen Ressourcen für die Ausführung des Diagnosesystems zur Verfügung, um verschiedene Anwendungsfälle wie Read Data Identifier (DID), Vehicle Scanning, Umprogrammierung etc. zu realisieren. Normalerweise arbeitet TCU mit LINUX als Betriebssystem mit unterschiedlichen Größen von RAM/Flash-Speicher und CPU-Leistung.

Das Diagnose Runtime stellt Infrastrukturkomponenten für die Diagnosekommunikation über Netzwerk (CAN, Ethernet etc.) zur Verfügung. Die Infrastrukturkomponenten umfassen Diagnostic APIs, OTX Runtime, D-Server- APIs) auf dem Remote-Server zu installieren.

Das Konzept einer solchen Architektur ist in Bild 3 dargestellt. Die Auswahl der Architektur gewährleistet eine Trade-Off-Analyse hinsichtlich der Geschäftsanforderungen, z. B. Unterstützung für den Online-/Offline-Modus, erforderliche Anwendungsfälle (Full-Service- Funktionalitäten vs. nur Umprogrammierung) etc.

Diagnoseverfahren
– OTX ist eine domänengesteuerte grafische Programmiersprache, die es erlaubt, automatisierte Diagnoseverfahren in grafischer Weise zu erstellen. OTX-Prozeduren werden im Standard-XML-Format angegeben.
– ODX ist ein XML-basierter Standard zur OEM-unabhängigen Definition von ECU-Diagnosedaten. Es enthält alle notwendigen Daten für die Diagnosekommunikation wie z. B. Kommunikationsparameter, ECU-Varianten-Beziehung, Diagnose- Services, Maßeinheiten, Genauigkeit, Datentypen etc. Die Komplexität und Größe der ODX-Daten hängt von den ECU-Varianten und der Anzahl der von den ECUs unterstützten Diagnoseservices ab.

Herausforderungen

Der in diesem Artikel angesprochene Ansatz ermöglicht die Diagnosefähigkeiten der nächsten Generation, aber er bringt auch einige Herausforderungen bzgl. einer tragfähigen Lösung mit sich.

Zu diesen Herausforderungen zählen beispielsweise:
 
Management des Fahrzeugzustands

– So muss der On-Board-Diagnose- Laufzeit-Stack sicherstellen, dass er den Netzwerkverkehr nicht überlastet oder die Fahrzeugfunktionen im Fehlerfall nicht beeinträchtigt.
– Sicherheit – Die Diagnoseinhalte, die an Bord und an/von TCU-Daten verfügbar sind, müssen hochgradig gesichert sein, um sie vor unbefugtem Zugriff zu schützen.
– Software-Aktualisierungen – Die Verfügbarkeit der erforderlichen Infrastruktur zur Unterstützung von drahtlosen (Over-the-Air)-Updates für den Fall, dass Softwarekomponenten innerhalb der TCU ausfallen.
– Mobilfunkbandbreite – Sicherstellung einer optimalen Nutzung der Mobilfunkbandbreite für die Datenübertragung zwischen Diagnoseserver und TCU
– Begrenzte Hardware-Ressourcen innerhalb der TCU – Software, die innerhalb der TCU läuft, muss hocheffizient sein, um innerhalb der begrenzten Ressourcenverfügbarkeit zuverlässig zu arbeiten.

Fazit

Die in diesem Artikel erwähnten Softwarekomponenten sind bereits vorhanden und werden bei verschiedenen Anwendungsfällen in den Bereichen Engineering, Fertigung und After-Sales-Service eingesetzt. Darüber hinaus sind immer mehr OEMs dabei, TCUs als Kernkomponenten ihrer Fahrzeugarchitekturen einzuführen. Schnell wechselnde Technologietrends, sich entwickelnde Kundenerwartungen und ein hart umkämpfter Markt werden OEMs und TCU-Zulieferer weiter dazu bewegen, den hier vorgestellten Ansatz für den Aufbau von Diagnosesystemen der Zukunft aufzugreifen. Bei KPIT wurde ein solcher Trend bereits bei technologisch fortgeschrittenen Kunden beobachtet. Die Diagnose- und Connectivity- Plattform (K-DCP) von KPIT ist schon in Produktion (in Embedded-Umgebung) und bedient Anwendungsfälle wie Over-the-Air-ECU-Flashing und Ferndiagnose.

Die eingebettete Fahrzeugdiagnose hat das Potenzial, den Nutzen entlang der gesamten automobilen Wertschöpfungskette zu steigern. Am Ende der Kette können die OEMs durch Kosteneinsparungen im Zusammenhang mit Fahrzeugrückrufen und der Reduzierung von Garantieansprüchen, die von No- Trouble-Found (NTF) gestützt werden, enorm profitieren, und das alles durch eine erweiterte und geführte Diagnose.

Die Service-Händler wiederum ziehen Nutzen aus einer Verbesserung der Fix- First-Visit-Kennzahlen, der Reduzierung von Servicezeit und -kosten durch Ferndiagnose, der Erzielung einer höheren Techniker-Effizienz und -Produktivität und nicht zuletzt aus dem höherem Komfort für den Kunden (Fahrzeughalter).

Dies alles auf Grundlage der neu gewonnenen Fähigkeiten der Service-Händler im Bereich der vorbeugenden/vorausschauenden Wartung.

Da sich eine Win-Win-Situation für alle Beteiligte ergibt, ist davon auszugehen, dass sich der Bereich der Embedded Diagnostics weiterentwickeln, wachsen und immer mehr Anhänger finden wird. W (oe)

»»www.kpit.com

 

Firmenkontakt und Herausgeber der Meldung:

KPIT Technologies GmbH
Adams-Lehman-Str. 109
80797 München
Telefon: +49 (89) 3229966-0
Telefax: +49 (89) 3229966-99
http://www.kpit.com

Ansprechpartner:
Stefanie Köhler
Telefon: +49 (89) 3229966-140
Fax: +49 (89) 3229966-999
E-Mail: stefanie.koehler@kpit.com
Für die oben stehende Pressemitteilung ist allein der jeweils angegebene Herausgeber (siehe Firmenkontakt oben) verantwortlich. Dieser ist in der Regel auch Urheber des Pressetextes, sowie der angehängten Bild-, Ton-, Video-, Medien- und Informationsmaterialien. Die United News Network GmbH übernimmt keine Haftung für die Korrektheit oder Vollständigkeit der dargestellten Meldung. Auch bei Übertragungsfehlern oder anderen Störungen haftet sie nur im Fall von Vorsatz oder grober Fahrlässigkeit. Die Nutzung von hier archivierten Informationen zur Eigeninformation und redaktionellen Weiterverarbeitung ist in der Regel kostenfrei. Bitte klären Sie vor einer Weiterverwendung urheberrechtliche Fragen mit dem angegebenen Herausgeber. Eine systematische Speicherung dieser Daten sowie die Verwendung auch von Teilen dieses Datenbankwerks sind nur mit schriftlicher Genehmigung durch die United News Network GmbH gestattet.
KPIT gibt die neuesten Upgrades seiner Produktfamilie für die Fahrzeugdiagnose bekannt

KPIT gibt die neuesten Upgrades seiner Produktfamilie für die Fahrzeugdiagnose bekannt

Die KPIT Technologies GmbH (europäische Tochtergesellschaft der KPIT Technologies Ltd), ein auf IT-Beratung und Produkt-Engineering spezialisiertes Technologieunternehmen gibt die neuesten Upgardes seiner Produktfamilie für die Fahrzeugdiagnose bekannt. Das Diagnostic & Connectivity-Portfolio von KPIT unterstützt Fahrzeug- und Gerätehersteller, Serviceanbieter und Techniker bei der Remoteüberwachung ihrer Geräte & Maschinen, Entwicklung von Prozessen und bei der Durchführung von Diagnoseabläufen. Die Diagnostic und Connectivity Plattform, die eine Reihe von Tools und Anwendungen umfasst, ermöglicht eine schnelle und genaue Fehlersuche und Fehlerdiagnose was erhebliche Auswirkungen auf die Reduzierung von Ausfallzeiten und Verbesserung der vorausschauenden Wartung und Rentabilität hat.

Das Release 2017-R2 der Produktfamilie Diagnostic & Connectivity Platform (KDCP) enthält zahlreiche neue Funktionen und Verbesserungen mit folgenden Highlights:
 

  • Der leistungsfähige Diagnose-Stack von KPIT enthält einen ISO MVCI Server, eine D-PDU API und einen OTX-Interpreter. Er unterstützt jetzt Diagnostics over IP, welches die mit UDS eingeführten Diagnosedienste über Ethernet verwendet. Dadurch stehen im Vergleich zu CAN beträchtlich höhere Datenraten zur Verfügung, was eine erhebliche Zeitersparnis bei komplexen Diagnoseaufgaben und Flash-Anwendungen ermöglicht.
  • Das in der D-PDU API integrierte Simulations-Modul, welches das Testen von Diagnosedaten auch ohne Steuergerät und VCI ermöglicht, wurde erneuert. Die neue JavaScript-basierte Dynamic ECU Simulation kann jetzt mehrere Steuergeräte enthalten und unterstützt neben dynamischen Änderungen von Werten auch das Setzen von Steuergeräte-Status, z.B. den Wechsel von Sessions.
  • Das neue Diagnostic Example erleichtert den Einstieg und verkürzt die Einarbeitung in die gesamte Produktfamilie. Dazu wurden die mitgelieferten ODX 2.2 Beispieldaten erweitert, in Form einer Steuergeräte-Spezifikation vollständig dokumentiert und mit einer passenden Simulation komplettiert. Weiterhin wurden zahlreiche OTX-Abläufe inklusive Benutzeroberflächen als Beispiele hinzugefügt.
  • Im OTX Authoring, der Entwicklungsumgebung für komplexe Diagnoseabläufe, grafische Benutzeroberflächen und Geführte Fehlersuche, wurde die Startseite komplett überarbeitet. Dies ermöglicht jetzt u.a. den direkten Zugriff auf die bereits erwähnten Beispiele.
  • Ein neues Mitglied der Produktfamilie ist das Diagnostic Tester Framework. Es ermöglicht die generische Erstellung von Diagnosetester-Applikationen für die Produktion oder den Kundenservice auf Basis anwenderspezifischer OTX-Abläufe und Benutzeroberflächen. Für den komfortablen Zugriff auf Fehlerspeicher, Messwerte oder spezielle Funktionen (z.B. die Steuergeräte-Programmierung) stehen jeweils spezifische Ansichten zur Verfügung.

Bitte beachten:
Anwendern mit einem Wartungs- und Servicepaket wird das Upgrade auf Release 2017-R2
kostenfrei zur Verfügung gestellt.

Mehr Informationen über die Diagnostic and Connectivity Platform von KPIT finden Sie unter www.kpit.com/diagnostics

Über die KPIT Technologies GmbH

Als Experte für Fahrzeugdiagnose und Telematik ist die KPIT Technologies GmbH seit knapp 20 Jahren ein kompetenter Entwicklungspartner für Fahrzeughersteller und deren Zulieferer. Dabei setzt KPIT auf die aktuellsten internationalen Automotive-Standards und ist aktives Mitglied in Standardisierungsgremien der ASAM. Deren Produktfamilie Diagnostic and Connectivity Platform deckt nahezu alle möglichen Anwendungsfälle der Off-Board-Diagnose in Entwicklung, Produktion und Service ab. Neben den auf unseren Produkten basierenden Systemlösungen bietet KPIT Consulting, Engineering-Dienstleistungen und Trainings an. Weltweit arbeiten aktuell etwa 200 Mitarbeiter an verschiedenen Standorten im Geschäftsbereich Diagnose, dessen Hauptsitz in München ist.

Über KPIT
Das globale Unternehmen KPIT ist auf Technologielösungen in den Bereichen der Automobil- und Transportindustrie, Industrielle Fertigung und Energie- und Versorgungswirtschaft spezialisiert. Mit einem Umsatz von über 490 Millionen USD, wurde die KPIT von führenden Analysten und Beratungsunternehmen als einer der am schnellsten wachsenden Unternehmen anerkannt. Gemeinsam mit seinen Kunden und Partnern entwickelt das Unternehmen Technologien, die zu einer sauberen, grüneren und intelligenteren Welt, sowie mehr Nachhaltigkeit und Effizient beitragen.

Firmenkontakt und Herausgeber der Meldung:

KPIT Technologies GmbH
Adams-Lehman-Str. 109
80797 München
Telefon: +49 (89) 3229966-0
Telefax: +49 (89) 3229966-99
http://www.kpit.com

Ansprechpartner:
Stefanie Köhler
Telefon: +49 (89) 3229966-140
Fax: +49 (89) 3229966-999
E-Mail: stefanie.koehler@kpit.com
Für die oben stehende Pressemitteilung ist allein der jeweils angegebene Herausgeber (siehe Firmenkontakt oben) verantwortlich. Dieser ist in der Regel auch Urheber des Pressetextes, sowie der angehängten Bild-, Ton-, Video-, Medien- und Informationsmaterialien. Die United News Network GmbH übernimmt keine Haftung für die Korrektheit oder Vollständigkeit der dargestellten Meldung. Auch bei Übertragungsfehlern oder anderen Störungen haftet sie nur im Fall von Vorsatz oder grober Fahrlässigkeit. Die Nutzung von hier archivierten Informationen zur Eigeninformation und redaktionellen Weiterverarbeitung ist in der Regel kostenfrei. Bitte klären Sie vor einer Weiterverwendung urheberrechtliche Fragen mit dem angegebenen Herausgeber. Eine systematische Speicherung dieser Daten sowie die Verwendung auch von Teilen dieses Datenbankwerks sind nur mit schriftlicher Genehmigung durch die United News Network GmbH gestattet.