Beiträge von Jochen_145

    ich glaube kaum, dass der APP_310 auslaufen wird, denn faktisch passt er in den MEBentry und ist günstiger in der Herstellung.


    Zudem unterscheiden sich APP_550 und APP_310 schon deutlich in ihrer "Arbeitsweise", genauer dem Drehmoment und vor allem dem Drehzahlband.

    In der Verbindung mit der hierdurch angepassten Untersetzung, ist der APP_550 nicht pauschal effektivier, als der APP_310.

    Denn gerade, wenn ich den APP_550 auf z.b. 170kW oder weniger "drossel"/begrenze, läuft er in einem Wirkungsgradbereich, in dem er seine Vorteile gegenüber den APP_310 nicht mehr ausspielen kann.


    Entsprechend erwarte ich den APP_310 weiterhin in den Basismodellen. Zudem den meisten 150kW/170kW wahrscheinlich absolut reichen werden..



    Vielmehr hoffe ich in Zukunft noch auf eine 170kW ID.7 "pur", damit auch dieser attracktiver für Familien wird.

    Aber das passiert wohl erst, wenn man über Stückzahlen und nicht über Marge Gewinne erwirtschaften kann/muss/will

    Würde mich also nicht wundern, wenn die jetzt bestellten auch das neue MIB4 bekommen.

    Mich auch nicht ...


    ich hatte im Cupra-Forum schon mal geschrieben, da hier nur die 77kWh-Variante laut Preisliste offensichtlich schon MIB4 hat:


    Ich tippe, dass bei den kleinen Varianten noch MIB3-Stand in den Preislisten steht und konfigurierbar ist, damit möglichst viele gefertige Fahrzeuge noch passend zugewiesen werden können.


    Hat man eine "aussergewöhnliche" Zusammenstellung, die nirgends auf Halde steht, wird man einen MIB4 Fahrzeug bekommen, wenn man "jetzt" bestellt...


    (Ist aber nur mein Bauchgefühl)


    Ich vermute die vorhandene SOK Absicherung wird ihnen ausreichen.

    K.A. :/


    Nur ist dann nicht zu erklären, warum der ID.Buzz schon vor 07-2022 mit MIB3 homologiert wurde, obwohl der erst im Herbst 2023 an Kunden ausgeliefert wurde.


    Mir hat man dies damit erklärt, dass man halt durch die frühe Homologation genau die Notwendigkeit der UNECE umgangen hat.

    Das wäre nicht nowendig gewesen, wenn die SWV3.5 UNECE ausreichend weit unterstützt..



    Aber was da genau betrieben wird, werden wir wohl nie erfahren :P

    Wobei ich mich noch gut dran erinnern kann wie im ICAS1 der SOK Support eingebaut wurde...

    Wobei dabei auch gleich der Zeitserver mitkam. Ich kenne nur SOK Implementierungen mit Zeitserver.

    Ja, es gibt auch SOK-Zeiten und damit auch den Zeitserver. Diese wird aber nicht zu allen "sicherheitsrelevanten" Steuergeräte passend mit Signatur gesendet.

    Zudem gibt es ja auch die "internen" DTCs (s.o.), die aber nicht zu entsprechenden Fehlerreaktion führen.


    Somit ist die MIB3 bei der E2E nicht manipulationssicher, was ich an anderer Stelle auch schon gezeigt habe.


    ist doch unerheblich. für unsere "altbestands" autos ist mit 3.7 ohnehin schluss.

    Genau:

    Wenn mit 3.7 Schluss an der MIB3 ist, reicht die E2E Absicherung iMA nicht, die Anforderungen der UNECE zu erfüllen.


    Und damit sind nach meinem Verständniss MIB3 mit SWV3.7 ab 07-2024 nicht mehr erzulassungsfähig..


    Aber gut, ich muss die VAG-Dokumente auch nicht vor dem KAB erklären ^^




    Da bin ich echt gespannt, was wir für SWV sehen, wenn ID.3 in 07-2024 angemeldet werden, die derzeit noch mit anscheinden (?) MIB3 Verbund frei konfiguiert und bestellt werden können :/

    Aus Defintionssicht UNECE hast du Recht, keine Frage..


    Es hier hier aber vielmehr um die Umsetzung, also ob ich mit der MIB3 UNECE erreiche und MIB3 nach 7-2024 erstzulassungsfähig bleibt.


    Und genau hierfür gebrauchst du halt die funktionierenden Lösungen auf das UNECE-Problem, die bis jetzt zwar implementiert, aber nicht mit der notwendigen Konsequenz überprüft wurde.


    Aus dem Grund ist SOK ein entsprechend wichtiger Idikator für das anstehende Problem.



    Wenn du UNECE nur als "Problem" siehst und SOK als "Lösung" ist aus Definitionssicht unterschiedlich. Aus Systemsicht ist es aber egal, da du ohne "Lösung" des "Problems" keine Erstzulassung mehr bekommst.


    Daher ist es aus Systemssicht nicht sinnvoll, beides für die MIB zu trennen..


    ;)

    SOK ist ein entscheidender Teil der E2E, die im Rahmen der UNECE Absicherung eingefüht wurde. BZ,CS würden zwar in der Theorie reichen, praktisch wird es aber nicht so einfach gemacht.

    Für UNECE musst du die Inter-Steuergeräte-Kommunikation manipulationsfrei darstellen, bzw. gegen Manipulation absicher, was entsprechend über SOK passiert.



    SOK ist als Signatur in MIB3 aktiv, nicht nur für die Entfernung, auch für den Momentenpfad

    SOK-Zeiten waren noch nicht aktiv bis jetzt...


    Master für die Entfernungen ist das ICAS1 (Gateway). Hatte ich gerade in einem anderen Threat beschrieben.

    Ich möchte nochmal auf einen etwas älteren Hinweis zurückkommen:


    Ich arbeite in dem Umfeld und stelle sicher, das Geräte in dem Umfeld UNECE konform sind. Von daher dürfte ich da durchaus näher am Ball sein. Und das bekommst du auch mit Hardware hin, die einige Jahre auf dem Buckel hat.

    Ja!

    das kann ich bestätigen.

    Selbst in der SW3.2 und früher sind schon alle notwendigen Infos und Signale zu finden, die es für UNECE gebraucht. Die Überprüfung wurde nur bis jetzt nicht "scharf geschaltet".


    Wer sich Fehlerspeicherauszüge der MIB3 angesehen hat, kennt SOK-Fehler als gespeicherte DTCs.


    Und deswegen wirst du ab dem 1.7. auch noch einen ID mit MIB3 kaufen können. Wie sinnvoll das aus Kundensicht ist, ist etwas anderes.

    Dann aber mit einem neuen SWV, oder wurde beim Welchsel auf SW3.7 die UNECE jetzt "scharf"?


    Kann aber eigentlich nicht sein, denn zumindest ist auf dem J623 bei der SW3.7 der gleiche Stand, wie bei der SW3.4.

    Und hier war die UNECE nach meinem Wissen, noch nicht "scharf"


    rezis du hast aber auch noch nichts neueres als SW3.7 gesehen?



    Beim Wechsel auf den SW4.x hat sich aber gerade bei der SOK-Kommunikation viel geändert..

    Wenn, beide MIB jetzt grundlegend UNECE können, ist das mit SW4.x aber ein "andere Level"..

    Entschuldigung, wenn ich dir das so direkt sage, aber solche Parolen haut man nur raus, wenn man keinen blassen Schimmer vom Kilometerstand oder Tachometeranzeige hat.

    Vorsicht:

    die Architektur hat sich in der MEB schon deutlich geändert..



    2. Habe ich selber 10 Jahre lang Tachometer und Kilometerzähler für Automobile entwickelt, sowie Sachverständiger dafür gespielt.

    Zur Zeit, als das Kombi noch das "Kombi" war, hattest vollkommen recht.


    In der MEB ist das Fahrerdisplay ("Kombi") wirklich nur noch "Anzeige". Die Funktionallität ist in das Gateway gewandert.

    Entsprechend wird der Kilometerstand vom Gateway gesendet (Entfernungen_01).


    Der Rest ist wieder vollkommen korrekt:

    der Kilometerstand ist hoch "manipulations gefährdet" und wird daher auch mit einer SOK-Signatur auf CAN gesendet.


    Es ist auch richtig, dass die Entfernungen von mehreren Steuergeräten gespeichert wird.

    Welche möchte ich aus verständlichen Grund nicht schreiben..



    Zurück zum eigentlichem Thema:

    In der App stehen rund 66 tkm, auf dem Tacho/ICAS3 werden rund 33 tkm angezeigt.

    Von welchem Steuergerät hast du den Kilometerstand mit OBDeleven gelesen?

    Ich habe zuvor einen BMW I3 gefahren....Ladekurve beginnt bei 49 KW, bleibt bei 49 kW und wird erst ab 90% weniger. Völlig egal, wie man vorher gefahren ist, welche Temperatur es hat

    Diese Aussage ist komplett falsch, die Batterie des i3 arbeitet komplett vergleich der des ID.3 bei entsprechender Temperatur.


    Wieviele Messdaten soll ich dir zeigen ?! :rolleyes:


    Zudem sind die 50kW nicht die Begrenzung der Batterie, sondern die des Systems (EME kann nicht mehr als 50kW DC "händeln" und die Verbindung zwischen KME und EME ist nur 25mm², was keinen höhren Dauerstrom zulässt...

    Ohne Messdaten und eine Fehlerspeicherauszug ist es wieder nur "Glaskugel gucken" und jeder zieht sich den Teil aus den Aussagen, der ihm am meisten "hilft", seine betreits getroffene Meinung zu festigen.


    Das bringt nur keinen weiter...


    Ein "High Voltage sudden resest error" könnte (!!!) ein "fail-save" des Systems auf eine fehlerhafte Fahrzeugfunktion sein. In diesem Fall wird die Energiequelle abgeschaltet, was jegliches Antrieben des Autos unterbindet. Entsprechend auch die Rekuperation als zusätzliche "Bremshilfe".

    Also der Selbstschutz des Fahrzeugs in einem entsprechenden Fehlerfall.


    Und nein, das ist kein Selbstbeschleuniger, denn der Fahrzeug hat diesen durch die Abschaltung dem selber unterbrochen.

    Wie wird diese normalerweise aufgezeichnet bzw. aus was berechnet und warum wird das Ausbleiben nicht als DTC eingetragen?

    das Airbag-SG guckt auf die Motordrehzahl, die das Motorsteuergerät sendet. Das ist historisch bedingt. Die ECU übernimmt die Motordrehzahl vom Inverter, der diese aus dem Resolver bestimmt und auf CAN sendet.

    Bleibt die Motordrehzahl auf CAN aus, gehen eine Vielzahl von Steuergeräte in den Fehler, da die Motordrehzahl eines wichtigsten Signale im Fahrzeug ist.


    Wenn keine DTCs eingetragen sind, war die Motordrehzahl für alle empfangenden Steuergeräte verfügbar.



    Steht diese Zahl im Zusammenhang mit den Drehzahlfühlern?

    Nein, das sind getrennte Signale und getrennte Quellen.

    Raddrehzahlen kommen von ABS, Motordrehzahl vom Inverter.



    Und wenn ich VW wäre und mir eine Kundin so genau eine Kurve durch alle drei Gaspedalstellungen von 3 verschiedenen Fahrern legen kann, würde ich dann doch mal in meinen Code schauen und überprüfen, ob das nicht meine Initialwerte für die Gaspedalstellung sind.

    Du verrennst dich hier gerade.

    Erstmal sind die Pedalwerte aller EDR-Aufzeichnungen unterschiedlich.

    Dann gibt es in Software nur einen Initialwert und nicht unterschiedliche für die gleiche Grösse (macht auch überhaupt keinen Sinn)

    Die Pedalbetätigung ist analog zu einer Bremsbetätigung, wie diese aktuiert wird, denn die erwartete Fahrzeugreaktion ausbleibt.


    Zudem arbeiten Logger nicht mit initial bedateten Speicher, die dann überschrieben werden, sondern es werden erst Daten in den Speicher geschrieben, wenn auch gespeichert wird.

    Passiert es nicht, steht "nichts" im Speicher..

    Genau das schreib ich auf der Seite. Dass Level 2 Assistenten ausfallen und keinen Fehlereintrag ablegen. Das ist halt deshalb problematisch, weil es da eben auch ein Video von einer Fehlfunktion auf der Autobahn gibt, wo der ID.3 auf 180km/h beschleunigen will. Damit rechnet erstens keiner und zweitens kann es nachher halt auch keiner beweisen, dass was falsch gelaufen ist.

    Ich halte die Aussage, das im genannten Fall die Level-2 Assistenzsysteme "ausfallen" für eine nicht passende Definition der Funktion:


    Das System fällt nicht aus, sondern deaktiviert bewusst eine Funktion und reaktiviert sie wieder, sowie die Umgebung plausibel detektiert wird,

    Genau genommen ist das eine definierte, funktionierende Funktion der Software, auch wenn sie vom Fahrer als "Ausfall" wahrgenommen wird.


    Daher gibt es halt auch verständlicher Weise keine DTCs.


    Auch ist die Zielgeschwindigkeit "180km/h" nach Reaktivierung der ACC-Funktion kein Softwarefehler, sondern eine Applikationsvorgabe.

    (rot ist auch keine fehlerhafte Farbe, wenn ich persönlich grau schöner finde).

    Die Software macht genau, was sie soll: sie re-aktiviert die ACC-Funktion auf die applizierte Geschwindigkeit, die bei "Auflösung der Geschwindigkeitsbegrenzung auf BAB", die eben nicht mehr limitiert ist,

    130km/h zu erwarten ist ein persönlicher Wunsch, den nicht jeder teilt.


    Auch kann ACC mit maximal 2m/s² beschleunigen. Das ist nichts, was auch nur annähert Volllast ist und kann jederzeit vom Fahrer überstimmt werden, wenn ihm da zu schnell erscheint.


    Die HV-Batterie wurde vom ADAC getrennt, aber die 12Volt war dran. Daher wahrscheinlich auch der Fehler zum Antriebsstrang. Das Fahrzeug hat bei dem Unfall wie schon erwähnt nur minimal Schaden genommen.

    Die Fehlermeldung ist in diesem Fall auch vollkommen korrekt:

    Wird der Service-Dis-connect oder die Sicherung der Klemme30c zur Deaktivierung der HV-Batterie gezogen, werden die Schütze der HV-Batterie nicht mehr aktuiert.

    Beim Aufschliessen und Türöffnen, aktiviert der HVK normaler bereits die HV-Versorgung zum Fahrzeug, was in diesem Fall nicht möglich ist.

    Entsprechend erscheinen die Fehlermeldungen, dass DCDC-Wandler und Inverter mangels HV-Versorgung nicht arbeiten können.


    Mein Punkt war der, wie auch von Auto Motor Sport erwähnt, dass die Steuergeräte eine gewisse Zeit brauchen, bis ein Fehler festgestellt wird.

    Im Falle des CAN-Busses ist diese Entprellzeit bei VW, je nach Integrität des Signals zwischen 1 und 3 Zykluszeiten.

    Also sind diese "gewisse Zeiten" beim sicherheitsrelevanten Signalen iDR deutlich und 50ms


    Im Momentenpfad muss ich 400ms nach Erkennen eines Fehler das System abgeschaltet haben.

    Von der Kommandierung der HV-Schützöffnung bis zum sicheren Öffnen und damit Unterbrechen des Stromflusses, vergehen maximal 150ms.


    Entsprechend kann die Debounce-Zeit über eine Fehlerentprellung maximal 250ms betragen.


    Das passiert halt schon "schnell"....

    Mir hat mal ein Ingenieur (Entwicklungszentrum Opel) erklärt, dass jedes Auto über stärkere Bremsen verfügen muss als die maximale Motorleistung beschleunigen kann, um eine Typzulassung zu bekommen.

    Das ist richtig:

    die Bremsleistung der mechanischen Bremse ist iDR um das drei bis vierfache der Motorleistung überragend.

    Um einen 1.8t in etwa 34Meter von 100km/h auf 0 km/h zu bremsen gebraucht es über 700kW Bremsleistung.

    Also ist es "problemlos" möglich die 150kW Antriebsleistung der APP_310 zu eliminieren.


    Was man hier nicht vergessen darf:

    die maximale Bremsleistung benötigt auch einen entsprechenden Bremsdruck, also einen beherzten Tritt auf das Pedal.

    Gerade, wenn z.B. die Bremsunterstützung nicht so arbeiitet, wie gedacht.



    Mit Jochen_145 hab ich inzwischen geredet und der geht d'accord mit dem, was ich auf http://www.myid3crash.com über Level2 Fahrerassistenzsysteme geschrieben habe.

    Ich habe mir den Part noch einmal durchgelesen und muss diesem Widersprechen:


    Punkte, die IMA nich ausreichend getrennt sind:

    es gibt nicht das eine "Level2":


    Ein Assistenzsystem mit Autonomie-Level 2 grundlegend etwas anderes, wie eine Level-2 Überwachung der Steuergeräte auf FuSi Ebene.


    Das "Ausfall" der Assisenssysteme, wie auf der Seite beschrieben, ist eine normale, sich selbst heilende Fehlerfunktion, wie sie ein Autonomie-System nach Level-2 macht:


    Die Assistensystem sind nicht "fail-operational", deaktiven ihre Funktion, sowie z.B. Sensor-Information nicht eindeutigt sind und re-aktivieren diese wieder, wenn die Sensorik wieder vertrauenswürdig ist.


    Genau aus dem Grund (!), muss der Fahrer jederzeit (!) vom Assisenssystem übernehmen oder überstimmen können.


    Dieses Verhalten ist aber keine Steuergeräte-Reset nach FuSi Level-2.

    Kommt es zu einem Level-2 Reset eines Steuergerätes, sendet es nicht mehr aud CAN. Alle weiteren Steuergeräte, die diese CAN-Signale empfangen gehen in einen Fehler, der NICHT selbstheilend ist und einen Zündungswechsel gebraucht, damit da Fahrzeug wieder funktionsfähig ist.

    Zudem sind in den Fehlerspeichern aller weiteren Steuergeräte mit entsprechend DTC gesetzt.


    Da die Fahrzeuge in dem Beispiel weiterfahren, kann zu 100% davon ausgegangen werden, dass hier kein Level-2 Reset vorliegt, sondern einfach eine Funktions-deaktivierung, die das System bei unplausibilität genau so machen darf und muss.




    Vielleicht noch einmal ganz deutlich:


    Der Funktionsumfang eines Level-2-Autonomiesystems wird vollkommen fehl eingeschätzt, wenn man/frau sich "blind" auf dessen Funktion verlassen will !


    Ich muss jederzeit (!) mit einer Fehlfunktions rechnen und das System überstimmen können. Das System assistiert mich nur, übernimmt nicht eigentständig Fahrfunktionen.

    Wenn ich die Beschreibung des Hardware Konzepts in der VW.OS in diesem Wikipedia Artikel allerdings richtig verstehe, genauer gesagt die sogenannte E³ End to End Elektronik- Architektur, hat VW die Kommunikation der Steuergeräte in Software ausgelagert. vw.os – Wikipedia

    Vorsicht:


    E³ ist ein Hardwarearchitektur mit der die Vernetzung in Zukunft aufgebaut wird.

    E³ hat erstmal nichts mit der E2E-Absicherung des CANs zu tun.


    E³ funktioniert auch mit Ethernet, LIN, SENT, K-Line und allen anderen möglichen Protokollen. Es beschreibt die grundlegende Architektur mit Hauptrechner und Slave-Sensorik und Aktorik, sowie "intelligente" Sensorik und Aktorik.

    Also das Zentralisieren in eine Hauptrechner, anstatt der derzeit verwendeten dezentralen Einzelsteuergeräte.


    E2E ist eine zusätzliche Absicherung auf Protokollebene, mit der du sicherstellen kannst, dass die gesendeten Daten auch so einem Empfänger angekommen sind, wie der Sender sie abgeschickt hat. (Integres senden).


    Kann diese gegenseitige Detektion noch funktionieren, wenn der Hauptprozessor, auf dem die Applikationssoftware läuft, einen Fehler hat?

    Auf den Einzelsteuergerät nicht mehr. Aber ein Hauptprozessorausfall wird über die Level2-Überwachung des Steuergerätes selber erkannt und mit Abschaltung quittiert. Dann fehlen dir aber alle entsprechenden auf CAN gesendeten Signale und die Funktion des Steuergerät selber (fail-save!).


    Diese fehlende Kommunikation muss/wird dann entsprechend in allen Steuergeräten als DTC hinterlegt sein, da die Steuergeräte für sich wichtige Signale "Vermissen".


    Der Hinweis zur Motordrehzahl als 13 bit Wert war die Vermutung von Jochen_145 Falls das nicht richtig ist und jemand weiß,

    Das passt doch aber:


    01 2C (dez. 300) ist die Identifikation der Datenreihe für die Motordrehzahl. Danach kommen 11 Datenwerte mit je 1Byte (8bit) Länge. Diese sind mit Faktor 64 zu multiplizieren, damit du die gespeicherte Motordrehzahl hast.

    Die gesamte Datenreihe hat 13 Bytes..


    (Bit/Byte durcheinander ?!)