Beiträge von Jochen_145

    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 ?!)

    Vieles ist schlüssig aber einige logische Fehlschlüsse und falsche Infos zur Interpretation von Daten sind bei dir mit drin.

    Ja, dem muss ich mich leider anschliessen..


    Z.T. werden durch wahrscheinlich nicht ausreichendes Wissen (nicht böse gemeint!) über Steuergeräte- und Vernetungsfunktionen, falsche Rückschlüsse gezogen.


    Simons Angebot ist sehr löblich und ich würde empfehlen, seine Meinung/Erfahrungen mit einzubeziehen und ggf. Korrekturen durchzuführen.


    Auch ich stehe gern weiterhin für Diskussionen bereit, sowie es sich zeitlich einrichten lässt.

    Schon mal vielen Dank für eure Rückmeldungen :thumbup:

    Gerne weitere Meinungen posten.


    Ich möchte mich nicht zu Tief in die Konzepte einer möglichen externen Vorkonditionierung vertiefen, da diese für eine Umsetzung auch nochmal verifiziert werden müssen.


    Letztendlich kann man vorhandene Komponenten nutzen.

    Die ensprechende Ansteuerung über die VW-Software hinaus, ist die eigentliche Herausforderung.

    Und da ich zumindest einen Schalter gebrauche, ob und wann ich vorkonditionieren will, wird diesen irgenwie "extern" erstellen müssen.


    Am Ende würde man aber grundlegend bereits vorhandene Bauteile nutzen.

    Mehr möchte ich aber nicht beschreiben.




    Nur um keine unnötigen Erwartungen zu erzeugen:

    ICH habe nicht vor, eine solche Lösung anzubieten.



    Mich interessiert einfach, wieviel "Leidensdruck" die fehlende Vorkonditionierung bei Bestandskunden schaft und ob diese daher bereit wäre, eine kostenpflichtige, externe Lösung zu zukaufen oder damit lebt, dass es die VoKo wahrscheinlich bei den Bestandfahrzeugen nicht mehr geben wird.


    Am Ende ist die ideale Lösung eine VW-seitige Implementierung von der VoKo in Software der ICAS3 und des BMS. Das ist klar...



    Also nochmals Danke! :thumbup: für eure Meinunge und gerne weiter posten

    … und in Zukunft ist dann VW raus, bei egal welchem Schaden. Super Idee.

    nicht zwingend, warum?


    Ganz zu schweigen von ABE oder ECE, das ist schlicht weg Fantasterei.

    Warum sollte es auf eine solche Möglichkeit keine ABE oder ECE geben?

    Wenn man weiss, was man da tut, wird nichts anderes als eine Serienfunktion der SW4.0 nachgebildet.


    Ich glaube, du hast gerade keine Idee (Phantasie), wie eine solche externe Akku-Vorkonditionierung aussehen muss, damit die Batterie nicht gefähredt wird.



    Aber das steht auch garnicht zur Diskussion:

    Es geht viel mehr darum, wie viele User, die die VoKo vordern und als absolutes Must-Have darstellen, bereit sind, eine entsprechende Lösung zusätzlich zu erstehen, wenn sie von VW nicht angeboten wird.

    dass müsste ich prüfen, wenn ich eine Größenordnung kenne

    ja, da habe auch noch wirkliches Gefühl..

    Es gebraucht halt schon etwas Hardware, mit PWM Endstufen, LIN-Knoten, CAN-Knoten und wahrscheinlich in Wifi o.ä. für eine Handy-App Anbindung oder ein Bedienfeld.


    Also muss die Funktion selber und eine Bedienoberfläche entwickelt werden.

    Ich glaube kaum, dass jemand soetwas unter 200€ hier anbieten würde, auch wenn alles in Fernost gefertigt würde. Die Entwicklungskosten kommen ja auch noch hinzu.


    Keinen Pfennig. Muss als kostenloses Update kommen.

    müsste es, ja..

    Aber die Anzeichen stehen halt nicht so toll.


    Du würdest weiterhin darauf verzichten, wenn du zusätzliches Geld in die Hand nehmen müsstest?

    ( ist eine offene Frage und nicht böse gemeint, mir geht es um ehrliche Meinungen :) )

    Mich würde mal interessieren, wie viele MEB-User bereit währen, für eine Externe Lösung einer AKku-Konditionierung Geld aus zu geben und wenn ja, wieviel ?


    Es wäre iMA schon möglich, unabhängig der SW3.x eine Vorkonditionierung für den Akku über eine "externe Lösung" zu ermöglichen.

    Wenn diese aber passend funktionieren soll und bedienbar sein soll, müsste man an schon ein bisschen Aufwand betreiben und ein. zwei Dinge noch mal gegenprüfen. Das ist natürlich auch ein finanzielles Risiko, was ein möglicher Anbieter abwägen muss.


    Daher interessiert es mich, wer bereit wäre für eine solche Funktion Geld in die Hand zunehmen und wieviel ?

    Fazit: Leider funktioniert mein Workaround überhaupt nicht.

    Konnte er auch nicht, denn im Gegensatz zu deiner Interpretation haben die ID keinen Kühlwasserzufluss in die HVAC.

    Mit Wärmepumpe kann der Innenraum über das Kältemittel und dem PTC-Heizer geheizt werden, ohne WP bleibt nur der Zuheizer.


    Entsprechend wird keine Abwärme aus dem Kühlwasser für die Innenraumheizung genutzt.


    Technisch könnte man die Abwärme des Antriebs für die Batterieheizung nutzen, das passiert gemäss Beschreibung und meinen Messungen nicht.

    Das BMS kommuniziert die maximale Ladeschlusspannung, die Peak- und Dauerladeleistung, und den Peak- und Dauerladestrom.

    Der OBC "übersetzt" diese Infos für den HPC und sendet es per Powerline-Kommunikation.


    Im Rahmen dieser Parameter stellt der HPC den entsprechend möglichen Ladestrom und damit die Ladeleistung.


    Ist die Batterie zu kalt, wird die mögliche Ladeleistung entsprechend reduziert und kommuniziert.

    Der HPC reduziert die aktuelle Ladespannung soweit, dass die maximale erlaubte Ladeleistung gestellt wird und der entsprechend reduzierte Ladestrom fliesst.


    Auf diese Weise kann ich sowohl eine strom- wie auch eine spannungsgeführte Ladung realisieren.


    Im Falle des 77kWh Akku ist die maximale Ladeleistung über das BMS auf < 200kW (genaue Parameter habe ich gerade nicht im Zugriff) reduziert, daher sieht man sie an der Ladesäule nicht.

    ist die Temperatur der Batterie auch zu tief, wenn es draußen 23°C sind?

    Ja, wenn die Batterie z.B. auf Grund kalter Nacht oder warum auch immer, noch deutlich kälter ist.

    Die 62kWh Batterie wiegt rund 385kg, die Module werden nur über die Bodeplatte an die Umgebungstemperatur angeglichen.

    Das dauert durchaus lange, bis die Batterie sich kurzfristigen Umgebungstemperaturänderungen anpasst.


    Nochmal:

    solange die gemesse Batterietemperatur und der Start-SoC beim Laden nicht bekannt ist, ist es müssig sich über Umgebungstemperaturen, Anfahrstrecken, Ladehäufigkeiten zu diskutieren.


    Der Zusammenhang zwischen Ladeleistung, Batterietemperatur und SoC ist "fixe" Zellchemie.

    Solange dieser Zusammenhang "passt", gibt es keinen Defekt an der Batterie.


    Erst, wenn trotz passender Batterietemperatur und SoC die Ladeleistung immer noch zu gering ist, kann man möglichen Ursachen suchen.

    Dafür muss dieser Nachweis aber erstmal erbracht werden.


    Pauschallieren hilft überhaupt nicht..