På papperet är det en en-till-en-konvertering. Det är det aldrig.

Migreringar som den här säljs in som en-till-en-konvertering. Ta det gamla systemet, återskapa vad det gör i ny hårdvara och mjukvara, lämna tillbaka det med exakt samma beteende. Ren omfattning, lätt att sälja — på försättsbladet läser det som copy-paste med en budget vidhängd.

Det finns en särskild sorts delsystem som tyst bevisar att försättsbladet har fel, och när man väl brottats med ett börjar man se det överallt: en gammal PLC ur Mitsubishis FX-serie, ett program skrivet på 1990-talet, i ladderlogik, i GX Developer — den äldre generationen av Mitsubishis MELSEC-programmeringsmjukvara. Jobbet är att flytta in det i ABB 800xA, ombyggt som en styrmodul och kodat i funktionsblocksdiagram (FBD) i stället för ladder. ”Samma beteende, ny plattform.” Det är instruktionen. Här är där instruktionen tar slut.

”En-till-en” är en säljmening, inte en ingenjörsmening

Jag tror inte att någon ljuger när de kallar det 1:1. Från kundens sida är det sant: samma knappar, samma sekvens, samma utsignal, linjen kör som den alltid gjort. Det är resultatet de betalar för, och det är ett rimligt sätt att beskriva det.

Men samma resultat och samma logik är två olika jobb, och gapet mellan dem är där det mesta av arbetet göms. Tre saker i ett delsystem som det här öppnar upp det gapet. Inget av dem står på försättsbladet.

Ett: ladder och FBD tänker inte på samma sätt

Ladderlogik och FBD är inte två dialekter av ett språk. De är två olika sätt att föreställa sig en maskin. Ladder läses som stegar av kontakter och spolar, ström som flödar från vänster till höger — en mental modell som var begriplig på den tiden den beskrev bokstavliga reläpaneler. FBD läses som signaler som flödar genom block. Olika generationer, olika instinkter.

Så att översätta det ena till det andra är inte mekaniskt, i någondera riktningen. Ett mönster som är en uppenbar enda stege i ladder kan bli ett klumpigt kluster av block i FBD, och något rent i FBD skulle bli en röra av stegar på vägen tillbaka. Fällan är att man oftast kan få utsignalen att stämma medan strukturen under blir något helt annat än originalet — vilket känns som framgång ända tills ett gränsfall beter sig annorlunda. Att återskapa det exakta beteendet är den genuint svåra biten. Inte för att den nya plattformen inte klarar det, utan för att bevisa att den nya versionen beter sig identiskt kräver att man förstår den gamla mycket djupare än att bara läsa den uppifrån och ner.

Två: delarna utan motsvarighet

En del av det som dessa gamla program lutar sig mot har helt enkelt ingen tvilling i 800xA. Det översätts inte; det måste byggas om för hand, och man hittar varje sådan bit bara genom att läsa noggrant.

• Hoppinstruktioner. Laddern använder villkorliga hopp (CJ) för att hoppa över hela logiksektioner — och allt som fångas inuti en överhoppad sektion håller sitt senaste tillstånd i stället för att nollställas, inklusive timers, som fryser i stället för att rensas. Det finns inget lika-för-lika-hopp att släppa in i FBD:n, så det styrflödet måste uttryckas om som exekveringsordning och enable-villkor — en annan mental modell, inte en utbytt instruktion. Återskapa frys-men-nollställ-inte-beteendet, annars har du infört en tyst gränsfallsskillnad.
• Fysiska justeringar inkopplade i logiken. Inte alla börvärden bor i koden. Vissa värden — sådant som timerförinställningar — trimmades på själva maskinen via fysiska potentiometrar. På FX:en håller de potentiometrarna inte värdet direkt: de landar i särskilda dataregister (D8030/D8031), och programmet skalar om dem till en förinställning. I den nya världen blir de parametrar i styrmodulen, vilket tvingar fram ett beslut originalet aldrig skrev ner: vad som var tänkt att förbli fältjusterbart, och vad som bara var så man gjorde 1995.
• Speciella hjälpreläer. De här programmen lutar sig mot systemreläer i M8000-serien — till exempel M8028, som växlar tidsbasen på ett block av timers — för att forma delar av logiken. De är plattformsspecifika systembitar. 800xA har sina egna mekanismer, så varje användning måste förstås för vad den faktiskt gjorde och sedan återskapas med vad den nya plattformen erbjuder — aldrig bara kopieras rakt över.

Tre: integrationsmodellen som gömmer sig inuti ”1:1”

Det här är den som inte syns förrän man går och letar, och en lika-för-lika-brief är det sämst placerade dokumentet för att fånga den.

En styrenhet arbetar aldrig ensam. Den pratar med allt som sitter runt omkring — andra styrenheter, I/O, linjen i stort — och hur den pratar är en del av vad den gör, även om inget av det syns när man läser programmet uppifrån och ner. Det tysta antagandet som är inbyggt i en 1:1-brief är att den här konversationen följer med oförändrad. Ofta gör den inte det. Gå från en decennier gammal plattform till en modern och själva integrationsmodellen kan förändras: hur det här hörnet av systemet ansluter till allt annat, och vad den anslutningen ens består av.

Låt det sjunka in. Samma funktion ute på golvet, ett annat nervsystem bakom. Man kan inte återskapa en anslutning som inte längre finns i samma form — man måste konstruera om hur saken pratar med resten av systemet, och det är verkligt arbete som försättsbladet aldrig prissatte. Det är inte exotiskt. Det är bara osynligt från programlistningen, vilket är precis därför en brief skriven utifrån den listningen gång på gång missar det.

Hur jag läser ett program skrivet innan jag föddes

Jag är tidigt nog i yrket för att ett ladderprogram från 1990-talet ska vara genuint främmande för mig — jag är 21, ungefär arton månader in. Jag skulle aldrig kunna ut-erfara kod som den. Så jag lutar mig på verktygen, medvetet — och jag tänker berätta hur, för metoden är halva poängen.

Greppet är att få ut det gamla programmet ur sin nativa miljö och in i en enkel, läsbar form — exportera det till PDF, eller vilket format som helst som bevarar vad logiken faktiskt gör — och sedan använda en AI-modell som lässtöd (se till att arbeta på en företagsintern, on-prem-driven ML-plattform — och först efter att du har verifierat att det är godkänt med ditt företag, kunden och alla andra vars data berörs): förklara det här sektion för sektion, med annoterade utdrag jag kan kontrollera direkt mot stegarna. Det förvandlar ett program som ingen rört på årtionden till en läsbar karta. Därifrån listar man ut vilka delar som inte kommer att överleva flytten — hoppen, special­bitarna, de fältsatta förinställningarna — och resonerar sig igenom hur ett givet block ladder borde byggas om som FBD.

Jag vill vara ärlig om begränsningarna, för en automationspublik kommer med rätta att misstro det här. AI:n har fel ibland. Den gissar om avsikt, ibland med en självsäkerhet den inte förtjänat. Den är ett läshjälpmedel och en tankepartner, inte en auktoritet — varje slutsats kontrolleras mot det verkliga programmet och det verkliga beteendet innan den kommer i närheten av den nya koden. Men som ett sätt att förvandla en ogenomtränglig 1990-talsartefakt till något man kan resonera om på dagar i stället för veckor förtjänar den sin plats. Det är precis det enkla arbete verktygen är bra på: inte att ta ingenjörsbeslutet, bara att röja undan snåret så att man kan.

Samma knep, riktat mot svaret

Att läsa det gamla programmet är bara hälften. Den andra hälften är att bevisa att det nya stämmer — och samma metod fungerar där också. Exportera båda programmen till text som speglar deras logik — laddern och FBD:n var och en dumpad till PDF, eller vilket format som helst som bevarar vad koden faktiskt gör — och mata in båda i en AI samtidigt, och be den jämföra dem logiskt och funktionellt och rapportera var de avviker. Den bygger inte om något åt dig, men den är en snabb, outtröttlig andra läsare: stegen som inte överlevde flytten, gränsfallet FBD:n hanterar annorlunda, utsignalen som tyst ändrades — den flaggar dem så att du kan jaga rätt på dem. Samma förbehåll som förut: varje flagga kontrolleras mot det verkliga beteendet innan du litar på den. Men att rikta verktygen mot båda sidorna samtidigt förvandlar ”stämmer det här?” från en vecka av manuell korsläsning till något man kan iterera på under en eftermiddag.

Slutsatsen

En en-till-en-migrering är verklig från kundens stol och en fiktion från ingenjörens, och båda kan vara sanna samtidigt. Faran är inte etiketten — det är när de som sätter omfattningen tror på den.

Så här är vad ett jobb som det här lär en, och vad som är värt att göra på nästa innan man rör en enda stege: när något säljs som en-till-en, gå och leta upp de tre ställen där det inte kan vara det.

• Paradigmgapet — där källverktyget och målverktyget tänker olika (ladder till FBD) är beteendet svårt att bevisa, inte bara att skriva.
• Föräldralösa bitarna — de plattformsspecifika delarna utan motsvarighet (hopp, systemreläer, fältsatta förinställningar) som måste byggas om för hand.
• Integrationsmodellen — hur saken pratar med allt runt omkring sig, vilket en ”lika-för-lika”-brief gärna antar förblir oförändrad när den inte gör det.

Hitta de tre tidigt. Prissätt dem ärligt. Då slutar ”en-till-en” att vara en lögn man upptäcker halvvägs in och blir en plan man faktiskt kan stå bakom. Etiketten var aldrig problemet — att tro på den var det.