A "frissítés" nem más, mint paramétertáblák újraírása, kisebb nagyobb intervallumtényezők miatt, nagy a szórás az elkészült alkatrészek között (pl minőségben a gyári az "A kategóriás (csillagos dobozban Boge) a gyárival megegyező utángyártott (Lemföderes Boge) "B" kat. stb) változtatni kell emiatt az élő és mért adatok kiértékelésében is.
A gyújtás levesz visszatesz, nem más mint egy "soft reset" a fennálló hibatárolót törli és amíg értéken belül marad addig nem is jelentkezik újra, az eltárolt hibának már vannak egyéb vonzatai is (lásd pl vészüzem).
A paramétertábla újraírásával hozzáadhatnak illetve elvehetnek funkciókat. Javíthatnak de nagyon sokat ronthatnak is az egyes egységek élettartamán (láttunk már nem egy példát erre is), attól függ mekkora a beragadt készlet a gyártóknál :)
Örök érvényű törvény, "Ami jó, nem baszogatjuk!", nálad más a helyzet, kicsit bele kéne ásni egy jó diaggal (minimum a gyárival, lehetőleg developer módban folyamatos élőadat figyeléssel, de ez nagyon idő és pénztárcaigényes) és lehet kiderülne egy pár turpisság.
"Értem én,de mi hajtja?" A lényeg,kell frissíteni,avagy sem? Nekem ugyanis,a vázolt jelenséget időnként produkálja. Pirosan világít az akku hiba és mintha nem lenne szervó. Leállítom,újraindítok és megszűnik........?
A gond csak az egésszel annyi hogy előbbiekben célhardverekről van szó nagyon kevés stack és flagbitekkel (ezért van tárolt hiba pl.) ne úgy képzeld hogy komplett hibajegy kerül be, hanem adott memóriablokkok címezve (egységeknek megfelleően) megfelelő jelzőbittel (hexa érték) ellátva majd tárolva (szintén hexában regiszterekkel), pár szó hosszúságúak csupán. Kiolvasásnál sorra kérdezzük az egységeket kinek mi a baja (regisztertartalma) és visszafejtve értesítjük a technikust a kijelzőn az adott egység nyűgjéről. A takarítás itt nem olyan mint a töredezettségmentesítés és azt megelőző cache-k és temp-ek törlése, nagyon el kell vonatkoztatni a PC-s világtól, itt nincs memóriaátszervezés stb, csupán egy pár regiszter és pár szó (hexa) hosszúságú tároló.
Az általad példaképp felhozott személyi számítógép, és az autókban használt moduláris fedélzeti vezérlőegység működését a hozzászólásodban vázolt párhuzamban nem lehet összehasonlítani. Nézzük meg egy kicsit jobban az összefüggéseket, és a különbségeket.
Sajnos nincs spoiler lehetőség, ezért elnézést kérek a terjedelmes hozzászólásért.
Az autók fedélzeti vezérlőegysége felhasználói beavatkozástól mentesen, előre megírt protokollok alapján, operációs rendszer nélkül végzik munkájukat. Nem végeznek számításokat, nincs beépített regenerációs platform, sőt nagyobb mennyiségű fizikai adattárolásra sincs lehetőség. Pusztán egy futtatási környezet van biztosítva, ami arra való, hogy egy külsős számítógéphez csatlakoztatva egy szintén külsős egység (pl.: kódolvasó) használatakor a szükséges adatok kinyerhetőek legyenek, valamint a különböző márkánként, és típusonként eltérő tuning szoftverek segítségével a gyári értékek módosíthatóak legyenek.
Sajnos nincs lehetőség felhasználói részről otthoni karbantartásra (felesleges/visszamaradt adatok, adatsorok törlése) ezért a fedélzeti vezérlőegység a lehetőségeihez mérten folyamatosan tárolja azokat. Minél több a felesleges adat, (amiket egy egyszerű hibakód olvasáskor megejtett törlés nem tüntet el) annál lassabb lesz az egység működése. Ez kezdetben nem jelent túl nagy gondot, csak pl. a megszokottól kicsit többet kell várni míg elindul a klíma, (amennyiben a fedélzeti vezérli) stb, majd ahogy egyre jobban lassul, úgy a főrendszerek működése is megváltozik.
A probléma tovább fokozódik abban az esetben is, ha pl. valamelyik egyszerű alrendszertől (pl.: világítás) többször is jön azonos alkatrésre (izzó) de különböző hibajel.
PL: Az első fényszóró valamelyik izzója kiégett. Jön a hibajel, felhasználó cseréli, vagy cserélteti. Hibajel megszűnik, de a hibához tartozó adatsor (dátum, hibakód előállása, és a megszűnés között eltelt idő, stb) tárolásra kerül. (Ezek az adatok nem láthatóak, és nem is törölhetőek egy szimpla kódolvasás alkalmával.) Aztán jön ismét a hibajel, hogy kiégett, stb, de társul mellé mondjuk egy zárlat. Eddig van egy azonos alkatrészre két különböző hibajelünk, amihez az előbbiekben említett másodlagos adatok is tartoznak.) Ugyanaz a metódus mint az előbb....
Telik múlik az idő, majd a felhasználó úgy dönt, hogy a gyáritól eltérő fajtájú izzót tesz be az eredeti helyére, mert az mondjuk jobban világít. Erre majdnem biztos, hogy a vezérlőegységet nem készíti fel, (oké nem is mindegyik tudja, sőt sok felhasználó sem ismeri, hogy az autójában lévő vezérlőegység(ek) az autó mely rendszereit felügyelik / működtetik, de a példa kedvéjért tételezzük fel, hogy ilyen a vezérlő), ezért az egység nem tudja, hogy miért van nagyobb, vagy kisebb energiafelhasználás, stb a gyári protokollban felprogramozott helyett, ezért idővel hibajelet küld.
Mivel látszólag minden rendben, az izzók világítanak, a kocsi megy, a felhasználó téves riasztásnak veszi, majd törli, vagy törölteti a kódot, de a fedélzeti ettől függően még letárolja az adatokat. Az autós gondtalanul autózik tovább, viszont a vezérlőegység ismét a gyári protokoll szerint vizsgálja a folyamatokat és bizony ismét hibaüzenetet fog küldeni. Mivel a központi egység a felprogramozott hibahatárokon belül képes a működésbe beavatkozni, ezért a példában szereplő egyszerű esetben is meg fogja ezt tenni, ha erre fel van készítve, vagyis feladata a világítás vezérlése. Ebből adódóan az új izzót figyelmen kívül hagyja (hiszen nem ismeri), majd a gyári értékeket emelve, vagy csökkentve, stb próbálja a gyári értékeket visszaállítani. Mivel az új izzó fogyasztása a példában eltér a gyáritól, ezért vagy ismét kiég, vagy leold a biztosíték. Újból hibajel, új felesleges másodlagos/visszamaradt adatok, stb. Itt jön a képbe a felhalmozódott azonos alkatrészre különböző hibajel, azonos forrásra hivatkozva. A vezérlő a gyári felprogramozott értékeket hasonlítja össze a hibákhoz tárolt adatsorokban szereplő értékekkel. Mivel az iménti egyszerű példában is több különböző adat lesz, ami a gyáritól eltér, ezért prioritásként a gyárit fogja használni, pontosabban megpróbálja az ahhoz legközelebbi, de még hibahatáron belüli értékeket beállítani. Ettől az új izzó ahogy az előbb azt írtam jó eséllyel tönkre megy.
Ezek a folyamatok természetesen nem csak a világítás felől érkező adatokra, hanem a jármű valamennyi, fő, és alrendszereket vezérlő egységektől érkező adatokra is igazak, ezért igen sok "felesleges" adat tárolódik egy-egy egységen.
Ez megy így egy darabig, míg végül annyi adat halmozódik fel a vezérlőben, hogy egyszerűen túl nagy lesz az idő a parancs kiadása, és az indítandó rendszer, vagy funkció elindulása között, jön az érzékelőtől a visszjel, hogy nincs impulzus, amire ismételt indítási parancs indul, de már akkora a késés, hogy a vezérlő egyszerűen lefagy, vagy túlmelegszik, és egyszerűen "leég" Ezt lehet megakadályozni egy frissítéssel, ugyanis minden frissítés alkalmával törlésre kerülnek ezek a másodlagos/felesleges adatok is.
Ezzel szemben az otthon használt számítógép valamilyen operációs rendszert futtat, ahol a felhasználó a rendszer által biztosított futtatási környezetben tud azzal kompatibilis programokat, alkalmazásokat, stb futtatni, használni. Minden elindított művelet kivitelezése különböző számítások tízezreiből áll, amit első sorban a processzor, majd a grafikai megjelenítés szükségességétől függően a GPU végez el. Minden program függ az op. rendszertől, és fordítva. Az elődolgozott, illetve a program működéséhez szükséges adatokat a rendszermemóriában, valamint a Cash blokkokban tárolja a gép, és a működésről naplófájlokban leírásokat készít. Ezek a műveletek rengeteg felesleges adatot generálnak, amik az adott program bezárása után a gépen maradnak. Minél több ilyen maradvány fájl, kulcs, stb marad a gépen, annál több a betöltéskor beolvasandó adat, ami nemcsak a boot időt növeli, de működésbeli problémákat is okozhatnak, attól függően, hogy milyen jellegű adatokról van szó, ugyanis törr olyan program is létezik, ami rendszerszinten épül be, de egy szokásos törlés nem távolítja el teljesen (pl.: vírusirtók többsége) ezért egy azonos funkciókkal bíró alkalmazás működésében zavar okozhatnak, ami egy komolyabb rendszerprogram esetében simán okozhat fagyást. Minél több ilyen "maradvány" van a gépen, vagyis minél jobban elhanyagolt egy otthoni gép, annál nagyobb az esélye, hogy gondok lesznek a működésében. Ennek eredményeképp akár jelentősen is belassulhat egy gép, amin egy alapos "takarítás" jó esetben segíthet.
Konklúzió: Bár a példában szereplő két platform egymástól jelentősen különbözik, mind üzemeltetés, mind vezérlés terén, azonban mégis van bennük egy közös pont. Karbantartás, és hozzáértő használat nélkül nem bírják sokáig!
Tudnátok ajánlani valakit aki központizár-ban otthon van?A beteg egy 99-es SLK!
Akiket találtam egyből vagy kompresszort akar cserélni 150000ft "és majd meglátjuk",vagy valami kinai vackot akar beépíteni az "ócska szemét német" gyári helyett! Ti ezt Értitek???
A fúrógép még stimmel, de én nem merném a fémszálas kefét használni egy festett felületen. Lehet kani kimondottan matrica eltávolító "csapos" korongot, amit be lehet fogni a tokmányba és akár a karosszéria fényezésén is használható.
93-as 600SEL-hez tudna nekem linkelni valaki magyar vagy német használati útmutatót és szerelési kézikönyvet? Csak angolt találtam hozzá de abból sokat nem értek...
