F-35:n softapuolesta minulla on hiukan kutku, että Lockheed on sotakonepuolella samaa kuin Nokia oli matkapuhelinpuolella kymmenisen vuotta sitten. Lockheedin etu Nokiaan nähden on se, että taustalla oleva valtio estää tehokkaasti markkinaa menemästä uusiksi samalla tavalla kuin Nokialle kävi paria vuotta myöhemmin.
Mielenkiintoinen vertaus, mutta se vähän ontuu siinä, että Nokia joutui oman osaamisalueensa ulkopuolelle kun puhelimet muuttuivat tietokoneeksi kilpailijoiden toimesta. LM taas on itse ollut ajamassa disruptiota luomalla ensimmäisiä moderneja, ohjelmistopohjaisia ja modulaarisia avioniikkajärjestelmiä F-22:een. Tässä analogiassa LM teki älypuhelimen jo 80-luvulla, ja muut yrittävät Nokian tavoin muuttaa olemassa olevia feature phoneja älypuhelimiksi lisäämällä niihin selaimen.
Tässä on myös se ero, että niin F-22:n kuin F-35:n tapauksessa Lockheed on ensisijaisesti järjestelmäintegraattori, ja osa koodista tulee alihankkijoilta, esim. Boeingilta.
Jostain syystä F-35:n ohjelmisto on ihan hirveän monoliittinen.
Itse asiassa ei ole...
En tiedä onko siellä kriittinen FCS ja muu primäärikoodisto eristetty muusta koodista tarpeeksi selkeästi, jotta muutoksia voi todella tehdä vähän nopeammin joskus myöhemmin.
...ja on. Jo F-22:n arkkitehtuuri oli modulaarinen ja pitkälle osioitu, mistä sitä on F-35:ssä viety eteenpäin. Koodi on abstraktoitu laitteistosta virtuaalikoneilla ja moduulirakenne on löyhästi sidoksissa middleware-pohjaisella arkkitehtuurilla. Myös ohjelmistopuolella on käytetty mahdollisimman paljon COTS-komponentteja kehityksen nopeuttamiseksi ja suurin osa ei-lentokriittisestä koodista tehdään C++:lla Ada:n sijaan kehityksen nopeuttamiseksi. (Tuosta miten C++:aa kehitettiin avioniikkastandardit täyttäväksi kielen kehittäjän kanssa löytyy mielenkiintoista juttua netistä, samoin kuin sen testaamisesta)
Teknisesti ohjelmistoarkkitehtuuri on selkeästi edellä muita, ainoastaan Gripen E ja jossain määrin SH Block II/III ovat pääsemässä samalle tasolle. Kyllä ne ongelmat taitavat olla jossain muualla kuin teknologiassa, kuten ohjelmistoprojekteissa yleensä, eli resursoinnissa, priorisoinnissa ja validoinnissa.
F-35:n ohjelmistokehitys oli myönnetysti aliresursoitu ja ylioptimistisesti aikataulutettu pitkän aikaa, mistä tunnetusti seuraa teknistä velkaa ja ongelmia tulevaisuudessa. Tämä yhdistettynä ohjelmiston kompleksisuuteen, joka on moninkertainen aiempiin/muihin hävittäjiin nähden, hidastaa väistämättä kehitystä pitkäksi aikaa, vaikka resursseja myöhemmin lisättäisiinkin, kun suuri osa resursseista kuluu kertautuneisiiin vanhojen virheiden paikkaamiseen.
Mitenkään kehumatta mitään muita valmistajia samaan aikaan. Joku MIL-speksi tällä luultavasti estää tekemästä työtä järkevästi.
Mil-speksit ja avioniikkastandardit yhdessä, veikkaisin. Minulla on hieman kokemusta tosiaikaisen ja tiukasti standardoidun koodin ohjelmistoprojektista, ja oma näppituntuma on että kehityksen nopeus on 5-10x hitaampaa kuin tavallisesti. Standardit edellyttävät kaikkien muutosten integraatio- ja hyväksymistestausta ja auditointia, joten vaikka ohjelmisto olisi kuinka modulaarista, vaatimukset ja prosessit niin toteuttajan, käyttäjän kuin viranomaisen puolelta estävät koodin nopean käyttöönoton. Veikkaan että mil-puolelle auditointia tehdään vielä jokaisen tahon ja viraston puolelta erikseen.
On tähän jonkun verran muutosta nähtävissä. MoD on perustanut oman nopeiden muutosten prototypointiin keskittyvän tiimin Typhoonille ja F-35:lle. Sekä Saab että LM ovat ilmoittaneet siirtyvänsä ketterämpään ohjelmistokehitykseen, F-35:ssä tuotekehitysvaiheen jälkeen siirrytään C2D2-malliin jossa muutoksia voidaan tuoda sisään blokkien välissä. F-35:n auto-GCAS on ensimmäisiä esimerkkejä tästä suunnasta, se tuodaan nopeutetusti tuotantoon jo ensi vuonna, kun alkuperäinen suunnitelma oli Block 4:ssä noin viiden vuoden päästä.
