SuperB iV - OCU vervangen

L

lsmv

Lid
Sinds een week heb ik een storing dat de SOS module niet werkt en dat ik naar de garage moet. De auto is daar geweest en de conclusie is dat de OCU vervangen zou moeten worden. Kosten: 1000 euro. Beetje zonde van het geld, wetende dat de auto het gewoon doet en ik zelfs verbinding krijg als ik op de SOS knop druk. Een werkend systeem zonder foutmeldingen is alleen verplicht voor de aanstaande APK.

Via onderdelensites is de betreffende VAG module aanzienlijk goedkoper te vinden. Deze zou dan alleen moeten worden ingebouwd en opnieuw worden aangemeld. Het lijkt me dat dit een specialistische klus is. Zijn er mensen/bedrijfjes die dit doen?
 
unphoto

unphoto

Lid
Welke garage, de handelaar of de dealer?
9 van de 10 garages hebben geen diagnose specialist meer en gooien direct onderdelen naar de wagen.

Ben je al bij een VAG specialist geweest?
Is het niet een software issue?

Dit probleem is niet alleen op het MQB platform heel frequent, maar ook op het MLB Evo platform bijna orde van de dag waar het softwarematig uiteindelijk kan worden opgelost.

Misschien dat @Antera of @Rainesh jou hiermee kan helpen.

Sowieso is het handig als je de daadwerkelijke storing hier even deelt.
Zonder specifieke info kan er van afstand niet veel onderscheid worden gemaakt.
 
L

lsmv

Lid
De auto is bij de Skoda dealer geweest. Die hebben hem uitgelezen en komen tot de conclusie dat de module moet worden vervangen op basis van foutcode B200049.
 
Laatst bewerkt:
unphoto

unphoto

Lid
Ik zie dat je al een keer contact zou hebben gehad met 1 van de 2 heren in het "Hoofdgebruiker" topic.

Sowieso komt het hier op hetzelfde principe neer. Dealer zal vrijwel altijd nieuwe hardware naar de auto gooien.

Hopelijk voor jou is het met een update van de OCU op te lossen.
 
unphoto

unphoto

Lid
Jazeker. SOS/Telematics moet functioneren tijdens het afnemen van de test.
Dit is onderdeel van het noodsysteem, net zoals ABS en airbags.
 
unphoto

unphoto

Lid
lsmv zei:
De auto is bij de Skoda dealer geweest. Die hebben hem uitgelezen en komen tot de conclusie dat de module moet worden vervangen op basis van foutcode B200049.
Klik om te vergroten...
Dit is een vrij generieke melding helaas.

In de basis is dit een interne voeding of modem issue.
Ben wel benieuwd op welke software versie die van jou draait.

De module zelf heeft wel verbinding lees ik uit jouw openingsbericht.
Eigenlijk zou je de module willen ontladen, alleen kom je er vaak moeilijk bij en heeft het dus ook nog een interne voeding.

Tja, hopelijk kan een van de heren hierin iets voor jou in betekenen.
 
Laatst bewerkt:
Antera

Antera

Donateur
Dealer pakt altijd nieuw

2de hands kan prima mits precies hetzelfde onderdeelnummer als er nu in zit.

Soms kan de storing ook simpel in engineering mode gereset worden. Dit ook al een paar keer gehad.

Module zit achter je scherm in je middenconsole. Kom je makkelijk bij laatst ook een gedaan
 
EdwardP

EdwardP

Forumguru
Klopt, je hebt die van mij laatst gedaan om de batterij te vervangen.
Het is zeker een hardware issue? Want als het de batterij is, dan kun je die online bestellen en via @Antera laten vervangen voor een fractie van de prijs.
 
L

lsmv

Lid
De dealer is ervan overtuigd dat het een hardware issue is en dat er voor 1000 euro een nieuwe OCU in moet.
Ondertussen is de storing spontaan verdwenen en rijd ik al 24 uur storingsloos. Geen idee wat ik daar dan van moet denken...;)
 
L

lsmv

Lid
Hij doet het weer, zonder foutmeldingen. Lampje staat op groen. Mocht ie weer in storing gaan, neem ik contact op met 1 van jullie.
Bedankt voor jullie reacties!
 
R

R1200C

Lid
unphoto zei:
Hardware issues zijn er, of ze zijn er niet.
Software issues komen en gaan.
Klik om te vergroten...
Mwa, hardware issues kunnen situationeel zijn. Sommige issues treden op bij bepaalde weertypes en zijn zeker hardware gerelateerd. Het grappige is dat software veel minder situationeel zijn. Code verandert namelijk niet zomaar en dat maakt fouten reproduceerbaar.

In beide gevallen geldt wel dat je om een fout te kunnen reproduceren alle aspecten hetzelfde moet hebben. Daar zit vaak het probleem.

Als een storing niet meer optreedt op dit moment dan is er iets verandert tussen het moment dat de storing voor het laatst is vastgesteld en nu. Kan al zoiets simpels zijn als "na x meldingen wordt een nieuwe melding genegeerd en dus niet doorgegeven".

Het zou mooi zijn als ontwikkelaars (van hard- en software) meer aandacht zouden besteden aan goede foutmeldingen...
 
unphoto

unphoto

Lid
Het volledig na tevredenheid rapporteren is iets wat enorm moeilijk is. Laten we zeggen dat we een ECM hebben van Siemens en de Gateway is van Continental. Deze communiceren over LIN en/of CAN.
De engineers die voor object X firmware programmeren hebben een andere aanpak dan voor object Y, in relatie tot laten we zeggen Bosch of Delphi.

Zij hebben een grotere markt en passen hun hardware op een grotere (andere) schaal toe.

Punt is, is dat je in veel gevallen moet spelen in de sandbox van fabrikant X en daar met ander speelgoed moet spelen dan fabrikant Y.

Dit is exact de reden waarom er veel hardware onderling wordt gebruikt, omdat het ontwerp/ontwikkel stadium al is gepasseerd.

Wat betreft de hardware issues:
Een hardware issue lost zichzelf nooit op. Wat jij al aangaf, condities veranderen waardoor het niet (altijd) reproduceerbaar is.

Software issues daarentegen kunnen zichzelf wel "oplossen" omdat een software issues in de regel gebaseerd zijn op conflicten. Daarom is het herstarten van een object vaak de "oplossing".

Eigenlijk bestaat er niet zoiets oplossing. Pragmatisch gezien kan je alles meer beschouwen als een workaround.
 
R

R1200C

Lid
Nog steeds niet mee eens. Een hardware issue kan zichzelf wel "oplossen" in die zin dat het probleem verholpen is. Een lekkende koppeling tussen twee materialen kan verholpen worden doordat de temperatuur verandert. Daarom merk je bepaalde problemen juist bij een koude motor en niet bij een warme motor en andersom.

Een software issue veroorzaakt door een conflict is geen issue maar een foutafhandeling. IFTT zorgt er dan voor dat er iets gebeurt waar de gebruiker misschien niet blij van wordt maar mits goed gecodeerd is er eigenlijk geen issue. De laatste T is vaak het probleem. Alles naar dezelfde foutcode zorgt er voor dat je niet meer weet wat de oorzaak is.

Lang verhaal kort: bij software (en gerelateerde hardware) accepteren "we" dat het niet vlekkeloos is. Niemand accepteert een Skoda met drie banden en vier velgen en de mededeling "In de volgende versie komt die vierde band er waarschijnlijk wel bij". Bij software is dat een standaard. Heeft met complexiteit te maken maar ook met de onvolwassenheid van de sector (waar ik al 30 jaar in werk).

Je sandbox verhaal is inderdaad een onderdeel van de oplossing: gebruik iets zoals het bedoeld is, niet zoals je graag zou willen dat het gaat werken. Te vaak kiest een bedrijf voor een leverancier waarna er wordt gezegd "ja maar ik wil ook dat en dat kunnen dus dat bouwen we er wel tegenaan". Als zowel Siemens als Continental hun product op elkaar af hebben gestemd werkt het. Ga je als automerk er dan eigen software overheen leggen waarbij je niet volledig in de materie zit (wat vaak onmogelijk wordt gemaakt door de leverancier, ook zo'n dingetje...) dan loop je tegen problemen aan.

Iets met "elke kleur als het maar zwart is"...

Anywayzzz: mijn punt is dat zowel soft- als hardware zijn 100% voorspelbaar maar alleen dan als je de situatie 100% hetzelfde hebt.
 
EdK

EdK

Forumguru
R1200C zei:
als hardware zijn 100% voorspelbaar maar alleen dan als je de situatie 100% hetzelfde hebt.
Klik om te vergroten...
Tsja en als dat 100% is dan komt de niet voorspelbare factor "de mens "er mee in aanraking en opeens werkt dan wat eerst 100% werkte opeens niet meer en hebben we storing na storing....
En sta je daar al monteur te achterhalen waar het probleem zit !?
En soms zijn dit de lulligste dingetjes en soms moet je de gebruiker gaan her opvoeden met het gebruik ervan !
 
Je moet ingelogd zijn om te kunnen reageren. Log in | Registreer
Bovenaan Onderaan