Ich verstehe dich und weiß durchaus was du meinst, aber ich denke bei sowas wird/sollte es nach wie vor große Updatepakete geben.
Bei den kleineren Dingen bspw. Übersetzungfehler, Logikfehler oder Verhalten, das sich rein auf die Software bezieht, denke ich, sind diese Delta-Updates durchaus gut und angebracht.
Von diesen „kleinen“ Fehlern stecken ja auch zu genüge in der Software unserer PS2 und die ärgern mich persönlich auch am allermeisten…
Ich verstehe nur nicht warum Polestar immer in Dingen rumpfuscht und diese verschlechtbessert, die zuvor funktioniert haben und in welchen sie im Nachhinein angeblich nichts geändert haben, laut deren Aussage?!
„Kleine“ Updates könnten gezielt eine winziges Problem beheben, wenn man sich sicher ist, dass es keine Seiteneffekte gibt. Klingt gut.
ABER: wie Uwe @Electrified richtig anmerkt, steigt so die Variantenvielfalt und damit wandert Polestar ganz leicht in die berühmte Version-Mismatch-Hell oder Dependency-Hell. Daran beissen sich echte Profis die Zähne aus und eigentlich versuchen alle heute das zu verhindern.
Viel Erfolg, @Polestar, aber verhebt Euch nicht…
Matthias, nein du hast mich noch nicht verstanden.
Ich rede rein von Software. Es ist, glaube ich den wenigsten klar, dass eine Automotive Software ein extrem sensibles Gebilde ist. Ich möchte da gar nicht zu weit ausholen - aber diese Software hat nichts mit Java Scripting oder sonst einer Anwender-SW zu tun die man so allgemein kennt.
Teilweise musst du in der Automotive-Software die Ausführungsdauer-Unterschiede einzelner Tasks auf verschiedenen Cores mit berücksichtigen damit das alles nahtlos funktioniert. Wir sprechen hier von nano-Sekunden Level. Im Extrem kann allein schon eine Code-Zeile weglassen oder hinzufügen die SW zum kippen bringen.
…und dann kommen dann noch so laienhaft Unbedarfte wie ich, die in den Menüs und Optionen die unzähligen möglichen Einstellungen in alle Richtungen einstellen (oder verstellen) und so - aus Sicht der Entwickler und Programmierer - unter Umständen ganz „unerwartete“ Kombinationen im System generieren (auch im Zusammenspiel mit externen Systemen wie z.B. den unterschiedlichsten Ladestationen)…und danach melden wir uns hier im Forum, dass vor dem letzten Update doch alles (oder wenigstens das meiste) ganz leidlich funktioniert hat, und jetzt nicht mehr…
So jedenfalls kann ich mir - zusammen mit euren Expertenkommentaren - in etwa vorstellen, wie schnell man
kann, wenigstens bei bestimmten Funktionen oder Abläufen: wie gesagt, wohl etwas laienhaft beschrieben, deshalb danke für eure Nachsicht
Exakt, du hast eines der vielen Probleme erkannt. Das was du beschreibst nennt man Use-Cases die ALLE über entsprechende Tests VOR Auslieferung zu testen sind.
Das Problem daran ist „alle“ - denn „alle“ ist eine universal Synonym und unmöglich fassbar. Darum gibt es normalerweise den „not defined use case“ für nicht von der SW Logik abgefangene Zustände. Der nduc muss sicher sein und darf nicht zu Fehlfunktionen führen. Im besten Fall geht ein Fenster auf „unbekannter Zustand“ oder so und alle Änderungen werden zurückgesetzt. Bei einer Ladesäule natürlich eine bisschen schwierig
Und jetzt „alle“ Zustände (die kombinatorische Explosion verbietet das schon) gegen eine völlig wilde Anzahl von Versions-Kombinationen, die bei Kunden herumschwirren testen…
…dafür gibt es Tools - schau mal unter zB. CONGRA-SCODE von ETAS.
Um das allein Hirn-technisch zu bewältigen ist heute der beste Entwickler überfordert; reicht schon wenn er kein Zustand/Bauteil in der Tool-Eingabe vergisst.
Erinnert mich an die erste Zeit nach Installation einer Alarmanlage eines namhaften Herstellers daheim. Nach einigen abenteuerlichen Reaktionen und Fehler-Loops, die nur per Hard-Resets zu beenden waren, hat mir der Errichter einen Teil der Antwort des Herstellers an ihn durchgesteckt:
„Ihr Kunde verhält sich nicht so, wie wir es erwartet haben“
… und ich nehme an, das war eher noch der höfliche und zitierfähige Part. Mittlerweile haben wir uns aneinander gewöhnt - insofern gebe ich die Hoffnung auch beim P2 nicht auf. Und in der letzten Zeit (bis zum AC-Ladebug) haben wir uns auch recht gut verstanden
Da bin ich absolut bei dir: über einen Monat begeistert im Alltag unterwegs, nichts neu eingestellt, was nicht unbedingt nötig war, da beim Hand Over Anfang Juni alles bestens eingerichtet wurde und geklappt hatte (inkl. App und deren Basisfunktionen, aber vorerst ohne Digital Key), „mein“ erstes OTA Update (P2124) problemlos installiert…bis dann halt beim ersten Mal AC Laden danach die Anzeige der Wallbox-App nicht mehr so aussah wie gewohnt.
Der momentane Ausfall der App Verbindung und der Funktionen scheint ja eher ein Severproblem o.ä. bei Polestar selber zu sein
Beim PC oder beim Mobiltelefon lohnt es sich mitunter, die „grossen“ Updates vorerst auszulassen (z.B. Version 10.1) und dann erst eine der meist relativ kurz danach nachgereichten Versionen (Version 10.1.X) zu installieren, welche nach dem „Test beim Kunden“ die gröbsten, in der realen Welt aufgetretenen Fehler bereinigt haben ohne gleichzeitig schon wieder neue Funktionen einzubauen.
Beim Polestar 2 kann ich das bis jetzt eigentlich nicht machen, denn die via OTA verteilten Updates sind bisher immer nur „grosse“ Updates: Fehler in Vorversionen werden zwar im besten Fall behoben sein, aber mit den neuen oder geänderten Funktionen werden gleichzeitig neue potenzielle Probleme installiert…
Also Updates konsequent nur noch in der Werkstatt aufspielen und installieren lassen? Dort gibt es ja dann offenbar eher eine Chance auf „nachgebesserte“ Updates via OTA
Bislang hatte ich kein Problem mit den OTA‘s und nach meinem Kenntnisstand haben auch die „Anpassungen“ bis incl. 2127 beim Service-Partner nicht vor dem AC-Ladebug geschützt.
Und ob die jeweils absolut neueste Variante beim Service-Partner unbedingt die Problemlosere sein wird, bezweifel ich (gerade nach den Ausführungen hier). Mal eben auf die Schnelle was nachbessern scheint nicht zwingend die beste Variante zu sein.
Du hast mich überzeugt, was die momentane Art und Weise betrifft, wie Polestar Updates „designt“, und die unterscheidet sich in meinem Verständnis offenbar sehr grundlegend von derjenigen, wie es z.B. manche Mobiltelefon Hersteller für ihre aktuellen Geräte machen.
Ich nutze beruflich z.B. ein iPhone und da kann ich (bzw. unser IT Support) anhand der fortlaufenden Versionsnummern (und nicht anhand von Versionswochen und -tagen wie bei Polestar…) ganz leidlich abschätzen, ob wir eine Version mit grossen Neuerungen oder eher eine Version mit gefixten Problemen erwarten dürfen. Und wenn dann auch noch die Qualität hinter den zu installierenden Programmzeilen stimmt, dann erhalte ich nichts auf die Schnelle Nachgebessertes, sondern eine +/- zuverlässig funktionierende „Zwischen-Version“ im Lebenszyklus eines Betriebssystems (im Falle von iOS z.B. wieder mit normalem Akkuverbrauch statt Leersaugen innert kurzer Zeit beim ersten Ausrollen neuer Funktionen).
Aber natürlich ist ein Betriebssystem wie AAOS um Grössenordnungen komplexer als ein Betriebssystem für ein Mobiltelefon, womit wir wieder zurück auf Feld 1 sind: viel Quantität ohne ausreichende Qualität schafft dann eher jedesmal neue Probleme als bestehende zu beheben: ob das der Ansatz im Thread Titel besser in der Griff kriegt? Eigentlich schon…
Wobei die grundlegenden Funktionen vermutlich nicht AAOS sind!
Spätestens sicherheitsrelevante Funktionen, welche in Echtzeit funktionieren müssen, werden m.E. nicht von AAOS gesteuert.
AAOS ist in meinen Augen mehr das Interface zum Fahrer.
Die Rückfahrkamera funktioniert z.B. schon während AAOS noch startet…
Korrekt!
AAOS ist Multimedia (Navi, Telefon, Musik, Video. …), externe Kommunikation (LTE, GPS, BT, …) und Human Interface (Einstellung von Ladeparametern, Assistenten An/Aus und sonstige Kleinigkeiten wie Klima,…).
Alles was zum eigentlichen Fahren (DC-Steuerung, Inverter, elekt. Lenkung, ESP/ABS…) und Laden (AC/DC, BMS,…) benötigt wird läuft nicht über AAOS sondern über Steuergeräte mit eigenem OS.
Danke euch beiden: wieder was gelernt, bin halt wirklich nur Laie, wenn’s so technisch wird , wobei’s dann wohl kaum weniger komplex ist und ich für mich in Gedanken bei meinen vorigen Überlegungen einfach AAOS durch „Polestar-2-eigenes-OS“ ersetze.
Aber ich halte mich nun hier wieder etwas raus und lese „nur“ noch mit, will mich ja schliesslich nicht weiter blamieren
Blamieren tut sich hier niemand!! Ganz im Gegenteil, Ansichten und Meinungen außerhalb des gewohnten Denkschemas können auch schonmal recht hilfreich sein.
Es ist soviel Hirnschmalz gerade unterwegs in diesem Thema. Ich Stelle mir nur eine Frage. WARUM wird wenn massive Fehler auftreten, nicht ein Rollback gemacht und die alte version aufgespielt ? Bis das Problem gefixt ist
Zum Einen sind „wenige Prozent“ im Automobilsektor eine Katastrophe.
Und zudem gehe ich davon aus, dass mit „successful installations“ lediglich der erfolgreich abgeschlossene Ausrollvorgang gemeint ist und nicht die Funktion danach. Wenn sich das auf die Funktionalität beziehen würde, müsste der Wert mit jedem aufgetauchten Bug sinken.
, wobei’s dann wohl kaum weniger komplex ist und ich für mich in Gedanken bei meinen vorigen Überlegungen einfach AAOS durch „Polestar-2-eigenes-OS“ ersetze.
