Enhet 1 / 11

Introduksjon til kunstig intelligens og sikkerhetskritisk verifikasjonsdisiplin i romfart

Gevinster:

  • Evne til å skille hvor AI sparer sanntid i arbeidsflyten for romfartsteknikk og hvilke beslutninger som bør forbli hos mennesker av sikkerhets- og ansvarsgrunner
  • Evne til å anvende en sikkerhetskritisk disiplin som verifiserer hver ingeniørleveranse etter størrelsesorden, enhetskonsistens og uavhengig reproduksjon
  • Evne til å bli vane med å spørre ved å anonymisere kontekst for å beskytte ITAR/EAR eksportkontroll og konfidensielle designdata

Se på skrivebordet til en luftfartsingeniør: vingelastberegninger, endelige elementresultater, vindtunneldata, flytestrekorder, sertifiseringsdokumenter, leverandørkorrespondanse og endeløse møter. Tiden viet til den faktiske ingeniørdommen, det vil si spørsmålene "er dette tallet trygt, vil dette designet fly, er denne risikoen akseptabel?" er knust under det repeterende regne- og dokumentarbeidet. Det er her kunstig intelligens (forkortet AI; programvare som fungerer på tekst, kode og tall med en stor språkmodell og maskinlæring) spiller inn. AI tar ikke avgjørelsen for deg; Den forbereder deg på beslutningen, produserer et utkast, setter fart på beregningen og legger bearbeidet informasjon foran deg.

Imidlertid er luftfart og romfart et felt der feil ikke måles i tekst, men i liv og millioner av dollar. En referanse laget av en språkmodell, en feil enhetskonvertering eller et "rimelig utseende" men fysisk umulig resultat kan være en liten løsning i andre bransjer, men her kan det bli en strukturell feil eller oppdragstap. Det er grunnen til at vi gjennom denne modulen vil posisjonere AI ikke som en "automatisk ingeniør", men som en assistent underlagt sikkerhetskritisk disiplin hvis utgang blir verifisert hver gang.

I denne første enheten avklarer vi tre ting: på hvilke stadier av arbeidsflyten for romfart tilfører AI reell verdi, hvilke beslutninger må forbli strengt i hendene på kvalifiserte mennesker, og hvilken verifisering, eksportkontroll og konfidensialitetsdisiplin du må følge når du gjør det. Uten dette taket installert på riktig måte, kan teknikker på etterfølgende enheter bli farlige.

Konsepter: Hallusinasjon: AIs overbevisende fremstilling av et tall, ligning, standardelement eller kilde som faktisk ikke eksisterer. Kontekst: Innspillet du gir til AI (designdata, antagelser, spørsmål). Verifikasjon: Kontrollere utdata på en uavhengig måte (håndberegning, andre verktøy, standardtekst). Disse tre konseptene er ryggraden i hele modulen.

I hvilke virksomheter er AI Accelerator, i hvilke virksomheter er det risikabelt?

Luftfartsoppdrag faller på et todelt spekter når det gjelder konsekvensene. I den ene enden er det gjenfinnbare, lavrisiko forberedelser (et litteratursammendrag, et kodeskjelett, en presentasjonsoversikt); I den andre enden er det irreversible beslutninger (en sikkerhetskoeffisient, en kontrolllov, en orbital brenntid) som direkte bestemmer luftdyktighet, livssikkerhet og oppdragssuksess. Verdien av AI varierer avhengig av hvor du står på dette spekteret.

virksomhetstype

AI-bidrag

Ingeniørens rolle

Litteratur/standard oppsummering

Trekker ut utdrag fra langt dokument

Sammenlign artikkelen med originalteksten

Håndberegning / forhåndsdimensjonering

Formelinnstilling, første nummer

Enhets-, rang- og forutsetningskontroll

Analysekode / skripting

Skjelett- og logikkgenerering

Validering med testinngang, enhetstesting

Rapport/kravutkast

Foreslå struktur og fortelling

Koble hvert uttrykk til ressursen og kravet

Dataanalyse / anomaliskanning

Mønster- og kandidathendelsesutvinning

Bekreftelse med rådata og fysikk

Beslutning om sikkerhet/sertifisering

Utarbeidelse av analysemateriale

Sluttvurdering, gjennomgang og underskrift

Regelen er enkel: risikoen for en AI-utgang er lik skaden den vil pådra seg hvis utgangen gjør en feil. Å feilstave tittelen på et lysbilde er ufarlig; Å beregne sikkerhetskoeffisienten til en vingespeil som 0,5 i stedet for 1,5 er en katastrofe. Så det første spørsmålet å stille før du bruker utdataene er: "Hva skjer hvis dette er feil, hvem blir skadet, og hvem legger merke til det?"

Oppmerksomhet: AI produserer flytende og selvsikker tekst. Flytende er ingen garanti for nøyaktighet. En språkmodell fyller gapet med statistisk "mest sannsynlige" ord, selv om den ikke har eksakte data; Innen luftfart kan denne fyllingen oppstå som en sammensatt materialspesifikasjon eller en ikke-eksisterende FAR-klausul.

Sikkerhetskritisk verifikasjonsdisiplin: Tre lag

Luftfartskulturen er allerede bygget på prinsippet om «trust but verify»; AI bør brukes til å styrke dette prinsippet, ikke svekke det. Før hver AI-utgang gjennom et trelagsfilter.

Det første laget er størrelsesordenskontroll. Se om resultatet er omtrent innenfor den forventede potensen på 10-området. Startmassen til et passasjerfly er i størrelsesorden titalls tonn; Hvis AI forteller deg 800 kg, vet du at det er en feil uten å gå i detalj.

Det andre laget er enhet og størrelse konsistens. En av de dyreste feilene i luftfartshistorien er Mars Climate Orbiter-tapet i 1999: ett lag brukte pund-sekunder, det andre newton-sekunder, og romfartøyet på rundt 327 millioner dollar gikk tapt i Mars-atmosfæren. I AI-utgangen bør enheter angis tydelig og dimensjonsanalyse bør utføres.

Det tredje laget er uavhengig reproduksjon. Gjengi et kritisk resultat med en annen metode (en annen manuell konto, et separat verktøy eller en annen ingeniør). Tilliten øker hvis to uavhengige veier gir samme svar; Hvis det ikke gjør det, stopp til du forstår hvorfor det er annerledes.

Tips: Når du spør AI om et resultat, spør også det samme spørsmålet omvendt. Si "beregn plassen som kreves for denne vingen", og si deretter "beregn vingebelastningen tilbake med plassen du ga den og sammenlign den med den typiske ruteavstanden." Å be modellen om å krysssjekke sin egen utgang gjør stille feil synlige.

Eksportkontroll og personvern: Luftfarts private grense

Luftfartsteknologi er underlagt eksportkontroll i de fleste land. I USA er dette styrt av ITAR (International Traffic in Arms Regulations) og EAR (Export Administration Regulations) (regler som regulerer teknologi for dobbeltbruk). Å legge inn en klassifisert missilkontrollalgoritme, satellittfremdriftsdata eller militærflyytelsesparameter i en ukontrollert ekstern AI-tjeneste kan være både et eksportbrudd, tap av intellektuell eiendom og kontraktsbrudd.

Tommelfingerregel: skriv aldri inn ekte, konfidensielle eller kontrollerte tekniske data i et ikke-godkjent eksternt verktøy. Anonymiser i stedet konteksten og erstatt reelle tall med representative verdier. For eksempel, i stedet for å dele en faktisk motortrykkkurve, spør "beskriv den generelle formen for et typisk turbofan skyvekraft-hastighetsforhold."

Svak forespørsel / Sterk forespørsel

De følgende to meldingene har samme formål, men den ene bryter både konfidensialitet og mottar et ukontrollerbart svar.

Svak melding:

Det ubemannede XR-7 kjøretøyet i vårt prosjekt har et vingespenn på 4,2 m, vekt på 38 kg, motor og hastighetskonvolutt. Fortell meg den optimale høyden.

Kraftig ledetekst:

Rolle: Du er aerodynamisk konsulent innen luftfart. Kontekst: Jeg gjør en generell analyse for en liten fastvinget UAV (verdier er representative, ikke faktiske prosjektdata): vingespenn ~4 m, masse ~40 kg, cruisehastighet ~25 m/s. Oppgave: Forklar de fysiske prinsippene som bestemmer den beste rekkeviddehøyden og oppgi hvilke parametere jeg bør måle. Begrensning: Skriv hver formel og antagelse tydelig; Hvis du gir et numerisk resultat, spesifiser enheten og legg til hvordan du bekrefter den.

Den kraftige ledeteksten beskytter de faktiske prosjektdataene, klargjør rollen og begrensningen og ber om en verifiseringsbane.

Kopierbare ledetekstmaler

Du kan bruke de fire malene nedenfor ved å tilpasse dem til din egen virksomhet. De bygger alle inn disiplinen anonymisering og verifisering.

Mal 1 — Obligatorisk forespørsel om validering for sikkerhetskritisk utdata:

Rolle: Du er senior luftfartsingeniør og passer inn i den sikkerhetskritiske disiplinen.Kontekst: [Anonymisert problem; representative verdier, ikke faktiske prosjektdata].Oppgave: [Analysen/beregningen jeg vil ha].Begrensning:- Skriv enheten til hvert tall.- Skriv tydelig opp hver formel og antakelse du bruker.- Sammenlign størrelsesrekkefølgen på resultatet med en kjent referanse.- I det siste trinnet, gi en kontrollplan som sier "hvordan verifiserer jeg denne utgangen uavhengig". Hvis det er usikkerhet, ikke gjett; Spør hvilke data du trenger.

Mal 2 – Krysssjekk (modellen tester sin egen utgang):

Beregn nå [resultat]-verdien du nettopp ga ved å bruke en uavhengig metode: bruk en annen formel eller invers løsning. Stemmer de to resultatene? Hvis ikke, oppgi mulige feilkilder (enhet, antakelse, formelvalg). Merk trinnet du ikke er sikker på.

Mal 3 – Verifiserbar forespørsel om standard-/kildeattribusjon:

List opp de relevante sertifiserings-/standardstoffene for [emne]. For hvert stoff: standardnavn, stoffnummer og sammendrag av stoffet. ADVARSEL: Ikke skriv et stoffnummer hvis du er usikker. Merk den som "må verifiseres". Gi oppdiktede referanser; Hvis du ikke vet, fortell meg at du ikke vet. Fortell meg også hvordan jeg bekrefter disse elementene fra den opprinnelige teksten.

Mal 4 – Anonymisering forhåndssjekk (før deling):

Jeg må slette følgende tekst for eksportkontroll (ITAR/EAR) og bedriftskonfidensialitet før jeg legger den inn i et eksternt AI-verktøy. Flagg potensielt sensitive elementer i teksten (faktiske delenummer, ytelsesverdier, prosjektnavn, leverandørinformasjon) og foreslå en representant/anonym erstatning for hver. Tekst: [lim inn her]

Minivesker

Sak 1 – Konstruert standardklausul. For å støtte en designbegrunnelse, spør en junioringeniør AI "hvilken FAR-klausul pålegger dette?" AI siterer en "FAR 25.1493"-klausul som faktisk ikke eksisterer. Når ingeniøren sammenligner teksten med den opprinnelige forskriften, ser han at klausulen er fabrikkert og finner den riktige klausulen (14 CFR 25.303, sikkerhetsfaktor). Leksjon: Hver standardreferanse gitt av AI er verifisert fra originalteksten.

Tilfelle 2 — Enhetsfelle. Et team får hjelp av AI i en skyvekraftberegning. AI gir skyvekraften til 5000, men enheten "lbf eller N" forblir uklar. Det er omtrent 4,45 ganger forskjell mellom 5000 lbf og 5000 N; Denne forskjellen endrer valget av en motor fullstendig. Hvis mannskapsenheten fortsetter uten å spørre eksplisitt, vil den gå til feil motorklasse. Leksjon: et hvilket som helst tall uten en enhet godtas ikke.

Tilfelle 3 — Rangeringskontroll redder liv. Et team av studenter fikk AI til å beregne delta-v (krav til hastighetsendring) for raketten og fikk resultatet på 95 m/s. Typisk delta-v for å nå lav bane er omtrent 9,4 km/s, dvs. i størrelsesorden 9400 m/s. En forskjell på rundt 100 ganger viser umiddelbart en redigeringsfeil; elevene finner grunnlogaritmefeilen i ligningen. Leksjon: sammenlign alltid resultatet med et kjent referanseområde.

Vanlige feil

  • Ta feil av flyt for nøyaktighet. En velskrevet forklaring kan være numerisk feil. Kvaliteten på teksten og nøyaktigheten av resultatet er to forskjellige ting.
  • Godta et enhetsløst nummer. I luftfart er et nummer som ikke spesifiserer en enhet et udefinert tall. lbf/N, ft/m, knot/m·s forvirring er karriereavsluttende feil.
  • Legge inn konfidensielle data i eksternt verktøy. brudd på ITAR/EAR og selskapets konfidensialitet; Når de er lekket, kan ikke tekniske data hentes.
  • Stoler på en enkelt kilde. Å bruke et kritisk resultat uten å produsere det på en annen måte er å bryte med den mest grunnleggende regelen i den sikkerhetskritiske disiplinen.
  • Ikke bekrefter standard attribusjon. Varenumrene gitt av AI kan være falske; Hver referanse er bekreftet fra den opprinnelige forskriften.

Oppsummert

AI øker dramatisk det repeterende arbeidet med beregninger, kode, dokumenter og data innen romfartsteknikk; men beslutningene som bestemmer sikkerhet, luftdyktighet og oppdragssuksess forblir hos den kvalifiserte personen. Hver utgang må filtreres gjennom størrelsesorden, enhetskonsistens og uavhengig reproduksjon. Av hensyn til eksportkontroll (ITAR/EAR) og konfidensialitet, bør faktiske tekniske data anonymiseres og kun godkjente verktøy skal brukes. Denne disiplinen er en forutsetning for alle påfølgende enheter.

Søknadsoppgave

Velg et ingeniørspørsmål fra ditt felt (aerodynamikk, struktur, kontroll, romfart, produksjon). Skriv først en "svak melding" og spør AI-en; Skriv deretter en "power prompt" som inkluderer rollen, anonymisert kontekst, begrensning og bekreftelsesforespørsel, og still det samme spørsmålet igjen. Sammenlign de to svarene når det gjelder størrelsesorden og enhetskonsistens og bekreft minst ett resultat ved en uavhengig håndberegning. Oppsummer funnene dine på en halv side.

sjekkliste

  • [ ] Jeg evaluerte risikoen ved utgangen med spørsmålet "hvem blir skadet hvis det er feil?"
  • [ ] Jeg sammenlignet resultatet med en kjent referanse når det gjelder størrelsesordener.
  • [ ] Jeg har tydelig bekreftet enheten for alle tall.
  • [ ] Jeg reproduserte det kritiske resultatet ved en annen uavhengig metode.
  • [ ] Jeg brukte anonymisert representativ verdi i stedet for ekte/konfidensielle tekniske data.
  • [ ] Jeg har verifisert hver standard/kildehenvisning gitt av AI fra originalteksten.