Filen är redan avkodad innan du öppnar jobbet.

Problemet, utan omskrivningar

Ett slaveverktyg är ett kommersiellt beslut, inte en teknisk brist. Slavehårdvara är billigare, det är vad de flesta återförsäljare och mindre verkstäder kan motivera, och den ger fullt användbara avläsningar. Det den inte ger är en fil som du kan öppna och redigera direkt. Avläsningen kommer ut inpackad i verktygets eget skyddade format och måste gå igenom verktygsleverantörens eget avkodningssteg innan den blir en redigerbar binärfil — och sedan tillbaka genom motsvarande kodningssteg så att verktyget kan skriva den till bilen.

I ett jobb är det en mindre olägenhet. Under en arbetsvecka blir det en belastning. Varje enskild fil innebär samma följd: ladda ned bilagan, hitta den i mappen Hämtade filer, öppna verktygets programvara, logga in, ladda upp, vänta, ladda ned den avkodade filen, hitta den, öppna den i WinOLS, göra det faktiska arbete du får betalt för, exportera, gå tillbaka till verktyget, ladda upp den ändrade filen, vänta igen, ladda ned den återkodade slavefilen och till sist skicka tillbaka den till kunden. Trimningen tog tjugo minuter. Hanteringen tog ytterligare femton — och hanteringen är den del som inte tillför något på fakturan.

Än värre är att det är den del som går fel. Där laddas fel fil upp, kundens original blandas ihop med en avkodad kopia, ett jobb ligger orört i en timme för att du inte märkte att det kommit in, och en trött operatör klockan 21 skickar tillbaka filen som aldrig återkodades alls.

Så fungerar det: botten bor på din dator

Detta är designbeslutet som gör hela lösningen möjlig, så det är värt att vara exakt.

RemapDash-botten är ett litet program som installeras på din egen Windows-dator — samma dator där du redan kör WinOLS och din verktygsprogramvara. Den kopplas en gång till din portal och ligger sedan tyst i bakgrunden, ansluten och väntar på arbete. När ett jobb kommer in i din portal hämtar botten det, avkodar det via ditt verktygskonto och lägger tillbaka den öppna filen på jobbet åt dig.

Dina verktygsuppgifter stannar på din dator. De lagras krypterat på själva datorn, kopplade till din Windows-användare, och avkodningen sker från din dator med ditt eget konto — precis som om du satt där och klickade på knapparna själv. Din relation till din verktygsleverantör förblir exakt densamma. Ingen proxar ditt konto genom någon annans infrastruktur och ingenting i ditt licensavtal ändras.

Det är viktigt av både praktiska och principiella skäl: eftersom arbetet sker från din dator och din session fungerar det på det sätt som ditt verktyg förväntar sig. Det är ditt vanliga arbetsflöde, utfört automatiskt, i maskinhastighet, utan dig.

Vad som faktiskt händer, steg för steg

• Kunden laddar upp. En återförsäljare skickar in ett jobb via din varumärkesprofilade portal och bifogar slaveavläsningen från sitt verktyg.
• Portalen känner igen den. Filen identifieras som en slavefil i stället för en öppen binärfil — och om kunden har kryssat i fel ruta rättar portalen det.
• Botten tar jobbet. Din parkopplade dator hämtar arbetet automatiskt. Inget behöver öppnas, klickas eller dras.
• Avkodningen körs via ditt konto. Botten utför avkodningssteget med dina egna verktygsuppgifter, som finns på din egen dator.
• Den öppna filen hamnar tillbaka på jobbet. När du sätter dig och läser kundens förfrågan är den redigerbara filen redan bifogad.
• Du gör den del du faktiskt får betalt för. Kalibreringsarbetet. I WinOLS, med ditt bibliotek, dina definitioner och ditt omdöme.
• Återkodningen går tillbaka samma väg. Dra och släpp din ändrade fil på jobbet så packar botten tillbaka den till en slavefil som kundens verktyg accepterar — eller, när en lämplig donator hittas i ditt bibliotek, körs hela cykeln automatiskt genom LUA-botten utan att du behöver dra och släppa alls.

Två hastigheter: dra och släpp eller helt automatiskt

Alla jobb bör inte automatiseras, och ett system som låtsas något annat är ett system du till slut slutar lita på. Därför finns det medvetet två lägen, och du väljer per jobb.

1. Dra och släpp

Avkodningen sker automatiskt på vägen in — den delen kostar dig inget och innebär ingen risk, eftersom avkodning av en fil inte ändrar några kalibreringsvärden. Du gör trimningen själv. När du är klar drar du den ändrade binärfilen till jobbet och kodningen körs automatiskt på vägen ut. Alla kalibreringsbeslut var dina; det mekaniska omslaget i båda ändar hanterades åt dig.

Det här är läget som de flesta verkstäder kommer att använda större delen av tiden, och det tar redan bort den överväldigande delen av hanteringskostnaden.

2. Helt automatiserat när en lämplig donator finns

Om den inkommande filen matchar ett jobb du redan har gjort och verifierat — samma ECU, samma programvara, en verklig donator i ditt eget WinOLS-bibliotek — kan automatiseringsbotten genomföra hela cykeln: avkoda, tillämpa ditt beprövade arbete från ditt eget bibliotek, återkoda och returnera.

Läs detta noga, för skillnaden är hela poängen: det här är ditt eget tidigare testade arbete som tillämpas igen på en fil som den verkligen matchar. Det är inte en modell som skapar en kalibrering. Ingenting uppfinns. Om ingen lämplig donator hittas får jobbet ingen gissning — det stannar på din arbetsbänk som ett vanligt manuellt jobb. Vi har skrivit en hel sida om varför biblioteksbaserad automatisering inte är ”AI-trimning”, eftersom skillnaden är skillnaden mellan en snabb verkstad och en skadad motor.

Smart identifiering: fånga den felbenämnda uppladdningen

Alla som tar emot filer från återförsäljare känner igen detta fel. Kunden laddar upp en slavefil och markerar den som en master. Eller döper om den till något hjälpsamt som golf.bin. Eller bifogar den under helt fel jobbtyp. Du upptäcker det inte när den laddas upp — du upptäcker det tio minuter in i jobbet, när något inte öppnas som det ska.

Portalen kontrollerar vad filen faktiskt är i stället för att lita på dess etikett. En slavefil känns igen som en slavefil oavsett vilken ruta kunden kryssade i eller vilket namn de gav den, och jobbet korrigeras på vägen in. Kunden straffas inte för ett misstag som den inte visste att den gjorde, och du förlorar inte tio minuter på att upptäcka det.

AutoTuner-metadata: kundens jobb fylls i automatiskt

AutoTuner-metadata: kundens jobb fylls i automatiskt

AutoTuner-slavefiler innehåller användbar information om avläsningen — fordonet, ECU:n och hur avläsningen togs. Portalen hämtar ut den vid uppladdning och använder den för att fylla i jobbet.

Effekten på kundens sida är den som faktiskt vinner återförsäljare åt dig: att skicka in en fil går snabbare och ger färre fel, eftersom uppgifterna de annars skulle behöva skriva — och skriva fel — redan är ifyllda från själva filen. Tillsammans med registreringsskyltssökning på fordonssidan kan en återförsäljare gå från ”jag har en avläsning” till ”jobbet är inskickat” på några sekunder, med rena data bifogade.

Och rena data vid inlämningen är inte bara trevligt. Det är det som gör ditt WinOLS-projektbibliotek sökbart om två år, vilket är tillgången som över huvud taget gör donatormatchning möjlig. Slarv vid inlämningen i dag blir ett manuellt jobb om arton månader.

Vad detta faktiskt sparar åt dig

Var skeptisk till runda tal i marknadsföring, så här är den ärliga formen i stället för en rubriksiffra.

En verkstad som gör tio slavejobb om dagen och lägger femton minuter per jobb på ren hantering lägger mer än två timmar om dagen på arbete som ingen kund någonsin har debiterats för och som ingen motoroptimerare någonsin har tyckt om. Oavsett dina verkliga siffror, räkna på dem — matematiken brukar vara obekväm.

• Hanteringstiden per jobb går ned till ungefär noll. Nedladdnings-öppnings-inloggnings-uppladdnings-vänta-nedladdningsdansen i båda ändar av jobbet är det specifika som tas bort.
• Väntan slutar vara ditt problem. Avkodningstiden finns fortfarande, men den sker medan du sover, kör bil eller arbetar med en annan bil — inte medan du tittar på en förloppsindikator.
• Leveranstiden förbättras utan att du arbetar snabbare. Filen är klar i samma ögonblick som du tittar på den, så den tid kunden upplever börjar vid din första användbara åtgärd i stället för efter femton minuters administration.
• En hel typ av misstag försvinner. Oåterkodade returer, uppladdningar av fel fil och sammanblandade original är hanteringsfel. Ta bort hanteringen så tar du bort dem.
• Kvällarna blir kortare. Jobben som kommer in klockan 17 är avkodade och väntar klockan 17.01 i stället för att starta en ny administrativ runda efter en lång arbetsdag.

Vilka verktyg stöds

Ett rakt svar, eftersom vaga svar här slösar allas tid:

Du behöver ett eget konto hos verktygsleverantören. RemapDash säljer inte vidare, underlicensierar inte och ersätter inte någon verktygsleverantörs programvara eller krediter — botten använder kontot du redan har, på datorn du redan använder.

• AutoTuner — stöds. Automatisk avkodning på vägen in, kodning på vägen ut och dessutom extrahering av metadata från slavefilen vid uppladdning.
• Alientech KESS3 — stöds. Automatisk avkodning och kodning via ditt eget Alientech-konto, för både OBD- och bänk-/bootavläsningar.
• Magic Motorsport — kommer snart. Känns igen av portalen redan i dag, men är ännu inte automatiserat. Vi säger hellre ”inte än” än skickar något halvt fungerande mitt in i ditt arbetsflöde.
• Andra verktyg — filer känns igen och hanteras som slavefiler, men automatisk avkodning utlovas inte. Fler verktyg finns på planen.

• WinOLS-automatiseringsbotten — vad den faktiskt gör, varför den ingår utan extra kostnad och varför det inte är ”AI-trimning”.
• Vad är WinOLS? — editorn i centrum av arbetsflödet.
• Vad programvara för trimfilsportaler gör — hela bilden kring arbetsbänken.
• Programvaruvillkor och automatiseringsfriskrivning — de regler på klarspråk som vår automatisering levereras med.

AutoTuner, Alientech, KESS och Magic Motorsport är varumärken som tillhör sina respektive ägare. RemapDash är en oberoende leverantör av portalprogramvara och är inte ansluten till eller godkänd av någon verktygsleverantör. Automatiseringen körs med ditt eget verktygskonto och din egen licens; du ansvarar fortfarande för att följa verktygsleverantörens villkor och för att kontrollera varje fil innan den flashas till ett fordon.