Sotilaallisen C2-ohjelmiston arviointi: 12 kriteeriä hankintapäätöksiin

Johto- ja valvontaohjelmiston valinta on yksi korkeimman panoksen hankintapäätöksistä, joita puolustusorganisaatio tekee. Väärä valinta — alusta, joka epäonnistuu heikentyneissä viestintäolosuhteissa, ei pysty integroimaan anturisyötteitäsi tai lukitsee sinut omistukselliseen ekosysteemiin — aiheuttaa operatiivisia seurauksia, jotka kestävät vuosikymmenen. Toisin kuin kaupallisessa yrityssoftwaressä, huonon C2-hankinnan hintaa ei mitata tuhlatulla budjetilla vaan heikentyneellä tilannekuvalla silloin kun se eniten ratkaisee.

Tässä artikkelissa esitetään jäsennelty arviointikehikko, joka perustuu 12 kriteeriin, jotka hankintatiimien tulee arvioida ennen sopimuksen tekemistä. Kullekin kriteerille kehikko tunnistaa mitä etsiä, punaisia lippuja jotka hylkäävät toimittajan sekä kuinka testata kriteeri kontrolloidussa demonstroinnissa. Kehikko soveltuu sekä tilauspohjaisten kehitysohjelmien että kaupallisten valmisohjelmistojen (COTS) C2-alustahankintoihin.

Kriteeri 1: Reaaliaikaisen datan syöttöviive

Mitä etsiä. Kohteen päivitysviive — aika sijaintiraportin syöttämisestä järjestelmään siihen, kun päivitetty symboli ilmestyy yhteiselle operatiiviselle kuvalle — ei saa ylittää 500 ms 95. persentiilissä edustavalla kuormituksella. Nopealiikkeisille ilmakohteille tai aikakriittiselle maalittamiselle soveltuvat alhaisemmat kynnykset (≤200 ms). Päästä päähän -viive on mitattava operatiivisilla kohdetiheystasolla, ei kevyesti kuormitetussa demoympäristössä.

Punaiset liput. Toimittajat, jotka eivät pysty toimittamaan viivemittauksia määritellyn kuormituksen alaisena tai jotka ilmoittavat vain keskiarvon ilman persentiilijakaumia, ovat joko testaamattomia tai peittävät suorituskyvyn heikkenemistä suuressa mittakaavassa. Keskimääräinen viive on lähes hyödytön operatiivisena mittarina — järjestelmä, jonka keskiarvo on 300 ms mutta joka piikkaa 8 sekuntiin 2 000 kohteella, on operatiivisesti epäluotettava.

Demotesti. Vaadi toimittajaa ajamaan automaattinen kuormitusgeneraattori, joka ruiskuttaa sijaintipäivityksiä ilmoittamallasi kohteiden enimmäiskapasiteetillä (esim. 3 000 samanaikaista kohdetta 0,1 Hz:n taajuudella kutakin). Mittaa päästä päähän -viive aikaleimattuja viestejä käyttäen ruiskutuksesta karttarenderöintiin. Pyydä p50-, p95- ja p99-viivearvot.

Kriteeri 2: Monilähteisen integraation laajuus

Mitä etsiä. Operatiivisten C2-järjestelmien on yhdistettävä kohteita heterogeenisistä lähteistä: UAV-maaohjauksesta (via Cursor on Target tai MAVLINK), SIGINT-syötteistä, OSINT-koostajista, logistiikanhallintajärjestelmistä ja vanhoista anturiverkostoista. Arvioi natiiviadaptereiden laajuus ja uuden lähteen lisäämiseen vaadittava työmäärä. Alusta, jolla on kaksikymmentä sertifioitua integraatiota mutta ei avoin SDK mukautetuille liittimille, on pitkän aikavälin integraatiovelka.

Punaiset liput. Integraatiotiekartat, jotka listaavat liittimiä "suunnitteilla" tai "saatavilla pyynnöstä", eivät ole sama kuin toimitettu koodi. Vaadi demonstrointia vähintään kahta todella käyttämääsi tietolähdettä vasten. Suljetut, omistukselliset viestimuodot ilman julkaistua skeemadokumentaatiota viittaavat tulevaan toimittajariippuvuuteen.

Demotesti. Toimita toimittajalle reaaliaikainen tai tallennettu dataseed yhdeltä nykyiseltä anturiltasi sen alkuperäisessä muodossa. Seuraa onko integraatio natiivi vai vaatiiko se toimittajan laskuttaman ammatillisten palvelujen sitoutumisen.

Kriteeri 3: Offline- ja heikentyneen verkon toimintakyky

Mitä etsiä. Kenttä-C2-järjestelmät toimivat kiistanalaisissa sähkömagneettisissa ympäristöissä, joissa yhteys keskuspalvelimelle on katkonainen tai poissa. Järjestelmän on ylläpidettävä käyttökelpoinen operatiivinen kuva paikallisesti välimuistiin tallennetusta datasta verkon katkojen aikana, synkronoitava tila automaattisesti yhteyden palautuessa ja jonottaa lähtevät komennot ilman datan häviämistä. Arvioi tuettu enimmäinen offline-kesto ja tilarekonsiliation tarkkuus uudelleenyhdistämisen jälkeen.

Punaiset liput. Järjestelmät, jotka vaativat jatkuvan palvelinyhtyeyden kartan renderöimiseksi tai komentojen antamiseksi. Arkkitehtuuri, jossa operaattoreiden näyttö on puhtaasti ohut asiakas ilman paikallista tilaa, on operatiivisesti hauras kiistanalaisessa ympäristössä. Vahvista, ylläpitääkö mobiili- tai jalkaväkiasiakas itsenäistä kohdetietokantaa vai suoratoistaa se vain palvelimelta.

Demotesti. Katkaise demonstroinnin aikana asiakassolmu fyysisesti palvelimesta. Seuraa pysyykö operaattorin näyttö toiminnallisena, mikä data heikkenee ja siirretäänkö katkoksen aikana jonossa olleet komennot automaattisesti uudelleenyhdistymisen yhteydessä.

Kriteeri 4: NATO-yhteentoimivuusstandardit (STANAGit)

Mitä etsiä. NATOn sisällä tai rinnalla toimivien ohjelmien on noudatettava asiaankuuluvia standardointiasiakirjoja. Keskeisiä STANAGeja C2-yhteentoimivuudelle ovat STANAG 5522 (taktiset datalinkit), STANAG 4677 (NFFI ystävällisten joukkojen tiedot), STANAG 4559 (NSILI kuvakirjastoliittymä) ja APP-6D (NATO:n sotilassymbologia). Tarkista vaatimustenmukaisuus tiettyjen versioiden osalta, ei vain standardin nimen — APP-6C ja APP-6D sisältävät merkittäviä symbolisarjaeroja, jotka vaikuttavat yhteentoimivuuteen koalitioharjoituksissa.

Punaiset liput. Toimittajat, jotka väittävät STANAG-vaatimustenmukaisuutta toimittamatta vaatimustenmukaisuustestiraporttia tai CWIX-osallistumistietuetta (Coalition Warrior Interoperability eXploration, eXperimentation, eXamination, eXercise). Itsejulistettu vaatimustenmukaisuus ilman kolmannen osapuolen validointia ei riitä koalitio-ohjelmien käyttöön.

Demotesti. Pyydä toimittajan viimeisintä CWIX-osallistumisyhteenvetoa tai vaatimustenmukaisuustuloksia vaatimuksissasi mainituille STANAGeille. Symbolien renderöinnin osalta toimita APP-6D-testitapausjoukko ja varmista oikea renderöinti referenssisymbolisarjaan nähden.

Kriteeri 5: Tietoluokituksen hallinta

Mitä etsiä. Luokiteltuja tietoja käsittelevien C2-järjestelmien on pakotettava tietomerkintä, pääsynhallinta ja toimialuerajat ylittävän tiedonsiirron rajoitukset objektitasolla — ei vain verkon kehällä. Jokaisella kohteella, asiakirjalla ja viestillä on oltava luokitusmetatiedot, jotka ohjaavat mitä kukin käyttäjä voi nähdä ja viedä. Arvioi järjestelmän toiminta, kun alemmalla luokitustasolla oleva käyttäjä yrittää tarkastella tai viedä ylemmälle tasolle merkittyä kohdetta.

Punaiset liput. Luokitus, jota pakotetaan vain kirjautumisessa (kaikki todennetut käyttäjät näkevät kaiken datan), ei riitä mihinkään monilokitustason käyttöympäristöön. Tarkastuslokien puuttuminen tietokäyttö-, vienti- ja alentamistapahtumista on vaatimustenmukaisuuden hylkäysperuste useimmissa puolustuksen hyväksyntäkehikoissa.

Demotesti. Luo testitilit kahdelle eri luokitustasolle. Varmista, ettei alemmalla luokituksella oleva tili pysty tarkastelemaan, viemään tai vastaanottamaan hälytyksiä tasoaan korkeammalle merkityistä objekteista. Tarkasta tarkastusloki ja vahvista, että käyttöyritys on kirjattu.

Kriteeri 6: Roolipohjaisen pääsynhallinnan tarkkuus

Mitä etsiä. Operatiivinen C2 vaatii hienojakoisen pääsynhallinnan toiminnallisten roolien välillä: tiedustelupäällikkö, joka voi tarkastella SIGINT-kohteita mutta ei antaa liikkumismääräyksiä; yhteysupseeri liittolaismaalta, joka voi tarkastella jaettuja kohteita mutta ei käyttää kotimaisten joukkojen dispositiota; logistiikkakoordinaattori, joka näkee ylläpito-kerrokset mutta ei maalittamisdataa. Arvioi, tukeeko RBAC-malli attribuuttipohjaisia käytäntöjä, jotka voivat ilmaista nämä rajoitukset, vai rajoittuuko se karkeaan roolimääritykseen.

Syvällisempää teknistä kattavuutta RBAC-arkkitehtuureista puolustusalustoissa löytyy artikkelista roolipohjainen pääsynhallinta puolustuksen C2-järjestelmissä.

Punaiset liput. Järjestelmät, joissa on alle viisi ennalta määriteltyä roolia eikä tukea mukautettujen roolien luomiselle. RBAC-mallit, jotka eivät pysty rajoittamaan pääsyä dataobjektitasolla (vain käyttöliittymän toimintotasolla), luovat aukkoja joissa käyttäjä voi käyttää arkaluonteista dataa API:n tai vientifunktion kautta, joka ohittaa käyttöliittymärajoituksen.

Demotesti. Määrittele mukautettu rooli — esimerkiksi koalitiokumppani, jolla on lukuoikeus sinisten joukkojen kohteisiin tietyllä maantieteellisellä alueella — ja varmista, pystyykö järjestelmä ilmaisemaan ja pakottamaan tämän rajoituksen ilman toimittajan ammatillisia palveluja.

Kriteeri 7: Skaalautuvuus korkean kohdetiheyden alaisena

Mitä etsiä. Arvioi järjestelmän suorituskykyominaisuudet kolmen skaalautuvuusdimension osalta: kohdetiheys (samanaikaiset objektit C2-kojelaudalla), samanaikaiset käyttäjät (operaattorit, jotka käyttävät järjestelmää samanaikaisesti) ja viestiliikenteen läpimeno (saapuvan datan nopeus kaikista lähteistä yhteensä). Hanki toimittajan suorituskykyvertailutulokset ja, mikäli mahdollista, toista ne itsenäisesti arviointivaiheen aikana.

Punaiset liput. Toimittajat, jotka eivät pysty toimittamaan suorituskykydataa yli 1 000 kohteen tai yli 20 samanaikaisen käyttäjän tasoilla. Yksittäiseen tietokantasolmuun ilman horisontaalista skaalautumispolkua tukeutuva arkkitehtuuri on kapasiteettikatto, joka rajoittaa ohjelmaa sen kasvaessa.

Demotesti. Käytä Kriteeri 1:n kuormitusgenerointitestiä laajennettuna sisältämään useita samanaikaisia käyttäjäsessioita, joista kukin suorittaa aktiivisia karttavuorovaikutuksia (zoomaus, suodatus, kyselyt). Mittaa heikkeneekö käyttäjäkohtainen viive lineaarisesti vai epälineaarisesti samanaikaisten käyttäjien lisääntyessä.

Kriteeri 8: Toimittajan tietoturvasertifikaatit

Mitä etsiä. Hyväksyttävien tietoturvasertifikaattien vähimmäistaso riippuu ohjelmaasi hallitsevasta hyväksyntäkehikosta. Yleisiä viitekohtia: ISO/IEC 27001 (tietoturvan hallinta), SOC 2 Type II (relevantti pilvihoidetuille ratkaisuille), Common Criteria EAL -sertifiointi (järjestelmille, jotka vaativat muodollisen tietoturvan varmennuksen) sekä ohjelmakohtainen hyväksyntä (esim. DISA STIG -vaatimustenmukaisuus, FedRAMP Yhdysvaltain liittovaltion ohjelmille, NCSC-ohjeet Yhdistyneen kuningaskunnan ohjelmille).

Punaiset liput. Sertifikaatit, jotka ovat vanhentuneet, rajoittuvat laajuudeltaan vain tuotteen osajoukkoon tai perustuvat versioon, joka poikkeaa merkittävästi nykyisestä julkaisusta. Toimittaja, jonka ISO 27001 on sertifioitu yritysten IT-ympäristölle mutta ei C2-tuotteen toimitusputkelle, tarjoaa rajallisen varmuuden. Vaadi sertifikaatin laajuusilmoitus.

Demotesti. Pyydä todellinen sertifikaattiasiakirja myöntämispäivämäärineen, laajuuksineen ja voimassaoloaikoineen. STIG-vaatimustenmukaisuuden osalta pyydä STIG Viewer -tulostetiedosto, ei yhteenvetotaulukkoa. Ota yhteyttä sertifiointielimeen voimassaolon vahvistamiseksi.

Kriteeri 9: Käyttöönoton joustavuus

Mitä etsiä. Arvioi tukeeko alusta kaikkia ohjelmaasi elinkaarensa aikana vaatimia käyttöönottomalleja: kaupallinen pilvi (harjoitus- ja koulutusympäristöihin), paikalliset palvelimet kovetetussa datakeskuksessa, taktinen reuna (toimii maastossa käytetyillä kuormitusta kestävillä laitteistolla) ja täysin ilmasuljettu (ei ulkoista verkkoyhteyttä). Monet alustat on optimoitu yhdelle käyttöönottomallille ja heikkenevät muissa — pilvinatiivi SaaS-alusta saattaa olla ilman toimivaa polkua ilmasuljettuun toimintaan.

Punaiset liput. Riippuvuus ulkoisista palveluista (lisenssipalvelimet, päivityspalvelimet, telemetriapalvelupisteet), jotka eivät toimi ilmasuljetussa ympäristössä. Lisensointimallit, jotka vaativat säännöllisen pilvikirjautumisen pysyäkseen aktiivisina, epäonnistuvat äänettömästi yhteydettömässä toiminnassa. Vahvista vaatiiko offline-toiminta erityistä lisenssitasoa.

Demotesti. Pyydä nimenomaisesti ilmasuljetun käyttöönottovariannin demonstrointia, jos ohjelmasi vaatii sitä. Monet toimittajat demonstroivat pilviversion ja väittävät ilmasuljetun kyvyn — testaa todellinen käyttöönottomalli, ei kyvyn väitettä.

Kriteeri 10: Käyttöliittymä stressitilanteissa

Mitä etsiä. C2-käyttöliittymä, jota operaattori käyttää aikapaineessa, epätäydellisillä tiedoilla ja meluisassa ympäristössä, asettaa perustaltaan erilaiset käytettävyysvaatimukset kuin yritysohjelmat. Arvioi tietotiheys (löytyykö relevantti data ilman valikoissa navigointia), hälytysten väsymys (erottaako järjestelmä kriittiset hälytykset rutiinitiedotteista) ja operatiivisten tehtävien suoritusaika yleisille toimille: tietyn yksikön paikallistaminen, tehtävämääräyksen antaminen ja kohteen merkitseminen vihamieliseksi.

Punaiset liput. Käyttöliittymät, jotka vaativat yli kaksi napsautusta aikakriittisen toiminnon suorittamiseen (kohteen sidosryhmän muuttaminen, kontaktiraportin lähettäminen). Järjestelmät, joissa on eriytymättömiä hälytysvirtoja, jotka esittävät alhaisen prioriteetin järjestelmätapahtumat kriittisten operatiivisten tiedotteiden rinnalla, jäävät operaattoreiden huomiotta ja jättävät kriittiset tapahtumat huomaamatta.

Demotesti. Anna arvioija, joka ei ole aiemmin nähnyt alustaa, ja pyydä häntä suorittamaan kolme määriteltyä tehtävää ilman toimittajan apua. Mittaa tehtävän suoritusaika ja virheprosentti. Tämä jäsennelty käytettävyystesti paljastaa työnkulun kitkaa, jonka toimittajan johtama demo peittää.

Kriteeri 11: Tuki- ja SLA-ehdot

Mitä etsiä. Operatiivinen C2-ohjelmisto vaatii tukiehtoja, jotka vastaavat operatiivisen käytettävyyden vaatimuksia — ei kaupallisia SaaS-SLA-tasoja. Arvioi: käytettävyystakuu (99,9 %:n käynnissäoloaika sallii silti 8,7 tuntia vuotuista seisokkia), kriittisten vikojen vastausaika (tunteja, ei arkipäiviä), tietoturva-aukkoja koskevien korjausten toimitusaikataulu sekä toimittajan kyky tukea luokiteltuja käyttöönottoja rajoitetun pääsyn olosuhteissa.

Punaiset liput. Tukitasot, jotka tarjoavat nopeampaa vastausta vain merkittävästi korkeammalla hinnalla, jolloin operatiivisen tason tuki on käytännössä lisämaksuinen vaihtoehto. Toimittajat, jotka eivät pysty osoittamaan aiempaa kokemusta luokiteltujen käyttöönottojen tukemisesta turvaluokitellulla henkilöstöllä, ovat riski ohjelmille, joilla on luokitusvaatimuksia.

Demotesti. Pyydä toimittajaa toimittamaan muokattuja esimerkkejä menneistä vakavuustason 1 tapausten vastausasiakirjoista. Ota yhteyttä referenssiasiakkaisiin erityisesti tuen reagointiherkkyyden kysymiseksi todellisten tapahtumien aikana, ei yleisen tyytyväisyyden osalta.

Kriteeri 12: Kokonaiskustannukset

Mitä etsiä. C2-ohjelmiston TCO viiden vuoden ohjelmaelinkaarella sisältää: alkuperäiset hankinta- tai kehityskustannukset, vuotuiset lisenssi- tai ylläpitomaksut, infrastruktuurikustannukset (pilvipalvelutilaukset tai paikalliset laitteistot), integraatiokustannukset (yhdistäminen olemassa oleviin anturi- ja logistiikkajärjestelmiin), koulutuskustannukset operaattoreille ja ylläpitäjille sekä arvioidut päivityskustannukset. Avoin arkkitehtuuri julkaistuilla API-rajapinnoilla ja siirrettävillä datamuodoilla aiheuttaa huomattavasti alhaisemmat pitkän aikavälin integraatio- ja migraatiokustannukset kuin omistukselliset järjestelmät.

Punaiset liput. Hinnoittelurakenteet, jotka veloittavat per käyttäjä kullekin samanaikaiselle käyttäjälle, luovat kasvavia kustannuksia ohjelman kasvaessa. Omistukselliset datamuodot ilman vientikyvykkyyttä luovat vaihtoehtoiskustannuksia, jotka käytännössä lukitsevat ohjelman sopimuksen uusimishetkellä. "Perushinnan" tarjoukset, jotka sulkevat pois pakolliset tukitasot, infrastruktuurin tai integraatiomoduulit, aliarvioivat TCO:n säännönmukaisesti 40–60 %:lla.

Demotesti. Pyydä kultakin toimittajalta yksityiskohtainen viiden vuoden TCO-malli käyttäen ilmoitettuja ohjelmaparametrejasi (käyttäjämäärä, kohteiden enimmäiskapasiteetti, käyttöönottaympäristö). Vaadi mallia erittelemään kaikki kustannuskomponentit, mukaan lukien infrastruktuuri, tuki ja integraatio. Vertaile elinkaarikustannuksia kokonaisuudessaan, ei hankintahintaa.

Kuinka toteuttaa C2-ohjelmiston arviointi 6 viikossa

Jäsennelty kuuden viikon arviointi tiivistää teknisen arvioinnin puolustettavaan ja dokumentoitavaan prosessiin menettämättä tarkkuutta.

Viikko 1: Vaatimukset ja rubriikki. Muunna operatiiviset vaatimukset kvantitatiivisiksi kynnyksiksi kullekin 12 kriteerille. Aseta painotukset. Julkaise rubriikki arviointilautakunnalle ennen toimittajayhteydenottoja. Älä muuta painotuksia demojen alkamisen jälkeen.

Viikot 1–2: Tietopyyntö ja seulonta. Lähetä jäsennelty tietopyyntö, joka vaatii pakollisia vastauksia kartoitettuna 12 kriteeriin. Seulo vastaukset vähimmäiskynnystä vasten — toimittajat, jotka eivät pysty kirjallisesti täyttämään viive-, sertifiointi- tai käyttöönottaatamisvaatimuksiasi, eivät etene demovaiheeseen.

Viikko 2: Demoskenaariosuunnittelu. Kirjoita kolmesta neljään käsikirjoitettuun skenaarioon, jotka kattavat korkeimman riskin kriteerisi: heikentyneen verkon skenaario, korkean kohdetiheyden skenaario, luokitusrajan testi ja monilähteinen integraatiotesti. Toimita skenaariokäsikirjoitukset toimittajille etukäteen. Arvioit ohjelmistoa, et toimittajan kykyä improvisoida heikkouksiensa ympärillä.

Viikot 3–4: Jäsennellyt demonstroinnit. Aja jokainen toimittaja identtisten skenaarioiden läpi samojen arvioijien läsnä ollessa. Pisteytä kriteerit välittömästi jokaisen demon jälkeen. Tallenna sessiot poissaoleville lautakunnan jäsenille. Pakota jäsennelty kysymys- ja vastausmuoto — käsikirjoittamattomat avoimet demot antavat toimittajille mahdollisuuden ohjata heikkouksien ohitse.

Viikot 4–5: Dokumentaatio- ja referenssitarkistus. Vahvista väitetyt sertifikaatit myöntävien elinten kanssa. Ota yhteyttä referenssiasiakkaisiin itsenäisesti. Pyydä todelliset SLA-asiakirjat, ei markkinointiyhteenvetoja. Pyydä STIG-tulostetiedostot, ei vaatimustenmukaisuustaulukoita.

Viikot 5–6: Pisteytys ja lähdevalintadokumentaatio. Kokoa arvioijien pisteet. Kartoita kukin pisteytys tiettyihin havaintoihin tai dokumentaatiotodisteisiin. Tuota lähdevalintapäätösasiakirja. Tämä asiakirja on välttämätön hankintapäätöksen valitussuojaukselle ja sopimuksen jälkeisille ohjelmajohtamisen peruslinjoille.

Kuinka Corvus.Head vastaa näihin kriteereihin

Corvus.Head on ISR-johto- ja valvontakojelauta, joka on rakennettu erityisesti tässä viitekehyksessä kuvatuille operatiivisille kriteereille. Se nielee monilähteisiä syötteitä — UAV-telemetria, SIGINT-kerrokset, OSINT-tasot ja logistiikkadata — avoimen adaptteriarkkitehtuurin kautta, joka tukee mukautettujen liittimien kehittämistä ilman toimittajan osallistumista. Kohteen päivitysviive mitataan alle 300 ms:ssa 95. persentiilissä prikaatimittakaavan kohdelatauksilla. Alusta tukee ilmasuljetun, paikallisen ja pilvipalvelun käyttöönottoa samasta koodikannasta, offline-toiminnalla ja automaattisella tilarekonsililaatiolla uudelleenyhdistämisen yhteydessä. Roolipohjainen pääsynhallinta tukee attribuuttipohjaisia käytäntöjä yksittäisen kohdeobjektin tasolla.

Jäsenneltyä arviointia toteuttaville hankintatiimeille Corvus Intelligence voi toimittaa vertailudatapaketteja, referenssiarkkitehtuuridokumentaation ja jäsennellyt demosessiot, jotka on käsikirjoitettu arviointikriteereidesi mukaan tavallisen markkinointikierroksen sijaan.

Usein kysytyt kysymykset

Aiheeseen liittyvää lukemista: Syvällisempää teknistä analyysia C2-järjestelmien suorituskykyyn vaikuttavista tekijöistä löytyy artikkeleista C2-kojelaudan arkkitehtuuri, C2-järjestelmän testaus ja verifiointi sekä roolipohjainen pääsynhallinta puolustuksen C2-järjestelmissä. Standardien taustoitukseen artikkeli kattava opas C2-järjestelmiin kattaa näiden arviointikriteerien taustalla olevan operatiivisen ja arkkitehtonisen kontekstin.