Error messages. Intro

Auto pašdiagnostika ir izstrādāta, lai atvieglotu defektu atrašanu auto elektronikas sistēmās. Katrs elektronikas modulis nepārtraukti kontrolē sensorus, izpildmehānismus, mezglu veiktspēju un problēmu gadījumā veic ierakstus kļūdu sarakstos un/vai modificē darbības algoritmus, lai nodrošinātu pēc iespējas bezpārtraukumu un maksimāli kvalitatīvu darbību. Mūsdienu auto kļūdu saraksti satur tūkstošus, pat desmitus tūkstošu kļūdu pozīciju.

Šajā postā vienkāršoti pastāstīšu par dažām niansēm, kas jāņem vērā, nolasot kļūdu kodus.

Sensoru un izpildmehānismu pieslēguma ķēžu kontrole.

Šī ir pati vienkāršākā pašdiagnostikas sadaļa – elektronikas modulis kontrolē sev pieslēgto ierīču elektriskās ķēdes: to nepārtrauktību un īssavienojumus. Vienkāršākais tādēļ, ka šo pašdiagnostikas daļu it kā neietekmē nekādi ārēji apstākļi, citas ierīces. Attiecīgi, ja kļūda uzrāda, ka ir bojāts savienojums ar kādu no sensoriem, mēs tai varētu ticēt. Diemžēl arī tik vienkāršās situācijās gadās izņēmumi. Tipveida situācija: sensors un/vai izpildmehānisms pieslēgts pie vadības bloka, otrs/ cits tā barošanas izvads pieslēgts pie barošanas avota (+5 vai +14V). Ķēdes pārrāvuma gadījumā elektronikas bloka izvads ‘’nokrīt’’ līdz nulles potenciālam un elektronikas modulis nespēj atšķirt ķēdes pārrāvumu no īssavienojuma ar zemes potenciālu. Tipisks piemērs: gaismu kontroles moduļi, spuldzes defekta rezultātā atsevišķi diagnostikas rīki uzrāda kļūdu (saskaņā ar tās aprakstu): short circuit to ground, kaut, protams, nekāda īssavienojuma nav. Kādēļ LM moduļos ieekonomēts pa vienam rezistoram uz katru bloka izeju (kas ļautu īssavienojuma situācijas identificēt), nav skaidrs. Bet tā tas ir, un jāsaprot, ka pašdiagnostikas sistēma var jaukt ķēdes bojājuma veidu.

Tieši šādu pašu paziņojumu (par īssavienojumu uz zemes potenciālu) var redzēt arī tad, ja sensoram vai izpildmehānismam būs bojāta sprieguma padeve vai arī bojāts pats sensors un/vai izpildmehānisms (pārrāvums tā iekšējās ķēdēs) un kontroles modulis neveic korektus slodzes sprieguma mērījumus (nav atsevišķs strāvas avots pieslēguma pārbaudei).
Secinājums ir viens - pat elementārākajās situācijās pašdiagnostika var norādīt nepareizu problēmas iemeslu un detaļu mainīšana ''pēc saraksta'' bieži vien ir nevietā.

Sensoru un izpildmehānismu darbības kontrole.

Patiesībā šo sadaļu var noreducēt uz: sensoru (un tikai sensoru) darbības kontrole, jo izpildmehānismu darbības kontrole tieši vai pastarpināti notiek caur sensoru kontroli.

Protams, ja sensors ir bojāts, pašdiagnostika veiksmīgi identificēs šo problēmu. Taču jāsaprot, ka sensora signāls (un elektronikas moduļa izdarītie secinājumi par tā atbilstību/patiesumu) ir atkarīgi no ārējiem apstākļiem. Piemēram: ABS sistēmas sensors signālu saņem no zobdiska, kurš ir nostiprināts uz riteņa rumbas. Ja disks un/vai gultnis ir bojāti – signāls būs nekorekts. Jeb, piemēram, ja izplūdes sistēmā ir gaisa pieplūde, skābekļa un NOx sensori var rādīt nepatiesu Lambda vērtību (un pašdiagnostika uzrādīs šo sensoru bojājumus).

Vēl sarežģītāka situācija ir tad, ja kļūda ir ierakstīta par izpildmehānismu – tātad pašdiagnostikas sistēma, balstoties uz kāda sensora (vai sensoru grupas) datiem ir NETIEŠI secinājusi, ka defekts ir nevis sensoros, nevis to pieslēguma ķēdēs, nevis izpildmehānisma ķēdēs, bet pašā izpildmehānismā. Piemēram – droseļvārsts ar pozīcijas sensoru. Kļūda par droseļvārsta motoru patiesībā nozīmē to, ka pozīcijas sensora rādījumi atzīti par patiesiem, bet tie uzrāda nekorektu droseļvārsta pozīciju. Iespējami gadījumi, kad tomēr ir specifiski pozīcijas sensora bojājumi vai, piemēram, droseļvārsta mehānisma mehāniski bojājumi, kas traucē tā normālai darbībai.

Ja bloka atmiņā figurē kļūdas par sensora (vai vēl aktuālāk – izpildmehānisma) funkcionalitāti, obligāti jānovērtē, cik šī kļūda ir patiesa. Ja iespējams, jāskata sensora live data, jānovērtē to patiesums, ja iespējams – jāveic testa bloks un jāizvērtē tā rezultāti (bez ierunām neuzticoties tā rezultātam).

Funkcionalitātes kontrole.

Šī ir pašdiagnostikas sarežģītākā  sadaļa, t.i.: lēmums par kāda komponenta kļūdu tiek pieņemts, balstoties uz sensoru grupas rādījumu kontroli un to darbības analīzi laikā. Piemēram, pēc visa dzinēja darbības kontroles tiek pieņemts lēmums par tā darbības nevienmērības fiksēšanu, jeb kāda skābekļa sensora datu neatbilstību. Šie lēmumi patiesībā ir sarežģītāki kā pirmajā brīdi šķiet. Piemēram, lai pieņemtu lēmumu par darbības nevienmērību, dzinēja vadības modulim ir jāspēj izlīdzsvarot visu cilindru degmaisījumu, to precīzi uzturēt, jākonstatē, ka nav citu apstākļu (piem., mainīga slodze, mainīgs droseļvārsta atvērums), kas varētu ietekmēt dzinēja darbu, precīzi jānosaka niecīgas spararata ātruma izmaiņas. Tieši komplicētības dēļ funkcionalitātes kļūdas visbiežāk uzrāda kļūdainus problēmu cēloņus. N sērijas benzīna dzinēju nevienmērīgas darbības noteikšanai dzinēja visām sistēmām jābūt darba kārtībā, cilindru efektivitātei izlīdzsvarotai, spararata sensoram adaptētam, degvielas sagatavošanas sistēmai – kārtībā, utml. Tikai tad nelielās spararata ātruma izmaiņas signalizēs par kāda cilindra degmaisījuma nesadegšanu. Bet, ja, piemēram, būs brīvkustība spararata divmasu demferī, ja būs nekvalitatīva degviela, nevienmērīgs ceļa segums, u.t.t. – kļūdas novērtējums būs nekorekts.

Šī iemesla dēļ funkcionalitātes kļūdu paziņojumiem jāpieiet ļoti kritiski, šo kļūdu izvērtēšana prasa nopietnas zināšanas par mehānisma darbību.

Virknes interfeisu kļūdas.

Pirmā kļūdu grupa – komunikācijas problēmas programmatūras kļūdu vai nepilnību dēļ. Te līdz tikai programmatūras atjaunošana un/vai bloku relīzes maiņa. Tipveida problēmas – timeout (problēma un kļūdas par to, piem.: module not responding) lielas tīkla noslodzes un/vai nesavlaicīgas kāda bloka ieslēgšanās dēļ. CAN virknes interfeisu īpatnība – augstākas prioritātes datu sūtītāji var pārslogot tīklu tā, ka zemākas prioritātes datu sūtītājs pie datu pārraides nemaz netiek. Šo kļūdu īpatnība – tās ir pārejošas, neregulāras. Šo kļūdu gadījumā vajadzētu pārbaudīt iespēju atjaunot grupas master iekārtas programmnodrošinājumu (iespējams, jaunāka programmatūras versija paredz biežāku tīkla apprasīšanu, kas labāk ''attīra'' to no slave iekārtu komunikācijas pieprasījumiem) un ar CAN interfeisa analizatoru paskatīties, kuras no grupas iekārtām pārslogo interfeisu, un, ja iespējams, atjaunot to programmnodrošinājumu.

Otra kļūdu grupa – hardware problēmas. Autoindustrijā izmantotie virknes interfeisi idejiski ir visnotaļ droši: atbildīgākās vietās izmantotie 2 līniju datu apmaiņas protokoli ir spējīgi strādāt pat vienas līnijas bojājuma gadījumā, tie spēj strādāt lielu sinfāzo traucējumu apstākļos, izmanto atvērta kolektora risinājumus (kas izslēdz lielu strāvu plūšanas iespēju caur interfeisu čipsetu izejām kāda bloka konflikta gadījumā), visi bloki redz bloku, kuram dotajā brīdī ir augstākā prioritāte datu raidīšanai (kas samazina konfliktu iespējamību), katra bloka virknes interfeiss izmanto čipsetus ar lielu izejas strāvu (Ipeak līdz 50..100mA), lielu pieļaujamo traucējumu līmeni (2..4kV human body model), supresijas aizsardzību (tipiski: ap 100W 8/20us lielas jaudas supresorus), u.t.t., kas nodrošina visnotaļ drošu darbību.

Virknes interfeisa līnijas bojājuma ticamākais iemesls: kāda bloka GND (zemes savienojuma) pazušana/bojājums, kas dažos gadījumos var novest pie mēģinājuma ‘’nobarot’’ šo bloku caur CAN līnijām. Šajā gadījumā tipiski tiek bojātas (caursistas) attiecīgās līnijas supresijas aizsardzības diodes (retāk – arī draivera chipset izejas mezgli), visa līnija – ‘’nosēdināta’’.

Šīs grupas kļūdu īpatnība – tās ir nepārtrauktas, traucēta datu apmaiņa visā moduļu grupā, kas šo datu apmaiņas līniju izmanto.

Piezīme – katrai virknes interfeisa moduļu grupai ir viens modulis, kurš pilda ‘’pēdējā’’ funkciju, t.i.: tas satur virknes interfeisa slodzi: terminator (rezistoru, kurš pilda slodzes un impedances salāgošanas funkciju). Izmantojot ‘’izslēgšanas’’ metodi (t.i.: atvienojot blokus no kopējās līnijas bojātā atrašanai) tas jāņem vērā (bez terminator datu apmaiņas līnija nestrādās) – datu līnijas slodze jāizveido saskaņā ar konkrētā datu apmaiņas protokola specifikāciju.

Kļūdas statuss.

Kļūdas statuss var būt pasīvs vai aktīvs, t.i.: kļūda dotajā brīdī tiek novērota, jeb tā ir noteikta pagātnē un šobrīd nav identificēta. Te jāņem vērā, ka kļūdas statuss nav realtime parametrs. Kaut arī, piem., INPA kļūdu sarakstu un statusus atjauno nepārtraukti, kļūdu sarakstu un/vai statusu izmaiņas var aizkavēties pat vairākas minūtes (atkarībā no konkrētā bloka noslodzes). Šī iemesla dēļ kļūdas statusu nevar izmantot kā indikatoru sliktas ķēdes pārbaudei – tas jādara ar multimetru, osciloskopu vai skatoties live data, ja ir pieejama tāda opcija.
Aktīvas kļūdas dzēšana nav iespējama. Pat, ja tā pēc dzēšanas it kā ''pazūd'' no diagnostikas datora ekrāna, pēc īsa brītiņa šī kļūda atkal parādīsies.

Pašdiagnostikas sistēma veic katras kļūdas parādīšanās reižu skaita fiksēšanu. Vairrākkārtējas kļūdas tiek atzīmētas kā sporādiskas (piem., DIS), gan DIS, gan INPA norāda konkrētās kļūdas piefiksēto gadījumu skaitu, kas ļauj aptuveni saprast - kļūda bija īpašs gadījums, jeb regulāra kļūme.

Vēl būtiska nianse – ņemot vērā laika aizturi starp kļūdas identificēšanu un tās iekļaušanu kļūdu sarakstā, nav garantētas saiknes starp bloka funkcionalitātes izmaiņām un kļūdu sarakstu, t.i.: elektronikas modulis var identificēt kļūdu, mainīt algoritmu uz citu (alternatīvu, avārijas), taču kļūda par sistēmas traucējumu parādīsies tikai pēc brīža.

Atkarībā no konkrētās kļūdas elektronikas modulis var veikt nepārtrauktu (tipiski – savienojumu ķēžu), ciklisku (piem., izpildmehānismu vai funkcionalitātes) tās identifikāciju un kontroli, ciklu skaits var būti limitēts (piem., veikt vienmērīgas darbības atjaunošanās mēģinājumus 5 reizes, ja neizdodas – pārtraukt līdz nākošajai sesijai), kļūdas statuss var tikt dzēsts, sākot jaunu darba sesiju, utml. – ražotājs nesniedz precīzu informāciju par tās/citas kļūdas apstrādes algoritmiem. Izpratne par to, kā ‘’uzvedas’’ konkrētās kļūdas, tikai – pieredzes jautājums.

Specifisku kļūdu (piem., dzinēju kontroles moduļu kļūdas par katalizatoru veiktspējas kritumu, kļūdas par LM moduļu izpildķēdēm, ja pārsniegts sesiju skaits, kurās fiksēta šī kļūda, daļa SRS moduļu kļūdu pēc avārijas, u.t.t.) dzēšana nav iespējama parastas kļūdu ‘’dzēšanas’’ ietvaros (to statuss vienmēr uzstādīts kā aktīvs), to dzēšana iespējama tikai specifisku servisu procedūru laikā, vai arī izmantojot tieši šim mērķim paredzētu programmnodrošinājumu (īpaši aktuāls gadījumos, kad ražotājs paredz bloka nomaiņu kā vienīgo risinājumu).  

Kļūdu info.

Sarežģītāku vadības moduļu (piem., DME/DDE, LCM/LM, u.c.) kļūdas tiek glabātas vairākos sarakstos. Piem., DME kļūdas glabā tekošās sesijas kļūdu sarakstā, iepriekšējo sesiju kļūdu sarakstā (info memory) un kopējā kļūdu logā (history memory). History memory normāli pat pēc dzēšanas patiesībā izdzēsts netiek, tiek tikai pārtraukta kopējā saraksta attēlošana. Ja nepieciešams redzēt dzinēja vecākas kļūdas (bet visus sarakstus kāds pirms jums nodzēsis), pietiek izprovocēt kādu jaunu kļūdu - viss kļūdu log atkal būs pieejams.
INPA ļauj apskatīt detalizētu kļūdas info (piem., aktuālās sesijas kļūdu saraksta menu nospiežot F2 vai F3). Papildus pamatinfo (kļūdas kods; apraksts; odometra rādītājs, pie kura kļūda fiksēta; kļūdas statuss; eventu skaits) tiek parādīti arī atbilstošie nosacījumi kļūdas ierakstīšanas brīdī (piem., kļūdai par kādas bankas trim problēmām: Lambda problēmas brīdī; kompensāciju integratoru; adaptāciju vērtības; dzinēja temperatūra; braukšanas ātrums; dzinēja RPM; dzinēja slodze, u.c. pamatinfo), šī informācija lieti noder problēmas novērtēšanai (piemērā par trim problēmu - ļauj novērtēt, vai problēmas cēlonis varētu būt gaisa piesūkšana ieplūdes kolektorā, vai degvielas spiediens sistēmā, vai kāda cita problēma). 

Kļūdu dzēšana un funkcionalitāte.

Pēc pasīvu kļūdu dzēšanas vadības moduļa funkcionalitāte nekavējoši var neatjaunoties pat tad, ja visi tā elementi ir teicamā kārtībā. Tikai tad, kad modulis (konkrētajos apstākļos) konstatēs, ka problēma patiešām ir pazudusi, tas atjaunos pilnas veiktspējas algoritmus. Piemēram, ja N43/N53 dzinējam ir bijušas kļūdas par dzinēja darbības nevienmērību, tad - problēma novērsta, kļūdas nodzēstas (un vairs neparādās), Stratified charge dzinējs ieslēgs tikai pēc specifiskas paštesta (laika atskaite un darbības vienmērības kontrole homogēni liesā maisījumā, tad - divi īsi Stratified cikli, papildus - Lambda adaptāciju izvērtēšana banku līmenī) procedūras veikšanas. Piedevām, līdz normālai funkcionalitātei tiks veikta virkne ''atjaunošanās'' darbību (vairāk kā 10 gab. ciklisku cilindru individuālo Lambda korekciju homogēnā režīmā kombinācijā ar Stratified cikliem, tad - Lambda adaptāciju papildināšana banku ietvaros). Par šīm niansēm ražotājs (programmatūras izstrādātājs) nevienu neinformē, tās tiek iepazītas, iedziļinoties moduļu darbības niansēs (vai nu strādājot par diagnostikas speciālistu, vai izstrādājot kādus funkcionalitātes papildrīkus). Galvenais secinājums - nevajag celt trauksmi, ja kļūdu dzēšanas ietekme nav momentāna. Tieši tas pats attiecas uz dzinēju vadības moduļu adaptāciju dzēšanu - pilna funkcionalitāte tiks ieslēgta tikai pēc vairākām braukšanas sesijām (sīkāk info - tēmās par dzinēju adaptācijām).

Kļūdu dzēšana un adaptācijas.

Sadaļa, protams, attiecas uz vadības moduļiem, kuros ir šāda funkcionalitāte (piem., dzinēju, ātrumkārbu vadības moduļi). Ja ir adaptācijas, tās noteikti jādzēš pēc kļūdu dzēšanas (kas tiek dzēstas pēc problēmas/defekta novēršanas). Iemesli šādai nepieciešamībai ir vairāki.
1. Iespējams, ka iepriekšējā defekta dēļ bloka adaptācijas bija izveidojušās nekorekti, atjaunojot funkcionalitāti - ir iespēja, ka pašdiagnostika konstatēs neeksistējošas problēmas (un ierakstīs neadekvātas kļūdas kļūdu sarakstos);
2. Adaptācijas parasti veidojas no desmitiem dažādu mainīgo analīzes reālas auto lietošanas apstākļos. Ja vadības blokam 10 reizes liek izveidot adaptācijas it kā līdzīgos apstākļos, visas 10 adaptāciju kartes savā starpā atšķirsies. Tādēļ ir būtiski izveidot jaunas adaptāciju kartes ar tieši tiem sensoriem/izpildmehānismiem, kas tiek izmantoti konkrētajā brīdī, tieši jaunajos apstākļos;
3. Adaptāciju veidošana aizņem daudz laika. Uzreiz pēc to dzēšanas adaptācijas tiek veidotas strauji, vēlāk to atjaunošanas tempu samazinot. Šis ir trešais iemesls, kādēļ dzēst adaptācijas - lai jaunās adaptācijas izveidotos ātri un saremontētā mezgla veiktspēja būtu novērtējama.

Piezīme - adaptāciju dzēšana parasti dzēš arī lietotājam nepieejamos (un neredzamos) statusa bitus par bijušajām (un tikko dzēstajām) kļūdām un bitus par nepieciešamajiem ārpusrindas darba procesiem (piem., kādu sensoru darbības papildkontrole to parametru neatbilstības dēļ, utml.), t.i.: atjauno bloka sākotnējo (jauna moduļa) stāvokli. Šeit gan situācija nav vienkārša - kā citos gadījumos, arī šajā - ražotājs (programmatūras: gan moduļu, gan diagnostikas) neinformē, kādas tieši adaptācijas un kādi tieši statusa biti tiek dzēsti. 
Piemēram, dzēšot cilindru sinhronizācijas adaptācijas, INPA dzēš arī spararata adaptācijas, ko ISTA nedara, savukārt ISTA dzēš zemākā ''slāņa'' sprauslu adaptācijas, mainot to rūpnīcas kodējumu, ko nedara INPA. Kā iepriekš - visas šīs nianses var iepazīt, tikai strādājot un pētot vadības bloku ''uzvedību'', dokumentācija par šo - precīza 0.