Sådan bruger du AI-oversættelse til dokumentation om funktionel sikkerhed under IEC 61508 og ISO 26262
At oversætte dokumentation om funktionel sikkerhed er et arbejde i seks trin: frys kildeteksten, lås sikkerhedsterminologien, kør AI-oversættelsen på en klienttilpasset model, lad en ingeniør gennemgå hver sikkerhedspåstand, tjek outputtet tilbage mod kilden, og arkivér derefter versionen. Én regel holder hele metoden sammen. En sikkerhedspåstand sendes aldrig afsted på maskinoutput alene.
AD VERBUM er et EU-hostet AI-oversættelsesbureau, der oversætter sikkerhedsmanualer, sikkerhedssager og FMEA-dokumenter til IEC 61508- og ISO 26262-programmer, hvor certificerede fagingeniører gennemgår hver sikkerhedspåstand under ISO 17100 og ISO 18587. Vi opbygger først din termbase og dit Translation Memory og kører derefter en klienttilpasset open-weight-model på EU-hostet infrastruktur, så intet går til offentlige cloud-tjenester.
Funktionel sikkerhed fylder automotive- og industrihallerne på electronica 2026 i München. Messen løber fra 10. til 13. november, og dette arbejde bygger oven på den oversættelse af teknisk dokumentation, du allerede laver. Se programmet for electronica 2026 for sporene om indlejrede systemer og effektelektronik, hvor en sikkerhedssag skal lyde ens på hvert sprog.
Hvad IEC 61508 og ISO 26262 kræver, og hvad de ikke gør
IEC 61508 er grundstandarden for funktionel sikkerhed af elektriske, elektroniske og programmerbare elektroniske sikkerhedsrelaterede systemer. Den nuværende anden udgave er fra 2010, løber over syv dele og vurderer risikoreduktion på et Safety Integrity Level fra SIL 1 til SIL 4. IEC 61508-serien og dens oversigtsrapport beskriver, hvordan sikkerhedslivscyklussen og SIL-målene passer sammen.
ISO 26262 tilpasser den grundstandard til vejkøretøjer. Anden udgave, ISO 26262:2018, spænder over tolv dele, dækker alle vejkøretøjer undtagen knallerter og vurderer automotive-risiko på et Automotive Safety Integrity Level fra ASIL A til ASIL D. Den er referencen for de sikkerhedssager, fareanalyser og FMEA-dokumenter, der går gennem arbejdet med automotive teknisk dokumentation.
Her er pointen, der afgør, hvem du hyrer. Begge standarder certificerer dit produkt og din udviklingsproces, ikke din oversætter. Intet oversættelsesbureau har en "ISO 26262-certificering" eller "IEC 61508-certificering", og den, der hævder det, beskriver noget, der ikke findes. Hvad et oversættelsesbureau kan, er at producere den sikkerhedsdokumentation, der understøtter din certificering, med ingeniører, der forstår SIL og ASIL og gennemgår hver sikkerhedspåstand. Vi hos AD VERBUM oversætter og gennemgår de dokumenter under ISO 17100 og ISO 18587, og vi siger klart, hvor standarderne står.
De seks trin, i rækkefølge
Metoden er den samme, uanset om du kører en SIL-vurdering under IEC 61508 eller en ASIL-dekomposition under ISO 26262. Følg den i denne rækkefølge:
Frys kildeteksten, så den version, der oversættes, ikke kan skride midt i projektet.
Lås sikkerhedsterminologien i en termbase, før et eneste segment oversættes.
Kør AI-oversættelsen på en klienttilpasset model, der er afgrænset af den termbase.
Lad en certificeret ingeniør gennemgå hver sikkerhedspåstand, ikke kun de flydende sætninger.
Tjek outputtet tilbage mod kilden, tal for tal og advarsel for advarsel.
Arkivér hver version med dens korrekturlæser og ændringslog.
Spring et trin over, og risikoen lander på det ene dokument, der fortæller en operatør eller en testingeniør, hvad der skal gøres. Afsnittene nedenfor tager hvert trin for sig.
1. Frys kildeteksten
En sikkerhedssag ændrer sig, mens ingeniørarbejdet stadig lukker fund, og en kilde i bevægelse er den hurtigste vej til en uoverensstemmelse i leveringen. Frys den præcise revision, du oversætter, notér dens dokumentnummer og dato, og oversæt kun fra den frosne kopi. Udsender ingeniørarbejdet en ændring under projektet, behandler du den som en ny revision med sin egen oversættelses- og gennemgangscyklus, ikke som en rettelse smidt ind i arbejde, der allerede er i gang. Den samme versionsdisciplin løber gennem vores oversættelse af teknisk dokumentation, hvor en testrapport og den manual, der citerer den, skal stemme overens.
2. Lås sikkerhedsterminologien
Træk dit kontrollerede ordforråd ind i en termbase først: SIL- og ASIL-mærkerne, de sikre tilstande, fejl- og svigttermerne og de udsagnsord, der fortæller en læser at handle. En klienttilpasset model, der er afgrænset af den termbase, holder "sikker tilstand", "diagnosedækning" og "restrisiko" identiske på tværs af hvert sprog i ét gennemløb, hvad en generisk maskine ikke kan love. Vores note om selvhostede open-weight-modeller til reguleret oversættelse forklarer, hvorfor en tilpasset model slår en standardmaskine på denne slags kontrolleret indhold.
3. Kør AI-oversættelsen på en klienttilpasset model
Generér udkastet på en model, der allerede rummer din terminologi, ikke på en offentlig chatbot. Vi kører klienttilpassede open-weight-modeller på EU-hostet infrastruktur, afgrænset af din termbase og dit Translation Memory, hvor intet sendes til offentlige cloud-værktøjer. Sikkerhedsdokumentation før udgivelse bærer ofte endnu ikke annoncerede produktdetaljer, så de samme residenskontroller, vi anvender på elektronik-datablade og indlejret software og på sikker oversættelse med EU-dataresidens, gælder også her.
4. Lad en ingeniør gennemgå hver sikkerhedspåstand
Dette er det trin, der gør outputtet brugbart, og det kræver en certificeret ingeniør-lingvist frem for en almindelig korrekturlæser. Korrekturlæseren tjekker:
Hver sikkerhedspåstand og hver instruktion om en sikker tilstand, mod kilden og mod termbasen.
Hvert SIL- og ASIL-mærke, så et niveau aldrig skrider mellem kilde og oversættelse.
Hvert tal, hver enhed og hver tolerance i en fareanalyse, FMEA- eller FMEDA-tabel.
Hver betingelse, så "må ikke" aldrig læses som "må", og en påkrævet handling aldrig ser valgfri ud.
Dette er fuld menneskelig post-editing under ISO 18587, hvor korrekturlæseren tager ansvaret for den endelige tekst. En sikkerhedspåstand sendes aldrig afsted på maskinoutput alene, og den regel bøjer sig ikke for en deadline.
5. Tjek tilbage mod kilden
At tjekke tilbage er en anden gennemlæsning mod den frosne kilde, ikke en stavekontrol. Korrekturlæseren går oversættelsen igennem ved siden af kilden og bekræfter, at hver advarsel, hver værdi og hver krydshenvisning stemmer, for et tabt decimal eller en vendt betingelse i en sikkerhedstabel er den fejl, der overlever en flydende læsning. På et stort program udfører en uafhængig lingvist tilbagetjekket, så den person, der bekræfter outputtet, ikke er den, der lavede det. Det samme uafhængige gennemløb bruger vi på arbejde med høj eksponering som dokumentation for EV-batterier og ladeinfrastruktur.
6. Arkivér versionen med dens korrekturlæser
Luk hver sprogversion ind i et arkiv, der registrerer den frosne kilderevision, korrekturlæseren og hver ændring. Spørger en auditor, en assessor eller en kunde, hvilken tekst der gik til hvilket marked, svarer du ud fra loggen frem for ud fra hukommelsen. Opbevaringslogikken matcher pligten i EU's maskinforordning til at bevare brugsanvisninger i udstyrets forventede levetid, og den fortsætter direkte ind i oversættelse af forsvarsteknisk dokumentation, hvor sporbarhed er et kontraktvilkår, ikke en præference.
Hvor det går galt
De fleste fejl i oversættelse om funktionel sikkerhed kan føres tilbage til et oversprunget trin. De hyppigste:
At oversætte fra en kilde, der stadig var i bevægelse, så den leverede manual citerer en revision, der ikke længere findes.
At køre en generisk maskine uden termbase, så en sikker tilstand eller et SIL-mærke skrider mellem sprog.
At lade en almindelig korrekturlæser godkende en sikkerhedssag, så en vendt betingelse i en advarsel når produktionen.
At sende sikkerhedsdokumentation før udgivelse gennem offentlige cloud-værktøjer, så endnu ikke annoncerede produktdetaljer forlader din kontrol.
At føre intet versionsarkiv, så du ikke kan vise en assessor, hvilken tekst der gik til hvilket marked.
Hver af disse kan undgås med kilden frosset først og gennemgangen ejet af en certificeret ingeniør. Det dokument, der fortæller nogen at handle, er det, der aldrig sendes afsted på maskinoutput alene.
Vores oversættelsestjenester til funktionel sikkerhed
Vores oversættelsestjenester til regulerede sektorer kører på ISO 27001- og ISO 42001-certificeret, EU-hostet infrastruktur, uden afhængighed af offentlige cloud-værktøjer til kernebehandlingen. Hvert projekt løber gennem vores AI+HUMAN hybride workflow: vi indlæser først klientens Translation Memories og termbaser, vores egenudviklede LLM-baserede LangOps System genererer output afgrænset af klientterminologi på klienttilpassede open-weight-modeller, og vores certificerede fageksperter gennemgår for teknisk nøjagtighed og regulatorisk overholdelse. Vores QA er afstemt efter ISO 17100 og ISO 18587, med sektorspecifikke krav som funktionel sikkerhed under IEC 61508 og køretøjssikkerhed under ISO 26262, hvor det er relevant, og den samme disciplin strækker sig til vores sikre oversættelses-workflows med EU-dataresidens. Vi betjener kunder inden for Life Sciences, Legal, Finance, Forsvar og Manufacturing på over 150 sprog med mere end 3.500 faglingvister. For teams, der oversætter en sikkerhedssag eller et FMEA-sæt, kontakt os for at drøfte din terminologi, gennemgang og arkivering direkte.
FAQ
Kan AI-oversættelse bruges til dokumentation om funktionel sikkerhed?
Ja, når en certificeret ingeniør gennemgår outputtet. AI-dokumentoversættelse leverer udkastet hurtigt, men under disciplinen fuld menneskelig post-editing i ISO 18587 tager en kvalificeret korrekturlæser ansvaret for den endelige tekst. En sikkerhedspåstand sendes aldrig afsted på rå maskinoversættelse alene.
Certificerer IEC 61508 eller ISO 26262 et oversættelsesbureau?
Nej. IEC 61508 og ISO 26262 certificerer kundens sikkerhedsrelaterede produkt og udviklingsproces, ikke en oversættelsesleverandør. Intet oversættelsesbureau har en "IEC 61508-certificering" eller "ISO 26262-certificering". Hvad en leverandør kan have, er ISO 17100 og ISO 18587, plus ingeniører, der gennemgår hver sikkerhedspåstand.
Hvad er forskellen på SIL og ASIL?
SIL, Safety Integrity Level fra 1 til 4, kommer fra IEC 61508 og gælder for elektriske, elektroniske og programmerbare elektroniske sikkerhedssystemer. ASIL, Automotive Safety Integrity Level fra A til D, kommer fra ISO 26262 og gælder for vejkøretøjer. ISO 26262 er den automotive tilpasning af IEC 61508, så begreberne flugter, mens mærkerne og livscyklussen adskiller sig.
Hvilke dokumenter om funktionel sikkerhed skal oversættes?
Typisk sikkerhedsmanualen, sikkerhedssagen, fare- og risikoanalyser, FMEA- og FMEDA-tabeller, verifikations- og valideringsrapporter samt de sikkerhedsrelaterede dele af brugsanvisningen. Ethvert dokument, der fremsætter en sikkerhedspåstand eller fortæller en læser at handle, oversættes og gennemgås derefter af en certificeret ingeniør.
Hvorfor skal kildeteksten fryses, før der oversættes?
Fordi en sikkerhedssag bliver ved med at ændre sig, mens ingeniørarbejdet lukker fund, og en kilde i bevægelse giver en oversættelse, der citerer en revision, der ikke længere findes. At fryse den præcise revision, med dokumentnummer og dato, er det første trin, og enhver senere ændring behandles som en ny revision med sin egen gennemgangscyklus.
Er maskinoversættelsesoutput acceptabelt for en sikkerhedssag?
Ikke i sig selv. Maskin- eller LLM-output kan være udkastet, men ISO 18587 kræver fuld menneskelig post-editing af en kvalificeret korrekturlæser, der tager ansvaret for resultatet. For en sikkerhedssag betyder det, at en certificeret ingeniør tjekker hver sikkerhedspåstand, hvert SIL- eller ASIL-mærke og hvert tal mod den frosne kilde.
