Så använder du AI-översättning för dokumentation om funktionssäkerhet enligt IEC 61508 och ISO 26262
Att översätta dokumentation om funktionssäkerhet är ett jobb i sex steg: frys källtexten, lås säkerhetsterminologin, kör AI-översättningen på en klientanpassad modell, låt en ingenjör granska varje säkerhetspåstående, kontrollera outputen tillbaka mot källan och arkivera sedan versionen. En regel håller hela metoden samman. Ett säkerhetspåstående skickas aldrig iväg på maskinoutput ensamt.
AD VERBUM är en EU-baserad AI-översättningsbyrå som översätter säkerhetsmanualer, säkerhetsfall och FMEA-dokument för IEC 61508- och ISO 26262-program, där certifierade fackingenjörer granskar varje säkerhetspåstående enligt ISO 17100 och ISO 18587. Vi bygger först din termbas och ditt Translation Memory och kör sedan en klientanpassad open-weight-modell på EU-baserad infrastruktur, så att ingenting går till offentliga molntjänster.
Funktionssäkerhet fyller fordons- och industrihallarna på electronica 2026 i München. Mässan pågår 10 till 13 november, och detta arbete bygger ovanpå den översättning av teknisk dokumentation du redan gör. Se programmet för electronica 2026 för spåren om inbyggda system och kraftelektronik, där ett säkerhetsfall måste låta likadant på varje språk.
Vad IEC 61508 och ISO 26262 kräver, och vad de inte gör
IEC 61508 är grundstandarden för funktionssäkerhet hos elektriska, elektroniska och programmerbara elektroniska säkerhetsrelaterade system. Den nuvarande andra utgåvan är från 2010, löper över sju delar och bedömer riskreduktion på en Safety Integrity Level från SIL 1 till SIL 4. IEC 61508-serien och dess översiktsrapport beskriver hur säkerhetslivscykeln och SIL-målen hänger ihop.
ISO 26262 anpassar den grundstandarden till vägfordon. Andra utgåvan, ISO 26262:2018, spänner över tolv delar, täcker alla vägfordon utom mopeder och bedömer fordonsrisk på en Automotive Safety Integrity Level från ASIL A till ASIL D. Den är referensen för de säkerhetsfall, riskanalyser och FMEA-dokument som går genom arbetet med fordonsteknisk dokumentation.
Här är poängen som avgör vem du anlitar. Båda standarderna certifierar din produkt och din utvecklingsprocess, inte din översättare. Ingen översättningsbyrå har en "ISO 26262-certifiering" eller "IEC 61508-certifiering", och den som påstår det beskriver något som inte finns. Det en översättningsbyrå kan göra är att ta fram den säkerhetsdokumentation som underbygger din certifiering, med ingenjörer som förstår SIL och ASIL och granskar varje säkerhetspåstående. Vi på AD VERBUM översätter och granskar de dokumenten enligt ISO 17100 och ISO 18587, och vi säger tydligt var standarderna står.
De sex stegen, i ordning
Metoden är densamma oavsett om du kör en SIL-bedömning enligt IEC 61508 eller en ASIL-dekomposition enligt ISO 26262. Följ den i den här ordningen:
Frys källtexten, så att versionen som översätts inte kan glida mitt i projektet.
Lås säkerhetsterminologin i en termbas innan ett enda segment översätts.
Kör AI-översättningen på en klientanpassad modell som avgränsas av den termbasen.
Låt en certifierad ingenjör granska varje säkerhetspåstående, inte bara de flytande meningarna.
Kontrollera outputen tillbaka mot källan, siffra för siffra och varning för varning.
Arkivera varje version med sin granskare och ändringslogg.
Hoppa över ett steg och risken landar på det enda dokument som talar om för en operatör eller en testingenjör vad som ska göras. Avsnitten nedan tar varje steg för sig.
1. Frys källtexten
Ett säkerhetsfall ändras medan ingenjörsarbetet fortfarande stänger iakttagelser, och en källa i rörelse är den snabbaste vägen till en avvikelse i leveransen. Frys den exakta revision du översätter, notera dokumentnumret och datumet, och översätt bara från den frysta kopian. Utfärdar ingenjörsarbetet en ändring under projektet behandlar du den som en ny revision med en egen översättnings- och granskningscykel, inte som en rättelse insläppt i arbete som redan pågår. Samma versionsdisciplin löper genom vår översättning av teknisk dokumentation, där en testrapport och manualen som citerar den måste stämma överens.
2. Lås säkerhetsterminologin
Dra in ditt kontrollerade ordförråd i en termbas först: SIL- och ASIL-beteckningarna, de säkra tillstånden, fel- och feltermerna och de verb som säger åt en läsare att handla. En klientanpassad modell som avgränsas av den termbasen håller "säkert tillstånd", "diagnostäckning" och "restrisk" identiska över varje språk i ett enda pass, något en generisk maskin inte kan lova. Vår not om självhostade open-weight-modeller för reglerad översättning förklarar varför en anpassad modell slår en standardmaskin på den här sortens kontrollerade innehåll.
3. Kör AI-översättningen på en klientanpassad modell
Generera utkastet på en modell som redan rymmer din terminologi, inte på en offentlig chatbot. Vi kör klientanpassade open-weight-modeller på EU-baserad infrastruktur, avgränsade av din termbas och ditt Translation Memory, där ingenting skickas till offentliga molnverktyg. Säkerhetsdokumentation före lansering bär ofta ännu inte tillkännagivna produktdetaljer, så samma residenskontroller vi tillämpar på elektronik-datablad och inbyggd mjukvara och på säker översättning med EU-dataresidens gäller även här.
4. Låt en ingenjör granska varje säkerhetspåstående
Det här är steget som gör outputen användbar, och det kräver en certifierad ingenjörslingvist snarare än en allmän korrekturläsare. Granskaren kontrollerar:
Varje säkerhetspåstående och varje instruktion om ett säkert tillstånd, mot källan och mot termbasen.
Varje SIL- och ASIL-beteckning, så att en nivå aldrig glider mellan källa och översättning.
Varje tal, enhet och tolerans i en riskanalys, FMEA- eller FMEDA-tabell.
Varje villkor, så att "får inte" aldrig läses som "får" och en obligatorisk åtgärd aldrig ser frivillig ut.
Detta är full mänsklig efterredigering enligt ISO 18587, där granskaren tar ansvaret för den slutliga texten. Ett säkerhetspåstående skickas aldrig iväg på maskinoutput ensamt, och den regeln böjer sig inte för en deadline.
5. Kontrollera tillbaka mot källan
Att kontrollera tillbaka är en andra genomläsning mot den frysta källan, inte en stavningskontroll. Granskaren går översättningen bredvid källan och bekräftar att varje varning, varje värde och varje korshänvisning stämmer, för en tappad decimal eller ett vänt villkor i en säkerhetstabell är felet som överlever en flytande läsning. På ett stort program utför en oberoende lingvist tillbakakontrollen, så att personen som bekräftar outputen inte är den som skapade den. Samma oberoende pass använder vi på arbete med hög exponering som dokumentation om EV-batterier och laddinfrastruktur.
6. Arkivera versionen med sin granskare
Stäng varje språkversion in i ett arkiv som registrerar den frysta källrevisionen, granskaren och varje ändring. Frågar en revisor, en assessor eller en kund vilken text som gick till vilken marknad svarar du ur loggen i stället för ur minnet. Bevarandelogiken matchar skyldigheten i EU:s maskinförordning att bevara bruksanvisningar under utrustningens förväntade livslängd, och den fortsätter rakt in i översättning av försvarsteknisk dokumentation, där spårbarhet är ett avtalsvillkor, inte en preferens.
Där det går fel
De flesta misslyckade översättningar om funktionssäkerhet kan härledas till ett överhoppat steg. De vanligaste:
Att översätta från en källa som fortfarande var i rörelse, så att den levererade manualen citerar en revision som inte längre finns.
Att köra en generisk maskin utan termbas, så att ett säkert tillstånd eller en SIL-beteckning glider mellan språk.
Att låta en allmän korrekturläsare godkänna ett säkerhetsfall, så att ett vänt villkor i en varning når produktionen.
Att skicka säkerhetsdokumentation före lansering genom offentliga molnverktyg, så att ännu inte tillkännagivna produktdetaljer lämnar din kontroll.
Att inte föra något versionsarkiv, så att du inte kan visa en assessor vilken text som gick till vilken marknad.
Var och en av dessa går att undvika med källan fryst först och granskningen ägd av en certifierad ingenjör. Dokumentet som säger åt någon att handla är det som aldrig skickas iväg på maskinoutput ensamt.
Våra översättningstjänster för funktionssäkerhet
Våra översättningstjänster för reglerade sektorer körs på ISO 27001- och ISO 42001-certifierad, EU-baserad infrastruktur, utan beroende av offentliga molnverktyg för kärnbearbetningen. Varje projekt går genom vårt AI+HUMAN hybridarbetsflöde: vi läser först in kundens Translation Memories och termbaser, vårt egenutvecklade LLM-baserade LangOps System genererar output avgränsad av kundterminologi på klientanpassade open-weight-modeller, och våra certifierade fackexperter granskar för teknisk noggrannhet och regelefterlevnad. Vår QA är anpassad till ISO 17100 och ISO 18587, med sektorspecifika krav som funktionssäkerhet enligt IEC 61508 och fordonssäkerhet enligt ISO 26262 där det är relevant, och samma disciplin sträcker sig till våra säkra översättningsarbetsflöden med EU-dataresidens. Vi betjänar kunder inom Life Sciences, Legal, Finance, Försvar och Manufacturing på över 150 språk med fler än 3 500 facklingvister. För team som översätter ett säkerhetsfall eller en FMEA-uppsättning, kontakta oss för att diskutera din terminologi, granskning och arkivering direkt.
FAQ
Kan AI-översättning användas för dokumentation om funktionssäkerhet?
Ja, när en certifierad ingenjör granskar outputen. AI-dokumentöversättning levererar utkastet snabbt, men under disciplinen full mänsklig efterredigering i ISO 18587 tar en kvalificerad granskare ansvaret för den slutliga texten. Ett säkerhetspåstående skickas aldrig iväg på rå maskinöversättning ensamt.
Certifierar IEC 61508 eller ISO 26262 en översättningsbyrå?
Nej. IEC 61508 och ISO 26262 certifierar kundens säkerhetsrelaterade produkt och utvecklingsprocess, inte en översättningsleverantör. Ingen översättningsbyrå har en "IEC 61508-certifiering" eller "ISO 26262-certifiering". Det en leverantör kan ha är ISO 17100 och ISO 18587, plus ingenjörer som granskar varje säkerhetspåstående.
Vad är skillnaden mellan SIL och ASIL?
SIL, Safety Integrity Level från 1 till 4, kommer från IEC 61508 och gäller för elektriska, elektroniska och programmerbara elektroniska säkerhetssystem. ASIL, Automotive Safety Integrity Level från A till D, kommer från ISO 26262 och gäller för vägfordon. ISO 26262 är den fordonsanpassade versionen av IEC 61508, så begreppen stämmer överens medan beteckningarna och livscykeln skiljer sig.
Vilka dokument om funktionssäkerhet behöver översättas?
Vanligtvis säkerhetsmanualen, säkerhetsfallet, fara- och riskanalyser, FMEA- och FMEDA-tabeller, verifierings- och valideringsrapporter samt de säkerhetsrelaterade delarna av bruksanvisningen. Varje dokument som gör ett säkerhetspåstående eller säger åt en läsare att handla översätts och granskas sedan av en certifierad ingenjör.
Varför måste källtexten frysas innan översättning?
Eftersom ett säkerhetsfall fortsätter att ändras medan ingenjörsarbetet stänger iakttagelser, och en källa i rörelse ger en översättning som citerar en revision som inte längre finns. Att frysa den exakta revisionen, med dokumentnummer och datum, är det första steget, och varje senare ändring behandlas som en ny revision med en egen granskningscykel.
Är maskinöversättningsoutput godtagbar för ett säkerhetsfall?
Inte på egen hand. Maskin- eller LLM-output kan vara utkastet, men ISO 18587 kräver full mänsklig efterredigering av en kvalificerad granskare som tar ansvaret för resultatet. För ett säkerhetsfall betyder det att en certifierad ingenjör kontrollerar varje säkerhetspåstående, varje SIL- eller ASIL-beteckning och varje tal mot den frysta källan.
