Kodėl svarbi „WinOLS“ projektų higiena
ECU derinimo (tiuningavimo) problemos dažnai prasideda dar prieš modifikuojant failą. Trūkstama originali atsarginė kopija, neaiškus failo pavadinimas, netinkama programinės įrangos versija, sumaišyti klientų aplankai, nepatikrinta kontrolinė suma (angl. checksum) arba prarastas įrankio žurnalas gali sukelti didesnę riziką nei pats kalibravimo pakeitimas.
Gera projekto higiena reiškia, kad kiekvienas ECU projektas turi nuoseklią aplankų struktūrą, patikrintą originalų failą, pastabas, versijų istoriją, kontrolinės sumos auditą ir atkūrimo planą. Tai nėra tiesiog biuro administravimas. Tai yra techninės rizikos valdymas.
Ši darbo eiga skirta ECU specialistams, derintojams ir dirbtuvėms, norintiems tvarkingesnio „WinOLS“ projektų valdymo ir saugesnio darbo su failais. Ji taip pat palaiko tyrimų darbo eigas, naudojantis tokiomis bendruomenėmis kaip MHHAuto ir CarTechnology.
Pradėkite nuo teisinės ir techninės atsakomybės
Prieš modifikuodami bet kurį ECU failą įsitikinkite, kad darbas yra teisėtas, autorizuotas ir techniškai tinkamas. Dirbtuvės privalo turėti kliento sutikimą, transporto priemonės identifikavimo duomenis, originalią atsarginę kopiją ir aiškų supratimą, kam kalibravimas yra skirtas.
Neatlikite failų modifikacijų, kurios pažeidžia vietinius įstatymus, taršos reikalavimus, saugos taisykles ar susitarimus su klientu. ECU tiuningas turėtų būti vertinamas kaip profesionali techninė paslauga, o ne kaip atsitiktinis failų redagavimas.
1. Sukurkite standartinę projekto aplankų struktūrą
Kiekvienas ECU projektas turi atitikti tą pačią aplankų struktūrą. Nuosekli struktūra neleidžia sumaišyti failų tarp transporto priemonių, įrankių ar klientų.
Pavyzdinis projekto aplankas:
Customer_or_InternalRef/ Vehicle_Info/ 00_Original_Read/ 01_Tool_Logs/ 02_WinOLS_Project/ 03_Definitions_A2L_DAMOS_Notes/ 04_Modified_Files/ 05_Checksum_Audit/ 06_Write_Logs/ 07_Test_Results/ 08_Recovery/ 09_Delivery/
Tikslūs pavadinimai gali būti koreguojami, tačiau logika turi išlikti ta pati: originalas pirmiausia, modifikacijos atskirai, atkūrimo galimybė visada pasiekiama.
2. Užregistruokite transporto priemonės ir ECU identifikacinius duomenis
Prieš atidarydami „WinOLS“, užregistruokite techninius ECU identifikacinius duomenis. Tai apsaugo nuo netinkamo failo parinkimo ir padeda vėliau, jei prireiktų projektą atidaryti iš naujo.
Užregistruokite:
- transporto priemonės markę ir modelį;
- modelio metus;
- variklio kodą;
- transmisijos tipą, jei aktualu;
- ECU gamintoją;
- ECU tipą;
- aparatinės įrangos (HW) numerį;
- programinės įrangos (SW) numerį;
- programinės įrangos versiją;
- nuskaitymo metodą: OBD, „bench“, „boot“ ar kitą;
- naudotą įrankį;
- akumuliatoriaus ar stendo įtampą;
- datą ir meistro vardą.
Ši informacija turėtų būti saugoma paprastame tekstiniame faile arba projekto užraše aplanko viduje.
3. Apsaugokite originalią atsarginę kopiją
Originalus nuskaitymas yra svarbiausias failas visame projekte. Jo niekada negalima perrašyti, neatsargiai pervadinti ar saugoti tik viename nešiojamajame kompiuteryje.
Originalaus failo taisyklės:
- išsaugokite originalų nuskaitymą nedelsiant;
- padarykite bent vieną atsarginę kopiją;
- laikykite vieną kopiją už aktyvaus darbinio aplanko ribų;
- neredaguokite tiesiogiai originalaus failo;
- išlaikykite aiškų ir nuoseklų originalaus failo pavadinimą;
- užfiksuokite failo dydį;
- sukurkite failo maišos kodą (angl. hash), jei tai jūsų darbo eigos dalis;
- laikykite įrankio žurnalą kartu su originaliu nuskaitymu.
Jei originalas prarandamas, atkūrimas tampa gerokai sunkesnis. Jei naudojamas netinkamas originalas, visas projektas tampa nepatikimas.
4. Naudokite aiškų failų įvardijimą
Failų pavadinimai turėtų nurodyti specialistui, koks tai failas, jo net neatidarant. Venkite tokių pavadinimų kaip „final“, „newfinal“, „test2“ ar „goodfile“. Šie pavadinimai kelia pavojų, kai atsiranda kelios versijos.
Geresnis įvardijimo formatas:
Brand_Model_Engine_ECU_HW_SW_ORI_Date.bin Brand_Model_Engine_ECU_HW_SW_MOD_v01_Date.bin Brand_Model_Engine_ECU_HW_SW_MOD_v02_ChecksumOK_Date.bin
Neįtraukite į failų pavadinimus pilnų kliento asmens duomenų. Jei reikia, naudokite vidinius identifikatorius.
5. Laikykite A2L ir DAMOS pastabas tvarkingai
A2L ir DAMOS informacija gali būti naudinga žemėlapių identifikavimui ir projekto dokumentavimui, tačiau su ja reikia elgtis atsargiai. Fiksuokite pastabas apie šaltinį, versiją, suderinamumą ir tai, kas iš tikrųjų buvo panaudota.
Rekomenduojamos pastabos:
- aprašo (angl. definition) šaltinis arba vidinė nuoroda;
- ECU šeima;
- programinės įrangos versijos atitiktis;
- identifikuoti žemėlapiai;
- rankiniu būdu patvirtinti žemėlapiai;
- nepanaudoti žemėlapiai;
- ašių informacija;
- matavimo vienetų prielaidos;
- komentarai apie neaiškias sritis.
Nemanykite, kad aprašas yra teisingas vien todėl, kad jis sėkmingai atsidaro. Visada patikrinkite pagal faktinę failo struktūrą ir žinomą kalibravimo logiką.
6. Atskirkite tyrimų pastabas nuo projekto sprendimų
Forumų temos, seni projektai ir bendri užrašai gali padėti analizei, tačiau jie neturėtų būti painiojami su galutiniais kalibravimo sprendimais. Laikykite tyrimų pastabas atskirai nuo patvirtintų projekto pastabų.
Naudokite dvi kategorijas:
- Tyrimų pastabos: forumų nuorodos, panašių ECU diskusijos, komentarai apie įrankius, naudotojų atsiliepimai.
- Patvirtintos pastabos: dabartiniame faile patikrintos reikšmės, patvirtinti žemėlapiai, atlikti pakeitimai ir bandymų rezultatai.
Šis atskyrimas neleidžia senoms prielaidoms virsti paslėptomis klaidomis naujame projekte.
7. Kurkite kiekvieno modifikuoto failo versijas
Kiekviena modifikacija turėtų sukurti naują versiją. Neperrašykite ankstesnio modifikuoto failo. Jei bandymas kelyje arba ant galios stendo (dyno) parodo problemą, specialistas turi turėti galimybę greitai grįžti prie ankstesnės versijos.
Versijos pastabose turėtų būti nurodyta:
- versijos numeris;
- data;
- meistras;
- pakeitimo priežastis;
- pakeisti žemėlapiai;
- laukiamas rezultatas;
- kontrolinės sumos (checksum) būsena;
- bandymo rezultatas;
- ar failas buvo įrašytas į ECU.
Failo versija be pastabų yra tiesiog spėjimas kitu pavadinimu.
8. Atlikite kontrolinės sumos auditą
Kontrolinės sumos (checksum) apdorojimas yra kritinis žingsnis. Kai kurie įrankiai kontrolines sumas pataiso automatiškai, kitiems reikia rankinio koregavimo, o kai kuriose darbo eigose prieš įrašymą reikalingas patikrinimas. Technikas privalo žinoti, kuris įrankis yra atsakingas už kontrolinės sumos koregavimą ir kaip patvirtinamas rezultatas.
Kontrolinės sumos audite turėtų būti fiksuojama:
- patikrinta failo versija;
- kontrolinės sumos koregavimui naudotas įrankis;
- ar kontrolinė suma buvo pataisyta automatiškai, ar rankiniu būdu;
- kontrolinės sumos būsena prieš įrašymą;
- naudotas įrašymo įrankis;
- išsaugotas įrašymo žurnalas (write log);
- nuskaitymas arba patikrinimas po įrašymo, jei buvo atliktas;
- bet kokie įrankio parodyti įspėjimai.
Nelaikykite pranešimo „klaidų nėra“ visaverčiu auditu. Išsaugokite įrodymus.
9. Turėkite paruoštą atkūrimo aplanką
Atkūrimo aplankas paruošiamas prieš įrašymą, o ne po to, kai kas nors nepavyksta. Jei įrašymas nepavyksta, technikas neturėtų gaišti laiko ieškodamas originalaus failo, protokolo, slaptažodžio, įrankio žurnalo ar pajungimo ant stalo (bench) pastabų.
Atkūrimo aplanke turėtų būti:
- originalus nuskaitymas;
- paskutinis žinomas geras modifikuotas failas;
- įrankių žurnalai (logs);
- ECU identifikacija;
- nuskaitymo ir įrašymo metodas;
- pajungimo ant stalo (bench) arba boot pastabos, jei taikoma;
- ECU etiketės nuotraukos;
- maitinimo šaltinio pastabos;
- kontaktų išdėstymo (pinout) arba prijungimo pastabos, kur teisiškai ir techniškai tinkama;
- kontaktai ar pagalbos tarnybos pastabos, jei kreipiamasi į įrankio tiekėją.
Geriausias atkūrimo planas yra tas, kuris paruoštas prieš atsirandant rizikai.
10. Išbandykite ir dokumentuokite rezultatą
Po įrašymo darbas nėra baigtas, kol automobilis nepatikrintas. Išsaugokite diagnostinį nuskaitymą, bandymų pastabas ir kliento perdavimo informaciją.
Patikrinimai po įrašymo gali apimti:
- ECU ryšio patikrinimą;
- DTC klaidų kodų nuskaitymą;
- tuščiosios eigos ir užvedimo elgseną;
- tiesioginių parametrų (live data) patikrą;
- bandomąjį važiavimą arba bandymą ant stendo (dyno), kur tinkama;
- kliento nusiskundimo patvirtinimą / išsprendimą;
- galutinės failo versijos užfiksavimą;
- atsarginės kopijos perdavimą arba archyvavimą pagal dirbtuvių politiką.
Jei atsiranda gedimų, užfiksuokite juos, užuot ištrynę įrodymus. Geros pastabos leidžia greičiau atlikti pataisymus.
Projekto higienos lentelė
| Sritis | Ką išsaugoti | Kodėl tai svarbu |
|---|---|---|
| Originali atsarginė kopija | Originalus nuskaitymas, failo dydis, maišos kodas (hash), įrankio žurnalas | Reikalinga palyginimui ir atkūrimui |
| Transporto priemonės informacija | ECU tipas, HW/SW numeris, variklio kodas | Apsaugo nuo netinkamo failo parinkimo |
| A2L/DAMOS pastabos | Aprašų šaltinis, žemėlapių pastabos, suderinamumo komentarai | Apsaugo nuo aklo žemėlapių redagavimo |
| Modifikuoti failai | Versijuoti failai su pakeitimų pastabomis | Leidžia grįžti atgal ir atlikti palyginimą |
| Kontrolinės sumos auditas | Koregavimo metodas, įrankio rezultatas, įrašymo žurnalas | Sumažina įrašymo ir užvedimo riziką |
| Atkūrimas | Originalas, įrankių žurnalai, prijungimo pastabos, paskutinis geras failas | Taupo laiką, jei įrašymas nepavyksta |
Kur padeda forumų prieiga
ECU tyrimams, įrankių elgsenai, programinės aparatinės įrangos (firmware) diskusijoms ir techniniams atvejams peržiūrėkite CarTechnology. Platesnėms automobilių ECU, diagnostikos ir programinės įrangos diskusijoms peržiūrėkite MHHAuto. Tyrimai forumuose turėtų padėti profesionaliam failų tvarkymui, o ne pakeisti patikrinimą pačiame projekte.
WinOLS projekto higienos kontrolinis sąrašas
- Prieš pradėdami sukurkite standartinį aplanką.
- Užregistruokite transporto priemonės ir ECU identifikaciją.
- Išsaugokite originalų nuskaitymą ir pasidarykite atsarginę kopiją.
- Niekada neredaguokite originalaus failo tiesiogiai.
- Naudokite aiškius versijų pavadinimus.
- Tvarkingai laikykite A2L/DAMOS pastabas.
- Atskirkite tyrimų pastabas nuo patvirtintų projekto pastabų.
- Versijuokite kiekvieną modifikuotą failą.
- Atlikite ir dokumentuokite kontrolinės sumos auditą.
- Prieš įrašydami paruoškite atkūrimo aplanką.
- Išsaugokite įrašymo žurnalus ir bandymų po įrašymo rezultatus.
DUK
Kodėl originali atsarginė kopija yra tokia svarbi?
Originalus failas yra atskaitos taškas palyginimui, pataisymams ir atkūrimui. Be jo projektą tampa sunkiau patikrinti ir kur kas sunkiau atkurti, jei kas nors nutiktų ne taip.
Ar turėčiau perrašyti senus modifikuotus failus?
Ne. Išsaugokite kiekvieną svarbią versiją su pastabomis. Failų perrašymas sunaikina projekto istoriją ir apsunkina trikčių šalinimą.
Ar A2L ir DAMOS failai visada teisingi?
Ne. Juos būtina suderinti ir patikrinti. Aprašas gali įsikelti, tačiau vis tiek netikti konkrečiai programinės įrangos versijai ar failo struktūrai.
Ar pakanka automatinio kontrolinės sumos koregavimo?
Tai priklauso nuo įrankio ir ECU. Visada užfiksuokite, kaip buvo apdorota kontrolinė suma, ir, kai įmanoma, išsaugokite įrankio rezultatą arba įrašymo žurnalą.
Kas turėtų būti atkūrimo aplanke?
Originalus nuskaitymas, paskutinis žinomas geras failas, įrankių žurnalai, ECU identifikacija, nuskaitymo / įrašymo metodas, pajungimo pastabos ir bet kokia informacija, reikalinga saugiam ECU atkūrimui.
Gera WinOLS projekto higiena – tai ne tvarkingai atrodantys aplankai. Tai rizikos mažinimas. Saugokite originalą, dokumentuokite ECU, versijuokite kiekvieną pakeitimą, audituokite kontrolines sumas ir paruoškite atkūrimą prieš pradedant įrašymą.
