Slik bruker du AI-oversettelse for dokumentasjon om funksjonell sikkerhet under IEC 61508 og ISO 26262
Å oversette dokumentasjon om funksjonell sikkerhet er en jobb i seks trinn: frys kildeteksten, lås sikkerhetsterminologien, kjør AI-oversettelsen på en klienttilpasset modell, la en ingeniør gjennomgå hver sikkerhetspåstand, kontroller outputet tilbake mot kilden, og arkiver deretter versjonen. Én regel holder hele metoden sammen. En sikkerhetspåstand sendes aldri av gårde på maskinoutput alene.
AD VERBUM er et EU-hostet AI-oversettelsesbyrå som oversetter sikkerhetsmanualer, sikkerhetssaker og FMEA-dokumenter til IEC 61508- og ISO 26262-programmer, der sertifiserte fagingeniører gjennomgår hver sikkerhetspåstand under ISO 17100 og ISO 18587. Vi bygger først termbasen og Translation Memory din, og kjører deretter en klienttilpasset open-weight-modell på EU-hostet infrastruktur, slik at ingenting går til offentlige skytjenester.
Funksjonell sikkerhet fyller automotive- og industrihallene på electronica 2026 i München. Messen går fra 10. til 13. november, og dette arbeidet bygger oppå den oversettelsen av teknisk dokumentasjon du allerede gjør. Se programmet for electronica 2026 for sporene om innebygde systemer og krafteelektronikk, der en sikkerhetssak må lyde likt på hvert språk.
Hva IEC 61508 og ISO 26262 krever, og hva de ikke gjør
IEC 61508 er grunnstandarden for funksjonell sikkerhet av elektriske, elektroniske og programmerbare elektroniske sikkerhetsrelaterte systemer. Den nåværende andre utgaven er fra 2010, går over sju deler og vurderer risikoreduksjon på et Safety Integrity Level fra SIL 1 til SIL 4. IEC 61508-serien og dens oversiktsrapport beskriver hvordan sikkerhetslivssyklusen og SIL-målene henger sammen.
ISO 26262 tilpasser den grunnstandarden til veikjøretøy. Andre utgave, ISO 26262:2018, spenner over tolv deler, dekker alle veikjøretøy unntatt mopeder og vurderer automotive-risiko på et Automotive Safety Integrity Level fra ASIL A til ASIL D. Den er referansen for sikkerhetssakene, fareanalysene og FMEA-dokumentene som går gjennom arbeidet med automotive teknisk dokumentasjon.
Her er poenget som avgjør hvem du hyrer. Begge standardene sertifiserer produktet og utviklingsprosessen din, ikke oversetteren din. Ingen oversettelsesbyrå har en "ISO 26262-sertifisering" eller "IEC 61508-sertifisering", og den som hevder det, beskriver noe som ikke finnes. Det et oversettelsesbyrå kan gjøre, er å produsere sikkerhetsdokumentasjonen som underbygger sertifiseringen din, med ingeniører som forstår SIL og ASIL og gjennomgår hver sikkerhetspåstand. Vi i AD VERBUM oversetter og gjennomgår de dokumentene under ISO 17100 og ISO 18587, og vi sier klart hvor standardene står.
De seks trinnene, i rekkefølge
Metoden er den samme enten du kjører en SIL-vurdering under IEC 61508 eller en ASIL-dekomponering under ISO 26262. Følg den i denne rekkefølgen:
Frys kildeteksten, slik at versjonen som oversettes ikke kan gli midt i prosjektet.
Lås sikkerhetsterminologien i en termbase før et eneste segment oversettes.
Kjør AI-oversettelsen på en klienttilpasset modell som er avgrenset av den termbasen.
La en sertifisert ingeniør gjennomgå hver sikkerhetspåstand, ikke bare de flytende setningene.
Kontroller outputet tilbake mot kilden, tall for tall og advarsel for advarsel.
Arkiver hver versjon med gjennomgåeren og endringsloggen.
Hopp over et trinn, og risikoen lander på det ene dokumentet som forteller en operatør eller en testingeniør hva som skal gjøres. Avsnittene nedenfor tar for seg hvert trinn.
1. Frys kildeteksten
En sikkerhetssak endrer seg mens ingeniørarbeidet fortsatt lukker funn, og en kilde i bevegelse er den raskeste veien til et avvik i leveransen. Frys den nøyaktige revisjonen du oversetter, noter dokumentnummeret og datoen, og oversett bare fra den frosne kopien. Utsteder ingeniørarbeidet en endring under prosjektet, behandler du den som en ny revisjon med sin egen oversettelses- og gjennomgangssyklus, ikke som en rettelse sluppet inn i arbeid som allerede er i gang. Den samme versjonsdisiplinen går gjennom vår oversettelse av teknisk dokumentasjon, der en testrapport og manualen som siterer den må stemme overens.
2. Lås sikkerhetsterminologien
Trekk det kontrollerte vokabularet ditt inn i en termbase først: SIL- og ASIL-merkene, de sikre tilstandene, feil- og sviktbegrepene og verbene som forteller en leser å handle. En klienttilpasset modell som er avgrenset av den termbasen, holder "sikker tilstand", "diagnosedekning" og "restrisiko" identiske på tvers av hvert språk i én gjennomgang, noe en generisk maskin ikke kan love. Notatet vårt om selvhostede open-weight-modeller for regulert oversettelse forklarer hvorfor en tilpasset modell slår en standardmaskin på denne typen kontrollert innhold.
3. Kjør AI-oversettelsen på en klienttilpasset modell
Generer utkastet på en modell som allerede rommer terminologien din, ikke på en offentlig chatbot. Vi kjører klienttilpassede open-weight-modeller på EU-hostet infrastruktur, avgrenset av termbasen og Translation Memory din, der ingenting sendes til offentlige skyverktøy. Sikkerhetsdokumentasjon før lansering bærer ofte ennå ikke annonserte produktdetaljer, så de samme residenskontrollene vi bruker på elektronikk-datablader og innebygd programvare og på sikker oversettelse med EU-dataresidens, gjelder også her.
4. La en ingeniør gjennomgå hver sikkerhetspåstand
Dette er trinnet som gjør outputet brukbart, og det krever en sertifisert ingeniør-lingvist fremfor en generell korrekturleser. Gjennomgåeren kontrollerer:
Hver sikkerhetspåstand og hver instruksjon om en sikker tilstand, mot kilden og mot termbasen.
Hvert SIL- og ASIL-merke, slik at et nivå aldri glir mellom kilde og oversettelse.
Hvert tall, hver enhet og hver toleranse i en fareanalyse, FMEA- eller FMEDA-tabell.
Hver betingelse, slik at "skal ikke" aldri leses som "skal", og en påkrevd handling aldri ser valgfri ut.
Dette er full menneskelig post-editing under ISO 18587, der gjennomgåeren tar ansvaret for den endelige teksten. En sikkerhetspåstand sendes aldri av gårde på maskinoutput alene, og den regelen bøyer seg ikke for en frist.
5. Kontroller tilbake mot kilden
Å kontrollere tilbake er en andre gjennomlesing mot den frosne kilden, ikke en stavekontroll. Gjennomgåeren går oversettelsen igjennom ved siden av kilden og bekrefter at hver advarsel, hver verdi og hver kryssreferanse stemmer, for et tapt desimal eller en snudd betingelse i en sikkerhetstabell er feilen som overlever en flytende lesing. På et stort program utfører en uavhengig lingvist tilbakekontrollen, slik at personen som bekrefter outputet ikke er den som laget det. Den samme uavhengige gjennomgangen bruker vi på arbeid med høy eksponering som dokumentasjon om EV-batterier og ladeinfrastruktur.
6. Arkiver versjonen med gjennomgåeren
Lukk hver språkversjon inn i et arkiv som registrerer den frosne kilderevisjonen, gjennomgåeren og hver endring. Spør en revisor, en assessor eller en kunde hvilken tekst som gikk til hvilket marked, svarer du ut fra loggen fremfor ut fra hukommelsen. Oppbevaringslogikken matcher plikten i EUs maskinforordning til å bevare bruksanvisninger i utstyrets forventede levetid, og den fortsetter rett inn i oversettelse av forsvarsteknisk dokumentasjon, der sporbarhet er et kontraktsvilkår, ikke en preferanse.
Der det går galt
De fleste feil i oversettelse om funksjonell sikkerhet kan føres tilbake til et oversett trinn. De vanligste:
Å oversette fra en kilde som fortsatt var i bevegelse, slik at den leverte manualen siterer en revisjon som ikke lenger finnes.
Å kjøre en generisk maskin uten termbase, slik at en sikker tilstand eller et SIL-merke glir mellom språk.
Å la en generell korrekturleser godkjenne en sikkerhetssak, slik at en snudd betingelse i en advarsel når produksjonen.
Å sende sikkerhetsdokumentasjon før lansering gjennom offentlige skyverktøy, slik at ennå ikke annonserte produktdetaljer forlater kontrollen din.
Å føre intet versjonsarkiv, slik at du ikke kan vise en assessor hvilken tekst som gikk til hvilket marked.
Hver av disse kan unngås med kilden frosset først og gjennomgangen eid av en sertifisert ingeniør. Dokumentet som forteller noen å handle, er det som aldri sendes av gårde på maskinoutput alene.
Våre oversettelsestjenester for funksjonell sikkerhet
Våre oversettelsestjenester for regulerte sektorer kjører på ISO 27001- og ISO 42001-sertifisert, EU-hostet infrastruktur, uten avhengighet av offentlige skyverktøy for kjernebehandlingen. Hvert prosjekt går gjennom vår AI+HUMAN hybride arbeidsflyt: vi laster først inn kundens Translation Memories og termbaser, vårt egenutviklede LLM-baserte LangOps System genererer output avgrenset av kundeterminologi på klienttilpassede open-weight-modeller, og våre sertifiserte fageksperter gjennomgår for teknisk nøyaktighet og regulatorisk samsvar. Vår QA er tilpasset ISO 17100 og ISO 18587, med sektorspesifikke krav som funksjonell sikkerhet under IEC 61508 og kjøretøysikkerhet under ISO 26262 der det er relevant, og den samme disiplinen strekker seg til våre sikre oversettelses-arbeidsflyter med EU-dataresidens. Vi betjener kunder innen Life Sciences, Legal, Finance, Forsvar og Manufacturing på over 150 språk med mer enn 3 500 faglingvister. For team som oversetter en sikkerhetssak eller et FMEA-sett, kontakt oss for å drøfte terminologien, gjennomgangen og arkiveringen din direkte.
FAQ
Kan AI-oversettelse brukes for dokumentasjon om funksjonell sikkerhet?
Ja, når en sertifisert ingeniør gjennomgår outputet. AI-dokumentoversettelse leverer utkastet raskt, men under disiplinen full menneskelig post-editing i ISO 18587 tar en kvalifisert gjennomgåer ansvaret for den endelige teksten. En sikkerhetspåstand sendes aldri av gårde på rå maskinoversettelse alene.
Sertifiserer IEC 61508 eller ISO 26262 et oversettelsesbyrå?
Nei. IEC 61508 og ISO 26262 sertifiserer kundens sikkerhetsrelaterte produkt og utviklingsprosess, ikke en oversettelsesleverandør. Ingen oversettelsesbyrå har en "IEC 61508-sertifisering" eller "ISO 26262-sertifisering". Det en leverandør kan ha, er ISO 17100 og ISO 18587, pluss ingeniører som gjennomgår hver sikkerhetspåstand.
Hva er forskjellen på SIL og ASIL?
SIL, Safety Integrity Level fra 1 til 4, kommer fra IEC 61508 og gjelder for elektriske, elektroniske og programmerbare elektroniske sikkerhetssystemer. ASIL, Automotive Safety Integrity Level fra A til D, kommer fra ISO 26262 og gjelder for veikjøretøy. ISO 26262 er den automotive tilpasningen av IEC 61508, så begrepene flukter mens merkene og livssyklusen er forskjellige.
Hvilke dokumenter om funksjonell sikkerhet må oversettes?
Vanligvis sikkerhetsmanualen, sikkerhetssaken, fare- og risikoanalyser, FMEA- og FMEDA-tabeller, verifikasjons- og valideringsrapporter samt de sikkerhetsrelaterte delene av bruksanvisningen. Ethvert dokument som fremsetter en sikkerhetspåstand eller forteller en leser å handle, oversettes og gjennomgås deretter av en sertifisert ingeniør.
Hvorfor må kildeteksten fryses før oversettelse?
Fordi en sikkerhetssak fortsetter å endre seg mens ingeniørarbeidet lukker funn, og en kilde i bevegelse gir en oversettelse som siterer en revisjon som ikke lenger finnes. Å fryse den nøyaktige revisjonen, med dokumentnummer og dato, er det første trinnet, og enhver senere endring behandles som en ny revisjon med sin egen gjennomgangssyklus.
Er maskinoversettelsesoutput akseptabelt for en sikkerhetssak?
Ikke alene. Maskin- eller LLM-output kan være utkastet, men ISO 18587 krever full menneskelig post-editing av en kvalifisert gjennomgåer som tar ansvaret for resultatet. For en sikkerhetssak betyr det at en sertifisert ingeniør kontrollerer hver sikkerhetspåstand, hvert SIL- eller ASIL-merke og hvert tall mot den frosne kilden.
