Osat 1 ja 2 tuottivat luotettavia ratoja. Osa 3 rakentaa pinnan, jonka operaattori oikeasti näkee. Yhteinen operatiivinen kuva on se kerros, jonka perusteella alustaa arvioidaan — tee se oikein ja anteeksianto virtaa alas muun stackin läpi; tee se väärin ja teknisesti oikea fuusioputkisto poistetaan käytöstä operaatioiden toisella viikolla. Arkkitehtuurikuviot ovat vakiintuneet (katso Yhteinen operatiivinen kuva: Miten se rakennetaan modernissa puolustusohjelmistossa); osa 3 muuntaa ne konkreettisiksi insinöörillisiksi päätöksiksi.
Vaihe 1: Käyttöliittymäpino
Juoksevassa esimerkkialustassa COP on selainpohjainen sovellus. Valinta natiivin ja webin välillä on ratkaistu webin hyväksi yli vuosikymmenen ajan; jäljelle jäänyt natiivi jalanjälki on erikoistuneissa kädessä pidettävissä alustoissa (ATAK-ekosysteemi — katso ATAK-liitännäiskehitys) eikä komentopaikkanäytöissä.
Puolustettava pino:
- React TypeScriptillä sovelluskuorelle. Ekosysteemin kypsyys, rekrytointisaatavuus ja akkreditointiystävälliset työkalut tekevät siitä turvallisen valinnan 20 vuoden alustalle. Vue on puolustettava; Svelte ei ole vielä hankintakelpoisuusluokan valinta puolustukseen.
- Cesium maapalloВnГ¤kymГ¤lle ja 3D:lle — maasto, ilmatilavyydet, satelliittiradат. WebGL-kiihdytetty, kypsГ¤, geospatiaalisen 3D:n de facto -standardi puolustuksessa.
- Mapbox GL tai MapLibre 2D-karttanäkymälle. Vektorilaattat nopeudelle; rasterilaattojen varavaihtoehto offline-käyttöön. Kompromissit ja suorituskykykatto ovat artikkelissa Reaaliaikainen kartanrenderöinti sotilaalliseen C2:een.
- Zustand tai Redux Toolkit tilalle. Suoratoistettavien ratapäivitysten määrä tekee naiivin React-tilan kestämättömäksi; käytä varastoa viitestabileilla valitsimilla ja pintavertailuilla.
- Ant Design tai Mantine ympäröivälle käyttöliittymälle — paneelit, modaalit, lomakkeet. Vastusta bespoke-suunnittelujärjestelmän rakentamista ensimmäisessä rakennuksessa; valitse kypsä kirjasto ja teemita se puolustuksen konventioihin.
Yksi ei-ilmeinen päätös: pidä COP yksisivuisena sovelluksena, ei monisivuisena sivustona. Operaattorit eivät navigoi. He avaavat COP:n kerran ja käyttävät sitä tunteja. Sivulataukset ovat väärä abstraktio; näkymät ja paneelit yhden kuoren sisällä ovat oikeat.
Vaihe 2: Sotilaallinen symbologia, oikein tehtynä
Radat renderöidään symboleina. Symboliluettelo on MIL-STD-2525D:n (tai vastaavan NATO APP-6 -variantin) hallinnoima. Käsinrakennettu symbologia on hankintapunainen lippu ja yhteentoimivuuden este: heti kun alusta integroituu liittoutuneen järjestelmään, epäyhteensopivat symbolit laukaisevat välittömän vaatimustenmukaisuusvirheen.
Käytä ylläpidettävää kirjastoa. Avoimen lähdekoodin milsymbol-toteutus on de facto -valinta web-pohjaisille COP:eille; se tuottaa vakiosymbolijoukon SVG- tai canvas-piirrettävinä. Kirjasto käsittelee yhteenliittymän (ystävä, vihamielinen, neutraali, tuntematon), osastotason merkit, tunnistavat tekstit ja muokkaimet, jotka muuttavat yleisen jalkaväkisymbolin "1. pataljoonaksi, mekanisoitu, puolustusasemassa".
Integrointikuvio: fuusiokone lähettää ratoja identiteettiattribuuteilla; COP etsii sopivan MIL-STD-2525 SIDC:n (Symbol Identification Code) näille attribuuteille; kirjasto renderöi symbolin. Välimuistita renderöidyt symbolit SIDC:llä; samaa symbolia käytetään uudelleen tuhansia kertoja tyypillisissä operatiivisissa kuvissa.
Huomionarvoinen käytännön yksityiskohta: MIL-STD-2525D:ssä on tuhansia erillisiä symboleita. Operatiivisesti relevantit skenaariot käyttävät lähes aina vain muutamaa sataa. Rakenna luettelo sisältä ulospäin — aloita siitä, mitä alustan anturit tuottavat, laajenna uusien anturiluokkien saapuessa.
Vaihe 3: Reaaliaikaiset päivitykset WebSocketin yli
COP:n tehtävä on heijastaa ratavarasto lähes reaaliajassa. Kysely ei skaalaudu; WebSocket on rakenteellinen vastaus. Arkkitehtuurikuvio:
Yhdyskäytäväpalvelu pitää auki WebSocket-yhteydet kuhunkin selaimeen. Se tilaa fuusiomoottorin tracks.updates- ja tracks.lifecycle-aiheita. Kun ratapäivitys saapuu, yhdyskäytävä arvioi yhteyskohtaisen suodattimen (mikä alue, mitkä roolit, mitkä luokittelut) ja työntää päivityksen selaimeen. Selain soveltaa päivityksen paikalliseen tilavarастoon; React renderöi uudelleen vain vaikuttuneet symbolit.
Ei-ilmeiset insinööriyksityiskohdat, jotka määräävät toimiiko tämä skaalassa:
Suodatus tapahtuu palvelinpuolella. Jokaisen radan työntäminen jokaiseen selaimeen ei toimi — 10 000 radan päivittyessä useita kertoja minuutissa sekä johto että selain tukkiutuvat. Jokaisella yhteydellä on tilaussuodatin (näkymärajat, roolipohjaiset kerrokset, luokittelusuodatin) ja vain täsmäävät päivitykset virtaavat.
Deltapäivitykset, eivät täydet korvaukset. Ratapäivitys on osittainen — sijainti muuttui, elinkaaritila muuttui, identiteetti tarkentui. Selain soveltaa patchin paikalliseen kopioonsа. Täydet ratakuormat lähetetään vain alkutilauksessa ja skeemamigraatioissa.
Uudelleenyhdistäminen tilan palautuksella. WebSocket-yhteydet katkeavat, erityisesti taktisissa verkoissa. Uudelleenyhdistymisen yhteydessä selain vaihtaa viimeksi nähdyn sarjanumeronsa yhdyskäytävän kanssa, joka toistaa puuttuvat päivitykset bussista. Ei tilatappiota, ei täyttä uudelleenHakua.
Takaisenpaineen käsittely. Hidas asiakas ei saa pysäyttää yhdyskäytävää. Jonon syvyys per asiakas on rajoitettu; kun jono ylittyy, asiakas pudotetaan ja pakotetaan yhdistämään uudelleen täydellä tilahaulla. On parempi, että yksi operaattori yhdistää uudelleen, kuin että kaikki operaattorit jäätyvät.
Vaihe 4: Roolipohjainen suodatus ja luokittelu
Jokainen operaattori ei näe jokaista rataa. Jalkaväen joukkueen johtajan COP ei näytä ilmapuolustuksen taisteluvyöhykkeitä. NATO RESTRICTED -tili ei näe SECRET-luokiteltuja ratoja. Alusta valvoo tätä kahdessa paikassa: yhdyskäytäväsuodattimessa (mitä lähetetään) ja politiikkamoottorissa (lähetetäänkö ylipäätään).
Roolisuodatin on käyttäjäkohtainen, istuntokohtainen konfiguraatio: mitkä ratatyypit, mitkä operaatioalueet, mitkä näyttökerrokset. Käyttäjä voi säätää valtuutuksensa puitteissa; järjestelmä valvoo ylärajan. Luokittelusuodatin on neuvottelematon: radan tehokas luokittelu (laskettuna fuusiossa, välitetty yhdyskäytävälle) täytyy olla käyttäjän selvityksessä tai sen alla. Ristikkäistarkistukset API- ja tietokantakerroksissa — ei koskaan pelkästään käyttöliittymässä — ovat sääntö. Yksityiskohtainen kuvio on artikkelissa Roolipohjainen pääsynhallinta puolustuksen C2-järjestelmissä.
Operatiivinen huomio: rakenna roolikonfiguraation käyttöliittymä yhdessä operaattoriyhteisön kanssa, ei eristyksissä. Oletusarvot ovat tärkeitä. Jalkaväkikäyttäjä ei halua aloittaa jokaista istuntoa poistamalla käytöstä kuusi kerrosta epärelevanttia ilmapuolustusdataa. Lentäjä ei halua aloittaa jokaista istuntoa ottamalla käyttöön ilmapuolustuskerrokset, jotka hänen edeltäjänsä poisti käytöstä. Roolipohjaiset oletukset, jotka vastaavat operaattorin todellista tehtävää, puolittavat operaattorin turhautumisen peruslinjan.
Keskeinen oivallus: COP, joka voittaa demon, on tiheä, animoitu ja täynnä peitettyjä tasoja. COP, joka voittaa operaatiot, on pidättyväinen, nopea ja näyttää vain sen, mitä operaattori tarvitsee. Oletus on vähemmän, suurempia, korkeakontrastisempia symboleita. Anna operaattoreiden lisätä yksityiskohtia; älä aloita heitä maksimitietotiheydellä.
Vaihe 5: Operaattorin ergonomia
COP, joka epäonnistuu ergonomisesti, epäonnistuu operatiivisesti. Kurinalaisuus rakentuu kourallisesta ehdottomista säännöistä.
Vanhentuneen radan merkintä. Kun radan elinkaaritila on haalistuva tai kadonnut, symboli muuttuu — tyypillisesti himmeämpi, mahdollisesti ääriviivalla, ikäindikaattorilla. Operaattoreiden täytyy nähdä yhdellä silmäyksellä mihin ratoihin he voivat luottaa.
Konfliktinratkaisun käyttöliittymä. Kun kaksi operaattoria muokkaa samaa rataa tai tehtävää samanaikaisesti, alustan täytyy tuoda esiin konflikti, ei hiljaa korvata toista puolta. Viimeisin kirjoittaja voittaa attribuuttikohtaisesti on oletus; eksplisiittinen sovittelu korkeapanoksia attribuuteille.
Näppäimistöensijainen suunnittelu. Pelkästään hiirellä toimivat käyttöliittymät epäonnistuvat stressaantuneissa operaatioissa. Jokaisella yleisellä toiminnolla on näppäinkomento; komennot on dokumentoitu tuotteessa ja löydettävissä.
Kosketus- ja hanskakäyttö karkaistuille kohteille. Sama COP toimii komentopaikoilla työasemilla ja karkaistutituilla tableteilla prikaatin etuasemilla. Osumiskohteet on mitoitettu hansikoille; korkean kontrastin tilat ovat ensiluokkaisia. Laajempi kuvio on artikkelissa Karkaistun UX:n suunnittelu sotilasoperaattoreille.
Offline-toiminta. Taktisen reunan käyttöönotot menettävät yhteyden. COP:n täytyy toimia paikallisessa välimuistissaan, toistaa jonossa olevat operaattorin toiminnot uudelleenyhdistymisen yhteydessä ja ilmoittaa selkeästi mikä data on vanhentunutta. Arkkitehtuurikuvio on artikkelissa Offline-ensisijaiset sotilassovellukset; offline-karttapuoli artikkelissa Offline-kartat MBTiles:llä ja PMTiles:llä.
Vaihe 6: Kartan tuolla puolen — kojetaulut ja paneelit
COP on enemmän kuin kartta. Operaattorit tarvitsevat tehtävän anto -rajapintoja, viestimuodostusta, suunnittelutyökaluja, tiedustelupaneeleja, lokikanemia. Alustan laajuinen UX-sääntö: jokainen paneeli noudattaa samoja vuorovaikutuskonventioita. Jos radan valitseminen kartalla korostaa sen sivupaneelissa, niin radan valitseminen missä tahansa paneelissa korostaa sen kartalla. Epäjohdonmukaisuus tässä kerroksessa on puolustusohjelmistojen yleisin UX-epäonnistuminen.
Ylläpidettävä arkkitehtuurinen erottelu: karttanäkymä on yksi paneeli; kojetaulut ja sivupaneelit ovat muita paneeleita; ne jakavat saman valintатilan keskusvaraston kautta. Uuden analyytikkotyökalun lisääminen on uusi paneeli, ei uusi sovellus. Kojetaulu-arkkitehtuurikuviot ovat artikkelissa C2-kojetaulun arkkitehtuuri.
Vaihe 7: Suorituskykytavoitteet
COP:n tavoitteet ovat tiukempia kuin miltä ne kuulostavat:
- Alkuaika alle 3 sekuntia taktisen reunan kannettavalla välimuistissa olevilla staattisilla asseteilla.
- Ratapäivityksen viive alle 200 ms yhdyskäytävän lähetyksestä symbolin näkyvästi liikkumiseen selaimessa.
- Jatkuva 60 FPS kartanrenderöinti enintään 10 000 näkyvällä radalla.
- Panorointi ja zoomaus reagoivat tyypillisissä taktisissa mittakaavoissa (1:50 000 – 1:1 000 000).
- Muisti rajoitettu — selaimen täytyy toimia koko päivän vuotamatta. Profiloi jokainen release.
Tavoitteet ovat saavutettavissa valitulla pinolla; niiden puuttuminen on yleensä arkkitehtuurisen oikopolun tulos aikaisemmin putkistossa (palvelinpuolen suodatusta ei toteutettu, täydet kuormat deltioiden sijaan, naiivi tilanhallinta).
Mitä seuraavaksi
Osa 3 on rakentanut COP:n. Radat renderöidään oikealla symbologialla; päivitykset virtaavat WebSocketin yli; operaattorit näkevät vain sen, mihin heillä on valtuutus; ergonomia tukee todellisia operaatioita. Alusta on nyt käyttökelpoinen operaattorille — mutta ei vielä toimitettavissa.
Osa 4 sulkee silmukan: NATO-yhteentoimivuussillat (CoT, MIP4, STANAG 4559), luokittelumerkinnät ja julkaistavuuden valvonta, DevSecOps-putki, joka tuottaa akkreditointitodisteet, ja ilmaraon käyttöönotto taktisen reunan käyttöön. Osan 4 jälkeen alusta on operatiivisesti käyttöön otettavissa.