Denke auch, in dem Fall muss Cariad ja "nur" die Basis mit VW Branding (glaub Skoda, Cupra machen das schon jetzt auch selbst) versehen und (hoffentlich nicht) das ganze an die Steuergeräte der eigenen Lieferanten anpassen und halt die Oberflächen anpassen und das Backend pflegen.
Also ich hoffe ja inständig dass VW/Skoda/Cariad und Co. zukünftig die Finger von Dingen wie der Oberfläche lassen und das mal schön Rivian erledigen lassen.
Überfällig. Ich frage mich aber, warum nur ein Drittel gehen müssen.
Also ich hoffe ja inständig dass VW/Skoda/Cariad und Co. zukünftig die Finger von Dingen wie der Oberfläche lassen und das mal schön Rivian erledigen lassen.
Das glaube ich nicht, da wird schön jede Marke ihr eigene Corporate Identity Oberfläche drüberstülpen. Zumindest das traue ich ihnen aber schon zu. Zudem wurde bei der Vorstellung des id.2 (ich weiß, dürfte noch nicht Riviansoftware sein, wenn es stimmt ist es noch reines MEB) dass man aus verschiedenen Skins aussuchen kann.
Aber noch ist ja nicht klar mit welchen Modellen das ganze startet. Bei VW wird gemunkelt dass evt. der id.1 der erste ist, bei Cupra soll beim Reval und Cupra Facelift zwar auf Android Auto, aber noch nicht Rivian sein. Mir stellen sich die Nackenhaaren auf wenn ich dieses Mischmasch an Systemen lese... das bei Cupra klingt Softwaremäßig DoA.
Ich bin sehr gespannt wie die Kooperation dann in der Praxis aussehen wird. Rivian baut selbst sehr gute Fahrzeuge und mit dem R2 und R3 kommen ja erst die Modelle für den Massenmarkt. Wie es dann bei VW wohl wird? Liefert Rivian alles und VW baut eine Hülle drum herum und ein paar Sitze ein? Stellt VW die Produktion so weit um, dass sie im Prinzip umgelabelte Rivian bauen? Ich kann es mir nur sehr schwer vorstellen, dass Rivian nur die Software liefert und die sich dann gut in ein VW Konstrukt integrieren lässt.
Könnte ja wechselseitig sein... Rivian> VW = Steuerelektronik und ein paar andere SW Dinge... VW> Rivian = geballte Produktions und Design-Kapazitäten-Power
Ich bin sehr gespannt wie die Kooperation dann in der Praxis aussehen wird. Rivian baut selbst sehr gute Fahrzeuge und mit dem R2 und R3 kommen ja erst die Modelle für den Massenmarkt. Wie es dann bei VW wohl wird? Liefert Rivian alles und VW baut eine Hülle drum herum und ein paar Sitze ein? Stellt VW die Produktion so weit um, dass sie im Prinzip umgelabelte Rivian bauen? Ich kann es mir nur sehr schwer vorstellen, dass Rivian nur die Software liefert und die sich dann gut in ein VW Konstrukt integrieren lässt.
Denke nicht dass VW alles übernimmt, soweit ich das mitbekommen habe geht es vor allem um die Steuergeräte und die dazu passende Software. Akkus (ok momentan noch dazugekauft, aber wollen sie ja auch in Zukunft selbst herstellen) eMotor, Fahrwerk usw. wird sicher VW noch selbst machen. Also ändert sich nicht soo viel: die Steuergeräte selbst kommen ja jetzt schon von verschiedenen Lieferanten (Conti, Bosch usw...) und die Software, naja lieber nicht darüber reden.
Wie ich schon schrieb. Bei OPD wird kein Bremsdruck aufgebaut. Weder Bremszylinder noch andere Komponenten der mechanischen Bremse kommen jemals zum Einsatz. Es wird rein nach dem physikalischen Prinzip der Wirbelstrombremse mit der E-Maschine gebremst, die im Schubbetrieb wie ein Generator wirkt.
Und die Bremsleistung ist nicht bis zum Stillstand linear x m/s zum Quadrat. So muss zum Beispiel, die Bremsleistung kontinuierlich verringert werden, je näher man dem Stillstand kommt. Nur so ist der Vorgang komfortabel und es gibt keinen starken Anhalteruck. Macht man selbst beim Bremsen ja auch.
Und das alles macht ein OPD bis zum Stillstand nicht ganz trivial.
Da eine Wirbelstrombremse prinzipbedingt nicht bis zum Stillstand bremsen kann muss ich entweder den Motor entgegen der Drehrichtung bestromen oder halt doch die mech. Bremse mit einsetzen. Beides kann ich für OPD auch nutzen.
Im Gegensatz zu (p)ACC hab ich bei der reinen OPD-Funktion auch kein bewegliches Hindernis vor mir, auf das ich dynamisch reagieren muss und eine simple Funktion bzw. eine Mappingtabelle "Beschleunigung in Abhängigkeit der Geschwindigkeit" ist absolut trivial (und gibt es an zig Stellen in der Software in abgewandelter in komplexerer Art: Heizleistung/Lüftergeschwindigkeit in Abhängigkeit von Innenraumtemperatur und Wunschtemperatur; Leistung Kühlwasserpumpe in Abhängigkeit von diversen Temperaturen, etc.). Brakeblending ist ebenfalls schon vorhanden, daher bleibe ich erstmal bei meiner Einschätzung, dass es nicht so große Unterschiede in der Komplexität machen kann und OPD vermutlich sogar einfacher umzusetzen ist wie eine Regelung für (p)ACC. (Und es fehlt doch auch nur der letzte Bereich von 5-0km/h - davor wird die Verzögerung vermutlich auch schon dynamisch angepasst, ich hab es für MEB nicht gemessen und finde im Gegensatz zum e-up keine Aussagen in den SSP.)
Wo ich aber bei Dir bin ist der Punkt "Komfort": (p)ACC bremst im Stau schon eher dynamisch und ist von einer manuellen komfortablen Bremsung doch etwas entfernt, das könnte (neben dem Punkt, dass man einem Umsteiger vom Verbrenner evtl. möglichst wenig neues zumuten wollte) ein Grund sein, warum man OPD nicht implementiert hat.
Liebe/r Besucher/in des Enyaq-Forum. Wir würden uns freuen, wenn du etwas zum obigen Thema beitragen möchtest.
Hier klicken, um ein kostenloses Benutzerkonto im Enyaq Forum anlegen
Bereits 10795 Mitglieder sind dabei und tauschen erste Informationen rund um das neue Elektro SUV Enyaq von Skoda aus! Viel Spaß :)
