Divi faili var izskatīties saistīti un tomēr būt nepareiza salīdzinājuma izvēle
Oriģinālā faila salīdzināšana ar modificētu failu izklausās vienkārši: atver abus, atrod atšķirības un pārskata mainītās kartes. Grūtības sākas tad, kad failiem nav vienas un tās pašas programmatūras bāzes.
OEM atjauninājums var pārvietot datus, aizstāt koda sekcijas, mainīt kalibrācijas struktūras vai ieviest jaunus karšu variantus. Virtuālā nolasīšana var nākt no saskaņota datubāzes faila, nevis no precīziem baitiem, kas iepriekš glabājās ECU. Klienta iesniegtais fails jau var saturēt nedokumentētas izmaiņas.
WinOLS var parādīt atšķirības, savienot projektus un atbalstīt izmaiņu pārnešanu, taču programmatūra nevar aizstāt failu identifikāciju un tehnisko spriestspēju. Pirms kaut ko importēt, tjūnerim jānoskaidro, kas ir katrs fails un vai salīdzinājums ir derīgs.
Definējiet failus pirms to salīdzināšanas
Projektā lietojiet skaidrus terminus:
- ORI: pārbaudīts oriģināls vai labākā pieejamā bāzes versija konkrētajai ECU programmatūrai.
- MOD: modificēta versija, kas iegūta no dokumentētas bāzes.
- OEM atjauninājums: vēlāka vai citāda ražotāja programmatūras versija.
- Virtuāls oriģināls: oriģināls fails, ko rīka pakalpojumu sniedzējs saskaņojis pēc ECU identifikācijas.
- Atpakaļnolasījums: dati, kas pēc ierakstīšanas fiziski nolasīti no vadības bloka, ja tas tiek atbalstīts.
- Nezināms fails: jebkurš fails bez pietiekamiem pierādījumiem, lai to pārliecinoši klasificētu.
Neapzīmējiet failu kā ORI tikai tāpēc, ka tā nosaukumā ir vārds “original”. Failu nosaukumi ir piezīmes, nevis pierādījumi.
Izveidojiet faila identitātes lapu
Pirms salīdzinājuma skata atvēršanas pierakstiet pieejamo identifikāciju katram failam.
| Identitātes lauks | Fails A | Fails B |
|---|---|---|
| ECU saime | Ierakstiet precīzu tipu | Ierakstiet precīzu tipu |
| Aparatūras numurs | Vērtība no rīka vai uzlīmes | Vērtība no rīka vai avota |
| Programmatūras numurs | Precīza vērtība | Precīza vērtība |
| Kalibrācijas vai atjauninājuma numurs | Ja pieejams | Ja pieejams |
| Nolasīšanas metode | OBD, Bench, Boot vai virtuāli | OBD, Bench, Boot vai virtuāli |
| Faila izmērs | Pierakstīts baitos | Pierakstīts baitos |
| Avots | Transportlīdzeklis, rīka datubāze vai klients | Transportlīdzeklis, rīka datubāze vai klients |
| Zināmā vēsture | Sērijas, tjūnēts, atjaunināts vai nezināms | Sērijas, tjūnēts, atjaunināts vai nezināms |
Saskanīgs faila izmērs ir noderīgs, taču tas nepierāda, ka diviem failiem ir vienāda programmatūras struktūra.
Trīs dažādi salīdzinājuma uzdevumi
Lielākā daļa WinOLS salīdzinājuma darbu iekrīt vienā no trim situācijām. Katra prasa atšķirīgu piesardzības līmeni.
1. ORI pret MOD no vienas bāzes
Tas ir tīrākais salīdzinājums. MOD tika izveidots tieši no ORI, un abiem failiem ir vienāda struktūra. Atšķirībām vajadzētu atbilst dokumentētām kalibrācijas izmaiņām un visām paredzamajām ar kontrolsummu saistītajām izmaiņām.
2. Viena OEM programmatūras versija pret citu
Tas nav parasts tjūninga salīdzinājums. Lieli apgabali var atšķirties, jo ražotājs ir mainījis kodu, diagnostiku, kalibrācijas struktūru vai datu izkārtojumu. Atšķirības nav jāinterpretē kā tjūninga izmaiņas.
3. Modificēta vecā versija pret jaunāku OEM versiju
Šis ir augstākā riska pārneses scenārijs. Vecās adreses, iespējams, vairs nenorāda uz tām pašām kartēm. Izmaiņas jāatveido un jāvalidē pret jauno programmatūras struktūru, nevis akli jākopē.
Sāciet ar augsta līmeņa atšķirību pārskatu
Pirms atvērt atsevišķas kartes, apskatiet kopējo atšķirību modeli.
Jautājiet:
- Vai izmaiņas ir koncentrētas nelielā kalibrācijas apgabalā?
- Vai atšķirības ir izkliedētas pa lielāko daļu faila?
- Vai lieli bloki šķiet pārvietoti?
- Vai gan koda, gan kalibrācijas apgabali atšķiras?
- Vai ir atkārtoti atšķirību modeļi?
- Vai viens fails satur papildu datus vai aizpildījumu?
- Vai izmaiņas atbilst faila vēsturei?
Kompakta karšu izmaiņu grupa var atbilst parastai kalibrācijas rediģēšanai. Lielas plaši izplatītas atšķirības parasti prasa programmatūras versijas analīzi, pirms tiek izdarīti secinājumi karšu līmenī.
Atšķirību modeļi ir norādes, nevis pierādījumi
| Atšķirību modelis | Iespējamais skaidrojums | Nepieciešamā pārbaude |
|---|---|---|
| Mazas kopas zināmās kartēs | Dokumentētas kalibrācijas izmaiņas | Apstipriniet asis, vienības un paredzamo funkciju |
| Lieli nepārtraukti apgabali | OEM programmatūras atjauninājums vai cita faila bāze | Pārbaudiet programmatūras numurus un koda struktūru |
| Atkārtoti izolēti baiti | Kontrolsumma, skaitītāji, metadati vai rīka apstrāde | Pārskatiet protokolu un kontrolsummu darbplūsmu |
| Līdzīgas kartes dažādās adresēs | Datu pārvietošana starp programmatūras versijām | Salīdziniet pēc struktūras, asīm un funkcijas, nevis adreses |
| Atšķirības ārpus paredzamajiem kalibrācijas apgabaliem | Nepareizs fails, atjauninājums, ielāps vai nedokumentēta modifikācija | Pārtrauciet pārnešanu, kamēr faila izcelsme nav saprasta |
Neviens modelis nav jāuzskata par garantiju. Izmantojiet to, lai izlemtu, kam nepieciešama rūpīgāka pārbaude.
Salīdziniet kartes, ne tikai adreses
Adrese ir derīga tikai savā programmatūras struktūrā. Kad failos ir dažādas programmatūras versijas, tā pati funkcija var būt saglabāta citā adresē vai attēlota atšķirīgi.
Katrai salīdzināmajai kartei apstipriniet:
- kartes izmērus;
- asu vērtības;
- asu secību;
- datu tipu;
- baitu secību;
- faktoru un nobīdi;
- inženiertehnisko vienību;
- apkārtējo datu struktūru;
- saistību ar saistītajām mērķa un ierobežotāja kartēm.
Tabula ar vienādu formu ne vienmēr ir tā pati funkcija. Arī asīm un apkārtējai loģikai jābūt jēgpilnām.
Uzmanīgi izmantojiet atsauces versijas
Atsauces versija ir noderīga, kad tiek pārskatīta tā pati projekta bāze vai veikts kontrolēts atjauninājuma salīdzinājums. Tā ļauj tehniķim pārbaudīt vērtības un atšķirības, nepārtraukti nepārslēdzot failus.
Tīra darbplūsma ir:
- Saglabājiet pārbaudīto oriģinālo versiju neskartu.
- Izveidojiet vai importējiet salīdzinājuma failu kā atsevišķu versiju vai savienotu projektu.
- Apstipriniet projekta identifikāciju pirms failu savienošanas.
- Vispirms pārskatiet plašās atšķirības.
- Atveriet zināmās kartes un salīdziniet struktūru un vērtības.
- Pierakstiet, kuras izmaiņas ir apstiprinātas, neskaidras vai noraidītas.
Nepārnesiet izmaiņas automātiski tikai tāpēc, ka WinOLS var identificēt līdzīgus apgabalus.
Kad ir piemērots automātisks imports
Izmaiņu importēšana ir uzticamākā, ja failiem ir vienāda programmatūras bāze un attiecības starp oriģinālu un modificēto versiju ir dokumentētas.
Automātiska vai pusautomātiska pārnešana jāuztver piesardzīgi, kad:
- programmatūras numuri atšķiras;
- viens fails ir OEM atjauninājums;
- viens fails ir virtuālā nolasīšana, bet otrs ir fiziska nolasīšana;
- karšu adreses ir pārvietotas;
- avota MOD satur nedokumentētus ielāpus;
- failu izmēri vai atmiņas izkārtojumi atšķiras;
- avota projektā tiek izmantotas nepārbaudītas definīcijas.
Šajās situācijās nepieciešamās kalibrācijas izmaiņas atveidojiet karti pa kartei un pārbaudiet loģiku mērķa programmatūrā.
Izveidojiet izmaiņu pārneses darblapu
| Karte vai funkcija | Avota statuss | Mērķa atbilstība | Darbība |
|---|---|---|---|
| Vadītāja pieprasījums | Apstiprināts avotā | Asis un vienības atbilst | Atveidot un pārskatīt |
| Griezes momenta ierobežotājs | Apstiprināts | Atrasti vairāki mērķa varianti | Izpētīt pirms rediģēšanas |
| Spiediena mērķis | Mainīts avotā | Mērogošana nav apstiprināta | Vēl nepārnest |
| Nezināms ielāps | Nedokumentēts | Nav pārbaudīta mērķa ekvivalenta | Noraidīt no pārneses |
Šī darblapa novērš to, ka nedokumentētas avota izmaiņas klusi nonāk jaunajā projektā.
Nepārnesiet procentuālās izmaiņas akli
Bieži lietota saīsne ir aprēķināt, par cik mainījās vērtība vecajā MOD, un piemērot to pašu procentu līdzīgi izskatošai kartei jaunajā programmatūrā. Tas var būt maldinošs, jo ražotājs varēja mainīt bāzes vērtību, vienības, ierobežotāja attiecības vai vadības stratēģiju.
Tā vietā jautājiet:
- Kādu rezultātu sākotnējā rediģēšana bija paredzēta sasniegt?
- Vai jaunā programmatūra jau satur pārskatītu mērķi?
- Kuras saistītās kartes kontrolē to pašu funkciju?
- Vai asis un darbības apgabali ir līdzvērtīgi?
- Vai paredzamo rezultātu var apstiprināt ar žurnāliem?
Pārnesiet kalibrācijas mērķi, ne tikai vecos skaitļus.
Nodaliet kalibrācijas izmaiņas no ielāpiem un metadatiem
Ne katra atšķirība ir kartes rediģēšana. Faili var atšķirties arī šādu iemeslu dēļ:
- kontrolsummas korekcija;
- rīkam specifiska apstrāde;
- programmēšanas skaitītāji;
- programmatūras ielāpi;
- versijas metadati;
- diagnostikas konfigurācija;
- nezināms iepriekšējais darbs.
Nezināmas izmaiņas ārpus dokumentētā kalibrācijas apgabala jāizpēta, pirms fails tiek apstiprināts.
Validējiet mērķa projektu pēc pārneses
Pēc izmaiņu atveidošanas vai importēšanas veiciet pilnu projekta pārskatu:
- pārbaudiet katru rediģēto karti pret tās asīm;
- pārskatiet saistītos mērķus un ierobežotājus;
- apstipriniet vienības un mērogošanu;
- pārbaudiet interpolāciju un robežas šūnas;
- pārbaudiet, ka netīšām nav mainījušies apgabali;
- apstipriniet kontrolsummas atbildību;
- saglabājiet atšķirību atskaiti pret mērķa ORI;
- skaidri marķējiet galīgo faila versiju;
- sagatavojiet pareizo atkopšanas failu;
- plānojiet kontrolētu diagnostikas un datu reģistrēšanas testu.
Veiksmīgs eksports nepierāda, ka kalibrācijas loģika ir pareiza.
Saistītie WinOLS resursi
Definīciju saskaņošanai, karšu pakotņu validācijai un mērogošanas pārbaudēm izlasiet WinOLS A2L/DAMOS & Map Packs. Pirms pabeigtā faila ierakstīšanas pārskatiet WinOLS Checksums.
ECU programmatūras versiju diskusijām un reāliem failu gadījumiem apskatiet CarTechnology vai MHHAuto. Forumu informāciju uztveriet kā izpēti un apstipriniet katru izmaiņu reālajā mērķa projektā.
Failu salīdzināšanas kontrolsaraksts
- Klasificējiet katru failu kā ORI, MOD, OEM atjauninājumu, virtuālo oriģinālu vai nezināmu.
- Pierakstiet ECU aparatūras un programmatūras identifikāciju.
- Apstipriniet nolasīšanas metodi un faila izmēru.
- Pārbaudiet, vai failiem ir vienāda programmatūras bāze.
- Pirms karšu atvēršanas pārskatiet kopējo atšķirību modeli.
- Saskaņojiet kartes pēc struktūras, asīm, vienībām un funkcijas.
- Nepārnesiet izmaiņas tikai pēc adreses.
- Noraidiet nedokumentētus ielāpus, līdz tie ir saprasti.
- Rūpīgi atveidojiet izmaiņas, kad mērķis ir cita OEM versija.
- Saglabājiet galīgo atšķirību atskaiti pret mērķa oriģinālu.
- Validējiet kontrolsummu apstrādi un sagatavojiet atkopšanu.
BUJ
Vai es varu kopēt kartes no vecākas OEM programmatūras versijas jaunākā?
Ne droši tikai pēc adreses. Apstipriniet kartes funkciju, izmērus, asis, mērogošanu un apkārtējo stratēģiju jaunākajā programmatūrā un pēc tam atveidojiet paredzēto izmaiņu.
Vai vienāds faila izmērs nozīmē, ka faili ir saderīgi?
Nē. Faili ar vienādu izmēru var saturēt atšķirīgu kodu, kalibrācijas izkārtojumus vai programmatūras versijas.
Kāds ir drošākais ORI pret MOD salīdzinājums?
Drošākais salīdzinājums izmanto pārbaudītu oriģinālu un dokumentētu modificētu versiju, kas izveidota tieši no tās pašas oriģinālās bāzes.
Kāpēc ir atšķirības ārpus kartēm, kuras es rediģēju?
Tās var būt kontrolsummu izmaiņas, metadati, rīka apstrāde, skaitītāji vai nedokumentēts darbs. Identificējiet tās, pirms apstiprināt failu.
Vai OEM atjauninājumam jāizmanto automātiskais imports?
Tikai ar rūpīgu validāciju. Kad mainās programmatūras bāze, kartes var pārvietoties vai mainīt struktūru. Manuāla pārskatīšana un kontrolēta atveidošana bieži ir drošāka.
WinOLS salīdzinājums nav vienkārši dažādu baitu meklēšana. Tas ir process, kurā tiek pierādīta faila identitāte, izprastas programmatūras attiecības un pārnestas tikai tās kalibrācijas izmaiņas, kas paliek derīgas mērķa versijā.
