Valtaosaa NATO-jäsenmaiden armeijoille tällä hetkellä tarjottavasta puolustusteknologiasta ei ole koskaan otettu käyttöön todellisissa taisteluoperaatioissa. Se on kehitetty, testattu valvotuissa ympäristöissä, esitelty arviointilautakunnille ja sertifioitu vaatimusten mukaiseksi. Tämä ei ole sama asia kuin taistelutodistettu — ja ero merkitsee tavoilla, joita on vaikea mitata etukäteen mutta jotka tulevat tuskallisen selvästi esiin käyttöönoton jälkeen.

Vuodesta 2022 lähtien Ukrainasta on tullut maailman aktiivisin puolustusteknologian testausympäristö. Konfliktin intensiteetti, kesto ja vertaisvastustajan luonne on paljastanut sotilasohjelmistojen vikatiloja, joita vuosien harjoitukset ja esittelyt eivät olleet tuoneet esiin. Selviytyneet ja hyödyllisiksi osoittautuneet järjestelmät ovat laadullisesti eri kategoriaa kuin ne, jotka eivät selvinneet.

Mitä "taistelutodistettu" todellisuudessa tarkoittaa

Taistelutodistettu ei tarkoita taisteluissa todistettua siinä mielessä, että se olisi osallistunut kineettisiin yhteenottoihin. Se tarkoittaa, että ohjelmistoa ovat käyttäneet todelliset sotilaskäyttäjät todellisissa operatiivisissa olosuhteissa, todellisen operatiivisen paineen alaisena, pitkän aikaa — ja esiin tulleet vikatilat on tunnistettu, korjattu ja korjaukset on testattu uudelleen samoissa olosuhteissa.

Tämä on kumulatiivinen ominaisuus. Ohjelmistojärjestelmä kerää operatiivista kokemusta sitä kautta, että se otetaan käyttöön, se pettää, nuo viat diagnosoidaan ja korjataan, se otetaan uudelleen käyttöön ja tämä sykli toistuu. Tuloksena on järjestelmä, jonka reunatapaukset on löydetty ja käsitelty — ei siksi, että kehittäjät olisivat ennakoineet ne, vaan siksi, että operatiivinen todellisuus toi ne esiin. Mikään määrä vaatimusanalyysiä tai testaussuunnittelua ei luotettavasti tuo esiin kaikkia reunatapauksia, joita todelliset operaatiot tuottavat.

Laboratoriotestattu järjestelmä on sen sijaan testattu vaatimusmäärittelyä vasten ja todettu sen mukaiseksi. Määrittelyn kirjoittivat ihmiset, jotka ennakoivat, miten järjestelmää käytettäisiin ja mitä olosuhteita se kohtaisi. Ero tuon ennakoinnin ja operatiivisen todellisuuden välillä on useimpien todellisten puolustusohjelmistojen vikojen lähde.

Ukraina: maailman aktiivisin puolustusteknologian testausympäristö

Useat ominaisuudet tekevät Ukrainan konfliktista ainutlaatuisen arvokkaan teknologian testausympäristönä. Ensinnäkin tahti: konfliktissa on nähty pitkäkestoisia korkean intensiteetin operaatioita sellaisella tempolla, jota harjoitukset eivät pysty jäljittelemään, mikä tuottaa vuosien edestä operatiivista käyttöä kuukausissa. Toiseksi vastustajan kehittyneisyys: venäläinen elektroninen sodankäynti, kyberoperaatiot ja lennokintorjuntakyvyt ovat testanneet puolustusteknologioita vertaistason vastustajaa vasten — eivät välikäden tai epäsymmetrisen uhan kautta. Kolmanneksi palautesilmukan nopeus: konfliktissa toimivat organisaatiot ovat olleet poikkeuksellisen halukkaita antamaan suoraa teknistä palautetta, mikä mahdollistaa nopean iteroinnin.

Tämän ympäristön konkreettiset opit ovat selkeitä. Johtamis- ja hallintaohjelmisto, joka toimi luotettavasti prikaatitason harjoituksissa, petti pataljoonien käyttäessä sitä tulen alla, koska operatiivisen paineen alainen käyttäjäjoukko on vuorovaikutuksessa ohjelmiston kanssa eri tavalla kuin koulutetut operaattorit harjoitusympäristössä. Logistiikkasovellukset, jotka toimivat hyvin yhteyksiltään varmistetuissa ympäristöissä, pettivät välittömästi, kun venäläinen elektroninen sodankäynti häiritsi viestintää kiistanalaisilla alueilla. Lennokkien ohjausohjelmisto, joka toimi moitteettomasti matalan viiveen yhteyksillä, petti toimittaessa heikentyneiden yhteyksien yli — paljastaen, että ohjelmisto oli implisiittisesti olettanut luotettavan yhteyden tasolla, jota määrittely ei vaatinut mutta johon kehittäjät olivat luottaneet.

Vikatilat, jotka ilmenevät vain todellisissa operaatioissa

Verkon heikkenemisen käsittely. Operatiivisten käyttöönottojen johdonmukaisin havainto on, että riittävän yhteyden oletuksella suunniteltu ohjelmisto pettää hallitusti simulaatioissa ja katastrofaalisesti operaatioissa. Todelliset taktiset verkot toimivat 10–30 %:lla siitä kaistanleveydestä, joka on käytettävissä varuskunta- tai harjoitusympäristössä. Sovellukset, jotka tekevät kymmeniä API-kutsuja yhtä käyttäjän vuorovaikutusta kohti tukeakseen yhtä näytön päivitystä — kaupallisessa web-kehityksessä tavanomaista — muuttuvat käyttökelvottomiksi ruuhkautuneessa taktisessa radioverkossa. Tämä vikatila jää lähes koskaan kiinni testauksessa, koska testausympäristöillä on poikkeuksetta paremmat yhteydet kuin operatiivisilla ympäristöillä.

Operaattorin stressi ja virheensietokyky. Todelliset operaattorit stressin alaisena käyttävät ohjelmistoa eri tavalla kuin koulutetut operaattorit valvotuissa olosuhteissa. He painavat painikkeita useita kertoja, koska he eivät ole varmoja, rekisteröityikö ensimmäinen painallus. He keskeyttävät pitkään kestäviä toimintoja. He valitsevat vääriä vaihtoehtoja ja tarvitsevat kumoamista. He tekevät asioita, joita kehittäjä ei koskaan ennakoinut. Ohjelmisto, josta puuttuu vankka virheenkäsittely ja palautuminen keskeytetyistä toiminnoista, pettää tavoilla, joita laboratoriotesti ei saa kiinni, koska laboratoriotestaaja noudattaa odotettua työnkulkua ja tuntee järjestelmän riittävän hyvin välttääkseen useimmat sudenkuopat.

Vastustajan häirintä. Vastustajat pyrkivät aktiivisesti häiritsemään ohjelmistojärjestelmiä — häirinnällä (vaikuttaen yhteyksiin ja GPS:ään), huijauksella (syöttämällä väärää dataa) ja kyberhyökkäyksillä (hyödyntämällä haavoittuvuuksia). Järjestelmää, jota ei ole koskaan käytetty vastustajan kiistämässä ympäristössä, ei ole koskaan testattu sen kestävyyden osalta näitä uhkia vastaan. Testausympäristö tarjoaa puhtaan signaalin; operatiivinen ympäristö tarjoaa vihamielisen.

Miksi laboratorioesittelyt voivat olla harhaanjohtavia

Esittely on suunniteltu näyttämään järjestelmä parhaimmillaan: oikein konfiguroituna, sen hyvin tuntevien ihmisten käyttämänä, luotettavassa verkossa, valmiiksi valittuja skenaarioita vasten. Kaikki olosuhteet ovat suotuisat. Hyvin sujuva esittely on todiste siitä, että järjestelmä kykenee toimimaan oikein ihanteellisissa olosuhteissa. Se ei ole todiste siitä, että järjestelmä toimii oikein operatiivisissa olosuhteissa, jotka eivät ole ihanteellisia.

Useimmissa puolustushankintaprosesseissa käytetyt arviointikriteerit palkitsevat esittelysuoritusta operatiivisen kestävyyden sijaan. Ominaisuudet arvioidaan; vioista palautuminen ei. Käyttöliittymän reagointikyky valvotussa ympäristössä arvioidaan; toiminta kiistanalaisten yhteyksien alaisena ei. Tuloksena on hankintaprosessi, joka järjestelmällisesti suosii hyvin esittelyssä toimivia järjestelmiä operaatioissa hyvin toimivien järjestelmien sijaan.

Keskeinen oivallus: Hankinnassa esitettävä kysymys ei ole "voitteko osoittaa, että tämä toimii?" — jokainen toimittaja osaa osoittaa sen. Kysymys on: "missä tämä on otettu operatiiviseen käyttöön, kuinka pitkäksi aikaa ja mitä vikoja ilmeni? Mitä opitte ja mitä muutitte?" Vastaus tuohon kysymykseen erottaa taistelutodistetun laboratoriotestatusta.

Mitä hankintapäälliköiden tulisi kysyä operatiivisesta historiasta

Useat tarkat kysymykset erottavat taistelutodistetut toimittajat laboratoriotestatuista — ja vastaavat sitä, mitä käsittelemme yksityiskohtaisesti oppaassamme siitä, miten valita puolustusohjelmistotoimittaja. Ensinnäkin: nimeä operatiiviset käyttöönotot — ei pilotteja, ei proof-of-concept-toimeksiantoja, vaan todellisia operatiivisia käyttöönottoja todellisia tehtäviä suorittaville yksiköille. Kuinka kauan nuo käyttöönotot ovat olleet käynnissä? Mitä ongelmia operatiiviset käyttäjät raportoivat (eivät ohjelmapäällikkö, vaan todelliset käyttäjät)? Mitä muutoksia tehtiin niiden seurauksena?

Toiseksi: mikä on järjestelmän toiminta, kun verkko ei ole käytettävissä 30 minuuttiin? 8 tuntiin? Mitä käyttäjä näkee? Mitä dataa säilytetään? Tämä kysymys, esitettynä tekniselle johtajalle myyntitiimin sijaan, paljastaa nopeasti, onko operatiivinen kestävyys ajateltu läpi vai oletettu.

Kolmanneksi: kuvaile tietty operatiivinen vika ja mitä teitte sen suhteen. Toimittaja, joka ei osaa kuvailla tiettyä vikaa, ei joko ole käyttänyt järjestelmäänsä operatiivisesti tai ei ole rehellinen. Operatiivinen käyttöönotto tuottaa vikoja. Kokeneilla toimittajilla on kokoelma tarkkoja vikadiagnooseja ja niiden korjaamiseksi tehtyä insinöörityötä. Tämä kokoelma on todellinen todiste taistelutestauksesta — ei ominaisuuslista, ei esittely, ei sertifikaatti.