Andmete edastamine

Katrin Kiisler Teie 03.10.2025 nr 10-1.1/25/4296 Haridus- ja Teadusministeerium [email protected] Meie 30.10.2025 nr 0.3-3/25/8-2 [email protected] Kaitseväe Akadeemia andmete esitamine teadus- ja arendustegevuse toetuse saamiseks 2026. aastal Austatud proua Kiisler Vastuseks Teie kirjale 03.10.2025 nr 10-1.1/25/4296 esitame Kaitseväe Akadeemia (KVA) andmed teadus- ja arendustegevuse toetuse saamiseks 2026. aastal. KVA andmed perioodi 2021–2024 kohta on kirjale lisatud. Täiendavad selgitused: • välisrahastusi perioodil 2021–2024 oli KVA-l ainult aastatel 2022 ja 2023; • riigieelarvevälistest vahendites saadud tulude (lisa 2 ja lisa 3) tekkepõhisuse tõendamiseks on esitatud maksekorraldused laekumiste kohta (lisa 2a, lisa 2b ja lisa 3a). Kaitseväe Akadeemia on juriidiliselt Kaitseväe allasutus ja Kaitsevägi ei koosta majandusaasta tulemiaruannet ning sellest tulenevalt esitati Kaitseministeeriumi valitsemisala raamatupidamistalitusest välisrahastajate maksete laekumise tõendamiseks maksekorraldused. Lugupidamisega (allkirjastatud digitaalselt) Johan-Elias Seljamaa mereväekapten Kaitseväe Akadeemia ülem Lisad: Lisa 1 Kaitseväe Akadeemia kasulik mudel EE01564U1 Lisa 2 KVA välisrahastused 2022 Lisa 2a Laekumine Milrem 10749382 Lisa 2b Laekumine Milrem 10826910 Lisa 2c Milrem KVA leping Lisa 3 KVA välisrahastused 2023 Lisa 3a Laekumine EK arve 10883825 Lisa 3b Service Contract number D1-IATE-ET-25 Epp Leete 717 6253 [email protected] Juhkentali 58 / 15007 Tallinn / Telefon 717 1155 / Faks 717 1008 / [email protected] / www.mil.ee Registrikood 70008641  UI lillil IIIIIlillIIIII lillil <|SS > EESTI VABARIIK oo EE 01564 UI 0EE1564 ( i 9) J 8§& (m) ( PATENDIAMET (51) IntCl. H03G 3/30 (2022.01) H03F 1/02 (2022.01) (12) KASULIKU MUDELI KIRJELDUS (21) Registreerimistaotluse (73) Kasuliku mudeli omanik: number: U202100027 Kaitsevägi (22) Registreerimistaotluse Juhkentali 58, 15007 Tallinn , EE esitamise kuupäev: 22.06.2021 (72) Kasuliku mudeli autorid: (24) Registreeringu kehtivuse alguse kuupäev: 22.06.2021 Jaanus Kalde Nooruse 1, 50411 Tartu, EE (45) Kasuliku mudeli kirjelduse avaldamise kuupäev: 18.04.2022 Kalle-Gustav Kruus Nooruse 1, 50411 Tartu, EE Veiko Dieves Riia 12, 51010 Tartu, EE (74) Patendivolinik: Jü rgen Toome AAA Patendibü roo OÜ Tartu mnt 16, 10117 Tallinn , EE (54) Meetod raadiosagedusvõimendi transistori eelpinge digitaalseks reguleerimiseks suletud tagasisideahelaga kontrolleriga (57) Leiutis käsitleb meetodit eelpinge digitaalseks reguleeri ¬ miseks suletud tagasisideahelaga kontrolleriga, mis on 102 108 konfigureeritud juhtima raadiosagedusvõimendi transistori voimsus - - RF i väl- jundport eelpingestuspunkti. Digitaalne süsteem, mis mõõdab mitmeid voolutugevuse süsteemi tööparameetreid, sealhulgas transistori võimsus- vf mõõtmise skeem tarvet ja raadiosagedussignaaii sisendvõimsuse taset. Digi¬ taalse süsteemi puhul kasutatakse algoritmi, et muuta eelpinge taset sisendsignaalide ja mällu salvestatud väärtuste järgi. 101 mikro- kontrolier < — 109 103 yvõimendi / transistor A Automaatne eelpingestuspunkti reguleerimine või võimsuse \ vähendamine on võimalik juhul, kui s üsteem tuvastab, et 104 X transistori sisendis ei ole raadiosagedussignaaii. Kõiki mõõde- eelpinge tase / tavaid väärtusi on võimalik digitaalselt jälgida mikro - kontrolleri abil ja parameetreid on võimalik tarkvara abil reguleerida. 106 105 (57) The invention relates to a method for a digital bias võimsus < andur - suuns- kompleks control by a closed loop feedback controller configured to drive the bias point of the radio frequency amplifying 107 transistor. Digital system that measures multiple parameters of system operations, including transistor power consumption - - RF i Si sendport and input radio frequency signal power level. Digital system uses an algorithm to change the bias level according to input signals and values recorded in the memory. Automatic bias point tuning or power down can be done when system detects no RF signal present on the input of the transistor. All the measurements can be digitally monitored from the micro¬ controller and parameters tuned from the software. EE 01564 U1  EE 01564 UI Meetod raadiosagedusvõimendi transistori eeipinge digitaalseks reguleeri¬ miseks suletud tagasisideahelaga kontrolleriga TEHNIKAVALDKOND Leiutis käsitleb raadiosagedusvõimendite programmeeritava eelpingestamise mee- 5 todit, teiste sõnadega meetodit raadiosagedusvõimendi (RF-võimendi, ingl radio frequency ) transistori eeipinge digitaalseks reguleerimiseks võimendi viimases või- mendamisetapis. Leiutise kontekstis tähendab väljend „võimendi eeipinge muutmine raadiosagedus¬ 11 võimendi (RF-võimendi) transistori alalisvoolu (DC, ingl direct current ) eeipinge 10 muutmist võimendi viimases võimendamisastmes. TEHNIKA TASE Raadiosignaalide võimendamise valdkonnas kasutatakse transistoreid signaalide võimendamiseks. Need transistorid peavad parimal võimalikul viisil toimimiseks olema õigesti eelpingestatud. Täpne optimeeritav parameeter võib olla iga raken- 15 duse puhul erinev, aga tavaliselt hõlmavad nimetatud parameetrid v õimendust, võimsuse maksimaalset taset või kasutegurit. Täpne eelpingestuspunkt ei ole kind¬ laks määratud. See oleneb mitmetest teguritest, kasutatava transistori mudelist, transistori eriomastest lubatud piirhälvetest, temperatuurist, signaali modulatsioo¬ nist, nõutavast võimsusest jne. 20 Kõige lihtsam kasutatav eelpingestustehnika on kindla eeipinge rakendamine - transistor eelpingestatakse tootmise ajal seadistatud konstantse pinge tasemega. Veidi arenenuma meetodi puhul kasutatakse temperatuuri tagasisidet, et muuta eel- pinget koos temperatuuri muutumisega. Kui transistorite temperatuuriga seotud omadused on tuntud ja lihtsad, on seda võimalik saavutada lihtsate analoogskee- 25 mide abil. Need meetodid ei tööta hästi, kui eeipinge omadused peavad muutuma kooskõlas sisendvõimsuse tasemetega või kui seda juhitakse eemalt. Ühendriikide patendis US6563385B2 (Xicor, inc., avaldatud 13.05.2003) on kirjel¬ datud meetodeid ja seadmeid raadiosagedusvõimendi (RF-võimendi) alalisvoolu 30 eeipinge reguleerimiseks töötingimuste muutmise eesmärgil, näiteks hulgimodulat-  EE 01564 UI 2 sioonitehnikaid , kui RF puudub. Digitaalselt reguleeritav pingeallikas on program ¬ meeritud sä ilitama võ imendi eelpinget. Pingeallikas võib olla digitaalselt juhitav po- tentsiomeeter. Võimendi alalisvooluvä ljundi voolutugevuse alusel võib leida pinge ja seda võib võ rrelda optimaalse võ imendi eelpinge programmeeritava esindusliku 5 võ rdlusn ä itajaga. Komparaatori vä ljund mää rab kindlaks pingeallika juhtimise suu ¬ na. Digitaalset kella rakendatakse selleks, et juhtida pingeallikat siis, kui RF puudub. Teise võimalusena võib võimendi vä ljundvoolu lugeda protsessori abil , mis mää rab kindlaks optimaalse eelpinge. See eelpinge võ ib olla kirjutatud andmeregistrisse, mis seadistab pingeallika pinge. Sü steem kompenseerib automaatselt võ imendi op¬ 10 timaalse eelpinge muutused , mis on põ hjustatud vananemisest , temperatuurist ja modulatsiooniskeemist. See süsteem loeb informatsiooni vä lisest allikast rakendatud sisendsignaali kohta , seega ei ole seda võimalik h õlpsasti kasutada tundmatute või s ü nkroniseerimata signaalide puhul. 15 LEIUTISE OLEMUS Leiutis käsitleb digitaalse raadiosagedusvõimendi eelpingestamise meetodit. Käesoleva meetodit puhul kasutatakse raadiosagedusvõimendi ( RF-võimendi) tran ¬ sistori eelpinge digitaalseks juhtimiseks võ imendi viimases võimendamisastmes mikrokontrollerit. Digitaalse juhtimise rakendamine muudab võimalikuks muuta tran ¬ 20 sistori eelpinget kooskõlas erinevate andurite sisenditega - temperatuuriga , võim ¬ sustarbega , sisendsignaali taseme ja teiste teguritega . See võ imaldab transistori eelpingestamist ja jä lgimist seoses sisendsignaalidega . See võimaldab n ä iteks seadistada eelpinge signaali puudumise tingimustes ja hoida seda samana , kui signaal on olemas. See on parem kui konstantse vooluga eelpin - 25 gestuslahendused , sest see ei muuda erinevate sisendsignaalide puhul transistori võimendust ja maksimaalset võimsust. Võimalik on kasutada lihtsat , kindlaksmää ¬ ratud eelpinget, et muuta transistor tundetuks signaali tasemete suhtes, aga kind ¬ laksmää ratud eelpingega seadmestikud n õ uavad iga toodetud transistori eelpinge taseme käsitsi h ää lestamist, et see sobiks iga transistori variatsiooniga . 30 Selle meetodi uudsus tuleneb eelpinget juhtiva algoritmi muutmisest võimendi si - sendsignaali jä rgi. Leiutisekohase s üsteemi puhul kasutatakse anduri tagasisidet, et muuta eelpinget siis, kui signaali pole, ja kui signaal on olemas, siis kasutab  EE 01564 UI 3 võimendi mällu salvestatud väärtusi, kuna mõned anduritest, näiteks voolutugevuse puhul, muutuvad koos rakendatava signaaliga. See meetod on kasulik nende süsteemide puhul, mille korral on võimendi saatjast eraldi süsteem. Kontrollerid, mis juhivad transistori eelpinget, võivad tuvastada või¬ 5 mendisse sisse tuleva signaali ja eelpingestada võimendi transistori selle järgi. Va ¬ rasemad signaalist sõltuvad eelpingestamise meetodid nõuavad eraldi signaale, mis näitavad, kas signaal on olemas ja milline on sisendsignaali võimsuse tase. Leiutisekohast meetodit kasutatakse selleks, et reguleerida suure võimsusega mik ¬ rolainete impulssvõimendit. Transistori eelpingestuspunkt määrata kindlaks seeläbi, 10 et mõõdeti toiteallika voolutarvet signaali puudumise tingimustes. Transistori eelpin¬ gestuspunkt salvestatakse säilmälus ja seda on võimalik hiljem meelde tuletada. Digitaalne reguleerimine võimaldab ka rikkeolukordade, näiteks liigvoolu ja liigtem- peratuuri jälgimist. Need rikkeolukorrad võivad põhjustada transistori tõrke, kui neid ei kõrvaldata, Rikkeolukordade kõrvaldamine võimaldab transistori turvaliselt blo ¬ 15 keerida enne pöördumatute kahjustuste ilmnemist. Selleks, et ületada ülalpool selgitatud tehnika taseme kohaseid puudusi, puudutab leiutis meetodit eelpinge digitaalseks reguleerimiseks suletud tagasisideahelaga kontrolleriga, mis on konfigureeritud reguleerima raadiosagedusvõimendi (RF-või- mendi) transistori eelpingestuspunkti, mis hõlmab etappe, 20 mille puhul mõõdetakse pidevalt transistori voolutarvet ja seda võrreldakse eel ¬ nevalt kindlaks määratud voolutugevuse tasemete vahemikuga, mis otsitakse välja kontrolleri mälust, ja nimetatud kontrolleri abil jälgitakse raadiosagedussig- naali (RF-signaali) olemasolu võimendi sisendis, kus raadiosagedussignaali (RF-signaali) olemasolu korral võimendi sisendis ot¬ 25 sitakse kontrolleri mälust välja eelnevalt kindlaks määratud eelpingestuspunkt ja seda rakendatakse transistorile ning jätkatakse transistori voolutarbe mõõtmist ja kus raadiosagedussignaali (RF-signaali) puudumise korral jätkatakse transistori voolutarbe mõõtmist ja seda võrreldakse kontrolleri mälust välja otsitud eelnevalt kindlaks määratud voolutugevuse tasemete vahemikuga jõudeolekus, 30 kus olemasolevat eelpingestuspunkti säilitatakse ja transistori voolutarbe mõõt ¬ mist jätkatakse, kui mõõdetud voolutarve on kontrolleri mälust välja otsitud eel¬ nevalt kindlaks määratud vahemikus, ja  EE 01564 UI 4 kui transistori voolutarve on väljaspool nimetatud eelnevalt kindlaks määratud va ¬ hemikku, siis reguleeritakse nimetatud transistori eelpinget kontrolleriga kontrol¬ leri mälust välja otsitud eelnevalt kindlaks määratud eelpingestuspunkti järgi ja voolutarvet mõõdetakse uuesti. 5 Leiutise veel ühe teise teostuse kohaselt jälgib nimetatud kontroller lisaks transistori temperatuuri ja reguleerib eelpinget kontrolleri mälust välja otsitud eelnevalt kind¬ laks määratud eelpingestuspunkti järgi. Leiutise veel ühe teise teostuse kohaselt jälgib nimetatud kontroller lisaks transistori voolutarvet ja reguleerib eelpinget ning lülitab toiteallika iiigvoolu esinemise korral 10 välja. Leiutise veel ühe teise teostuse kohaselt peab nimetatud kontroller digitaalsete lii ¬ deste vahenduse! lisaks sidet teiste süsteemidega, et anda tagasisidet ja võtta vastu käske, mis muudavad kontrolleri mälu sisu. JOONISTE LÜHIKIRJELDUS 15 Joonisel fig 1 on näidatud leiutisekohase süsteemi skemaatilist elektroonilist ülevaa ¬ det - peamise raadiosagedussignaali teed on näidatud rasvases kirjas noolte abil, digitaalseid signaale on näidatud katkendjoontega noolte abil. Joonisel fig 2 on illustreeritud leiutisekohaselt rakendatavat algoritmi. LEIUTISE TEOSTAMISED 20 Joonise fig 1 kohaselt on sellel kujutatud leiutisekohase süsteemi skemaatilist elekt ¬ roonilist ülevaadet. Järgnevalt on toodud kirjelduses ja joonistel kasutatud elementide viitenumbrid, kus 101 on mikrokontroller, 102 on võimsuslüliti, 103 on võimendi transistor, 104 on eel- pinge tase, 105 on võimsusandur, 106 on suunakompleks, 107 on RF-i sisendport, 25 108 on RF-i väljundport ja 109 on voolutugevuse mõõtmise skeem. RF-signaal siseneb joonisel RF-i sisendpordi 107 kaudu. Siis liigub signaal läbisuu- nakompleksi 106, mis suunab ümber väikse, aga hästituntud osa sisendsignaali võimsusest. Suurem osa signaalist liigub edasi võimendi transistorisse 103. Võimendatud signaal väljub süsteemist transistori kaudu läbi RF-i väljundpordi 108. 30 Suunakompleksi 106 abil ümber suunatud signaal liigub võimsusandurisse 105.  EE 01564 UI 5 Võ imsusandur 105 koosneb logaritmilisest võ imendist, et lineariseerida võ imsuse tase ja analoog-digitaalmuundur. Informatsioon digitaliseeritud võ imsuse taseme kohta liigub sisendina kasutamiseks algoritmi kä itavasse mikrokontrollerisse 101. Mikrokontroller võ ib kasutada võ im ¬ 5 suse taset ja muud informatsiooni , et juhtida transistori võ imsusl ü litit 102 ja eelpinge taset 104. Võimsusl ü litil 102 on sisseehitatud temperatuuri- ja liigvoolukaitse ning see on transistori peavoolutoite l ü liti. VÕimsusl ü liti 102 ja transistori 103 energiaga varustamise sisendi vahel asub voolutugevuse mõõtmise skeem 109. See mõõdab transistori voolu tarbimist, et mikrokontroller saaks seda käsutada al¬ 10 goritmi sisendina . Eelpinge taseme kontroller 104 koosneb digitaalanaloogmuundu - rist , võimendist, et reguleerida pinge tasemed vahemikku , mis on vajalik transistori ja signaali n õutava filtreerimise jaoks. Joonisel fig 2 on illustreeritud rakendatud algoritmi , mille puhul kasutatakse transis¬ tori eelpingestamiseks sisendsignaali võimsuse taset. Programm alustab stabiilses 15 olekus (etapp 201 ). Siis kontrollib see seda , kas transistori sisendis esineb m õ ni RF- signaal (etapp 202). Kui signaali olemas ei ole , rakendab see transistorile salvestatud eelpingestuspunkti (etapp 203). Kui signaali olemas ei ole (etapp 202) , mõõdab see transistori voolutarvet (etapp 20 204) ja võ rdleb seda soovitud voolutugevuse tasemega jõ udeolekus (etapp 205). Kui mõõdetud voolutugevuse tase on vastuvõetavas vää rtuste vahemikus , siis voo¬ lutugevuse eelpingestuspunkt salvestatakse (etapp 207) ja algoritm jä tkab eelpinge seadistamisega (etapp 203) ning liigub tagasi algusesse (etapp 201). Kui transistori voolutarve on soovitud vahemikust vä ljas (etapp 205) , siis eelpinge 25 kompenseeritakse (etapp 206) ja voolutarvet m õõdetakse uuesti (etapp 204). See eelpingestusmeetod on kasulik selleks , et ehitada suure võ imsusega ja RF- võ imendeid eelkõ ige tundlike ja ü lesannete tä itmiseks oluliste rakenduste jaoks. See meetod on eriti kasulik võ imendite puhul , mida kasutatakse koos signaaliallika- tega , mida ei ole võ imalik muuta võ i h õlpsasti vä liste s üsteemidega ü hendada .  EE 01564 UI 6 KASULIKU MUDELI NÕUDLUS . 1 Meetod raadiosagedusvõimendi transistori eeipinge digitaalseks reguleerimi ¬ seks suletud tagasisideahelaga kontrolleriga, mis on konfigureeritud juhtima raadio¬ sagedusvõimendi transistori eelpingestuspunkti, mis hõlmab etappe, mis erinevad 5 selle poolest , et transistori voolutarvet mõõdetakse pidevalt ja seda võrreldakse kontrolleri mälust välja otsitud eelnevalt kindlaks määratud voolutugevuse tasemete vahemikuga ja nimetatud kontrolleri abil jälgitakse raadiosagedussignaali olemasolu transistori sisendis, io kus raadiosagedussignaali olemasolu korral transistori sisendis otsitakse kontrol¬ leri mälust välja eelnevalt kindlaks määratud eelpingestuspunktja seda rakenda¬ takse transistorile ja transistori voolutarbe mõõtmist jätkatakse ja kus raadiosagedussignaali puudumise korral jätkatakse transistori voolutarbe mõõtmist ja seda võrreldakse kontrolleri mälust välja otsitud eelnevalt kindlaks 15 määratud voolutugevuse tasemete vahemikuga jõudeolekus, kus olemasolevat eelpingestuspunkti säilitatakse ja transistori voolutarbe mõõt¬ misega jätkatakse, kui mõõdetud voolutarve on kontrolleri mälust välja otsitud eelnevalt kindlaks määratud vahemikus, ja kui transistori voolutarve on nimetatud eelnevalt kindlaks määratud vahemikust 20 väljas, siis reguleeritakse nimetatud transistori eelpinget kontrolleriga kontrolleri mälust välja otsitud eelnevalt kindlaks määratud eelpingestuspunkti järgi ja voo¬ lutarvet mõõdetakse uuesti. 2. Meetod vastavalt nõudluspunktile 1, mis erineb selle poolest , et nimetatud kontrolleriga jälgitakse lisaks transistori temperatuuri ja reguleeritakse transistori 25 eelpinget kontrolleri mälust välja otsitud eelnevalt kindlaks määratud eelpingestus¬ punkti järgi. 3. Meetod vastavalt nõudluspunktile 1, mis erineb selle poolest , et nimetatud kontrolleriga jälgitakse lisaks transistori voolutarvet ja reguleeritakse transistori eel¬ pinget ning lülitatakse liigvoolu esinemise korral toiteallikas välja. 30 4. Meetod vastavalt nõudluspunktile 1 , mis erineb selle poolest , et nimetatud kontrolleriga peetakse digitaalsete liideste abil lisaks sidet teiste süsteemidega, et anda tagasisidet ja võtta vastu käske, mis muudavad kontrolleri mälu sisu.  Koostatud:21.10.2025 16:41:35 Konto väljavõte Organisatsioon: KAITSEMINISTEERIUM E-konto number: 2800082844 EUR tulukonto KV10415,10230-10236 Kaitsevägi K600 Töökood Kuupäev Dokumendi Maksja/saaja Maksja/saaja konto Maksja/saaja nimi Viitenumber Summa Kande Kande Summa number regsitrikood kande valuuta valuuta konto valuutas kurss valuutas Panga arhiveerimiskood Eelarve Selgitus 20220405000265194265 05.04.2022 12494266 EE247700771003613370 Milrem AS 10415107493823 35 800.00 EUR 1.0000000 35 800.00 FF08E4DBD8B4EC11A2E400155DA95D0B Arve 10749382 Periood 05.04.2022 - 05.04.2022 Perioodi algjääk: 3 913 196.73 Perioodi kreeditkäive: 0.00 Perioodi deebetkäive: 35 800.00 Perioodi lõppjääk: 3 948 996.73 Hetkeseisuga 21.10.2025 kell 16:41 Vabad vahendid: 5 712 965.90 Reserveeritud:: 0.00 Kinnitan: Kinnitan: asutuse juht juhataja raamatupidamise eest vastutav isik peaspetsialist pitsat pitsat  Koostatud:21.10.2025 16:51:38 Konto väljavõte Organisatsioon: KAITSEMINISTEERIUM E-konto number: 2800082844 EUR tulukonto KV10415,10230-10236 Kaitsevägi K600 Töökood Kuupäev Dokumendi number Maksja/saaja Maksja/saaja konto Maksja/ Viitenumber Summa Kande Kande Summa regsitrikood saaja nimi kande valuuta valuuta konto valuutas kurss valuutas Panga arhiveerimiskood Eelarve Selgitus 20221202000283610151 02.12.2022 960535924353161671 12494266 EE247700771003613370 Milrem AS 10415108269108 116 200.00 EUR 1.0000000 116 200.00 RO3274488602L02 10826910 Periood 13.05.2022 - 13.12.2022 Perioodi algjääk: 4 351 757.46 Perioodi kreeditkäive: 0.00 Perioodi deebetkäive: 116 200.00 Perioodi lõppjääk: 4 467 957.46 Hetkeseisuga 21.10.2025 kell 16:51 Vabad vahendid: 5 712 965.90 Reserveeritud:: 0.00 Kinnitan: Kinnitan: asutuse juht juhataja raamatupidamise eest vastutav isik peaspetsialist pitsat pitsat  TEADUS- JA ARENDUSTÖÖ LEPING Käesoleva teadus- ja arendustöö lepingu (Leping) on selle digiallkirjastamise kuupäeval sõlminud: (1) Milrem AS, registrikood 12494266, asukoht Betooni tn 1, Tallinn 13619 (Tellija), mida esindab juhatuse liige Kuldar Väärsi ja (2) Kaitseväe Akadeemia, asukoht Riia 12, Tartu 51010 (Töövõtja), mida esindab Kaitseväe põhimääruse § 20 lg 3 p 3 ja Kaitseväe Akadeemia põhimääruse § 5 lg 2 p 3 ja § 6 lg 1 alusel akadeemia ülem kolonel Vahur Karus, edaspidi eraldi nimetatud ka kui Pool või koos kui Pooled, VÕTTES ARVESSE A. Tellija kuulub Euroopa ettevõtete konsortsiumisse, mis on sõlminud toetuse lepingu Euroopa Komisjoniga, eesmärgiga viia läbi Euroopa kaitsevaldkonna tööstusliku arendamise programmi projekti “Development of an integrated Modular Unmanned Ground System“ (iMUGS projekt), kus Tellija tegutseb konsortsiumi koordinaatorina; B. Vastavalt Euroopa Komisjoniga sõlmitud toetuse lepingule toimub projekti tööde vastuvõtmine ja kvaliteedi hindamine projektis osalevate liikmesriikide esindajate poolt loodud komisjonis (Project Office), mis kinnitab tingimustele vastava töö vastava sertifikaadiga nn Certificate of Conformity; C. Tellija on iMUGS projektis registreerinud Töövõtja oma ametlikuks alltöövõtjaks ning käesoleva Lepinguga soovivad pooled kokku leppida alltöövõtu täpsemates tingimustes. POOLED ON SÕLMINUD LEPINGU ALLJÄRGNEVATEL TINGIMUSTEL: 1. LEPINGU ESE JA TÖÖ TEOSTAMISE TÄHTAEG 1.1 Tellija tellib ja Töövõtja viib läbi Lepingu tingimuste kohaselt teadus ja arendustöö, mille sisuks on uuringute läbiviimine mehitamata maismaasõidukite süsteemide kasutamise osas. Uuringud tuleb teostada inglise keeles ning läbi viia vastavalt iMUGS-i toetuse lepingus sätestatud tingimustele (Lisa 1: Toetuse lepingu lisa 1) ning projekti partnerite vahel eraldi kokku lepitud tingimustele (Lisa 2: Tingimused, ID viited 183, 184 ja 185) (Töö). Töö on jaotatud kolmeks eraldiseisvaks uuringuks: 1) Uuring 1: “Study on the use of UGS in the context of customary law of war and applicable to EU and national legislation”; 2) Uuring 2: “Study of attitudes of military personnel and general population towards the use of unmanned platforms”; 3) Uuring 3: “Study of ethical aspects regarding MUGS employment in operational context” 1.2 Töö raames teostatavad uuringud esitatakse Tellijale hiljemalt: 1) Uuring 1 – 01.06.2022; 2) Uuring 2 – 01.02.2022; 3) Uuring 3 – 01.06.2022. Lk 1 / 5 2. LEPINGU DOKUMENDID 2.1 Leping koosneb Lepingu tekstist, selle lisadest ja Poolte kirjalikest kokkulepetest mistahes Lepingu muudatuste või täienduste kohta, mis sõlmitakse pärast Lepingu jõustumist. Kui Lepingu ja sellele allkirjastamise hetkel lisatud lisade vahel esineb lahknevusi, on ülimuslik Lepingu tekst. Kui Lepingu ja selle lisade ning hiljem allkirjastatud Lepingu lisade või hilisemate kirjalike lepingute vahel esineb lahknevusi, on ülimuslikud hilisemad lisad ja kirjalikud lepingud. 2.2 Lepingu allkirjastamisel on sellel järgmised lisad: 1) Lisa 1 – Toetuse lepingu lisa 1; 2) Lisa 2 – Tingimused. 3. TÖÖ ÜLEANDMINE JA VASTUVÕTMINE 3.1 Töö raames teostatavad uuringud antakse Tellijale üle eraldiseisvalt ning iga uuringu üleandmine ja vastuvõtmine toimub käesolevas peatükis sätestatud korras. 3.2 Töövõtja teavitab uuringu valmimisest viivitamata Tellijat ning esitab uuringu ülevaatamiseks Tellijale elektroonselt e-posti teel. Töövõtja kohustub koos uuringuga Tellijale üle andma kõik olemuslikult uuringu juurde kuuluvad dokumendid. 3.3 Tellija korraldab mõistliku aja jooksul pärast seda, kui Töövõtja on Tellijat uuringu valmimisest teavitanud uuringu vastavuse hindamiseks koosoleku koos Project Office’ga, kus Töövõtja esitleb uuringu tulemusi. 3.4 Uuring loetakse Tellija poolt vastuvõetuks kui Project Office kinnitab uuringu Certificate of Conformity’ga. 3.5 Kui Project Office esitab pretensioone uuringu kohta kohustub Töövõtja kõrvaldama puudused uuringus mõistliku aja jooksul peale puudustest teavitamist ning esitama uuringu uuesti üle vaatamiseks Tellijale ja Project Office’le. 4. TASU 4.1 Tellija maksab Töövõtjale nõuetekohase Töö teostamise eest kokku 152 000 eurot (Tasu), millele lisandub seaduses sätestatud käibemaks. Tasu jaotub uuringute vahel järgmiselt: 1) Uuring 1 - 58 700 eurot (ilma KM-ta); 2) Uuring 2 - 35 800 eurot (ilma KM-ta); 3) Uuring 3 - 57 500 eurot (ilma KM-ta) 4.2 Tellija maksab Töövõtjale Tasu iga nõuetekohaselt tehtud uuringu eest eraldi vastavalt Töövõtja poolt esitatud arvele, mille maksetähtaeg ei ole lühem kui 30 kalendripäeva. 4.3 Töövõtjal on õigus esitada Tellijale arve alates vastava uuringu kinnitamisest Certificate of Conformity’ga vastavalt punktile 3.4. Arve loetakse tasutuks, kui kogu arvel näidatud summa on laekunud Töövõtja arveldusarvele. 5. POOLTE ÕIGUSED JA KOHUSTUSED 5.1 Töövõtja kohustub: 5.1.1 teostama Töö vastavalt Lepingule, kehtivatele õigusaktidele ja Tellija juhistele; 5.1.2 järgima Töö teostamisel ja korraldamisel Tellija mõistlikke huve ja eesmärke ning kõiki Tellija poolt antud seaduslikke juhiseid; 5.1.3 viivitamata pöörduma Tellija poole juhiste saamiseks, kui need on vajalikud Töö teostamiseks; Lk 2 / 5  5.1.4 teavitama Tellijat viivitamatult kõikidest asjaoludest, mis mõjutavad Töö teostamist või Töövõtjapoolsete muude Lepinguliste kohustuste täitmist ning mille vastu on Tellijal mõistlik huvi; 5.1.5 hankima kõik Töö teostamiseks vajalikud materjalid; 5.1.6 ilma eraldi kokkuleppeta teostama ka sellised tööd ja toimingud, mis ei ole Lepingus ega selle lisades selgesõnaliselt ette nähtud, kuid mille tegemine on tavapäraselt vajalik Lepingu kohaseks täitmiseks ja eesmärgi saavutamiseks ning mis olemuslikult kuuluvad Töö hulka; 5.1.7 tagama Töö käigus valmivate dokumentide vastavuse kehtivatele õigusaktidele ja Lepingule; 5.1.8 mitte rikkuma Tellijale või kolmandatele isikutele kuuluvaid õigusi, sh intellektuaalse omandi õigusi ning tagama, et Töövõtjal oleks kõik õigused anda Töö Tellijale üle vastavalt käesolevas Lepingus sätestatule; 5.2 Töövõtjal on õigus: 5.2.1 nõuda Tellijalt juhiseid, kui need on vajalikud Töö teostamiseks; 5.2.2 peatada Töö teostamine, kui Töövõtja on nõudnud Tellijalt juhiseid ja Tellija ei ole mõjuva põhjuseta neid mõistliku aja jooksul andnud; 5.2.3 saada Töö teostamise eest tasu vastavalt Lepingule. 5.3 Tellija kohustub: 5.3.1 andma Töövõtjale viivitamata juhiseid, kui need on vajalikud Töö teostamiseks; 5.3.2 andma viivitamata Töövõtjale üle kõik Töö teostamiseks vajalikud lähteandmed; 5.3.3 Töö valmimisel korraldama Töö üle vaatamise ja koos Project Office’ga selle vastu võtma või vastuvõtmisest keelduma mõistliku aja jooksul pärast seda, kui Töövõtja on Tellijat Töö valmimisest teavitanud ning seda Tellijale ja Project Office’le esitlenud; 5.3.4 maksma Töövõtjale valminud Töö eest tasu vastavalt Lepingule; 5.3.5 teavitama Töövõtjat koheselt kõikidest asjaoludest, mis mõjutavad Tellijapoolsete Lepinguliste kohustuste täitmist ning mille vastu on Töövõtjal mõistlik huvi; 5.3.6 Töös puuduse avastamisel teavitama Töövõtjat avastatud puudusest mõistliku aja jooksul pärast puuduse avastamist; 5.3.7 Töös avastatud puudusest teavitamisel kirjeldama avastatud puudust võimalikult täpselt. 5.4 Tellijal on õigus: 5.4.1 igal ajal tutvuda Töö käiguga, välja arvatud juhul, kui see segaks oluliselt Töö teostamist; 5.4.2 Töös esinevate puuduste korral nõuda Töö vastavusse viimist Lepingu tingimustega; 5.4.3 kõrvaldada Töös esinev puudus ise või lasta see kõrvaldada kolmandal isikul juhul, kui Töövõtja ei kõrvalda Töös esinevat puudust mõistliku aja jooksul pärast Tellijapoolset puudusest teavitamist; 5.4.4 nõuda Töövõtjalt Töö puuduse kõrvaldamisega seotud kulutuste hüvitamist; 5.4.5 jätta Töö vastu võtmata, kui Töös esineb puudusi, välja arvatud pisipuudused, mis ei takista Töö tulemuse kasutamist; 5.4.6 keelduda Töö eest tasumast kui Töö ei vasta Lepingutingimustele, muuhulgas kui Lepingutingimustele ei vasta Töö juurde kuuluvad dokumendid või sellised dokumendid on Tellijale üle andmata. Lk 3 / 5 6. INTELLEKTUAALNE OMAND 6.1 Töövõtja annab Lepingu täitmise käigus loodud Töö omandiõiguse ja loovutatavad intellektuaalomandiõigused (sh autori varalised õigused, õigus esitada taotlus kaubamärgi, patendi, kasuliku mudeli, tööstusdisainilahenduse või mikrolülituse topoloogia registreerimiseks, samuti õigused tundmatutele kasutusviisidele, mis tekivad tulevikus) Lepingus või Eesti Vabariigi seadustes sätestatud maksimaalses ulatuses Töö üleandmisega üle Tellijale mistahes täiendava toimingu või tahteavalduseta. 6.2 Töövõtja annab Töövõtjale kuuluvate või temale litsentsi alusel kasutusse antud võõrandamatute, ent litsentseeritavate õiguste osas Tellijale tagasivõetamatu ainulitsentsi Töövõtjale kuuluvate võõrandamatute õiguste kasutamiseks ja/või teostamiseks maksimaalses kohalduva õiguse alusel lubatud ulatuses ilma geograafiliste piiranguteta ning ilma piiranguteta kasutamise viisi, eesmärgi ja kasutajate ringi suhtes. Litsents on ülemaailmne ja loovutatav ning sisaldab õigust luua teoste põhjal tuletatud teoseid, väljastada all-litsentse nii kolmandatele isikutele kui ka üldsusele, süstematiseerida ja lülitada teosed kogumikku, kasutada teost kollektiivse teose või andmebaasi loomiseks, samuti kasutada teose eri osi ja elemente tulemusest eraldi isegi juhul, kui need on salvestatud koos ja moodustavad ühtse terviku. Ainulitsents kehtib alates vastava õiguse tekkimisest kuni litsentsitud intellektuaalse omandi õiguse kehtivuse tähtaja lõppemiseni. 6.3 Kahtluste vältimiseks on Pooled kokku leppinud, et Töövõtja kohustub piirama oma intellektuaalse omandi õiguste teostamist järgmiselt: 6.3.1 kui Töövõtja on Töö Tellijale üle andnud või muul moel Tellijale kättesaadavaks teinud, võib Tellija otsustada, kas Töö on sellisel kujul valmis avaldamiseks kolmandatele isikutele või avalikkusele. Töövõtja ei tee Tellijale takistusi Töö avaldamiseks. Töövõtja ei või ise ilma Tellija eelneva kirjaliku nõusolekuta Tööd avaldada; 6.3.2 Nii Tellija kui ka kolmandad isikud võivad Tellija nõusolekul või heakskiidul muuta, parandada ja täiendada Tööd ning lisada Tööle teiste autorite loomingut ja muid materjale, mida Tellija peab vajalikuks. 6.4 Töövõtjal on õigus kasutada Tööd enda teadustöödes ja/või publikatsioonides tingimusel, et avalikustatava teabe sisu, koht, viis ja aeg kooskõlastatakse eelnevalt kirjalikult Tellijaga. Tellija vastab Töövõtja vastavasisulisele päringule 20 tööpäeva jooksul alates päringu saamisest. Kui Tellija päringule ei vasta, loetakse, et Tellija nõustub Tulemi kasutamise lubamisega päringus märgitud viisil. 6.5 Pooled on leppinud kokku, et tasu intellektuaalse omandi ja kaasnevate õiguste Tellijale loovutamise ja litsentsi andmise eest sisaldub Tasus. 6.6 Töövõtja kohustub tagama, et tema poolt Töö tegemisel loodavad intellektuaalse omandi objektid on loodud Töövõtja poolt ega kahjusta mistahes kolmanda isiku autori- või mistahes muid intellektuaalse omandi õigusi. Kui Töövõtja on teose loomisel rikkunud kolmandate isikute õigusi ning Tellija on sellega seoses kohustatud hüvitama kolmandale isikule tekitatud varalise ja/või mittevaralise kahju, on Töövõtja kohustatud Tööandja poolt maksmisele kuuluvad summad ning sellega seoses kantavad kulutused ja kahju Tellijale hüvitama. 7. POOLTE VASTUTUS 7.1 Kui Tellija viivitab Töövõtjale tasu maksmisega, siis on Töövõtjal õigus nõuda Tellijalt viivist 0,05% päevas viivitatud summalt iga tasumisega viivitatud päeva eest. 7.2 Töö valmimise, üleandmise või Töös esineva puuduse kõrvaldamisega viivitamisel kohustub Töövõtja tasuma Tellijale leppetrahvi 0,05% valmimata, üle andmata või puudusega Töö maksumusest päevas iga viivitatud päeva eest. Tellija kohustub leppetrahvi nõudmisest Töövõtjat teavitama mõistliku aja jooksul pärast seda, kui ta Töövõtjapoolsest viivitusest teada sai. Lk 4 / 5 8. KEHTIVUS JA LÕPPEMINE 8.1 Kumbki Pool võib Lepingust taganeda, kui teine Pool on Lepingut oluliselt rikkunud ja rikkuv Pool ei ole heastanud rikkumist täiendava mõistliku tähtaja jooksul, mis ei tohi olla lühem kui 30 kalendripäeva. 8.2 Kui Tellija ütleb käesoleva Lepingu üles või loobub Töö edasisest tellimisest, on Töövõtja õigustatud saama tasu enne katkestamise hetke faktiliselt teostatud Töö eest. 9. TEATED 9.1 Kõik Lepingu kohased teated, nõuded, pretensioonid või muud teated edastatakse eesti keeles, ning kirjalikku taasesitamist võimaldavas vormis teisele Poolele järgmistel kontaktandmetel: Kaitseväe Akadeemia: Milrem AS: Raul Järviste Silver Lätt Riia 12, Betooni tn 1 51010 Tartu Tallinn 13619 e-mail: [email protected] e-mail: [email protected] või mõnele muule kontaktaadressile, mille vastav Pool võib edaspidi teisele Poolel täpsustada kirjalikult. 9.2 Pooled teatavad teineteisele viivitamata kõigist muudatustest oma kontaktandmetes. Kuni sellise teate kättesaamiseni loetakse ülal nimetatud kontaktandmetele edastatud teated nõuetekohaselt edastatuks. 10. LÕPPSÄTTED 10.1 Leping jõustub selle digiallkirjastamise hetkest mõlema Poole poolt ning on kehtiv kuni Poolte kohustuste täitmiseni Lepingu alusel. 10.2 Töövõtja peab hoidma saladuses talle seoses Lepingu täitmisega teatavaks saanud asjaolusid, mille saladuses hoidmiseks on Tellijal õigustatud huvi (sealhulgas, kuid mitte ainult asjaajamist ja majandustegevust puudutavat teavet) arvestades Poolte äritegevuses väljakujunenud tavasid ja praktikat. 10.3 Lepingut võib muuta või täiendada ainult Poolte sellekohasel kirjalikul kokkuleppel. Kirjaliku vormi järgimata jätmine on tühine. Kõik Lepingu muudatused vormistatakse kirjalikult Lepingu lisana, mis on Lepingu lahutamatuks osaks. 10.4 Kumbki Pool ei tohi käesolevast Lepingust tulenevaid õigusi ja kohustusi üle anda kolmandale isikule ilma teise Poole kirjaliku nõusolekuta. 10.5 Lepingu suhtes kohaldatakse Eesti Vabariigi õigust. 10.6 Pooled lahendavad Lepingust tulenevad vaidlused heas usus läbirääkimiste teel. Kokkuleppe mittesaavutamise korral lahendatakse vaidlused Harju Maakohtus. 10.7 Lepingu tingimusteks ei loeta Poolte varasemaid tahteavaldusi ega kokkuleppeid, mis ei ole Lepingus otseselt sätestatud. Samuti ei oma Lepingu suhtes tähendust Poolte varasem käitumine. KINNITAMAKS EELTOODUT on Pooled allkirjastanud käesoleva Lepingu /allkirjastatud digitaalselt/ /allkirjastatud digitaalselt/ Milrem AS Kaitseväe Akadeemia Kuldar Väärsi kolonel Vahur Karus Lk 5 / 5  iMUGS-Decomposition of MUGS Requirements EDIDP-MUGS-2019-002-iMUGS COMPANY CONFIDENTAL iMUGS: Decomposition of the MUGS high level requirements as agreed in the 23.08.2019 signed Letter of Intent between participating Member States Decomposed Sections: VII Operational Requirements for MUGS VIII Technical Requirements for MUGS IX Requirements for development activities Sections V and VI not addressed Prepared by S.Lätt/SA/PCO Reference 10PCO005 Issue 2 Revision 0 Date of issue 07.12.2020 Status Issued for approval Document type Requirements specification Classification COMPANY CONFIDENTIAL 10PCO005 Iss 2 Rev 0 Page i of ii  iMUGS-Decomposition of MUGS Requirements EDIDP-MUGS-2019-002-iMUGS COMPANY CONFIDENTAL Decomposed Requirements Specification Reference 10PCO005 – iMUGS - ORS Document type Requirements Specification Classification COMPANY CONFIDENTIAL Location iMUGS PDM Approval Title 10PCO005 iMUGS: Decomposed Requirements Specification (Compliancy Matrix) Issue 2 Revision 0 Author S.L./SA/PCO Date 07.12.2020 Change log Reason of change Issue Rev Date Issued for acceptance to pMS QAM 1 0 30.10.2020 Template update; added legend and missing SP no, removed empty lines 162.6 and 86.3, renumbered 086.4-.6 to .3-.5. Issued for acceptance to pMS QAM and iMUGS Consortium 2 0 07.12.2020 Distribution Receiver Issue Rev Date pMS QAM PM and consequent reviewers 2 0 07.12.2020 iMUGS Consortium Partners (Industry) 2 0 07.12.2020 Initial Issue Signatures Date: __________________ Date: __________________ ________________________________ ________________________________ PCO pMS QAM PM 10PCO005 Iss 2 Rev 0 Page ii of ii EDIDP-MUGS-2019-002-iMUGS Original pMS definition is identifed as cells with background color, contrary to respective decomposed requirements without color. COMPANY CONFIDENTIAL DEMO MoM ID / ID Ref. MR ID pMS High Level Requirements (HLR) iMUGS Decomposed Mission (Operational) Requirement Req Type SOC SP NO Date Accepted 001 V.A. Section V – OPERATIONAL CHALLENGES Heading Noted 002 V.A. Known and unknown emerging technologies create a wide range of opportunities and possibilities to employ new ways and means on the battlefield. Heading Noted 003 V.A. New technologies are developed simultaneously in every continent and therefore, industry-academia-state cooperation, innovation, agility, investments in Heading Noted technology and critical thinking are substantial factors to create a competitive technological advantage to protect national and European interests. 004 V.B. Specific challenges to be taken into consideration within the scope of the Project include, without necessarily being limited to: Heading Noted 005 V.B.a. The reduced acceptance of the loss of human life in society leads to the expectation that future wars should be fought using combined unmanned and autonomous Heading Noted systems to accomplish missions with the least possible risk to soldiers. 006 V.B.b. Interoperability complexity will increase due to human-machine collaboration, a growing number of assets, processing power needed, big data analytics, throughput Heading Noted challenges and other communication/information systems limitations. 007 V.B.c. It is highly likely that the center of gravity in future wars will be population-related with military activities concentrated in and around cities, natural resources Heading Noted (including water), lines of communication, and energy/power. 008 V.B.d. The “face” of warfare may look hybrid, and it is becoming extremely hard to distinguish enemy from friend while operating in complex environments. Heading Noted 009 V.B.d. Meaningful human control over all autonomous systems remains critical. Note Noted 010 V.B.d. However, assistance from machine learning and AI for effective decision-making (e.g. positive identification, rules of engagement, etc.) will deliver a competitive Note Noted advantage on the battlefield. 011 V.B.e. Collateral damage risks increase due to the population density in operational theatres and require an accurate, up-to-date common operational picture and adequate Heading Noted information management for precise targeting. 012 V.B.f. Information is power. Heading Noted 013 V.B.f. Sensors and information gathering tools are more accessible than before. Note Noted 014 V.B.f. The amount of raw data and information continues to increase and requires enormous information systems to enable data fusion to obtain actionable intelligence. Note Noted 015 V.B.f. Artificial intelligence, machine learning and processing power are the key enablers to establish a common situational understanding and timely-made, informed Note Noted decisions. 016 V.B.g. Modern battlefield is based on co-operating units and systems creating network-enabled capabilities. Heading Noted 017 V.B.g. Thus networking is an essential force multiplier. Note Noted 018 V.B.h. Increasing Electronic Warfare and Cyber (EW&C) threats require capabilities to detect jamming and intrusion and to protect (limit and recover) the MUGS from their Heading Noted effects. 019 V.B.i. Access to position, navigation and timing is and will be more crucial than ever before, making autonomy and alternative navigation methods mission critical Heading Noted elements. 020 V.B.j. System autonomy has developed significantly over the last decade, thus minimizing the need for direct control over assets. Heading Noted 021 V.B.j. The nature of the human-machine interaction will continue to evolve in the future. Note Noted 10PCO005_2 Sub-Project for responsibility; SP1 = Integ.; SP2 = Aut.; SP3 = Cyber; SP4 = Comms; SP5 = Swarm.; SP6 = C2; SP7 = MUM-T. Demo No is for indication only. 1 / 29 EDIDP-MUGS-2019-002-iMUGS Original pMS definition is identifed as cells with background color, contrary to respective decomposed requirements without color. COMPANY CONFIDENTIAL DEMO MoM ID / ID Ref. MR ID pMS High Level Requirements (HLR) iMUGS Decomposed Mission (Operational) Requirement Req Type SOC SP NO Date Accepted 022 V.B.k. Globalization and international crises require readiness to conduct operations outside of the home country (expeditionary force). Heading Noted 023 V.B.k. New capabilities will be rapidly deployable, independent and require limited assistance to perform their duties. Note Noted 024 V.B.l. Use of off-the-shelf products increases among the Participants involved in combat activities. Heading Noted 025 V.B.l. It increases security risks for the users but also introduces exploitation opportunities. Note Noted 026 V.B.l. Off-the-shelf products may give enormous advantage in specific situations. Note Noted 027 V.B.l. The ability to control third-party, off-the-shelf resources in the operational environment works as a capability multiplier. Note Noted 028 V.B.m. New weapon systems (laser, acoustic, railguns, etc.) provide new opportunities, but on the other hand lead to new requirements and demands for force protection Heading Noted and operational security. 029 V.B.n. Psychological Operations and Internet Influence Operations are increasing and target primarily non-combatant audiences to tailor their preferences, giving both Heading Noted friendly and adversary forces an ability to quickly change the permissiveness of an operations area. 030 V.B.o. The need for longer endurance challenges the energy sector and technology development. Heading Noted 031 V.B.o. The introduction of alternative energies may change the battlefield and require readiness to adopt and implement new power systems. Note Noted 032 V.B.p. Emerging technologies allow to build greater overmatch distances to affect adversaries and, on the other hand, require advanced force protection measures from Heading Noted adversaries’ assets. 033 VI. Section VI – MUGS DESIGN PRINCIPLES AND OPERATIONAL USE CASES Heading Noted 034 VI.A. The MUGS will be a modular unmanned systems with autonomous and semi-autonomous features and deployable capability that provides the battle group or Heading Noted company commander CSS, which requires only limited/minimum man-in-the-loop involvement. 035 VI.A. MUGS will be designed for operations encompassing the entire spectrum of conflict from permissive to denied environments. Note Noted 036 VI.A. Depending on the payload, MUGS will fight battles and engagements by employing the tactical advantages of unmanned arms structure and will be used as an Note Noted enabler for supporting missions like resupply and Medical Evacuation (MEDEVAC). 037 VI.A. MUGS will accomplish its mission by integrating the actions of manned and unmanned ground vehicles, UAS, unmanned sensing systems, EW&C, AI, autonomy, Note Noted swarming, manned-unmanned teaming, and other capabilities derived from emerging technologies. 038 VI.B. MUGS ISTAR assets and automated intelligent information systems will give information superiority over threat forces. Heading Noted 039 VI.B. These assets will enable MUGS to gather large amounts of information, process them rapidly into intelligence, and disseminate them to decision-makers quickly. Note Noted 040 VI.B. AIl elements in the information systems will evaluate reliability and credibility of the gathered data and provide evidence-based conclusions, situational Note Noted understanding and recommendations for further collection or exploitation. 041 VI.C. The MUGS Project will take a fused view of EW&C and fully leverages MUGS' semi-autonomous approach, thereby significantly increasing tactical intelligence for Heading Noted greater situational understanding and informed decision-making effectiveness. 10PCO005_2 Sub-Project for responsibility; SP1 = Integ.; SP2 = Aut.; SP3 = Cyber; SP4 = Comms; SP5 = Swarm.; SP6 = C2; SP7 = MUM-T. Demo No is for indication only. 2 / 29 EDIDP-MUGS-2019-002-iMUGS Original pMS definition is identifed as cells with background color, contrary to respective decomposed requirements without color. COMPANY CONFIDENTIAL DEMO MoM ID / ID Ref. MR ID pMS High Level Requirements (HLR) iMUGS Decomposed Mission (Operational) Requirement Req Type SOC SP NO Date Accepted 042 VI.C. MUGS will take a modular approach to cyber capabilities, allowing the development and rapid deployment of additional functionality and payloads over time. Note Noted 043 VI.D. By providing processing power and the capability to interact at all layers of the communication stack in the spectrum at the tactical edge, MUGS' cyber capabilities Heading Noted will enhance friendly forces' combat power. 044 VI.D. In terms of cyber protection, the MUGS Project will deliver data integrity protection to protect sensor fusion functions, resilience to cyber-attack through Note Noted autonomous reconfiguration, and cyber supply chain security for all technology providers. 045 VI.E. MUGS will exercise common control over a variety of ground and air systems that are interlinked to the same architecture. Heading Noted 046 VI.E. A Common Control and Management System (CCMS) will allow a single individual to control multiple semi-autonomous systems using the same software suite (user Note Noted interface) and controller, therefore, maximizing the use of assets, sensors, payloads, weapon systems, data/information sharing and decision-making. 047 VI.F. MUGS will be an addition to a platoon- or company-sized infantry unit with the purpose of supporting the infantry unit’s primary role, combat, which may occur in Heading Noted any type of mission, in any theatre or environment. 048 VI.F. MUGS will be capable of moving with an infantry unit in most demanding conditions while raising the unit’s maneuverability by reducing rifleman’s individual Note Noted equipment load required to carry out the mission, making MEDEVAC drills more efficient and less manpower-dependent, and raising unit’s level of readiness, security, firepower, Intelligence, Surveillance, Reconnaissance (ISR) and EW&C capabilities. 049 VI.F. MUGS with a reduced combat payload may be used for resupply missions in a minimum man-in-the-loop mode. Note Noted 050 VI.G. MUGS will have the ability to raise asymmetric effects of use of infantry units on modern battlefield, by providing strategic, operational and tactical advantages, also, Heading Noted will make more complicated and demanding tasks available and possible for light combat and maneuver units. 051 VI.H. Specifically, the possible use cases for MUGS may include, without being limited to: Heading Noted 052 VI.H.a. Remotely-controlled combat activity using Line of Sight (LOS) control. Heading Noted 053 VI.H.a. In this mode, MUGS will be closely working together with fighting unit of platoon size, providing them transportation support and additional sustainability. Note Noted 054 VI.H.a. MUGS will have plenty of options for that, as modular design would enable multiple mission sets, which are all easily serviceable by the unit itself. Note Noted 055 VI.H.a. MUGS will manoeuvre as well as the infantry unit and will not restrict its freedom of manoeuvre or speed. Note Noted 056 VI.H.a. The control of the system will be easily switched from remote-control to semi-autonomous mode (e.g. follow-me, path/trail following, etc), making operating the Note Noted system as seamless as possible. 057 VI.H.a. In both modes, a fratricide avoidance system will provide extra safety for the fighting unit. Note Noted 058 VI.H.b. Remotely-controlled combat activity using Beyond the Line of Sight (BLOS) control. Heading Noted 059 VI.H.b. In this mode MUGS will be used for high-risk missions in the area of responsibility of an infantry company, in order to gather and provide information, security and Note Noted protection for the fighting unit. 060 VI.H.b. By use of various autonomous and automated functions for manoeuvring and data fusion, including swarm intelligence, MUGS will make operating and decision- Note Noted making for the operator as fast as possible. 061 VI.H.b. This will enable the operator to command multiple platforms, on land and in air, at the same time. Note Noted 062 VI.H.b. MUGS will have multiple passive measures for self-protection in order to operate in denied environments, while also not excluding the development of active Note Noted protection measures. 10PCO005_2 Sub-Project for responsibility; SP1 = Integ.; SP2 = Aut.; SP3 = Cyber; SP4 = Comms; SP5 = Swarm.; SP6 = C2; SP7 = MUM-T. Demo No is for indication only. 3 / 29 EDIDP-MUGS-2019-002-iMUGS Original pMS definition is identifed as cells with background color, contrary to respective decomposed requirements without color. COMPANY CONFIDENTIAL DEMO MoM ID / ID Ref. MR ID pMS High Level Requirements (HLR) iMUGS Decomposed Mission (Operational) Requirement Req Type SOC SP NO Date Accepted 063 VI.H.c. Autonomous mode for Logistics, Medical evacuation and force protection missions. Heading Noted 064 VI.H.c. In this mode, MUGS will provide for company-sized unit transportation services from the rear area to the battle area or force protection by screening the unit’s Note Noted perimeter. 065 VI.H.c. For that purpose, MUGS will be able to autonomously operate between multiple checkpoints, as long as the area is pre-mapped by the system before. Note Noted 066 VI.H.c. MUGS may be used for carrying either combat casualties or unit equipment. Note Noted 067 VII Section VII – OPERATIONAL REQUIREMENTS FOR MUGS Heading Noted 068 VII.A. Minimum operational requirements for MUGS developed under the Project are as Heading Noted follows: 069 VII.A.a. Increased situational awareness by using the platform for autonomous and Heading Noted unmanned ISR missions 070 VII.A.a.i. Exploit terrain to expedite tactical movements Heading Noted 071 VII.A.a.i.1. Capable of autonomous multihorizon path planning using data from pre-mapped Requirement Comply 2 5 environment 071.1 iMUGS operators shall be able to import maps from different sources and formats Derived Requirement 071.2 iMUGS shall be capable of mapping its environment during remotly controlled Derived operations within or without line of sight from remote operator. Requirement 071.3 iMUGS operators shall be able to record the maps which has been mapped. Derived Requirement 071.4 iMUGS shall autonomously find a path to one or several waypoints within pre- Derived mapped environment, when it is feasible Requirement 071.5 iMUGS local swarming functions shall use multi-horizon path planning with Derived interface to lower level path planner and with pre-mapped data. Requirement 071.6 Interfaces between different levels of path planners shall be defined. Derived Requirement 071.7 iMUGS global swarming shall deploy multi-horizon path planner as a single Derived process within the network, using shared data of the swarm to coorindate the Requirement swarm as a whole. 072 VII.A.a.ii. Navigate from one point to another Heading Noted 073 VII.A.a.ii.1. Capable of maneuvering autonomously from the Line of Departure to the tasked Requirement Comply 2 5 location. 073.1 iMUGS mobility platofm shall locate itself within pre-mapped environement using Derived GNSS sensor. Requirement 073.2 iMUGS operators shall be able to define the tasked location (a geolocated target Derived waypoint). Requirement 10PCO005_2 Sub-Project for responsibility; SP1 = Integ.; SP2 = Aut.; SP3 = Cyber; SP4 = Comms; SP5 = Swarm.; SP6 = C2; SP7 = MUM-T. Demo No is for indication only. 4 / 29 EDIDP-MUGS-2019-002-iMUGS Original pMS definition is identifed as cells with background color, contrary to respective decomposed requirements without color. COMPANY CONFIDENTIAL DEMO MoM ID / ID Ref. MR ID pMS High Level Requirements (HLR) iMUGS Decomposed Mission (Operational) Requirement Req Type SOC SP NO Date Accepted 073.3 iMUGS operators shall be able to set the maximum speed between each Derived waypoints. Requirement 073.4 iMUGS shall autonomously elaborate actions to move from a point to another, Derived respecting the maximum speed, with performances depending on the Requirement environment and conditions. 073.5 Local swarming shall be developed for maneuvering autonomously from the Line Derived of Departure to the tasked location. Requirement 073.6 The global route planner shall generate individual trails to be followed by Derived individual agents. Requirement 074 VII.A.a.ii.2. Capable of using alternative Global Navigation Satellite System (GNSS) capable of Requirement Comply 2 6 detecting GNSS jamming and spoofing, positioning and navigating in GNSS denied environment, simultaneous location and mapping (SLAM) 074.1 iMUGS shall re-locate itself within pre-mapped environement using passive or Derived active non GNSS sensors, with performances depending on the environment and Requirement conditions. 074.2 iMUGS shall position and navigate within pre-mapped environement using Derived passive or active non GNSS sensors, with performances depending on the Requirement environment and conditions. 074.3 iMUGS shall detect GNSS jamming. Derived Requirement 074.4 iMUGS shall detect GNSS spoofing. Derived Requirement 074.5 iMUGS shall detect inconsistencies between GNSS fleets. Derived Requirement 074.6 iMUGS shall be capable of simultaneous location and mapping, with Derived performances depending on the environment and conditions. Requirement 074.7 Local swarming shall be developed for navigating also in GNSS denied Derived environment using positioning and mapping information from platform sensors. Requirement 074.8 Global swarming shall be designed to use the UWB distance mesh of the fleet and Derived other on board sensors to provide GNSS free positioning, the aim is to have a Requirement sufficiently accurate positioning to enable navigation. 075 VII.A.a.ii.3. Allow a single operator to control multiple systems using the same software suite Requirement Comply 6 6 and controller 075.1 Local swarming shall be developed to act upon operator controls when receiving Derived them. Requirement 075.2 An interface shall be developed to control the fleet as a whole using global Derived swarming Requirement 10PCO005_2 Sub-Project for responsibility; SP1 = Integ.; SP2 = Aut.; SP3 = Cyber; SP4 = Comms; SP5 = Swarm.; SP6 = C2; SP7 = MUM-T. Demo No is for indication only. 5 / 29 EDIDP-MUGS-2019-002-iMUGS Original pMS definition is identifed as cells with background color, contrary to respective decomposed requirements without color. COMPANY CONFIDENTIAL DEMO MoM ID / ID Ref. MR ID pMS High Level Requirements (HLR) iMUGS Decomposed Mission (Operational) Requirement Req Type SOC SP NO Date Accepted 075.3 iMUGS C2 shall allow a single operator to control and monitor several UGVs from Derived the same position. Requirement 075.4 iMUGS Control Station shall be designed to allow integration of a control station / Derived control elements into an Armoured Fighting Vehicle. (Command Vehicle Requirement Configuration) 076 VII.A.a.iii. Conduct a zone reconnaissance Heading Noted 077 VII.A.a.iii.1. Capable of sensing battlefield elements using, for example, onboard, dispersed or Requirement Comply 1 4 tethered electro-optical, thermal, infrared, acoustic, Signal Intelligence (SIGINT) and radar sensors 077.1 Local swarming shall be developed to use available data from the sensors. Derived Requirement 077.2 The global swarming controller shall collect available data on board and forward Derived the necessary information to the global planner Requirement 077.3 iMUGS shall have standardised interfaces for sensors on mobility platform and as Derived payloads. Requirement 078 VII.A.a.iv. Conduct targeting Heading Noted 079 VII.A.a.iv.1. Capable of detecting, classifying, positioning and tracking autonomously different Requirement Comply 2 5 types of pre-determined objects on the battlefield using data from different platforms 079.1 iMUGS operators shall be able to select objects types to detect on the battelfield, Derived among a list of pre-determined objects. Requirement 079.2 iMUGS shall autonomously detect and classify the different types of pre- Derived determined objects using data from different sensors or platforms. Requirement 079.3 iMUGS shall autonomously position different types of static pre-determined Derived objects using data from different sensors or plateforms, if needed Requirement 079.4 MUGS shall autonomously track different types of pre-determined objects Derived (vehicles, pedestrians, etc), using data from different sensors or platforms. Requirement 079.5 iMUGS C2 shall receive information of battlefield objects detected by UGV(s) Derived autonomous functions. Requirement 079.6 iMUGS C2 shall send information of battlefield objects to the UGV(s) autonomous Derived functions. Requirement 079.7 iMUGS C2 shall receive and display information from UGV sensors/payloads. Derived Requirement 10PCO005_2 Sub-Project for responsibility; SP1 = Integ.; SP2 = Aut.; SP3 = Cyber; SP4 = Comms; SP5 = Swarm.; SP6 = C2; SP7 = MUM-T. Demo No is for indication only. 6 / 29 EDIDP-MUGS-2019-002-iMUGS Original pMS definition is identifed as cells with background color, contrary to respective decomposed requirements without color. COMPANY CONFIDENTIAL DEMO MoM ID / ID Ref. MR ID pMS High Level Requirements (HLR) iMUGS Decomposed Mission (Operational) Requirement Req Type SOC SP NO Date Accepted 079.8 Local swarming shall be developed to use available labelled object data. Derived Requirement 079.9 The global swarming controller shall collect available data on board and forward Derived the necessary information to the global planner Requirement 080 VII.A.a.v. Provide tactical intelligence overwatch Heading Noted 081 VII.A.a.v.1. Capable of processing and classifying collected data autonomously and Requirement Comply 2 6 distributing near-real-time and fused robot-centric battlefield information over the network following “need to know” principles, making probability assessments 081.1 iMUGS shall be able collect, date, label, manage and store data. Derived Requirement 081.2 iMUGS shall autonomously process and classify (label) the collected data. Derived Requirement 081.3 iMUGS shall distribute near-real-time and fused platform-centric battlefield Derived information over the network following "need to know" principles. Requirement 081.4 iMUGS shall assess distributed data confidence with probabilities. Derived Requirement 081.5 The global swarming shall forward necessary data to subscribes on DDS nodes. Derived Requirement 082 VII.A.a.v.2. Capable of interacting and integrating with a larger hub vehicle for receiving Requirement Comply 1 4 logistics support (including transportation, refueling and power supply), and support for Command and Control (C2) data link and EW capacities. 082.1 Local swarming shall be developed for driving MUGS vehicles on low energy level Derived to refuel or recharge to a preknown larger hub vehicle. Requirement 082.2 The global swarming presumes being networked, either local or in a large scale Derived network Requirement 082.3 Vehicle shall have standardised interfaces for interacting with hub vehicles. Derived Requirement 083 VII.A.a.vi. Perform electronic protection actions Heading 084 VII.A.a.vi.1. Capable of detecting jamming, locating jammer and operating in jammed Requirement Comply 4 3 environment. 10PCO005_2 Sub-Project for responsibility; SP1 = Integ.; SP2 = Aut.; SP3 = Cyber; SP4 = Comms; SP5 = Swarm.; SP6 = C2; SP7 = MUM-T. Demo No is for indication only. 7 / 29 EDIDP-MUGS-2019-002-iMUGS Original pMS definition is identifed as cells with background color, contrary to respective decomposed requirements without color. COMPANY CONFIDENTIAL DEMO MoM ID / ID Ref. MR ID pMS High Level Requirements (HLR) iMUGS Decomposed Mission (Operational) Requirement Req Type SOC SP NO Date Accepted 084.1 The communication network status shall be monitored. Derived Requirement 084.2 The tactical communication network shall monitor network and link statuses, Derived provide quality and alarms in real-time. Requirement 084.3 Communication shall provide an external interface to extract network status data. Derived Requirement 084.4 Communications system shall provide a tool for recording network events for Derived collecting big data to later analysis. Requirement 084.5 The communicationns shall provide intelligent methods to detect and report Derived jamming at node level Requirement 084.6 Jamming may be detected by using information from multiple sources and OSI Derived layers. Requirement 084.7 Jamming source may be located with the help of multiple nodes. Derived Requirement 084.8 The network nodes shall be capable of monitoring the radio spectrum and Derived processing the measurement results with AI-based methods to detect e.g. Requirement anomalities and to reduce the data that needs to be transferred to network management 084.9 Local swarming is developed for operating in jammed environment according to Derived local swarming's rules. Requirement 084.10 Global swarming will immediatly notice deteriorating network conditions Derived Requirement 085 VII.A.a.vi.2. Capable of avoiding detection by enemy EW assets. Requirement Comply 1 3 085.1 Tactical communication equipment shall be able to operate lowest possible Derived output power level. Requirement 085.2 The tactical communication equipment shall use electronically controlled Derived directive antennas with the beam control synchronized to the transmission / Requirement reception of the nodes. 085.3 The tactical network shall use Low Probability of Intercept (LPI) waveforms Derived capable of, for example, frequency hopping. Requirement 085.4 Vehicle shall have RF and active sensor emission control functionality interface. Derived Requirement 085.5 Local swarming shall be developed for avoiding known locations of enemy EW Derived assets. Requirement 10PCO005_2 Sub-Project for responsibility; SP1 = Integ.; SP2 = Aut.; SP3 = Cyber; SP4 = Comms; SP5 = Swarm.; SP6 = C2; SP7 = MUM-T. Demo No is for indication only. 8 / 29 EDIDP-MUGS-2019-002-iMUGS Original pMS definition is identifed as cells with background color, contrary to respective decomposed requirements without color. COMPANY CONFIDENTIAL DEMO MoM ID / ID Ref. MR ID pMS High Level Requirements (HLR) iMUGS Decomposed Mission (Operational) Requirement Req Type SOC SP NO Date Accepted 085.6 Global swarming takes known EW assets into account in the optimization. Derived Requirement 086 VII.A.a.vi.3. Capable of operating in crowded and hostile electromagnetic spectrum by Requirement Comply 4 3 cognitive use of electromagnetic spectrum. 086.1 The tactical communication equipment shall support multiple frequencies and Derived frequency hopping Requirement 086.2 The tactical communication equipment shall be able to change frequency or the Derived FH pattern when needed Requirement 86,3 The tactical communication system shall support multiple modulation and coding Derived schemes in order to reduce the jamming effects. Requirement 86,4 The tactical communication system shall be capable of deploying directional Derived antennas. Requirement 86,5 The tactical communication system may use other anti-jamming methods. Derived Requirement 087 VII.A.a.vii. Conduct risk management Heading Noted 088 VII.A.a.vii.1. Capable of recording and preserving the system data for at least 3 days Requirement Comply 1 4 088.1 Vehicle shall be equipped with a data storage to store 72 hours of set of recorded Derived sensor and telemetry data Requirement 089 VII.A.a.vii.2. Capable of evaluating reliability and credibility of the gathered data and provide Requirement Comply 1 6 evidence-based conclusions, situational understanding and recommendations for further collection or exploitation 089.1 Vehicle shall have datalogger with comprehensive fault logging capability. Derived Requirement 090 VII.A.a.viii. Develop and implement command safety program Heading Noted 091 VII.A.a.viii.1. Capable of applying preprogrammed action plans in case of data link is cut down Requirement Comply 2 5 or overloaded, by use of preprogrammed action plans until the first decision- making point 091.1 Local swarming shall be developed for applying its rules in case of data link Derived malfunctions. Requirement 091.2 Global swarming shall include fallback strategies in case of data link loss Derived Requirement 10PCO005_2 Sub-Project for responsibility; SP1 = Integ.; SP2 = Aut.; SP3 = Cyber; SP4 = Comms; SP5 = Swarm.; SP6 = C2; SP7 = MUM-T. Demo No is for indication only. 9 / 29 EDIDP-MUGS-2019-002-iMUGS Original pMS definition is identifed as cells with background color, contrary to respective decomposed requirements without color. COMPANY CONFIDENTIAL DEMO MoM ID / ID Ref. MR ID pMS High Level Requirements (HLR) iMUGS Decomposed Mission (Operational) Requirement Req Type SOC SP NO Date Accepted 091.3 iMUGS shall detect data link cut down. Derived Requirement 091.4 iMUGS shall detect data link overload. Derived Requirement 091.5 iMUGS operators shall be able to choose an action plans to conduct among the Derived pre-programmed possibilities. Requirement 091.6 iMUGS shall be able to apply the pre-programmed actions until the first decision- Derived making point. Requirement 091.7 iMUGS shall be able to stop autonomously Derived Requirement 092 VII.A.a.viii.2. Capable of automated detection and response to cyber-attacks Requirement Comply 6 092.1 iMUGS shall encompass Cyber Defence System to automatically detect and Derived respond to cyber-attacks. Requirement 092.2 The Cyber Ddefense System shall detect known cyber-attacks that originate within Derived the iMUGS platform. Requirement 092.3 The Cyber Defense System shall detect known cyber-attacks that originate from Derived connected external systems. Requirement 092.4 The Cyber Defense System shall help detect physical actions taken against the Derived system to enable cyber-attacks. Requirement 092.5 The Cyber Defense System shall help detect EW actions taken against the system Derived to enable cyber-attacks. Requirement 092.6 The Cyber Defense System shall recommend a response to a detected cyber Derived attack that allows a graceful degradation of the platform where possible. Requirement 092.7 The Cyber Defense System shall recommend the actions to disconnect Derived components from networks, reset components, or power off components in Requirement order to implement a decided response. 092.8 The Cyber Defence System shall provide a human interface. Derived Requirement 092.9 The Cyber Defence System shall have interfaces to other components as required Derived to achieve its purpose. Requirement 093 VII.A.b. Lightened soldier workload by using the platform for carrying squad sized unit Heading Noted equipment during tactical movements on foot and by using autonomous mobility software and intuitive control pad 10PCO005_2 Sub-Project for responsibility; SP1 = Integ.; SP2 = Aut.; SP3 = Cyber; SP4 = Comms; SP5 = Swarm.; SP6 = C2; SP7 = MUM-T. Demo No is for indication only. 10 / 29 EDIDP-MUGS-2019-002-iMUGS Original pMS definition is identifed as cells with background color, contrary to respective decomposed requirements without color. COMPANY CONFIDENTIAL DEMO MoM ID / ID Ref. MR ID pMS High Level Requirements (HLR) iMUGS Decomposed Mission (Operational) Requirement Req Type SOC SP NO Date Accepted 094 VII.A.b.i. Conduct an approach march Heading Noted 095 VII.A.b.i.1. Capable of moving autonomously with infantry troops on foot over rugged and Requirement Comply 2 1,5,6 heavily vegetated terrain 095.1 iMUGS shall move over rugged and heavily vegetated terrain, with performances Derived depending on the conditions. Requirement 095.2 iMUGS shall move autonomously with infantry troops on foot, when the leader is Derived visible, and with performances depending on the conditions. Requirement 095.3 Local swarming shall be developed for moving with dismounted infantry speed. Derived Requirement 095.4 Global swarming shall include the swarm behavior to track and follow a beacon Derived carried by the infantry troops Requirement 096 VII.A.b.ii. Perform fratricide avoidance Heading Noted 097 VII.A.b.ii.1. Capable of avoiding harming humans, vehicles and equipment, in order to provide Requirement Comply 1 5 additional safety compared to remote-controlled platforms 097.1 Mobility platofrm shall have interfaces to receive obstacle avoidance data and Derived perform safety actions (emergency stop, etc) and alert the operator Requirement 097.2 Mobility platform shall have obstacle detection algorithm to stop the vehicle if Derived close to stationary or moving objects and report to the operator about the Requirement obstacle 097.3 Local swarming shall be developed for avoiding harming humans, known vehicles Derived and equipment within its functions. Requirement 097.4 Global swarming shall include high-level safety mechanisms, but relies on Derived Autonomy features for the real-time safety-critical aspects. Requirement 098 VII.A.b.iii. Overcome barriers and obstacles and other features to be defined Heading Noted 099 VII.A.b.iii.1. Capable of planning the route to overcome obstacles Requirement Comply 2 5 099.1 Local swarming is developed for planning routes avoiding known obstacles. Derived Requirement 099.2 Global swarming is developed for planning routes avoiding known obstacles. Derived Requirement 10PCO005_2 Sub-Project for responsibility; SP1 = Integ.; SP2 = Aut.; SP3 = Cyber; SP4 = Comms; SP5 = Swarm.; SP6 = C2; SP7 = MUM-T. Demo No is for indication only. 11 / 29 EDIDP-MUGS-2019-002-iMUGS Original pMS definition is identifed as cells with background color, contrary to respective decomposed requirements without color. COMPANY CONFIDENTIAL DEMO MoM ID / ID Ref. MR ID pMS High Level Requirements (HLR) iMUGS Decomposed Mission (Operational) Requirement Req Type SOC SP NO Date Accepted 099.3 iMUGS shall identify static obstacles Derived Requirement 099.4 iMUGS shall find a crossing or bypassing strategy to overcome static obstacles, Derived when it is feasible Requirement 099.5 iMUGS shall adapt its mobility strategy to overcome obstacles (speed, etc.) Derived Requirement 100 VII.A.b.iv. Provide transportation support Heading Noted 101 VII.A.b.iv.1. Capable of carrying squad-sized troop equipment during the foot march Requirement Comply 1 1 101.1 iMUGS shall be capable of carrying squad-sized troop equipment during a foot Derived march. Requirement 102 VII.A.b.iv.2. Capable of sustaining the foot march over 8 hours in most difficult terrain one day Requirement Comply 1 1 period without any need for fuel resupply 102,1 iMUGS shall be capable of sustaining the foot march over 8 hours in respective Derived terrain over one day period without any need for fuel resupply. Requirement 103 VII.A.b.v. Provide information support for operator Heading Noted 104 VII.A.b.v.1. Share system status and problems with controller through one-hand intuitive Requirement Comply 1 3 controller pad. 104.1 Vehicle shall send telemetry information in real-time to one-hand operator Derived control unit Requirement 105 VII.A.c. Increased force protection by using the system for autonomous navigation and Heading Noted unmanned missions to threat areas to discover and remotely controlled neutralize or provide cover for fighting units and remote systems from possible threats 106 VII.A.c.i. Conduct Area and Base Security Operations Heading Noted 107 VII.A.c.i.1. Capable of moving autonomously along a preplanned patrol route Requirement Comply 2 4 107.1 iMUGS shall be able to record its route in different modes Derived Requirement 107.2 iMUGS shall be able to import route from different sources and formats. Derived Requirement 10PCO005_2 Sub-Project for responsibility; SP1 = Integ.; SP2 = Aut.; SP3 = Cyber; SP4 = Comms; SP5 = Swarm.; SP6 = C2; SP7 = MUM-T. Demo No is for indication only. 12 / 29 EDIDP-MUGS-2019-002-iMUGS Original pMS definition is identifed as cells with background color, contrary to respective decomposed requirements without color. COMPANY CONFIDENTIAL DEMO MoM ID / ID Ref. MR ID pMS High Level Requirements (HLR) iMUGS Decomposed Mission (Operational) Requirement Req Type SOC SP NO Date Accepted 107.3 iMUGS shall be able to move autonomously along a preplanned route (i.e. a set of Derived waypoints) Requirement 107.4 Local swarming is developed for area patrolling function. Derived Requirement 107.5 Global swarming will include a route patrolling modus Derived Requirement 108 VII.A.c.ii. Protect against enemy hazards in the area of operations Heading Noted 109 VII.A.c.ii.1. Capable of employing modular ballistic protection for fighting units and systems. Requirement Comply 1 3 109.1 iMUGS shall be capable of employing modular ballistic protection for fighting Derived units and systems. Requirement 110 VII.A.c.ii.2. Capable of employing smoke/obscurant/close-in jamming Requirement Comply 1 3 110.1 iMUGS shall have functionality and interfaces to deploy obscurant. Derived Requirement 110.2 iMUGS shall have interface to a close-in jamming device. Derived Requirement 111 VII.A.c.ii.3. Capable of identifying hazards from the battlefield such as, but not limited to, Requirement Comply 1 1 detection of direct fire rounds fired at the vehicle, detection of mortar and artillery impacts in close vicinity of the vehicle, laser targeting and ranging 111.1 Local swarming uses information of hazard from the battlefield in its force Derived protection function. Requirement 111.2 Global swarming uses information of hazard from the battlefield in its force Derived protection function. Requirement 111.3 Vehicle shall be able to interface acoustic shot detection, laser targeting and Derived ranging detection system Requirement 112 VII.A.c.ii.4. Capable of providing real-time, fused and sufficient information to controller to Requirement Comply 1 4 make decisions, to assess precision and effects of countermeasures 112.1 Local swarming is developed for sharing its status information to operator when Derived possible. Requirement 112.2 iMUGS shall have capability to sharing its sensor and system information to Derived operator when possible. Requirement 10PCO005_2 Sub-Project for responsibility; SP1 = Integ.; SP2 = Aut.; SP3 = Cyber; SP4 = Comms; SP5 = Swarm.; SP6 = C2; SP7 = MUM-T. Demo No is for indication only. 13 / 29 EDIDP-MUGS-2019-002-iMUGS Original pMS definition is identifed as cells with background color, contrary to respective decomposed requirements without color. COMPANY CONFIDENTIAL DEMO MoM ID / ID Ref. MR ID pMS High Level Requirements (HLR) iMUGS Decomposed Mission (Operational) Requirement Req Type SOC SP NO Date Accepted 113 VII.A.d. Increased sustainability of the fighting unit by using the platform for autonomous Heading Noted and unmanned resupply missions of fighting unit, as a power bank and by providing communications support 114 VII.A.d.i. Provide MEDEVAC and supplies Heading Noted 115 VII.A.d.i.1. Capable of carrying minimum of two casualties and/or total payload of 600 kg of Requirement Comply 1 1 supplies 115.1 Capable of carrying minimum of two casualties and/or total payload of 600 kg of Derived supplies Requirement 116 VII.A.d.ii. Provide electricity Heading Noted 117 VII.A.d.ii.1. Capable of producing electric power for charging troop's batteries and tethered Requirement Comply 1 1 Unmanned Aerial System (UAS) 117.1 Vehicle shall have NATO standard interfaces for charging troop's batteries and Derived tethered Unmanned Aerial System (UAS). Requirement 118 VII.A.d.iii. Provide network transport and information services Heading Noted 119 VII.A.d.iii.1. Capable of increasing communications distances by acting as relay station Requirement Comply 4 1 119.1 The tactical networks shall support relaying and routing feature as per mobile ad Derived hoc or other selected network protocols allowing multi-hop relaying. Requirement 119.2 The network shall be able to reliably route IP packets via multiple routes Derived Requirement 119.3 The communication system shall be capable of relaying IP packets over all Derived available radio networks including commercial mobile networks. Requirement 119.4 Local swarming shall include a relay network behavour. Derived Requirement 119.5 Global swarming will include a relaying behavior. Derived Requirement 120 VII.A.d.iii.2. Capable of utilizing multiple wireless communications technologies, including Requirement Comply 4 3 tactical and commercial networks 10PCO005_2 Sub-Project for responsibility; SP1 = Integ.; SP2 = Aut.; SP3 = Cyber; SP4 = Comms; SP5 = Swarm.; SP6 = C2; SP7 = MUM-T. Demo No is for indication only. 14 / 29 EDIDP-MUGS-2019-002-iMUGS Original pMS definition is identifed as cells with background color, contrary to respective decomposed requirements without color. COMPANY CONFIDENTIAL DEMO MoM ID / ID Ref. MR ID pMS High Level Requirements (HLR) iMUGS Decomposed Mission (Operational) Requirement Req Type SOC SP NO Date Accepted 120.1 The communication system is capable of handling multiple simultaneous Derived connections via different networks including tactical, special V2V and commercial Requirement networks (e.g. mobile / satellite etc), and capable of routing data over the available channels in an intelligent manner. 120.2 When commercial network is used, the data shall be protected with stronger Derived encryption - VPN. Requirement 120.3 The stronger encryption solution (VPN) shall include: Derived - Block ciphers Requirement - Hash functions - Authenticated encryption with integrity check - Digital signature algorithms - Key exchange algorithms 120.4 The interface point between tactical and commercial network shall be protected Derived by a firewall solution. Requirement 121 VII.A.e. Facilitated deployability by deploying the system quickly and cheaply to the Heading Noted operation area by using the preexisting logistic system or manned combat vehicle. 122 VII.A.e.i. Prepare Forces for Movement. Heading Noted 123 VII.A.e.i.1. Capable of assembling or dissembling system in a fast and easy manner by one Requirement Comply 1 1 person in one hour 123.1 iMUGS mobility platform shall be capable of being assembled or dissembled in a Derived fast and easy manner by one person in one hour. Requirement 124 VII.A.e.ii. Conduct operational deployment and redeployment activities Heading Noted 125 VII.A.e.ii.1. Capable of moving system by sling load or in a cargo department of preexisting Requirement Comply 1 1 helicopters of Partners 125.1 iMUGS shall be capable of being moved by sling load or in a cargo department of Derived preexisting helicopters of Partners. Requirement 126 VII.A.e.ii.2. Capable of moving system in a cargo department of preexisting transport plane of Requirement Comply 1 1 Partners 126.1 iMUGS shalle be capable of being moved in a cargo department of preexisting Derived transport plane of Partners. Requirement 127 VII.A.e.ii.3. Capable of moving system by towing and in a cargo area of preexisting trucks of Requirement Comply 1 1 Partners 127.1 iMUGS shall be capable of bein moved in a cargo area of preexisting trucks of Derived Partners. Requirement 10PCO005_2 Sub-Project for responsibility; SP1 = Integ.; SP2 = Aut.; SP3 = Cyber; SP4 = Comms; SP5 = Swarm.; SP6 = C2; SP7 = MUM-T. Demo No is for indication only. 15 / 29 EDIDP-MUGS-2019-002-iMUGS Original pMS definition is identifed as cells with background color, contrary to respective decomposed requirements without color. COMPANY CONFIDENTIAL DEMO MoM ID / ID Ref. MR ID pMS High Level Requirements (HLR) iMUGS Decomposed Mission (Operational) Requirement Req Type SOC SP NO Date Accepted 127.2 iMUGS shall be capable of towed deployment with a larger vehicle. Derived Requirement 128 VII.A.e.ii.4. Capable of moving system by rail or sea lift. Requirement Comply 1 1 128.1 iMUGS shall be capable of being moved by rail or sea lift. Derived Requirement 129 VII.A.f. Increased interoperability and affordability of the force, by using the standardized Heading Noted technology and modular and open system architecture for the platform 130 VII.A.f.i. Use standard fuel for engine operation Requirement Comply 1 1 130.1 iMUGS shall use standard fuel for engine operation. Derived Requirement 131 VII.A.f.ii. Use radio-agnostic solutions for data links and encryption to provide connectivity Requirement Comply 4 2 with different communication systems 131.1 All iMUGS communication links shall support IP traffic. Derived Requirement 131.2 Any encryption methods shall be applied so, that any IP traffic can pass through it. Derived Requirement 132 VII.A.f.iii. Possibility to use wired control Requirement Comply 1 1 132.1 Vehicle shall be controllable by using a wired connection. Derived Requirement 133 VII.A.f.iv. Use standardized modality to code sensor data Requirement Comply 2 4 133.1 iMUGS sensor data shall be coded with standardized data formats. Derived Requirement 133.2 iMUGS sensor data shall be collected and shared through a dedicated backbone, Derived with a well defined standardized interface Requirement 134 VII.A.f.v. Use standardized and open system architecture, including NATO Generic Vehicle Requirement Comply 1 4 Architecture (STANAG 4754), Unmanned Ground Vehicle (UGV) Interoperability Profile (STANAG 4818) and Robot Operating System (ROS) 134.1 iMUGS shall use standardized and open system architecture, including NATO Derived Generic Vehicle Architecture Requirement 10PCO005_2 Sub-Project for responsibility; SP1 = Integ.; SP2 = Aut.; SP3 = Cyber; SP4 = Comms; SP5 = Swarm.; SP6 = C2; SP7 = MUM-T. Demo No is for indication only. 16 / 29 EDIDP-MUGS-2019-002-iMUGS Original pMS definition is identifed as cells with background color, contrary to respective decomposed requirements without color. COMPANY CONFIDENTIAL DEMO MoM ID / ID Ref. MR ID pMS High Level Requirements (HLR) iMUGS Decomposed Mission (Operational) Requirement Req Type SOC SP NO Date Accepted 134.2 iMUGS shall follow (UGV) Interoperability Profile (STANAG 4818) - when Derived promulgated. Requirement 134.3 iMUGS shall use Robotic Operating System framework. Derived Requirement 134.4 Local swarming is developed using ROS where possible. Derived Requirement 134.5 Global swarming will be based on the ROS2 framework Derived Requirement 135 VII.A.f.vi. Exchange information with preexisting Battlefield Management System (BMS) and Requirement Comply 6 5 Command and Control Information Systems (C2I) systems via standardized interface 135.1 iMUGS C2 shall implement NATO NFFI and NATO ISR interoperability standards. Derived Requirement 135.2 iMUGS C2 shall send UGVs positions to external C2/C4I as NFFI tracks. Derived Requirement 135.3 iMUGS C2 shall be interoperable with a NATO STANAG 4559 CSD server for Derived dissemination of ISR data received from UGV sensors/payloads. Requirement 136 VII.A.f.vii. Use modular payloads and standardized connections Requirement Comply 1 5 136.1 iMUGS shall use modular payloads and standardized connections Derived Requirement 137 VII.A.f.viii. Use standardized digital battlefield data links and encryption Requirement Comply 6 5 137.1 All data links shall be digital. Derived Requirement 137.2 Standardized data links deployed by the manned ground forces shall be Derived supported. The system is capable of deploying European standard IP-data Requirement waveforms such as as the ESSOR waveforms. 137.3 Commercial data links shall be implemented using standardized 3GPP (4G/5G) Derived and/or IEEE (WIFI) links. Requirement 137.4 The data link encryption shall be implemented using standardized solutions for Derived example, but not limited to, those mentioned in NIST SP 800-175B Requirement 137.5 iMUGS C2 will support IP conectivity with communication equipment. Derived Requirement 10PCO005_2 Sub-Project for responsibility; SP1 = Integ.; SP2 = Aut.; SP3 = Cyber; SP4 = Comms; SP5 = Swarm.; SP6 = C2; SP7 = MUM-T. Demo No is for indication only. 17 / 29 EDIDP-MUGS-2019-002-iMUGS Original pMS definition is identifed as cells with background color, contrary to respective decomposed requirements without color. COMPANY CONFIDENTIAL DEMO MoM ID / ID Ref. MR ID pMS High Level Requirements (HLR) iMUGS Decomposed Mission (Operational) Requirement Req Type SOC SP NO Date Accepted 138 VII.A.f.ix. Use standardized data format for geoinformation, mapping, positioning etc. Requirement Comply 1 5 138.1 iMUGS C2 will support standardized data format for geoinformation, mapping and Derived positioning data. Requirement 138.2 Local swarming is developed for sharing its status information with standardized Derived geoinformation. Requirement 138.3 Global swarming is developed for sharing its status information with standardized Derived geoinformation. Requirement 139 VII.B. All autonomy related capabilities will ensure a sufficient degree of human control Heading Noted as well as the ability to conduct operations in compliance with national and international law, in particular international humanitarian law, where applicable. 140 VIII Section VIII – TECHNICAL SPECIFICATIONS FOR MUGS Heading Noted 141 VIII.A. The development of MUGS will be conducted according to the following inter- Note Noted linked and transferable technological packages: 142 VIII.A.a. Modular, multi-mission-capable UGV on which a variety of payloads can be Heading Noted mounted to support various mission functionalities (transport, fire-support, ISR, EW&C, etc.) and integration for required sensors and communication systems. 143 VIII.A.a. The package will include: Note Noted 144 VIII.A.a.i. Development of the base mobility platform. Requirement Comply 1 1 144.1 iMUGS shall develop a base mobility platform. Derived Requirement 145 VIII.A.a.i. Assessed and assigned TRL rating for the solution will be at least TRL 6. Requirement Comply 1 1 145.1 The TRL of the base mobility platform shall be 6. Derived Requirement 146 VIII.A.a.ii. Development of a logistics solution using a pre-existing combat vehicle Requirement Comply 7 2 (transporting combat units) for safely and quickly dispatching unmanned ground and aerial vehicles, with minimal human effort. 146.1 Integration of the UAV transport/take-off/landing box and the belonging Derived components to a pre-existing combat vehicle. Requirement 10PCO005_2 Sub-Project for responsibility; SP1 = Integ.; SP2 = Aut.; SP3 = Cyber; SP4 = Comms; SP5 = Swarm.; SP6 = C2; SP7 = MUM-T. Demo No is for indication only. 18 / 29 EDIDP-MUGS-2019-002-iMUGS Original pMS definition is identifed as cells with background color, contrary to respective decomposed requirements without color. COMPANY CONFIDENTIAL DEMO MoM ID / ID Ref. MR ID pMS High Level Requirements (HLR) iMUGS Decomposed Mission (Operational) Requirement Req Type SOC SP NO Date Accepted 146.2 Integration of components for the deployment of a UGV to a pre-existing combat Derived vehicle. Requirement 146.3 Integration of control stations for UGV and UAV in a pre-existing combat vehicle. Derived Requirement 147 VIII.A.a.ii. The method should avoid slowing down dispatching troops and thereby Requirement Comply 1 1 exacerbating risks. 147.1 iMUGS deployment method should avoid slowing down dispatching troops and Derived thereby exacerbating risks. Requirement 148 VIII.A.a.ii. The method should be as autonomous as possible, in particular for dull, Requirement Comply 1 3 dangerous and dirty missions. 148.1 iMUGS deployment method should be as autonomous as possible, in particular Derived for dull, dangerous and dirty missions. Requirement 149 VIII.A.a.ii. Assessed and assigned TRL rating for the solution will be at least TRL 5. Requirement Comply 1 3 149.1 Assessed and assigned TRL rating for the deployment solution will be at least TRL Derived 5. Requirement 150 VIII.A.a.iii. Demonstration of at least three pre-existing payload integration to the base Requirement Comply 1 4 mobility platform. 150.1 iMUGS shall demontrate at least three pre-existing payload integration to the Derived base mobility platform. Requirement 151 VIII.A.a.iii. Mission kits for autonomous ISR and force protection missions and tethered UAS Requirement Comply 1 4 solution are considered as mandatory. 151.1 iMUGs shall demonstrate mission kits for autonomous ISR and force protection Derived missions and tethered UAS. Requirement 152 VIII.A.b. EW resistant networking Command, Control & Communications (C3) solution. Heading Noted 153 VIII.A.b. This package will capture multiple integrated elements: Note Noted 154 VIII.A.b.i. Development of the secure mesh service layers for predefined local or wide-area Requirement Partial 4 3 radio systems for IP-based information exchange and C2 of multiple platforms. 154.1 iMUGS shall demonstrate a secure service mesh service layer for predefined local Derived or wide-area radio systems for IP-based information exchange. Requirement 10PCO005_2 Sub-Project for responsibility; SP1 = Integ.; SP2 = Aut.; SP3 = Cyber; SP4 = Comms; SP5 = Swarm.; SP6 = C2; SP7 = MUM-T. Demo No is for indication only. 19 / 29 EDIDP-MUGS-2019-002-iMUGS Original pMS definition is identifed as cells with background color, contrary to respective decomposed requirements without color. COMPANY CONFIDENTIAL DEMO MoM ID / ID Ref. MR ID pMS High Level Requirements (HLR) iMUGS Decomposed Mission (Operational) Requirement Req Type SOC SP NO Date Accepted 155 VIII.A.b.i. Assessed and assigned TRL rating for the solution will be at least TRL 5. Requirement Comply 4 3 155.1 The TRL rating for the secure service mesh layer solution will be at least TRL 5. Derived Requirement 156 VIII.A.b.ii. Development of enabling software for Common Operational Picture purpose, Requirement Comply 6 5 capable of transferring codified messages from the platform to pre-defined BMS solutions. 156.1 iMUGS C2 will present a Tactical Situation Map with battlefield information to the Derived operator. Requirement 156.2 iMUGS C2 Situation Map will present tactical information entered by C2 Operator, Derived UGVs position and operational status, and information received from external Requirement C2/C4ISR systems (through interoperability protocols supported by iMUGS C2). 156.3 iMUGS C2 will enable operator to define in the Situation Map routes for UGVs, Derived patrolling areas for UGVs, obstacles and threats for UGVs. Requirement 157 VIII.A.b.ii. Assessed and assigned TRL rating for the solution will be at least TRL 5. Requirement Comply 6 5 157.1 iMUGS C2 shall reach a TRL-5 Derived Requirement 158 VIII.A.b.iii. Development of digitalized C2 interface for the hub (“command-pad”) and Requirement Comply 6 6 integration with sensor data and artificial intelligence enabled software for BLOS missions. 158.1 iMUGS C2 will enable operator to create and send orders to UGV(s) autonomous Derived functions for BLOS missions. Requirement 158.2 iMUGS C2 will enable operator to monitor UGV BLOS autonomous missions Derived execution. Requirement 158.3 Local swarming is developed for sharing its status information to operator and Derived receiving operator commands when possible. Requirement 158.4 Global swarming is developed for sharing its status information to operator and Derived receiving operator commands when possible. Requirement 159 VIII.A.b.iii. Assessed and assigned TRL rating for the solution will be at least TRL 5. Requirement Comply 6 6 159.1 iMUGS C2 interface shall reach a TRL-5. Derived Requirement 160 VIII.A.b.iv. Development of intuitive one-hand Command & Control interface for dismounted Requirement Comply 1 3 troops (“control-pad”) for LOS and Close Support missions. 10PCO005_2 Sub-Project for responsibility; SP1 = Integ.; SP2 = Aut.; SP3 = Cyber; SP4 = Comms; SP5 = Swarm.; SP6 = C2; SP7 = MUM-T. Demo No is for indication only. 20 / 29 EDIDP-MUGS-2019-002-iMUGS Original pMS definition is identifed as cells with background color, contrary to respective decomposed requirements without color. COMPANY CONFIDENTIAL DEMO MoM ID / ID Ref. MR ID pMS High Level Requirements (HLR) iMUGS Decomposed Mission (Operational) Requirement Req Type SOC SP NO Date Accepted 160.1 iMUGS shall develop a intuitive one-hand Command & Control interface for Derived dismounted troops (“control-pad”) for LOS and Close Support missions. Requirement 160.2 Local swarming is developed for sharing its's status information to operator and Derived receiving operator commands when possible. Requirement 160.3 Manual control and override will always be possible for the global swarming Derived functions Requirement 161 VIII.A.b.iv. Assessed and assigned TRL rating for the solution will be at least TRL 6. Requirement Comply 1 3 161.1 The TRL for intuitive one-hand Command & Control interface for dismounted Derived troops (“control-pad”) for LOS and Close Support missions shall be 6. Requirement 162 VIII.A.b.v. EW resistance instrumentation against detection, interception, suppression, Requirement Comply 1 3 deception and spoofing. 162.1 iMUGS shall be designed for EW resistance instrumentation against detection, Derived interception, suppression, deception and spoofing. Requirement 162.2 The tactical communication system shall be capable of deploying LPD/LPI/AJ Derived techniques. Requirement 162.3 All communication must be encrypted with sufficient key length Derived Requirement 162.4 When (commercial network) COTS devices are used, they must be hardened Derived against various cyber security threads. Requirement 162.5 When (commercial network) COTS devices are used, they should be centrally Derived managed by MDM system. Requirement 163 VIII.A.b.v. Detection of different forms of jamming. Requirement Comply 1 3 163.1 iMUGS Radio system shall have jamming detection and avoidance functionality by Derived switching to another communication frequency/channel Requirement 164 VIII.A.b.v. Assessed and assigned TRL rating for the solution will be at least TRL 6. Requirement Comply 1 3 164.1 iMUGS jamming detection solution shall have a TRL of 6 Derived Requirement 165 VIII.A.c. Cyber secure autonomous functions solution. Heading Noted 10PCO005_2 Sub-Project for responsibility; SP1 = Integ.; SP2 = Aut.; SP3 = Cyber; SP4 = Comms; SP5 = Swarm.; SP6 = C2; SP7 = MUM-T. Demo No is for indication only. 21 / 29 EDIDP-MUGS-2019-002-iMUGS Original pMS definition is identifed as cells with background color, contrary to respective decomposed requirements without color. COMPANY CONFIDENTIAL DEMO MoM ID / ID Ref. MR ID pMS High Level Requirements (HLR) iMUGS Decomposed Mission (Operational) Requirement Req Type SOC SP NO Date Accepted 166 VIII.A.c. This package will capture the following elements: Note Noted 167 VIII.A.c.i. Development for machine learning-based autonomous mobility solution for BLOS, Requirement Comply 2 6 LOS and autonomous missions. 167.1 Local swarming navigation is developed with machine learning in local swarming Derived functions. Requirement 167.2 Global swarming navigation relies on the autonomy for the local planning and Derived applies machine learning for optimising the global planning. Requirement 167.3 iMUGS should implement a common data base well adapted to the machine Derived learning. Requirement 167.4 iMUGS's autonomous mobility solution should be machine learning-based for the Derived autonomous missions. Requirement 168 VIII.A.c.i. The solution will provide an interoperable operating system for MUGS with at Requirement Comply 2 6 least waypoint navigation, fratricide avoidance, obstacle avoidance and follow-me (vehicle and pedestrian) functionalities as well as automated multi-horizon planning and scheduling for route and mission management. 168.1 iMUGS shall run an interoperable operating system enabling the different Derived autonomous functionalities Requirement 168.2 iMUGS shall have waypoint navigation functionality Derived Requirement 168.3 iMUGS shall have fratricide avoidance functionality Derived Requirement 168.4 iMUGS shall have obstacle avoidance functionality Derived Requirement 168.5 iMUGS shall have follow-me (vehicle and pedestrian) functionality Derived Requirement 168.6 iMUGS shall have automated multi-horizon planning and scheduling for route and Derived mission management Requirement 168.7 Local swarming is developed for co-operating with autonomy functionalities. Derived Requirement 168.8 Global swarming will include waypoint navigation capabilities and relies on Derived autonomy for solving the local motion planning Requirement 10PCO005_2 Sub-Project for responsibility; SP1 = Integ.; SP2 = Aut.; SP3 = Cyber; SP4 = Comms; SP5 = Swarm.; SP6 = C2; SP7 = MUM-T. Demo No is for indication only. 22 / 29 EDIDP-MUGS-2019-002-iMUGS Original pMS definition is identifed as cells with background color, contrary to respective decomposed requirements without color. COMPANY CONFIDENTIAL DEMO MoM ID / ID Ref. MR ID pMS High Level Requirements (HLR) iMUGS Decomposed Mission (Operational) Requirement Req Type SOC SP NO Date Accepted 169 VIII.A.c.i. A combination between several alternative algorithmic approaches will be Requirement Comply 2 6 considered to increase performance and robustness of the autonomous navigation modes. 169.1 iMUGS should be able to run several algorithms in parallel, with the same Derived interfaces and high-level functionalities Requirement 169.2 iMUGS should be able to combine outputs from multiple algorithms when similar Derived algorithms are running in parallel. Requirement 169.3 iMUGS operators should be able to select algorithms to run in order to increase Derived performance and robustness, dependending on the context. Requirement 169.4 Local swarming is developed for co-operating with autonomy functionalities. Derived Requirement 169.5 Global swarming is developed for co-operating with autonomy functionalities. Derived Requirement 170 VIII.A.c.i. Assessed and assigned TRL rating for the solution will be at least TRL 6. Requirement Comply 2 6 170.1 iMUGS solutions for alternative algorithm execution shall be developet to TRL 6 Derived Requirement 171 VIII.A.c.ii. Development of standardized data labeling and storage architecture to support Requirement Comply 2 6 implementation of machine learning based algorithms based on both real world and simulations data for MUGS. 171.1 Standard data formats shall be defined for labeled data exchange and storage Derived Requirement 171.2 Data warehouse architecture shall be defined for storage and sharing of iMUGS Derived data. Requirement 171.3 Data processing and filtering architecture shall be defined. Derived Requirement 171.4 Data labeling pipeline architecture shall be defined. Derived Requirement 171.5 Architecture for machine learning model training shall be defined. Derived Requirement 172 VIII.A.c.ii. At least TRL 5. Requirement Comply 2 6 172.1 Data labelling and storage architecture shall be developed to TRL 5. Derived Requirement 10PCO005_2 Sub-Project for responsibility; SP1 = Integ.; SP2 = Aut.; SP3 = Cyber; SP4 = Comms; SP5 = Swarm.; SP6 = C2; SP7 = MUM-T. Demo No is for indication only. 23 / 29 EDIDP-MUGS-2019-002-iMUGS Original pMS definition is identifed as cells with background color, contrary to respective decomposed requirements without color. COMPANY CONFIDENTIAL DEMO MoM ID / ID Ref. MR ID pMS High Level Requirements (HLR) iMUGS Decomposed Mission (Operational) Requirement Req Type SOC SP NO Date Accepted 173 VIII.A.c.iii Development of autonomous swarming capabilities with a solution using Requirement Comply 5 6 autonomous features developed for individual UGVs. 173.1 Local swarming capabilities are developed for defined use cases. Derived Requirement 173.2 Global swarming capabilities are developed for defined use cases and rely on the Derived autonomy functionality or solving the local problems and to harvest information Requirement for the global planner. 173.3 Local swarming and Global swarming interface and co-operation is defined. Derived Requirement 174 VIII.A.c.iii. Moreover, the solution will include swarm intelligence, autonomous swarm Requirement Comply 5 6 manoeuvring and one or more of the following swarming functions: area patrolling, maintaining a relay network, and area exploration and reconnaissance as part of the use cases. 174.1 Local swarming capabilities are developed for defined use cases. Derived Requirement 174.2 Global swarming will include behaviors reated to relaying, area exploration, Derived reconnaissance. Requirement 175 VIII.A.c.iii. The assessed and assigned TRL rating for the solution will be TRL 5. Requirement Comply 5 6 175.1 Local swarming is developed to TRL 5 Derived Requirement 175.2 Global swarming technologies will be developed to TRL 5 Derived Requirement 176 VIII.A.c.iv. Development of the platform-based system and data integrity instrumentation Requirement Comply 1 6 (“Black Box”) for intended and continuous operations of the autonomous units. 176.1 iMUGS shall be capable of house platform-based system and data integrity Derived instrumentation (“Black Box”) for intended and continuous operations of the Requirement autonomous units. 177 VIII.A.c.iv. Assessed and assigned TRL rating for the solution will be at least TRL 6. Requirement Comply 1 6 177.1 The platform-based system and data integrity instrumentation shall be developed Derived to TRL 6 Requirement 178 VIII.A.c.iv. Cloud-based solution will stay as optional for development. Note Noted 179 IX Section IX – REQUIREMENTS FOR DEVELOPMENT ACTIVITIES Heading Noted 10PCO005_2 Sub-Project for responsibility; SP1 = Integ.; SP2 = Aut.; SP3 = Cyber; SP4 = Comms; SP5 = Swarm.; SP6 = C2; SP7 = MUM-T. Demo No is for indication only. 24 / 29 EDIDP-MUGS-2019-002-iMUGS Original pMS definition is identifed as cells with background color, contrary to respective decomposed requirements without color. COMPANY CONFIDENTIAL DEMO MoM ID / ID Ref. MR ID pMS High Level Requirements (HLR) iMUGS Decomposed Mission (Operational) Requirement Req Type SOC SP NO Date Accepted 180 IX.A. The Project will include several development actions as follows: Note Noted 181 IX.A.a. feasibility study, which will include, without being limited to: Heading Noted 182 IX.A.a.i. operational and cost-effectiveness analyses study to specify conditions and Requirement Comply 1 5 criteria for each operational use case defined in Section VI H within the framework of Section VII 182.1 iMUGS shall deliver an operational and cost-effectiveness analyses study to Derived specify conditions and criteria for each operational use case defined in Section VI Requirement H within the framework of Section VII 183 IX.A.a.ii. study the use of UGS in the context of customary law of war and applicable EU Requirement Comply 1 2 and national legislation 183.1 iMUGS shall deliver a study on the use of UGS in the context of customary law of Derived war and applicable EU and national legislation. Requirement 184 IX.A.a.iii. study attitudes of military personnel and general population towards the use of Requirement Comply 1 2 unmanned platforms 184.1 iMUGS shall deliver a study of attitudes of military personnel and general Derived population towards the use of unmanned platforms. Requirement 185 IX.A.a.iv. study on ethics of MUGS employment in operational context Requirement Comply 1 2 185.1 iMUGS shall deliver a study on ethics of MUGS employment in operational Derived context Requirement 186 IX.A.a.v. definition of relevant scenarios and use cases Requirement Comply 7 6 186.1 iMUGS shall define operational scenarios in workshops with participants from Derived pMS and industry partners. Requirement 186.2 iMUGS shall define defining test cases based on the operational scenarios. Derived Requirement 187 IX.A.a.vi. definition of key capability requirements, main system requirements and Requirement Comply 1 6 constraints 187.1 iMUGS shall define key capability requirements, main system requirements and Derived constraints Requirement 188 IX.A.a.vii. definition of CONOPS Requirement Comply 7 6 10PCO005_2 Sub-Project for responsibility; SP1 = Integ.; SP2 = Aut.; SP3 = Cyber; SP4 = Comms; SP5 = Swarm.; SP6 = C2; SP7 = MUM-T. Demo No is for indication only. 25 / 29 EDIDP-MUGS-2019-002-iMUGS Original pMS definition is identifed as cells with background color, contrary to respective decomposed requirements without color. COMPANY CONFIDENTIAL DEMO MoM ID / ID Ref. MR ID pMS High Level Requirements (HLR) iMUGS Decomposed Mission (Operational) Requirement Req Type SOC SP NO Date Accepted 188.1 Definition of CONOPS based on the results of the workshops for operational Derived scenarios and the outcomes of the belonging tests/demonstrations. Requirement 189 IX.A.b. designing, which will include, without being limited to: Heading Noted 190 IX.A.b.i. integration of MUGS into simulation systems Requirement Comply 2 6 190.1 Integration of MUGS autonomy functions into specific simulation system (physics Derived simulation) 190.2 Integration of UGV into the virtual and constructive simulation of KMW for the Derived test of the outcome of the workshops for operational scenarios. Requirement 191 IX.A.b.ii. development of modular, multi-mission capable UGS Requirement Comply 1 2 191.1 iMUGS shall develop a modular, multi-mission capable UGS. Derived Requirement 192 IX.A.b.iii. development of cyber secure autonomous mobility software suite Requirement Comply 2 6 192.1 iMUGS shall develop a cyber secure autonomous mobility software suite Derived (backbone). Requirement 193 IX.A.b.iv. development of EW and cyber resistant C3 solution Requirement Comply 6 6 193.1 iMUGS C2 hardware platforms running COTS Operational System will be subject Derived to an Operating System Hardening process. Requirement 193.2 iMUGS C2 software development will consider security requirements and Derived guidelines. Requirement 193.3 iMUGS C2 will monitor the status of: Derived - UGV(s) GNSS signal availabilty (loss of navigation) Requirement - Datalink among C2 and UGV (loss of comms) - UGV cyber threat warnings and indicators (loss of control) - UGV operational warnings and indicators (system failure) 194 IX.A.b.v. testing MUGS concept in simulated environment Requirement Comply 7 5 194.1 iMUGS autonomy concept shall be tested in simulated environment Derived Requirement 10PCO005_2 Sub-Project for responsibility; SP1 = Integ.; SP2 = Aut.; SP3 = Cyber; SP4 = Comms; SP5 = Swarm.; SP6 = C2; SP7 = MUM-T. Demo No is for indication only. 26 / 29 EDIDP-MUGS-2019-002-iMUGS Original pMS definition is identifed as cells with background color, contrary to respective decomposed requirements without color. COMPANY CONFIDENTIAL DEMO MoM ID / ID Ref. MR ID pMS High Level Requirements (HLR) iMUGS Decomposed Mission (Operational) Requirement Req Type SOC SP NO Date Accepted 194.2 iMUGS operational scenarios shall be tested in the virtual and constructive Derived simulation of KMW Requirement 195 IX.A.c. prototyping, which will include, without being limited to: Heading Noted 196 IX.A.c.i. integration of three development packages Requirement Comply 1 6 196,1 integration of three development packages Derived Requirement 197 IX.A.c.ii. demonstration of MUGS in operational environment Requirement Comply 1 6 197.1 iMUGS shall test the appropriate selected outcomes of the workshops for Derived operational scenarios. Requirement 197.2 Local swarming is demonstrated in an internal simulation system. Derived Requirement 197.3 Global swarming will be validated and demonstrated in a relevant environment Derived Requirement 198 IX.A.d. testing, which may include, without being limited to: Heading Noted 199 IX.A.d.i. testing in artic environment Requirement Partial 1 3 199.1 iMUGS concept should be demonstrated close to arctic latitudes, in winter season Derived (pending on demonstration plan approval). Requirement 200 IX.A.d.ii. testing in urban environment Requirement Partial 1 4 200.1 iMUGS concept should be demonstrated in representative urban environment Derived (pending on demonstration plan approval). Requirement 201 IX.A.d.iii. testing in forested and rugged environment Requirement Partial 1 2 201.1 iMUGS concept should be demonstrated representative forested and rugged Derived environment (pending on demonstration plan approval). Requirement 202 IX.A.d.iv. testing in coastal areas Requirement Partial 1 4 10PCO005_2 Sub-Project for responsibility; SP1 = Integ.; SP2 = Aut.; SP3 = Cyber; SP4 = Comms; SP5 = Swarm.; SP6 = C2; SP7 = MUM-T. Demo No is for indication only. 27 / 29 EDIDP-MUGS-2019-002-iMUGS Original pMS definition is identifed as cells with background color, contrary to respective decomposed requirements without color. COMPANY CONFIDENTIAL DEMO MoM ID / ID Ref. MR ID pMS High Level Requirements (HLR) iMUGS Decomposed Mission (Operational) Requirement Req Type SOC SP NO Date Accepted 202.1 iMUGS concept should be demonstrated in representative coastal environment Derived (pending on demonstration plan approval). Requirement 203 IX.A.d.v. testing in desert environment Requirement Partial 1 6 203.1 iMUGS concept should be demonstrated in representative desert environment Derived (pending on demonstration plan approval). Requirement 204 IX.A.d.vi. testing in a hostile electromagnetic environment (EW) to find key features how to Requirement Partial 1 6 protect the communication systems against EW/cyber countermeasures 204.1 testing in a hostile electromagnetic environment (EW) to find key features how to Derived protect the communication systems against EW/cyber countermeasures. Requirement 205 IX.A.d.vii. testing the performance of autonomous navigation modules in various Requirement Partial 1 6 environments seen above 205.1 iMUGS operators shall be able to monitor MUGS performance. Derived Requirement 205.2 iMUGS autonomous navigation capabilites shall be reached in urban Derived environmment. Requirement 205.3 MUGS autonomous navigation capabilites shall be reached in forested and rugged Derived environment. Requirement 205.4 MUGS autonomous navigation capabilites shall be reached in various other Derived environments. Requirement 206 IX.A.d.viii. testing of possibilities and limitations of swarming technologies in various Requirement Comply 5 6 environments seen above 206.1 Local swarming shall tested in an internal simulation system in various Derived environments. Requirement 206.2 During the validation of the global swarming system, possibilities and limitations Derived in various environments shall be assessed Requirement 207 IX.A.d.ix. testing possibilities of utilizing different radio systems (local, commercial, tactical, Requirement Comply 4 3 etc) and waveforms (e.g. ESSOR 2D and 3D) 207.1 Various military radio waveforms shall be tested using SDR solution. Derived Requirement 207.2 Commercial waveforms may be tested using COTS equipment. Derived Requirement 10PCO005_2 Sub-Project for responsibility; SP1 = Integ.; SP2 = Aut.; SP3 = Cyber; SP4 = Comms; SP5 = Swarm.; SP6 = C2; SP7 = MUM-T. Demo No is for indication only. 28 / 29 EDIDP-MUGS-2019-002-iMUGS Original pMS definition is identifed as cells with background color, contrary to respective decomposed requirements without color. COMPANY CONFIDENTIAL DEMO MoM ID / ID Ref. MR ID pMS High Level Requirements (HLR) iMUGS Decomposed Mission (Operational) Requirement Req Type SOC SP NO Date Accepted 208 IX.A.d.x. testing and measuring of antenna propagations and emissions Requirement Comply 4 3 208.1 Antenna emissions and sensitivity shall be measured in a laboratory Derived Requirement 208.2 Antenna emissions shall be measured around the antenna to achieve the 3D Derived radiation pattern. Requirement 208.3 The antenna measurement shall be done using intented frequency. Derived Requirement 209 IX.A.d.xi. testing and measuring the possibilities offered by utilizing different power Requirement Comply 1 6 sources (fuel cells, solar-power, performance of different battery types, total energy consumption of the system chosen) 209.1 iMUGS assesses the possibilities offered by utilizing different power sources. Derived Requirement 210 IX.A.d.xii. testing and measuring of the integrated fire control and aiming systems offered Requirement Comply 1 6 by MUGS and UAS in order to benefit from the increased SA in the optimization of the artillery and mortar fire 210.1 iMUGS assesses the integrated fire control and aiming systems offered by Derived mobility platform and UAS. Requirement 211 IX.A.d.xiii. testing and measuring of the integrated damage assessment systems in MUGS Requirement Comply 1 2 and UAS to benefit from the use of resources in artillery fire 211.1 iMUGS assesses the possibilities offered by damage assessment systems utilizing Derived UAS. Requirement 212 IX.A.d.xiv. testing and measuring the combined performance produced by MUGS and UAS to Requirement Comply 1 2 gain maximal Situational Awareness (SA). 212.1 iMUGS assesses the possibilities offered by situational awareness systems Derived utilizing UAS. Requirement 213 IX.A.d.xiv. This data will be used for taking the initiative in the battle space. Note Noted EOF EOF End Of File EOF 10PCO005_2 Sub-Project for responsibility; SP1 = Integ.; SP2 = Aut.; SP3 = Cyber; SP4 = Comms; SP5 = Swarm.; SP6 = C2; SP7 = MUM-T. Demo No is for indication only. 29 / 29  Grant Agreement number: EDIDP-MUGS-2019-002-iMUGS ANNEX 1 DESCRIPTION OF THE ACTION Part A 1. General Information 2. Identification of the beneficiaries, linked third parties, subcontractors involved in the action and associated partners 3. Bonuses 3.1. SMEs and mid-caps participation 3.2. Permanent Structured Cooperation 4. Tables 4.1. List of work packages 4.2. Work package description 4.3. List of deliverables 4.4. List of milestones 4.5. Critical risks for implementation 4.6. Summary of staff effort Part B 5. Project presentation 6. Focus on award criteria 1 Grant Agreement number: EDIDP-MUGS-2019-002-iMUGS ANNEX 1 Part A 1. General Information Call identifier: EDIDP-MUGS-2019 (Multipurpose unmanned ground system) Topic identifier: EDIDP-MUGS-2019 Activities: Studies; Design; Prototyping; Testing Acronym of the proposal: iMUGS Title of the proposal: Integrated Modular Unmanned Ground System Duration in months: 30 Abstract: The iMUGS (integrated Modular Unmanned Ground System) project consists in the studies, design, prototyping and testing of the fundamental features for unmanned systems and of their integration based on a modular, standardized and open software system. The project will develop a modular and scalable architecture for hybrid manned-unmanned systems in order to address a large range of missions and to enable easy update or modification of assets and functionalities within the system: aerial and ground platforms, command, control and communication equipment, sensors, payloads and algorithms. The project is structured along 7 sub-projects that all cover studies, design, prototyping, testing and technical coordination: 1. System Integration 2. Autonomous Functions 3. Cyber Security 4. Communication 5. Swarming 6. Command, Control and Interoperability 7. Manned-Unmanned Teaming To be in synergy with the forces’ needs and requirements, and foster their engagement, 6 demonstrations performed throughout Europe and a final engagement event will punctuate the project. The governing bodies of the project also comprise end-users. The consortium, led by MILREM AS, comprises some of the best in class European players in their respective fields: SAFRAN Electronics & Defense SAS, GT Cyber Technologies OÜ, 2 Grant Agreement number: EDIDP-MUGS-2019-002-iMUGS ANNEX 1 Bittium Wireless Oy, Insta DefSec Oy, GMV Aerospace and Defence SAU, Krauss-Maffei Wegmann GmbH & Co KG, Diehl Defence GmbH & Co KG, Nexter Systems SA, Latvijas Mobilais Telefons SIA, (Un)Manned NV, Ecole Royale Militaire – Koninkljike Militaire School and dotOcean NV. It is fully committed to make the project a success and demonstrate the added-value of EU-funded defence research. It also offers a large place to SMEs. iMUGS fully complies with the call EDIDP-MUGS-2019. The work will pave the way for building a robust, innovative and credible competency in Europe. The overall budget of iMUGS is 32,6 M€, of which up to 30,6 M€ are funded by the EDIDP and up to 2 M€ by the participating Member States. Free keywords: Unmanned platforms; unmanned ground systems; UGVs; autonomy; autonomous functions; cyber security; swarming; command and control; communication networks; manned unmanned teaming 2. Identification of the beneficiaries, linked third parties, subcontractors involved in the action and associated partners 2.1. BENEFICIARIES Country of No Legal name PIC number establishment 1.1 Milrem AS 915338270 Estonia 1.2 SAFRAN Electronics & Defense SAS 999954668 France 1.3 GT Cyber Technologies OÜ 902919069 Estonia 1.4 Bittium Wireless Oy 999647372 Finland 1.5 Insta DefSec Oy 973303918 Finland 1.6 GMV Aerospace and Defence SAU 999905004 Spain 1.7 Krauss-Maffei Wegmann GmbH & Co KG 902829247 Germany 1.8 Diehl Defence GmbH & Co KG 998381813 Germany 1.9 Nexter Systems SA 901314301 France 1.10 Latvijas Mobilais Telefons SIA 906133746 Latvia 1.11 (Un)Manned NV 911717842 Belgium 1.12 Ecole Royale Militaire – Koninkljike Militaire School 999831575 Belgium 1.13 dotOcean NV 940929392 Belgium 3 Grant Agreement number: EDIDP-MUGS-2019-002-iMUGS ANNEX 1 2.2. LINKED THIRD PARTIES National Country of No Legal name registration Applicant to which it is linked establishment number 2.1 Bittium Safemove Oy 1855598-7 Finland Bittium Wireless Ltd. 2.2 Nexter Robotics SAS 538115684 France NEXTER Systems SA 2.3. SUBCONTRACTORS INVOLVED IN THE ACTION Applicant, linked third party or National Country of subcontractor involved in the No Legal name registration establishment action to which it is number subcontracted 3.1 Rantelon OÜ 10496551 Estonia GT Cyber Technologies OÜ 3.2 DA-Design Oy FI10094047 Finland Bittium Wireless Oy 3.3 AVQ GmbH HRB201209 Germany Diehl Defence GmbH & Co KG 3.4 Threod Systems OÜ 12323903 Estonia Milrem AS 3.5 FN Herstal NV 0441.928.931 Belgium Milrem AS NL822622762 The 3.6 RHEA System B.V GT Cyber Technologies OÜ B01 Netherlands Kaitseväe Akadeemia 3.7 (Estonian Military EE101272342 Estonia Milrem AS Academy) DefSecIntel Solutions 3.8 14514582 Estonia Milrem AS OÜ 3.9 Hentschel System GmbH DE115646189 Germany Diehl Defence GmbH & Co KG 3.10 Nedaciana Holdings Ltd ΗΕ 289151 Cyprus Diehl Defence GmbH & Co KG 3.11 Hensoldt Sensors GmbH HRB 219393 Germany GT Cyber Technologies OÜ 3.12 FY-Composites Oy 1611395-8 Finland Milrem AS FR078023559 3.13 4D-VIRTUALIZ France Milrem AS 33 2.4. ASSOCIATED PARTNERS Not applicable. 4 Grant Agreement number: EDIDP-MUGS-2019-002-iMUGS ANNEX 1 3. Bonuses 3.1. SMEs and mid-caps participation iMUGS Budgeted Work Shares Studies Design Prototyping Testing Non-cross-border SMEs 9% 15% 14% 21% Cross-border SMEs 8% 24% 34% 26% SMEs 17% 38% 48% 48% Mid-caps 17% 20% 13% 18% 3.2. Permanent Structured Cooperation The action is developed in the context of the Permanent Structured Cooperation (PESCO). 4. Tables 4.1. List of work packages No Work Package (WP) Start Month End Month 1 Studies 1 30 2 Design 1 26 3 Prototyping 1 30 4 Testing 1 28 5 Grant Agreement number: EDIDP-MUGS-2019-002-iMUGS ANNEX 1 4.2. Work package description WP number Activity covered Start month M1 1 Studies End month M30 Participant number 1.1 1.2 1.3 1.4 1.5 1.6 1.7 Short Name MILREM SAFRAN GTCT Bittium Insta GMV KMW PM per participant 70 11 43 16 106 13 223 Participant Number 1.8 1.9 1.1 1.11 1.12 1.13 1.14 Short name DIEHL NEXTER LMT UnManned ERM-KMS dotOcean EMA PM per participant 8 26 27 15 12 17 0 Objectives The objective of this WP is to provide the high-level architecture for the whole system of systems, as well as for its components and features. This high-level approach will also lead to identify the critical points for the design, whichever their nature: technological, integration, use-case… This overall objective is divided according to the main tasks of this WP:  Based on end user experience and workshops, and with the help of virtual and constructive simulation, a common understanding for military operational scenarios, as a base for upcoming ConOps with iMUGS will be established. These scenarios will define and describe how to deploy and operate iMUGS with different combinations of other military systems and soldiers. Furthermore, possibilities MUM-T will be described.  State the systems engineering approach, define the systems engineering management plan, integration schedule and define system requirements and preliminary design and interfaces;  Define the Operational Concept and Technical Requirements Specification of the C2 subsystem  Specify the high-level architecture of the autonomy subsystem (Autonomy framework), taking into account all available and applicable standards as well as use cases and environments  Gain a better understanding of the current cyber-threats autonomous vehicles are subject to, and thus find the optimal solution in addressing these threats; Define the Cyber-secured solutions to be implemented in the global architecture of the system.  Provide an architecture of the subsystem communication that meets the call requirements, allows the system to perform all the missions and functions identified in ConOps, and a corresponding to systems engineering management plan;  Provide architectures and methods for swarming operations in various interconnectivity conditions as well as methods to structure data inputs and efficient search algorithms capable of dealing with structured dynamic data. Description of work Task 1.1 System engineering and platform studies: MILREM, subcontractor EMA (M1-M12) The goal of this task is to provide system engineering management and deliver global architecture and preliminary system requirements and preliminary interface definitions for iMUGS (including requirements for a novel single-handed controller and THeMIS platform). In addition, a system level safety package will be delivered together with legal, ethical and perception analysis on the use of unmanned ground systems. Subtask 1.1.1 System engineering and architecture development: MILREM (M1-M7) In this task, System engineering management activities consist of requirements engineering, system architecture development and -design specification. Requirements engineering will consist of specifying a requirements model, reviewing and releasing requirements specifications. System architecture development activities will map and specify the high-level system architecture (model) and coordinate the specification of Interface Control Documents (ICDs). Requirement traceability is continuously provided by the system engineering team. System engineering management plan, integration plan, system budgets and documentation requirements definition will be drafted and issued. MILREM, through the Project Architect, will be responsible for systems engineering management with the support from SP leaders. 6 Grant Agreement number: EDIDP-MUGS-2019-002-iMUGS ANNEX 1 Subtask 1.1.2 Requirements Reviews: MILREM (M1-M4) The high-level requirements for iMUGS are to be synthesized into Mission requirements and released after validation in a MDR, to be completed before M1. From these Mission requirements, System and subsystem requirements are derived and accepted by Preliminary Requirements Review. This task will be led by MILREM with responsibilities on coordinating and conducting Mission Definition and Preliminary Requirements Reviews and delivering respectful reports. Subtask 1.1.3 Safety & securities studies: MILREM (M1-M7) As safety and ethical aspect of the iMUGS is of crucial importance, several Safety assessment studies will be foreseen. Safety & security analysis on the core functions iMUGS System of Systems (SoS) covering the transport mission, the ISR mission, the MEDEVAC mission and related C2 aspects. The safety analysis process (based on approved ARP/MIL standards) will apply AEP-4754/ARP 4754 specified methodology to evaluate iMUGS System of Systems (SoS) core functions and the development of the systems performing these functions. To determine that the associated hazards have been properly addressed, the safety & security assessment process takes into account any additional complexities and interdependencies which arise due to integration. The SoS safety & security process defines safety & security requirements for high- level iMUGS functions based on the functional analyses made at subsystem level by the iMUGS partners as well as security recommendations for the demonstrations performed during the project. FN Herstal will deliver a System of Systems level safety & security analysis package following AEP- 4754/ARP 4754 methodology including guidelines for subsystem safety assessments and recommendations for security of the demonstrations. Subtask 1.1.4 Legal, ethical and attitude studies towards the use of unmanned platforms: MILREM (M1-M12) Specific studies will investigate ethical concerns with regards to iMUGS employment in operational context and legal concerns for autonomous unmanned ground systems. In a BVLOS scenario, with a situational awareness limited to the UGV sensors with increasing use of autonomy, under the lead of MILREM, subcontractor FN Herstal will analyse and propose ethical rules of engagement of iMUGS. A study on military and social attitudes towards the use of unmanned platforms will be provided along with inputs to the development of Operational Scenarios and on user experience, general design and safety principles. The study will contribute to EU-wide guidelines regarding ethical use of AI in military UGS in the context of customary law of war and applicable legislation. Subcontractor EMA will deliver a study on legal aspects of UGVs and on attitudes of general population and military on UGV. Subcontractor FN Herstal will deliver a study on ethical and legal concerns of UGVs. Subtask 1.1.5 Single-handed remote-control requirements engineering: MILREM (M1-M3) Requirements for an intuitive single-handed control pad for high cognitive load situations for dismounted troops will be developed to provide control over iMUGS system functions (autonomy, lights, obscurant deployment etc) during troop advancement. This serves as a primary remote for logistics and maintenance activities. The activity will cater for deriving requirements for the control pad and preparing for design phase. Under the lead of Milrem, subcontractor THREOD will be deliver the requirements for single-handed remote controller. Subtask 1.1.6 Requirement analysis for THeMIS platform production: MILREM (M1-M3) Since the design of Autonomy functions requires validation of sensor placement and driving dynamics as early as possible an iteration of requirements for producing THeMIS platforms will be commenced. The analysis and review will accommodate the requirements towards THeMIS platform for iMUGS functionality. MILREM will be responsible for requirements analysis for THeMIS platform and delivery of platform requirements. Task 1.2 Studies Autonomous functions: SAFRAN, DIEHL, NEXTER, MILREM (M1-M6) This task will consist in specifying the high-level architecture of the Autonomy framework as set in the objectives of the WP. Available and applicable standards, autonomy use cases and environments from military operation scenarios will be determined and used in the architecture process. Task 1.2 will study the interfaces between the Autonomy framework and other subsystems as cybersecurity 7 Grant Agreement number: EDIDP-MUGS-2019-002-iMUGS ANNEX 1 unit (task 1.3), Communications system (task 1.4), C2 system (task 1.6) and MILREM THeMIS Platform (task 1.1). Subtask 1.2.1 Autonomy subsystem Normative Framework: DIEHL (M1-M3) DIEHL will lead this subtask. Based on military operation scenarios and iMUGS requirements, DIEHL will define together with MILREM, SAFRAN and NEXTER the Autonomy use cases and will derived autonomy functions (as Follow me vehicle/pedestrian, Way point navigation, surveillance, patrolling, …). Use cases and operational requirements for autonomy functions will be derived from UGV scenarios analysis. The existing normative repository and the required capabilities and available technologies will be identified. Subtasks 1.2.2 Autonomy subsystem External interfaces: DIEHL, SAFRAN, NEXTER, MILREM (M1-M6) DIEHL will lead this subtask. From the selected use cases, together with SAFRAN, NEXTER, MILREM and DIEHL, the high-level specification and the interfaces between Autonomy Subsystem and other subsystems (e.g. communication, UGV, C2, …) will be identified. Subtask 1.2.3 Autonomy subsystem User-Robot interactions: DIEHL, SAFRAN, NEXTER, MILREM (M1-M3) DIEHL will lead this subtask. From the selected use cases, together with SAFRAN, NEXTER, MILREM and DIEHL, from the high-level specification of the autonomy subsystem User-Robot interactions will be defined. To do so, they will identify and analyse system requirements regarding user-robot interface for autonomy functions (including operations, ergonomic, adjustable autonomy, …), Man-Machine interfaces and mission planning/supervision tools (including inputs/specifications to C2 SP regarding autonomy SP). Subtask 1.2.4 Autonomy subsystem Safety & Security: DIEHL (M1-M6) DIEHL will lead this subtask and perform a subsystem Autonomy framework safety and security analysis. This analysis will consider soldier support vehicles as the MILREM Themis platform but also larger platforms (e.g. trucks) in order to guarantee an adaptability of the Autonomy framework to other types of ground vehicles. Based on this safety & security Analysis and input from other SPs (particularly Cybersecurity) the High-Level Hardware and Software Architecture will be defined as well as the interfaces towards other subsystems (communications, Swarming, C2, Ground vehicle). Subtask 1.2.5 Hardware and Software architecture of Autonomy framework: DIEHL (M1-M3) DIEHL will lead this subtask. With partners, DIEHL will define subsystem requirements for hardware architecture (including PC system, network, sensors and power infrastructure based on system requirements and capabilities of partners within the project) and for software architecture (including services, taxonomy, internal interfaces, data model, UGC-assessment) of Autonomy framework. DIEHL with the other partners will also define the Autonomy framework central services by identifying the services which are used by all means within autonomy subsystems (common definitions/models, common tools and means) and redacting the central services high level specification. Task 1.3 Studies of Cybersecurity: GTCT (M1-M15) The objective of Studies of Cybersecurity will be to understand the types of cyber threats that iMUGS will face when in an operational military environment. Furthermore, risk assessments will consider these threats and evaluate vulnerabilities introducing risk in designs by the consortium partners for individual subsystems of iMUGS. Subtask 1.3.1 Study on the Security of Unmanned Military Ground Systems: GTCT (M1-M7) GTCT will conduct a study that will focus on the risks surrounding the use of autonomous unmanned ground vehicles (UGV) from nation state and military level cyber threats and postulate the most probable attack vectors to a UGV, including the effects of cyber related attacks. With the consortium partners, GTCT will study the technological design of the MUGS platform and autonomous systems in general. The study will consist of interviews, technical discussions and desk research to gain a better understanding of the architecture of autonomous systems, how they could be exploited with cyber weapons, and what are the most probable attack vectors from a cyber-attack. Subtask 1.3.2 Risk Assessment for iMUGS operations: GTCT (M1-M7) 8 Grant Agreement number: EDIDP-MUGS-2019-002-iMUGS ANNEX 1 GTCT will use the service of their subcontractor, RHEA, for conducting the risk assessment, focusing on military operations for the iMUGS. The purpose of this risk assessment is to evaluate the cyber risks of the platform while operating in a military environment and identifying risk mitigation measures. Subcontractor RHEA will communicate with the consortium partners and coordinate closely with GTCT and each partner in the process of assessing cyber risk and determining a method of treating or mitigating each risk. The risk assessment will consist of in person visits and questionnaires of at least three different partners. Subtask 1.3.3 Risk Assessment of the iMUGS Supply Chain: GTCT (M8-M15) GTCT will again work with their subcontractor RHEA to perform a second risk assessment of the iMUGS platform. This risk assessment will focus on the supply chain of the partners, in order to evaluate cyber risks, present in the fabrication and long-term maintenance of the vehicle. Task 1.4 Studies Communication equipment and network: Bittium, LMT (M1-M3) The goal of the task is to analyse the use cases and select proper technologies and functionalities to be implemented and integrated to the iMUGS. In addition, further study on the utilization of commercial networks shall be carried out. The work starts with use cases analysis and a preliminary system design including definition of the interfaces between module sub-systems and sub- components. Then, technologies shall be analysed and selected. The last task is to provide a detailed plan for the design and development steps. Subtask 1.4.1 Communication and network Use case definition and analysis: Bittium (M1-M2) This subtask will analyse the end-user requirements, study application of modern commercial networks, and define the use cases in detail. The outcome of the task is the updated and detailed use case description. Subtask 1.4.2 Communications and network Preliminary system design: Bittium (M1-M2): Based on the use cases definition and customer requirements, preliminary system design shall be carried out. The preliminary system design comprises system requirements consolidation and system architecture description, which consists of the needed details such as a block level architecture design and interface description as well as functional description. Subtask 1.4.3 Communication and network Technology analysis and selection: Bittium, LMT(M2- M13) Based on the results of Subtask 1.4.1 and partially jointly with Subtask 1.4.2, the technologies to be deployed in the iMUGS communications sub-system will be selected. The subtask covers both tactical and commercial communication technologies and services. Technological dependency on third party components will be taken into account in the design. Subtask 1.4.4 Detailed planning: Bittium (M1-M13) To carry out the design and implementation successfully, a detailed plan shall be provided. Required updates based on the on-going work with focus on Phase 3 topics shall be provided as part of WP2 (Design) work. Task 1.5 Studies Swarming: ERM-KMS, DotOcean, INSTA (M1-M7) The objective of this task is to explore and find ways of integrating existing technologies into building blocks usable for real-time swarming capabilities, addressing the use cases. Subtask 1.5.1 Swarming Integration and adaptation: ERM-KMS, DotOcean, Insta (M1-M4) Under the lead of ERM-KMS, ERM-KMS and DotOcean will modify the DotOcean multi-agent toolbox for IIoT digitally twinned robotic systems, to enable the use within the iMUGS swarming framework. Insta will update existing in-house simulation environment to develop local swarming of iMUGS. Subtask 1.5.2 Swarming use case definition and analysis: ERM-KMS, DotOcean, Insta (M1-M7) The aim is to define principles and methods to maximally reduce the problem dimensions, maximally structure data and to define search strategies. ERM-KMS will lead this subtask, map possible concepts of swarm operation and identify possible scenarios and strategies. DotOcean and Insta will define possible solutions to the combined set of concepts of operation, DotOcean within an unconstrained context regarding communications, data and computational power (Global) and Insta within a constrained context regarding communications, data and computational power (Local). 9 Grant Agreement number: EDIDP-MUGS-2019-002-iMUGS ANNEX 1 Subtask 1.5.3 Swarming Technology analysis and selection: ERM-KMS, DotOcean, Insta (M4- M7) Based upon the findings of subtask 1.5.2, technologies and algorithms with the potential to solve individual and combined use cases, within the constraints set, will be analysed and selected. ERM- KMS and DotOcean will define possible architecture and algorithms of swarming systems, centralized optimization of swarming systems. Insta will focus on decentralized collaborative methods and algorithms for swarming systems. Technological dependency on third party components will be taken into account in the design. Subtask 1.5.4 Swarming Iterations and optimally solving increasing complexity: ERM-KMS, DotOcean, Insta (M7-M24) Optimally solving combined swarm objectives will surface specific needs, restrictions or adaptations to the individual objective function solvers. Within this subtask a specific focus will be laid on how to optimize the algorithms, data structures and solvers towards enabling multi objective swarm function solvers. ERM-KMS and dotOcean will work on solutions for centralized decision making in order to achieve the swarm objectives, Insta on solutions for decentralized decision making in order to achieve the swarm objectives. Task 1.6 Studies Command and Control and interoperability: GMV, (Un)Manned, LMT (M1-M2) The objectives of this task are to define the Operational Concept of the C2 subsystem and to elaborate the Technical Requirements Specification of the C2 subsystem. Subtask 1.6.1 Preparation of the Operational Concept Description: GMV, (Un)Manned, LMT (M1- M2) The aim is to develop an operational description of the C2 subsystem, including the elaboration of C2 System NATO Architecture Framework (NAF) views, identification of interfaces and of conformance requirements to appropriate standards, STANAGs etc. GMV will lead this subtask. GMV will focus on the tactical C2 component. (Un)Manned will focus on real time safety critical C2 component and its high-level design aspects, including definition of a flexible architecture for generic unmanned system control covering multi domain control station and allowing future expansion with different unmanned systems and safety critical payloads. LMT will participate as interoperability test case with their C2 system. Subtask 1.6.2 C2 Technical Requirements Specification: (UN)Manned, GMV (M1-M2) (Un)Manned, with GMV contribution, will lead the preparation of the Technical Requirements Specification of the C2 subsystem. Task 1.7 Manned-Unmanned Teaming Studies: KMW, NEXTER, MILREM (M1-M30) Goal of this task is to define military operational scenarios for the development of MUGS and the engagement with iMUGS in different combinations with soldiers and other systems. Subtask 1.7.1 Initial MUM-T study: KMW, NEXTER, MILREM (M1-M14) First aim of this subtask is to develop military operational scenarios to be used as global definitions for a set of ConOps master scenarios for iMUGS phase 1. Second aim of this subtask is to analyse deployment methods with already existing means of transport and to describe requirements on the deployment of iMUGS. KMW will lead this subtask and will be the meeting coordinator. As part of this initial MUM-T study, KMW will organize three meetings (workshops in M4, M8 and M12) of five working days in its Munich facilities (Germany). These workshops shall help to develop the military operational scenarios on one side and to discuss ways of deployment of iMUGS on the other side. These workshops will take place with the help of the virtual and constructive simulation of KMW where applicable (see corresponding subtasks 1.7.3 and 1.7.4). It shall support the discussions, deliver pictures of possible engagements and allow the visualization of concepts and ideas. KMW will deliver in M14 the initial MUM-T study containing: a summary of the workshops, the first version of military operational scenarios which can be used as a base for the demonstrations and an analysis of deployment methods for iMUGS. NEXTER and MILREM will participate to the meetings, bring in their expertise for military operational scenarios, review the outcomes and work as a first point of contact for the French army, respectively the Estonian army. Participating Ministries of Defence (MoD’s) shall bring in knowledge and own tactical goals in terms of deployment and operational use of iMUGS now and in future. 10 Grant Agreement number: EDIDP-MUGS-2019-002-iMUGS ANNEX 1 Subtask 1.7.2 MUM-T evaluation study: KMW, NEXTER, MILREM (M14-M30) The initial MUM-T study will be updated and actualised based on the results from the design, prototyping and the demonstration phases. As a first step, test cases for the military operational scenarios will be written as helping guideline for the upcoming demonstrations. The handover to the participating MoD’s and discussion of the test cases will be done in the context of a status meeting at KMW in Munich, 16 months after project’s start. KMW will note and evaluate the results, according to the outcomes and requirements of the initial MUM-T study. KWM will update and actualise the initial MUM-study. Ideas and concepts not considered for this project will be collected for a possible follow-on project. NEXTER and MILREM will participate during the meeting and support the preparation of the study. Subtask 1.7.3 MUM-T virtual simulation: KMW (M1-M20) The subtask MUM-T virtual simulation will support the initial and the evaluation MUM-T studies as described above. KMW will enlarge the existing simulation, integrate the iMUGS and a generic UAV as new simulated units, adapt the user interfaces (generic optic and control unit) in the simulation and investigate possible operations in different environments under different conditions, like e.g. different weather conditions. For the different environments, four existing terrain databases will be used. A damage model for the iMUGS will be implemented. The damages can be caused by collisions and/or enemy fire. Damages of the iMUGS will be based on problems with the engine, the camera, the tracks or a lost radio connection. Autonomous or semi-autonomous operating modes will be to follow a unit (vehicle/human), return to the starting point, drive towards a target point. Simulated problems with the digital/analogue radio connection will be latencies, transmission errors (loss of pictures or data) or a complete breakdown. It is foreseen to use the existing AI in the simulation tool and adjust the capabilities to the assumed and predicted capabilities of the iMUGS. The use of the original iMUGS AI in the simulation is not foreseen. Main focus for this project will be the use cases LOS and BVLOS. Subtask 1.7.4 MUM-T constructive simulation: KMW (M1-M20) KMW will lead this task and integrate a simplified iMUGS in the simulation environment to support the MUM-T studies evaluation. KMW will generate scenarios with different combinations of forces and with different settings in a high-level analysis tool (MASA SWORD) KMW will realise three military operational scenarios based on the initial MUM-T study and evaluate them, with the support of Participating MoD’s, to determine iMUGS advantages and necessary improvements. Deliverables D1.1 iMUGS Development and Test Plan. Design & development goals for all Sub Projects. D1.2 iMUGS Study Report. Each subproject provides at least one section to the document. It includes the system architecture, subsystem architecture, ICD (interfaces definition between all subsystems). D1.3 Manned-Unmanned Teaming Study Report. 11 Grant Agreement number: EDIDP-MUGS-2019-002-iMUGS ANNEX 1 WP number Activity covered Start month M1 2 Design End month M26 Participant number 1.1 1.2 1.3 1.4 1.5 1.6 1.7 Short Name MILREM SAFRAN GTCT Bittium Insta GMV KMW PM per participant 241 193 142 266 0 85 4 Participant Number 1.8 1.9 1.1 1.11 1.12 1.13 1.14 Short name DIEHL NEXTER LMT UnManned ERM-KMS dotOcean EMA PM per participant 46 168 0 132 41 50 0 Objectives This WP will include all design activities of the project and also elaborate subsystem level engineering plans / specifications as configuration management, test and integration plans. The development will follow the iterative process described in section 6.1.4.1 allowing then to demonstrate all along the project some developed functions (performed in WP4). This overall objective is divided according to the main tasks:  to prepare and perform the System Requirements Review  to prepare and perform the Preliminary Design Review (PDR) and Customer Consultation / Critical Design Review (CDR).  to develop all the components that are composing the Autonomy subsystem (Autonomy Framework): the backbone, the autonomous algorithms and functions, the related means and tools for autonomy functions and mission’s development (data warehouse, simulation for autonomy, data labelling tool, collection of data for IA algorithm training, ...).  to provide a field-test ready communications system for the UGV application for all use cases.  to focus on the design phase of C2 software, including the design of user interfaces and human factors, and to maximize the use of Commercial-off-the-Shelf (COTS) hardware  to develop a generic framework for the design of a CDS allowing the system to be adapted to other autonomous vehicles for military or civilian uses and to design a solution for securing the supply chain from cyber threats.  to develop the results of the Swarming studies and tests within maritime domain into adaptations and improvements of algorithms to support UGV multi-agent collaboration.  to define the design for UGV and UAV integration into a Boxer for tests and demonstrations of military operational scenarios with focus on deployment and MUM-T. Description of the work Task 2.1 System and UGV/UAV design: MILREM (M2-M7) The objective of the task is to perform system requirements and design reviews, design and interface specifications (including single handed controller and THeMIS platform) for iMUGS system. Subtask 2.1.1 Design Reviews: MILREM (M4-M7) The objective of this task is to collect input, prepare and perform SRR, Customer consultations and Preliminary and Critical Design Reviews. MILREM will lead this task according to the requirements (derived in subtask 1.1.2) and will coordinate and conduct the design reviews with the engagement of relevant subproject leads and customer representatives. After SRR, an incremental design development process (throughout the consortium) with multiple deliveries will enable subsystems to finalize the design and continue into prototyping asynchronously, lowering risk and dependencies between subsystems. This will lead to multiple Preliminary Design reviews and Critical Design reviews concluding with a system level PDR and CDR. A Customer consultation is envisioned to be held before system prototyping (M6). Subtask 2.1.2 Design of a single-handed controller: MILREM (M2-M7) Under the lead of MILREM, subcontractor THREOD will develop and approve the design for intuitive one-handed remote controller for UGV system. Subtask 2.1.3 Design of iMUGS customized THeMIS platform: MILREM (M2-M7) A STANAG 4370/AECTP-500 (EMC) certifiable THeMIS UGV platforms will be provided to enable as- early-as-possible testing and verification of autonomy and other relevant system testing. Platforms will 12 Grant Agreement number: EDIDP-MUGS-2019-002-iMUGS ANNEX 1 reside at relevant partner locations for agile hardware-in-the-loop testing and verification campaigns. MILREM will be responsible for design implementation of THeMIS platform. Task 2.2 Design Autonomous Functions: SAFRAN, NEXTER, DIEHL, MILREM (M1-M18) Autonomy subsystem (Autonomy framework) is composed of Autonomy Backbone (HW, OS/Middleware/common services, autonomy sensors) and autonomy algorithms/functions. The design of such an Autonomy framework is based on specific tools as Data Warehouse (populated with data collected during specific campaign to address use cases defined by the project, to train Artificial Intelligent algorithms of Autonomy functions), autonomy simulation (with Hardware in the loop, for development and integration purpose), ... Subtask 2.2.1 Detailed specification and development of Autonomy Backbone: NEXTER, SAFRAN, MILREM, DIEHL (M1-M12) From the high-level specification of autonomy framework (Subtask 1.2.1), the objective of this subtask is to specify and develop the autonomy backbone that will be used as basis within the project to host all the algorithms and modules for the autonomous functions described in high level specification. Autonomy backbone will be divided into 2 parts: one SIL part for safety critical functions of autonomy and one non SIL part for non-safety critical functions of the autonomy. SAFRAN will lead the subtask. SAFRAN, DIEHL, NEXTER and MILREM will specify the detailed architecture of the autonomy backbone and will choose the adequate HW (computers and sensors) and SW (OS, tools) components. DIEHL will specify and purchase a certifiable computer system (SIL 3/4) based on existing standards (if no existing standards, DIEHL will make a proposal for standardisation). NEXTER will participate to the SIL software development on the SIL platform together with DIEHL. MILREM will develop the low- level drivers for selected autonomy sensors. SAFRAN will also develop the Non SIL computer part of the Autonomy framework, the common backbone services that will be used by all Autonomy functions and will propose a generic container for autonomy algorithms. Finally, SAFRAN will set up the Backbone together with the other partners as specified. Subtask 2.2.2 Detailed specification and development of Autonomy Data Warehouse: NEXTER, MILREM, DIEHL (M1-M12) The objective of this task is to specify, develop and populate a specific Data Warehouse for Autonomy Algorithms training. It also includes the specification of the data formats to be used within the Autonomy framework development and tools for data labelling. MILREM will lead this subtask and will buy the data Warehouse. MILREM will define, together with DIEHL, NEXTER and SAFRAN, the Data Warehouse architecture and will specify the collected data (in line with data regulations and existing data format definition). MILREM will, with NEXTER, develop the Autonomy Algorithms labelling and training tools together and organize data collection campaigns together with partners. DIEHL and NEXTER will provide recorded data from their own test campaigns for the warehouse. Subtask 2.2.3 Detailed specification and development of a simulation tool for Autonomy: NEXTER, SAFRAN, MILREM, DIEHL (M1-M12) The objective of this subtask is to specify and buy an adequate simulation tool in order to perform simulation of the Autonomy framework. The simulation tool will be used to integrate all Autonomy algorithms of the partners within the Autonomy Backbone (with the principle of Hardware (HW) in the loop simulation). It will also be used to test the Autonomy framework following the use cases selected in the Task 1.2 before integration and testing of the Autonomy framework in the global system within WP5. MILREM will lead this subtask. MILREM together with NEXTER, SAFRAN and DIEHL, will lead the specification of the simulation environment based on the use cases defined in task 2.2 and on the objective of the integration phase. For this, the simulation environment will be purchased and installed in each companies’ laboratories. Subtask 2.2.4 Detailed specification of Autonomy for Mobility: NEXTER, SAFRAN, MILREM, DIEHL (M6-M18) The objective of this subtask is to specify and develop the algorithms that will be used for the autonomy demonstrations according to specified Use Cases. The latter will refactor them to allow them to work seamlessly within the backbone. Several algorithms achieving the same function will be implemented to challenge the autonomy backbone containers definition and to provide a better final result through algorithm concurrency. 13 Grant Agreement number: EDIDP-MUGS-2019-002-iMUGS ANNEX 1 NEXTER will lead this subtask. NEXTER, SAFRAN and DIEHL will provide some existing state-of-the- art algorithms that are running on their existing platforms (NextMapping3D for localization based on lidar as well as obstacle map management, Path following on rough terrain based on vision, Object detection algorithms – already trained to detect soldiers, vehicles and weapons, way point navigation and patrolling, person follow, vehicle follow). These algorithms will be adapted to the new autonomy backbone and modified with respect to safety & security requirements in order to be employed to demonstrate the specified Use Cases. Subtask 2.2.5 Detailed Specification of Autonomy for Mission: NEXTER, SAFRAN, MILREM, DIEHL (M6-M18) The objective of this subtask is to specify and develop the building blocks necessary to fulfil the selected missions or capabilities. This task includes mission planning, live supervision features, specifications of man-robot interactions and Human Machine Interface (HMI):  formalisation of the planning and scheduling problem, identification of uncertainties in problem variables and parameters.  formalisation of mission constraints, objectives and operational resources. This formalisation is elaborated according to use cases.  Automatic generation of executable scripts based on planning formalisms  modelling, definition and development of solving techniques wit search algorithms, proposition and trials of heuristics.  development of machine-learning techniques, based on convolution graph neural networks to learn heuristics  verification, experimentation and evaluation on small and real scale operational scenario, extracted from use cases. NEXTER will lead this subtask. NEXTER, SAFRAN and DIEHL will provide and adapt some existing state-of-the-art algorithms running on their platforms and develop some new ones. MILREM will develop an interface to send information from THeMis platform to Autonomy framework and C2. Task 2.3 Design Cyber Security: GTCT (M1-M24) The objective of this task is to create the design of the CDS. This will begin with a generic framework that can be applied to any autonomous vehicle and then refined to incorporate the scope of the iMUGS vehicle. Mitigating measures to secure the supply chain will also be developed, as presented from the cyber risk assessment. Subtask 2.3.1 Design of Security Measures for UGVs: GTCT (M1-M12) This task will focus on the design of a generic framework that can be used as a cyber defence system for any military autonomous vehicle. GTCT will design the generic framework, in collaboration with all consortium partners in order to address every issue that must be solved by the generic design for any type of autonomous vehicle. Subtask 2.3.2 Design of the Security of the iMUGS Supply Chain: GTCT (M12-M24) The objective of this task is to analyse cybersecurity issues related to the supply chain used in the iMUGS project. With the information provided from RHEA’s Cyber risk assessment tool, GTCT will formulate a design document for addressing cyber risks and collaborate with the three companies selected for conducting the cyber risk assessment to address the issues presented from the assessment and to implement a solution from the design document. Subtask 2.3.3 Design of the iMUGS Cyber Defence System (CDS): GTCT, SAFRAN, GMV, Bittium, MILREM (M1-M24) GTCT will lead the effort in refining the scope of the generic security framework into a design which is tailored to the iMUGS project. This will primarily consist of incorporating the mission and specific architectural features (Autonomy, C2, Communications, and Swarming) into the design. GTCT will work in close collaboration with other partners to understand the specifics architectures of the subsystems, as the CDS must monitor the network traffic between the system components to observe for malicious activity. The system software will run on a high assurance Operating System (OS) that will be provided from a subcontractor, chosen after completion of the Cyber Risk Assessment. Subtask 2.3.4 Design of EW Capabilities: GTCT (M8-M24) The objective of this task is to design a subsystem capable of managing all aspects of Electronic Warfare (EW), to include the status of Emissions Control (EMCON) of radiating equipment, detection of GNSS 14 Grant Agreement number: EDIDP-MUGS-2019-002-iMUGS ANNEX 1 spoofing, and the security and control of EW based payloads, such as portable jammers. This will be designed with the assistance of GTCT’s subcontractor, Rantelon. Task 2.4 Design Communication equipment and network: Bittium (M2-M23) The design work comprises development and implementation activities and, in addition, required testing and integration activities. The integration shall be carried out in module, sub-system and system level (cross-WP). Manufacturing and integration of the physical prototype shall be carried out in Activity Prototyping. The work shall be carried out in 3 incremental steps with the 1st step focusing on demonstrating a concept based on existing capabilities (basic) and the 2nd demonstrating new more advanced capabilities as defined in the Feasibility Study. The 3rd step develops and integrates the full functionality to the communications module. The work comprises the following subtasks for all steps: Subtask 2.4.1 Secure network solution (SNS): Bittium (M2-M23) Developed jointly by Bittium and subcontractor Safemove, the secure network solution provides the required distributed services including Mobile VPN and MDM for end-to-end security, seamless networking and remote device management. It gathers various communication technologies in a single IP- entity. The SNS supports mobility with system level handovers, e.g. from mobile 4G network to tactical network and vice versa. A novel solution is to deploy AI/Machine Learning (ML)-based technology to add intelligent control and routing functionality to the system. Subtask 2.4.2 Enhanced V2V communications: Bittium (M6-M22) Bittium shall develop novel functionality integrated to the selected tactical waveform supporting an antenna solution that combines the connectivity of an omnidirectional antenna to high gain of directional antennas to support full mobility and swarming with superior combat sustainability Low Probability of Intercept/Low Probability of Detection (LPD, LPI) in V2V comms applications. Subcontractor DA-Design will develop the microwave RF front-end that will be integrated to the tactical communications equipment to support the short-range broad band V2V communications. Together these technologies will provide the capability for the vehicles to transfer broadband data between each other required to support joint operations and swarming. Subtask 2.4.3 Tactical waveform development for UGS: Bittium (M6-M21) Based on the results of the technology selection carried out in the feasibility study, Bittium develops new functionality integrated to selected tactical waveform that enhances the system performance with the aim to support mobility, combat sustainability and to meet the data transfer requirements of the iMUGS. As a result, this task provides a fully functional and high-performance tactical mesh network solution for the UGV communications, fully interoperable with systems deployed by the forces for manned operations. The solution will also fully support relayed multi-hop and tethered drones to extend the comms coverage. Subtask 2.4.4 Technology integration: Bittium (M6-M23) Together with subcontractors Safemove and DA-Design, Bittium carries out the integration of communications technologies; tactical, commercial, special etc. into a functional communications module (subsystem). The work also comprises integration/interfacing of the communications system to other systems (autonomy, C2, platform, cyber). Subtask 2.4.5 EW support: Bittium (M2-M22) Based on the results of the prestudy and technology selection, Bittium shall develop and integrate to the selected tactical waveform (Subtask 3.4.4) EW/ESM capabilities that enhance the performance of the UGV communications in the battlefield conditions. The functionality may include, for example, jamming detection, LPD, LPI, AJ, localization and countermeasures to the communications system. Task 2.5 Design Swarming: ERM-KMS, dotOcean, Insta (M1-M24) Design efforts related to architecture, interfaces, data structuring, search algorithms as well as solvers and optimizers needed to address the use cases shall be carried out in the following subtasks. The subtasks consist of spins with increasing complexity, considering system and controller constraints, data structures and data structuring and increasing dimensions, search and optimization algorithms and MOFS to translate objectives to tasks that fulfil the overall optimized objective of the swarming system within given constraints. Subtask 2.5.1 Architecture, internal interfaces and system design: dotOcean, ERM-KMS (M1-M7) This task aims at structuring all requirements into architectures, interaction methods and concrete technical solutions. DotOcean and EMR-KMS focus on edge-fog-cloud linked architectures supporting centralized decision making in a sufficiently timely manner. Insta focusses on architectures supporting decentralized decision making relying on local computational resources and data. 15 Grant Agreement number: EDIDP-MUGS-2019-002-iMUGS ANNEX 1 Subtask 2.5.2 External interface design: Insta, dotOcean, ERM-KMS (M5-M14) Partners will jointly agree on how to interface to a swarm, predominantly from the end-user perspective and the autonomy perspective should be designed and will define interfaces between C2, Comms and autonomy and define the interaction boundaries with the autonomy module. Define methods of controlling the vehicles as well as sharing data and metadata for optimization purposes. Subtask 2.5.3 Data capturing, annotations, structuring and search algorithms: Insta, dotOcean, ERM- KMS (M5-M19) Define generic and non-proprietary methods to organize and securely share data between agents or internal modules (ex: autonomy). Insta will focus on developing algorithmic solutions within constraints of the available computing power and data. DotOcean and ERM-KMS will focus on algorithms using distributed massive parallel computational resources. Define methods to distribute and outsource computations to other resources available in the network. Subtask 2.5.4 Solvers and optimizers: dotOcean, ERM-KMS (M8-M24) Solvers and optimizers will be defined and implemented. DotOcean and ERM-KMS will focus on solvers that can be distributed over edge-fog-cloud, in order to optimize all agents and objectives combined. Insta will focus on developing individual solvers within constraints of the available computing power and data. Task 2.6 Design Command and Control and Interoperability: GMV, (Un)Manned, MILREM (M3-M20) The objective of this task is to design the C2 subsystem components. Design considers three activities:  Software and hardware requirements specification.  C2 components preliminary design.  C2 components detailed design. This task will also address the elaboration of subsystem test plans and procedures. Subtask 2.6.1 UGV Control Station design: (Un)Manned, GMV, MILREM (M3-M20) The task aims to provide a Preliminary Design and Detailed Design of C2 components including software design, UGV CS GUI and human factors design, COTS HW specification and definition of test procedures. A focus on Systems interfaces and implementation, software design and conformance requirements and hardware computing requirements on the C2 components will be done. (Un)Manned will lead this task and work on real time safety-critical component of the C2 station to drive the UGV and its design aspects, including definition of flexible architecture with modifiable vehicle profiles to allow for modularity and expandability of the design. Further contributions/interactions with the UGV manufacturer and other specialists will be used to further clarify the HMI aspects. Design feasibility within DO-178C development framework will be analysed and the platform will be expanded if necessary. GMV with (Un)Manned will identify data and control exchange with the Tactical C2ISR, overall architecture and other human factors engineering work. Subtask 2.6.2 Tactical C2ISR design: GMV, (Un)Manned (M3-M20) This subtask aims to define system interfaces and implementation, including both software and hardware C2 components. Preliminary Design and Detailed Design of C2 components including software design, GUI design, COTS HW specification and test procedures. GMV works on the Tactical C2ISR design, including external interfaces, handling of data and clarification of computing and communication needs. GMV will collaborate with (Un)Manned and other actors on control and data handling and exchange between components, including non-real-time or safety critical payloads. (Un)Manned works on the data exchange and collaborates with GMV in data and control signals handling. (Un)Manned will also work on safety critical payloads so handling and operator control of those will be designed into the software architecture. Subtask 2.6.3 Interface design: GMV, (Un)Manned, KMW (M3-M7) The task is devoted to the design of interfaces between these components, interfaces with vehicle and interfaces with other system WP as Platform, Communications, Autonomy, Swarming and Cybersecurity. GMV will lead this sub-task with the contribution of (Un)Manned. KMW will provide contributions for HW and human factors requirements and C2 design, in relation with the integration of C2 in Boxer vehicle. Task 2.7 Design MUM-T: KMW, MILREM (M1-M23) With this task the design for the connection between an unmanned air or ground system and a Boxer, and the belonging integration will be written. Subtask 2.7.1 Design UGV and UAV deployment with Boxer: KMW, MILREM (M1-M23) Here the following topics will be defined: design for the integration of the UGV control elements in the Boxer, design for the integration of the UAV transport/starting/landing box and the antenna on the top of 16 Grant Agreement number: EDIDP-MUGS-2019-002-iMUGS ANNEX 1 the Boxer, design for the integration of the UAV control station with belonging connecting cables in the Boxer and finally how to test the development of the UAV integration at the Boxer at the EMC chamber of KMW. A Boxer driving module will be requested as provision of GFE by the BAAINBw (Federal Office of Bundeswehr Equipment, Information Technology and In-Service Support) for the demonstrations and tests (preliminary positive confirmation has been received). KMW will lead this subtask and be responsible for the definitions. MILREM will provide the UGV with control elements for its deployment with the Boxer, deliver UGV interfaces to get towed by the Boxer and provide a corresponding technical support. MILREM, together with the responsible for the UAV, will do the provision of the UAV with belonging transport/starting/landing box, control station, antenna and connecting cables for the deployment with the Boxer, deliver the interfaces for the provisioned UAV with belonging components and give technical support for the integration. Deliverables Synchronized with CDR meetings. Each Sub Project will have its own CDR. D2.1 iMUGS Detailed Design Definition: System’s Integration (Initial version). It includes input from all SPs. D2.2 iMUGS Detailed Design Definition: System’s Integration (2nd version). It includes input from all SPs. D2.3 iMUGS Detailed Design Definition: System’ Integration (Final version). It includes input from all SPs. 17 Grant Agreement number: EDIDP-MUGS-2019-002-iMUGS ANNEX 1 WP number Activity covered Start month M1 3 Prototyping End month M24 Participant number 1.1 1.2 1.3 1.4 1.5 1.6 1.7 Short Name MILREM SAFRAN GTCT Bittium Insta GMV KMW PM per participant 81 0 31 13 2 46 21 Participant Number 1.8 1.9 1.1 1.11 1.12 1.13 1.14 Short name DIEHL NEXTER LMT UnManned ERM-KMS dotOcean EMA PM per participant 2 7 14 51 0 0 0 Objectives This overall objective is divided according to the main tasks of this WP:  to build, from the components developed in the design activity, the Autonomy Framework (delivering autonomy backbone and sensors);  to build a functional prototype of the CDS and integrate it with the platform and other functional prototyped components of autonomy and C2;  to build, from the components developed in the design activity, the C2 subsystem including: Software for the Control Station and Tactical C2 components, Software/Hardware integration and C2 Subsystem Integration;  to assemble and integrate THeMIS platforms for testing by integrating subsystems and payloads at system level and prepare system functionalities for testing.  to provide a demonstration ready and validated integrated prototype.  to integrate an UAV and the control elements for an UGV and an UAV into a Boxer. Description of work Task 3.1 System prototyping: MILREM (M1-M30) The objective of this task is to manufacture the prototypes of Platform, single-handed remote controller and integrate payloads (including tethered UAV) with the system. Subtask 3.1.1 Prototype production of the platform: MILREM (M1-M12) A STANAG 4370/AECTP-500 (EMC) certifiable MILREM THeMIS UGV platform will be manufactured to enable as-early-as-possible testing and verification of autonomy and other relevant system testing. Platforms will reside at relevant partner locations for agile Hardware in the loop testing and verification campaigns. The service life of the vehicles is consumed by test-driving in various climatic environments and weather conditions to compile and fine-tune a dynamic model of the platform and assessment of the system traversability and provide maximum amount of real-life dynamic mobility data for development and verification of autonomy algorithms. No life-cycle management costs (extending the service life of the produced platforms) are foreseen during the projects. This activity caters for production of the units and concludes with an acceptance review. MILREM will be responsible to produce the THeMIS platform units. Subtask 3.1.2 Continuous system level integration: MILREM, All project partners (M5-M26) Purpose of the subtask is to coordinate the system level integration and verification efforts and ensure timely availability of the system components and verified subsystems. This will include the set-up and coordination for the distributed bench model - including the autonomy functions simulator - to enable rapid testing, inclusion on components and technologies, and to enable agile system level test driven development approach. MILREM will be responsible for leading system level integrations and leading respective reviews, with the support of relevant subsystem providers and SP leaders. Subtask 3.1.3 Integration of a Tethered UAV payload: MILREM (M4-M6) Purpose of the subtask is to integrate tethered UAV solution with the system and prepare for testing and demonstration. MILREM will be responsible for tethered UAV integration, with the support of THREOD (subcontractor and UAV provider). Subtask 3.1.4 Single-handed controller prototype: THREOD, MILREM (M8-M10) Purpose of the subtask is to manufacture the prototype of the intuitive single-handed remote controller for UGV system and prepare for testing and verification. Under the lead of MILREM, subcontractor THREOD will be responsible for the prototyping of the single- handed remote. Subtask 3.1.5 Continuous payload integration: MILREM, All payload partners (M2-M26) 18 Grant Agreement number: EDIDP-MUGS-2019-002-iMUGS ANNEX 1 The objective of this subtask is to integrate payloads to the system for functionality testing and demonstration. The activity will consist of integration planning, execution, verification and relevant pre- and post- integration reviews and will deliver the relevant iMUGS functionality augmentation to the respective demonstration events for ex: integrated ISR (kit, with electro-optical imagers, object detection capabilities and links to C4I infrastructure), MEDEVAC (relevant equipment with telemedicine capabilities) and force protection (ranging from ballistic protection, laser ranging detection etc) capabilities. MILREM will be responsible for payload integration (inc. verification) and relevant reviews with the support from payload providers. Task 3.2 Prototyping Autonomous Functions: SAFRAN, MILREM, DIEHL, NEXTER (M1-M18) The objective of this task is to provide within the project an autonomy sensor kit and a full autonomy framework for testing and integration within the THeMIS. Subtask 3.2.1 Integration of the autonomy sensor kit: SAFRAN, NEXTER, DIEHL, MILREM (M1- M6) The objective of this subtask is to buy all autonomy sensors identified in feasibility activity, to adapt them and integrate them to an autonomy sensor kit that will be tested within WP5 and integrated at system level on the THeMIS platform within WP4. All partners of autonomy SP will purchase together the sensors identified for dedicated autonomy functions (one set of sensors will be purchased by each partner). The sensors are selected taking into account the global cost of the autonomy sensor kit in order to reach the lowest cost for the needed performances. DIEHL, SAFRAN, MILREM and NEXTER will integrate the selected sensors in the autonomy framework (integration activities, sensor tuning) that will be tested then within the autonomy simulator. The resulting Autonomy sensor kit will be used by all partners of the autonomy SP for the tests and demonstrations realized within WP4. Subtask 3.2.2 Integration of Autonomy framework: SAFRAN, DIEHL, MILREM, NEXTER (M12- M18) The objective of this subtask is to take all components developed within Design activities (autonomy backbone, autonomy for mobility and mission algorithms) as well as the previously integrated autonomy sensor kit, and to integrate those components to the autonomy framework. The, so integrated, prototype of autonomy framework will then be tested within autonomy simulation in WP4 and integrated on THeMIS platform at system level within WP3. DIEHL, SAFRAN, MILREM and NEXTER will all purchase the components (HW and SW) needed for the Autonomy Framework and will integrate components developed within WP2 (each partner will purchase one set of components to build an autonomy framework). DIEHL, SAFRAN, MILREM and NEXTER will work together to integrate the backbone, autonomy sensor kit and autonomy algorithms within the autonomy framework (each partner will be in charge of integrating its own development within the autonomy backbone). The resulting Autonomy framework will be used by all partners of the autonomy SP for testing and demonstrations within WP4. 4 Autonomy Frameworks will be available for the project: 2 in France, 1 in Germany and 1 in Estonia. Task 3.3 Prototyping Cybersecurity: GTCT, SAFRAN, MILREM, Bittium, GMV, INSTA, DotOcean (M8-M20) The objective of this task is to prototype the Cyber Defence System’s Response Controller. This part of the system will be mounted within the THeMIS and provide recommendation of actions for the iMUGS to take in response to a compromise or cyber-attack. Subtask 3.3.1 Cyber Defence System Response Controller (CDS-RC) Prototyping: GTCT, SAFRAN, GMV, Bittium, MILREM (M8-M20) The objective of this subtask is to build the prototype of the CDS-Response Controller (CDS-RC). The software of this component will be developed using a high assurance Operating System (OS). GTCT will build the prototype with support from a subcontractor which will provide the high assurance OS; GTCT will develop the software that will run with the OS on the hardware platform. GTCT will coordinate with partners working on the autonomy, C2, communications, and swarming capabilities in order to ensure proper integration of the CDS-RC prototype for the monitoring and logging of communication between the networked components via physical taps. The hardware platform to run the software will be chosen to withstand the extreme conditions necessary to survive in an operational military environment. The chosen subcontractor used for development of the high assurance OS will assist with the selection of an appropriate hardware platform, ensuring functional correctness in the pairing of this hardware platform with the high assurance OS. Finally, GTCT will 19 Grant Agreement number: EDIDP-MUGS-2019-002-iMUGS ANNEX 1 collaborate closely with partners from the platform and autonomy sub-projects for physical integration of the CDS-RC hardware and network taps into the iMUGS platform and will build additional external hardware components to complete the prototype. Task 3.4 Prototyping Communication equipment and network: Bittium (M1-M22) Prototyping comprises physically constructing the demonstration system as well as integration of the sub- systems to form a functional entity that meets the defined requirements. The work comprises manufacturing the demonstration system components if required, system integration and system testing tasks. Although the HW-solution is based on existing products, the “prototype” equipment must be manufactured or purchased. Existing HW shall be deployed, if available. The task comprises the following subtasks: Subtask 3.4.1 Manufacturing & Assembly: Bittium (M1-M21) Together with subcontractor DA-Design, Bittium shall provide the required system components ready for assembly & integration. The subtask comprises procurement and/or manufacturing of the required equipment and materials etc. and assembly of the hardware components as well as installing the required soft- and firmware. Subtask 3.4.2 System integration: Bittium (M1-M22) This subtask, done together by subcontractor DA-Design and Bittium, will integrate the system components provided by T3.4.1 together. The task comprises both mechanical assembly work as well as testing as a joint effort with other project members. The work shall be carried out step-by-step adding new components to the entity until the system is ready for validation tests. Collaboration with other project participants and subprojects is essential in this task. Subtask 3.4.3 System validation: Bittium (M4-M22) Together with subcontractor DA-Design, Bittium validate the functionality of system components of the demo system through Initial testing. The tests shall be planned beforehand. As a result, an internal acceptance report shall be provided in addition to the demonstration ready system. Task 3.5 Prototyping Swarming: Insta (M21-M24) Subtask 3.5.1 Simulation environment for demonstrations of local swarming: Insta (M21-M24) A demonstration in a local swarming simulation will be finalized to allow demonstration of the developed algorithms. The simulation application will be able to simulate vehicles and military personnel. Insta will structure the data in a simulation application to enable demonstration of the developed algorithms. Task 3.6 Prototyping Command and Control and Interoperability: GMV, (Un)Manned, KMW, MILREM (M8-M24) The objectives of this task are to prototype the C2 components including the following activities:  Finalize software development.  Software/Hardware integration.  C2 Subsystem Integration. Subtask 3.6.1 UGV Control Station Prototyping: (Un)Manned, GMV (M8-M23) (Un)Manned will lead the prototyping of Control Station real time safety critical component and its adaptation to the mobile control environment. Subtask 3.6.2 Tactical C2ISR Prototyping: GMV, (Un)Manned (M8-M23) GMV will lead the prototyping of Tactical C2ISR components and manage and coordinate the C2 integration activities and ensure overall coordination. Subtask 3.6.3 C2 subsystem integration: GMV, (Un)Manned, KMW (M14-M24) This subtask is divided into 4 main activities: COTS hardware setup, installation and configuration of SW components in the HW, assembly of C2 HW deployable kit for Demo #3 and the integration of C2 HW Deployable Kit in Boxer Vehicle for Demos #4 and #5. All the activities related to the installation of the C2 HW Kit in the Vehicle and the use of additional vehicle HW devices or equipment are part of this subtask. Integration will be performed in 3 increments: Increment 1 for the scope defined in Demo #3 (Control Station and Tactical C2ISR: Version 1 + C2 HW in deployable kit). Increment 2 for the scope defined in Demo #4 (Control Station and Tactical C2ISR: Version 2 + C2 HW in Mobile Command Post (Boxer vehicle)). Increment 3 for the scope defined in Demo #5 (Control Station and Tactical C2ISR. Version 3 + C2 HW in Mobile Command Post (Boxer vehicle). Also, feedback from the operators/UV manufacturers point of view will be collected even at the prototype definition stage at each increment and lessons learned will be used in incremental updates of both tactical 20 Grant Agreement number: EDIDP-MUGS-2019-002-iMUGS ANNEX 1 C2ISR station and UGV control station. GMV will manage and coordinate the C2 integration activities. KMW will lead integration in Boxer vehicle for increment 3. Task 3.7 Prototyping MUM-T: KMW, MILREM (M1-M23) Objective of this task is the connection of the control elements of an unmanned air or ground system to a Boxer, and the belonging integration. Subtask 3.7.1 Integration of UGV control elements in the Boxer: KMW, MILREM (M1-M6) Within this subtask the UGV control elements will be integrated in the Boxer. KMW will lead this subtask and be responsible for the integrations in the Boxer. MILREM will provide the UGV with belonging control elements for the deployment with the Boxer and help with technical support. Subtask 3.7.2 Integration of an UAV box on, and an UAV control station in the Boxer: KMW, MILREM (M17-M23) Within this subtask the UAV transport/starting/landing box and the antenna on the top of the Boxer and the UAV control station with the belonging connecting cables in the Boxer will be integrated. MILREM, together with the responsible for the UAV, will provide the UAV with belonging transport/starting/landing box, control station, antenna and connecting cables for the deployment with the Boxer and help with technical support. Deliverables D3.1 iMUGS Demonstration 1 Ready System D3.7 iMUGS Demonstration 4 Ready System Prototype Prototype D3.2 iMUGS Integration Report 1 D3.8 iMUGS Integration Report 4 D3.3 iMUGS Demonstration 2 Ready System D3.9 iMUGS Demonstration 5 Ready System Prototype Prototype D3.4 iMUGS Integration Report 2 D3.10 iMUGS Integration Report 5 D3.5 iMUGS Demonstration 3 Ready System D3.11 iMUGS Demonstration 6 Ready System Prototype Prototype D3.6 iMUGS Integration Report 3 D3.12 iMUGS Integration Report 6 21 Grant Agreement number: EDIDP-MUGS-2019-002-iMUGS ANNEX 1 WP number Activity covered Start month M1 4 Testing End month M28 Participant number 1.1 1.2 1.3 1.4 1.5 1.6 1.7 Short Name MILREM SAFRAN GTCT Bittium Insta GMV KMW PM per participant 120 28 31 33 14 23 13 Participant Number 1.8 1.9 1.1 1.11 1.12 1.13 1.14 Short name DIEHL NEXTER LMT UnManned ERM-KMS dotOcean EMA PM per participant 17 27 0 33 15 29 0 Objectives This overall objective is divided according to the main tasks of this WP:  to test Autonomy Framework, based on Autonomy Framework prototype from WP3, through a dedicated autonomy simulation environment (developed in WP2, before the delivery of Autonomy Framework to the vehicle) and perform 3 demonstrations of autonomy functions;  to test the Cyber Defence System (CDS) in an operational setting, demonstrate security measures implemented to secure the supply chain, and to test Electronic Warfare (EW) payloads aboard the iMUGS platform in an operational setting as well as the platform’s resistance to EW type attacks;  to test the C2 components. C2 component testing, will ensure that each component meets the component SW requirements and provide traceability to the component SW requirements from Design WP. The C2 Subsystem Testing, with all C2 components jointly operating will provide traceability to subsystem technical requirements from Studies WP;  to demonstrate the UGV and UAV deployment with the Boxer and the integration of UGV/UAV control elements (HW/SW) in an existing vehicle/shelter for demonstration and as a test object for military operational scenarios;  to check and identify algorithm performance and identify additional data needs overseen in the swarm algorithm simulations;  to coordinate and support demonstration events: agreements on the venues, acquiring permissions and licenses from relevant authorities and ensuring safety requirements are met.  to ensure the certifiability of the relevant components and systems in iMUGS, including compiling certifiability assessments and roadmaps and performing relevant test campaigns;  to carry out the specified field tests and demonstrations for the communication modules. Description of the work Task 4.1 System Testing: MILREM, all project partners (M4-M28) The objective of this task is to prepare, conduct the system level testing campaign and provide input for verification if system functionality with regards to the system and mission requirements. MILREM will be responsible for the system level test campaigns, relevant reviews with the support from relevant subsystem and payload providers. Subtask 4.1.1 System level test reviews: MILREM, All project partners (M5-M28) The objective of this subtask is to prepare and conduct the system level testing reviews (acceptance of the system functionality) and confirm the system’s performance to the requirements. MILREM will be responsible for the system level test campaign and relevant reviews with the support form relevant subsystem and payload providers. Subtask 4.1.2 Demonstration events: MILREM, All project and partners (M4-M28) The objective of the ST is to prepare and organize operator-centric system functionality demonstrations as per project master schedule. The presence of participating Member States’ representatives and observers is planned. The selection of the venue and specific demonstration scenarios, the coordination and logistics and scenario verification will be catered for in this task. MILREM will be responsible for coordinating the demonstration events with the support from subsystem and payload providers and cater for communication with and pMS representatives and observers. Task 4.2 Testing Autonomous Functions: SAFRAN, NEXTER, DIEHL, MILREM (M12-M24) 22 Grant Agreement number: EDIDP-MUGS-2019-002-iMUGS ANNEX 1 This task focuses on Autonomy Framework testing and demonstrations. The task ensures the testing of the Autonomy Framework integrated in WP3 through autonomy simulator and validates its performances for the targeted autonomy missions. The integration will be carried out in stages: integration of baseline solution (backbone and sensors), intermediate level (as way point navigation, patrolling and surveillance missions). Each partner of the Autonomy SP is in charge of testing the Autonomy Framework for some dedicated autonomy missions, to perform a detailed analysis of the test campaigns regarding the performance and provide dedicated report. SAFRAN will be in charge of way point navigation and surveillance functions. NEXTER will be in charge of an alternative waypoint navigation, and patrolling functions. DIEHL will work on the follow me functions. MILREM will be the main contributor to demonstration regarding teleoperation LOS and BLOS. Task 4.3 Testing Cybersecurity: GTCT, SAFRAN, NEXTER, DIEHL, Bittium, MILREM (M18- M24) The objective of this task is to perform an operational demonstration of the cyber defence system in order to verify its functional correctness in identifying and responding to threats, as well as testing its robustness in the rigors of a military environment. Testing of the cyber risk assessment mitigating measures will also be conducted. Subtask 4.3.1 Test of Resilience to Communications Jamming: GTCT, Bittium (M18-M24) This test will validate the resiliency of the iMUGS communications system while operating in a hostile and contested Electromagnetic (EM) environment. The communications system will be subjected to jamming of specified frequency bands to ensure continued and normal operation. Subtask 4.3.2 Test of Resilience to GNSS Attacks: GTCT, SAFRAN (M18-M24) With the support of SAFRAN, GTCT will perform this test. It continues the validation of resiliency for iMUGS to operate in an EM contested environment. The test will focus on providing a spoofed or denied GNSS signal to iMUGS to validate capability of detecting and continuing operation in this environment. Subtask 4.3.3 Test of Cyber-Attack Detection: GTCT, LMT, SAFRAN, NEXTER, DIEHL Bittium, MILREM (M18-M24) With the support of LMT, SAFRAN, NEXTER, DIEHL, Bittium and MILREM, GTCT will perform this test. It will focus on validating the complete CDS, using a red team provided from LMT. A real vulnerability will be inserted into the system and the red team will exploit this to demonstrate a potential system compromise, however the CDS will not be active or installed. Following this, the same test with the same exploit will be conducted on an iMUGS platform with the CDS installed and activated. The second test will demonstrate the capability of the system to detect the compromise, alert the Response Controller, and for the Response Controller to recommend to autonomy the appropriate action to take. GTCT will develop, plan, and test with assistance from LMT’s red team. Subtask 4.3.4 Supply Chain Security Demonstration: GTCT, MILREM (M18-M24) This test will demonstrate a security risk discovered through the cyber risk assessment. The test will demonstrate how this vulnerability in the supply chain could introduce malicious activity into the platform, and how measures implemented from the risk assessment will stop this action. GTCT will develop, plan, and execute the test with support from their subcontractor RHEA. Subtask 4.3.5 Test of high assurance Cyber Defence System Response Controller (CDS-RC): GTCT, MILREM, SAFRAN, NEXTER, DIEHL (M18-M24) WIth the support of SAFRAN, NEXTER, DIEHL and MILREM, GTCT will perform this test. It validates the functionality of the CDS-RC in an operational setting by providing a test signal to the Response Controller (RC), indicating a potential compromise. The test will also validate the hardening of the RC in withstanding the rigors required to operate aboard the iMUGS platform in an operational setting. GTCT will develop, plan, and execute the test in the operational environment. Task 4.4 Testing Communication equipment and network: Bittium (M5-M26) Testing is a joint activity with selected consortium members comprising system level integration of ready modules (system components) and testing activities required to ensure the proper functionality of the developed system. In addition, the task comprises preliminary field testing and demonstrations. Finally, the results of the activity shall be analysed and documented. 23 Grant Agreement number: EDIDP-MUGS-2019-002-iMUGS ANNEX 1 Subtask 4.4.1 Field tests: Bittium (M5-M23) The 1st step towards demonstrations is to test the validated system in limited/specific environments and use cases. The work shall be carried out by arranging field tests with specific goals. With the support of subcontractor DA-design, Bittium will perform the tests. It shall be planned beforehand and will be continued until all required system functionality has been tested. Subtask 4.4.2 Demonstrations: Bittium (M6-M26) With the support of subcontractor DA-design, Bittium will perform the demonstrations. It shall be arranged as a joint effort with selected project members. The content and other practical details for the demonstrations shall be planned together with the end-customer. It is assumed, there will be multiple demonstrations with possibly different project members with different focus; functionality, use cases, equipment and implementation. Subtask 4.4.3 Analysis & Reporting: Bittium (M7-M26) With the support of subcontractor DA-design, Bittium will perform the task. It analyses the results of the field tests and demonstrations and provides the documentation. Task 4.5 Testing Swarming: dotOcean, ERM-KMS, Insta (M1-M24) Verification and demonstrations of the implemented designs and joint integrations. Understanding the boundary conditions of the performance of the designs and identifying improvements to be taken to the next design spin. Subtask 4.5.1 Hardware tests: dotOcean, MILREM (M1-M5) Test the integration of dotOcean AYB with multiple MILREM AGV’s and 10 small vehicle platforms. The objective is to have several vehicles available for future algorithm testing and demonstration. DotOcean will integrate and test in close cooperation with MILREM. Subtask 4.5.2 Field tests of dual objective swarms: dotOcean, ERM-KMS, MILREM (M12-M14) Field testing algorithms to optimize a multi-agent system against 2 objectives in a fully structured world (combined patrol and resupply use cases). The aim is to match theory (swarming simulations) on the practical world and to analyse for possible gaps in the available structured data given to the optimization algorithms. DotOcean will be supported by ERM-KMS during the field tests in close cooperation with MILREM. Subtask 4.5.3 Field tests on constraint control and multi objective swarms: dotOcean, ERM-KMS (M19-M23) Testing use cases including constraints on the vehicle dynamics (accelerations, rotations) or vehicle trajectory, such as MEDEVAC, will be tested. A multi-agent system optimized against multiple objectives simultaneously is aimed to be demonstrated. ERM-KMS will provide their equipment and support to dotOcean during the field tests. Subtask 4.5.4 Demonstrations: dotOcean, ERM-KMS, Insta (M21-M24) Multi objective swarms in a fully structured world will be demonstrated. The local swarming will also be demonstrated in simulated environment. DotOcean, ERM-KMS and Insta will participate in the demonstrations. Subtask 4.5.5 Reporting: Insta, dotOcean, ERM-KMS (M21-M26) Performance and requirements of local and global swarming will be analysed and reported based on the demonstrations. ERM-KMS will coordinate the reporting activities of SP4. Task 4.6 Testing Command and Control and Interoperability: GMV, (Un)Manned, KMW (M17-M26) This task in general focuses on verification of the developed command and control station, interworking of developed components at module level and interworking with the UGV system, in both controlled environments and field testing with a manned vehicle-based control platform. Subtask 4.6.1 UGV Control Station Testing: (Un)Manned, GMV (M17-M23) It will cover individual software component testing at UGV control station level. Testing activities include development of the test rigs, specific test software and test procedures, report formats and associated meetings/demonstration activities. UNMANNED will lead the test planning, execution and reporting of C2 test procedures at the UGV Ground station level. Identification and integration of feedback and change requests from users/other stakeholders will be part of the subtask. Subtask 4.6.2 Tactical C2ISR Testing: GMV, (Un)Manned (M17-M23) 24 Grant Agreement number: EDIDP-MUGS-2019-002-iMUGS ANNEX 1 It will cover individual software component testing at tactical C2ISR level. GMV will lead the test planning, execution and reporting of C2 test procedures at the Tactical C2ISR level. Identification and integration of feedback and change requests from users/ stakeholders will be part of the subtask. Subtask 4.6.3 C2 subsystem testing: (Un)Manned, GMV, KMW (M17-M26) This subtask covers overall integrated testing of the Command and Control subsystem and its integration into the demonstration platform as an integrated C2 function. Subsystem Testing will be performed in 3 increments: Increment 1 for the scope defined in Demo #3; Increment 2 for the scope defined in Demo #4; Increment 3 for the scope defined in Demo #5. (Un)Manned will lead the test execution and test reporting of C2 test procedures. KMW will provide support for the Boxer vehicle command post during demonstrations and tests and evaluate the results of the C2 tests for the MUM- T evaluation study to advance on the military operational scenarios with test feedback. Task 4.7 Testing MUM-T: KMW, MILREM (M1-M24) The military operational scenarios of the initial MUM-T study will be tested and demonstrated for evaluation within this task. Subtask 4.7.1 Demonstration of the UGV deployment with the Boxer: KMW, MILREM (M1-M6) This subtask will test and show with the help of a demonstration, what a possible way of deployment may look like with the following activities: preparing the UGV to get towed by a Boxer. Towing the UGV, releasing the UGV from the tow rope, controlling the UGV from the Boxer in LOS and BLOS mode. The steering of the UGV will be one by the control elements installed in the Boxer. This test will be made as part of the upcoming demonstrations, where representatives of the EU and the participating member states can attend. The results will be considered in the MUM-T evaluation study. MILREM and KMW will be responsible for the organisation. KMW will be responsible for the Boxer. MILREM will be responsible for the UGV. Subtask 4.7.2 Demonstration of the UAV deployment with the Boxer: KMW, MILREM (M10-M24) This subtask will consist in several activities. The first one will consist in starting the UAV from the top of the Boxer. The partners will also control the flight of the UAV from the control station inside the Boxer, show the information exchange between the UAV and the control station inside the Boxer, and land the UAV on the top of the Boxer. These tests will be made as part of the upcoming demonstrations, where representatives of the EU and the participating member states will attend. MILREM and KMW will be responsible for the organisation, KMW will be responsible for the Boxer, and MILREM together with a subcontractor will be responsible for the UAV. Deliverables D4.1 iMUGS Test Report 1 D4.7 iMUGS Test Report 4 D4.2 iMUGS Demonstration 1 D4.8 iMUGS Demonstration 4 D4.3 iMUGS Test Report 2 D4.9 iMUGS Test Report 5 D4.4 iMUGS Demonstration 2 D4.10 iMUGS Demonstration 5 D4.5 iMUGS Test Report 3 D4.11 iMUGS Test Report 6 D4.6 iMUGS Demonstration 3 D4.12 iMUGS Demonstration 6 25 Grant Agreement number: EDIDP-MUGS-2019-002-iMUGS ANNEX 1 Description of Management and Coordination (effort included into activities) Objectives  To ensure an efficient coordination of the consortium throughout the whole project duration;  To enable fluid communication among participants, with European Commission and towards relevant stakeholders;  To monitor the progress of the tasks and deliverables of WPs and SPs;  To foresee any risks of delay and set up mitigation plans and corrective actions;  To prepare the special reports and facilitate the end-user’s involvement through the EAB, to guarantee user-driven results;  To communicate and disseminate the project results;  To ensure the management of the data collected within technical WPs;  To ensure the ethics management; For an overview, kindly refer to section 6.1.4.2. Description of work Task 0.1 Project coordination and management: MILREM (M1-M30) Subtask 0.1.1 General coordination of the consortium: MILREM (M1-M30) This task consists of general management of the consortium and communication among partners, with the European Commission (EC) and other stakeholders. The Project Coordinator (PC) will be the contact point for the EC and will ensure the communication between the Consortium and the EC as well as among consortium members. The PC will ensure that all procedures implemented within iMUGS are in line with the Grant Agreement and the Consortium Agreement. He will ensure that each partner is well informed of the project progress, understands its role and contractual obligations in the project, and is aware of the requests and information from the EC. Regular phone meetings between the Project Coordinator and EC project officer will be organized to ensure the correct monitoring of the action. The coordinator will submit a monthly project status report to the project officer based on a template to be provided by EC. The coordinator will also ensure the correct update of the Workspace in EC Collaboration Platform. Subtask 0.1.2 Monitoring of the progress and daily management: MILREM, all partners (M1-M30) The monitoring of the project progress will be made through regular meetings and conference calls. A - In addition to the Kick-off Meeting and the Final Meeting of the project, the periodical meetings of the Steering Group (SG) will allow a thorough monitoring and operational management of the project. The internal monthly Progress Reports provided by each partner will allow the SG to monitor the project’s progress, foresee any risk of delay, set up any mitigation plan accordingly and finally make information-based decisions. The project coordinator, with the support of the project management team, will be in charge of the organisation of the meetings and conference calls as well as the preparation of the meeting minutes. SP leaders will organise meetings of their SPs. B - Daily management of the project includes the coordination among partners to ensure timely delivery of the project reports and deliverables to the EC. The project coordinator and sub-projects lead the procedure and deadlines, will create and use specific tools such as deliverable and milestone follow-up tables, templates for minutes and deliverables, keep contact list up to date, web conference tools and so on for the daily management of the project. Management procedures (preparation of the reports, validation procedure of deliverables, financial aspects, etc.) will be presented to the participants by the Project Coordinator during the meetings. Subtask 0.1.3 Quality assurance, risk management: MILREM, all partners (M1-M30) A - To ensure a high quality of deliverables produced by iMUGS, a quality assurance loop for all relevant documents will be established. The Project Coordinator will set a quality and risk management policy validated by the SG covering all aspects related to practical management of the project. The main issues addressed can include project SWOT, technical and non-technical risk management incl. critical path of the project and associated contingency plans, communication and quality control activities. For instance, it will clearly state internal processes related to standards of documents, proof- reading, validation workflow for the approval of deliverables, reports and communication activities. 26 Grant Agreement number: EDIDP-MUGS-2019-002-iMUGS ANNEX 1 B - Regarding the risk management, the risks identified (see section 6.1.4.2.) will be logged in a Risk Register created at the beginning of the project and updated during the lifetime of the project. These risks will be structured along each SP and classified in several categories, such as structural, managerial, operational, technical, scientific, financial or legal. The risks will be assessed and prioritised by the SG and monitored by the PC. In each SG meeting, a risk management session will be held, the list of the risks will be updated, each risk will be reviewed and new mitigation measures and partners responsible for implementing mitigation measures will be defined. Subtask 0.1.4 Reporting and financial management: MILREM, all partners (M1-M30) A - Preparation of Periodic and Final reports will be coordinated within this task. The procedure will be explained to the partners by the Management Support Team (MST). All partners will get support and necessary information regarding how to prepare their technical and financial reports. Basically, each SP leader will report the progress within his/her SP to the PC, who will consolidate all the data, complete the management aspects of the report and send it to the coordinator. The coordinator will complete and inspect the report before submission to the EC. B - Financial procedures include the plan for the transfer of the European funding to the consortium, the transfer of payments, guidance on costs declaration, etc. Person-month (PM) and over-all budget consumption by partners will be monitored in order to comply with the planned PM effort. This task will also be carried out by PC who will consolidate and analyse financial data at the end of each reporting period to compare the actual costs vs. budget figures and anticipate any deviations (over or under consumption), with the PC. The PC will check the quality (completeness, correctness, requested format...) of information from all partners and review all individual financial statements to ensure the consistency with the planned and real technical tasks and to verify each partners’ engagement. Subtask 0.1.5 Security management: MILREM, all partners (M1-M30) A Security Management Board (SMB) can be established with the participation of one Security Officer per partner. The SMB, chaired by MILREM, will deal with all the issues related to the security and provide advice and recommendations on the security aspects of the project. The Consortium will try, if possible, to concentrate the use of classified background information in specific parts of the relevant deliverables (e.g. annexes) and mark them accordingly. This task can be combined with task for communication. Task 0.2 Subprojects Coordination: MILREM, SAFRAN, GTCT, Bittium, ERM-KMS, GMV, KMW (M1-M30) The subprojects will be coordinated by leaders: MILREM (SP1), SAFRAN (SP2), GT Cyber Technologies (SP3), Bittium (SP4), RMA (SP5), GMV (SP6), KMW (SP7). They will be in charge of monitoring the progress of each technical tasks which they will be responsible of. Each SP leader will organise periodical meetings with the technical tasks' leaders. Regular phone meetings will also be held. Coherently to the projects’ reporting plan, the SP leaders will be in charge of producing reports to the respective WP coordinators to monitor the progress. The coordinator will gather the inputs in order to prepare the global reports. Task 0.3 Management of the Advisory Board (AB): MILREM, all partners (M1-M30) An AB gathering end-users (military subject matter experts, policy advisors and national and EU stakeholders) can be set-up for the project. AB will be consulted during workshops in order to gather inputs on the military scenarios, operational requirements and on the prioritization and alignment of the development roadmap with national and multinational initiatives. Task 0.4 Communication and dissemination of project results: MILREM, all partners (M1-M30) Subtask 0.4.1 Communication: MILREM, all partners (M1-M30) At M6, MILREM can provide a plan for communication including the adopted strategy, target audience, type of actions, and persons responsible for the implementation and planning of the actions. Based on our preliminary plan and taking into account EU law on protection and access to classified information, following communication activities will be undertaken: a project identity set including a logo; an A4 brochure; elaboration of Releasable Information, classification of Releasable Information and confidentiality (with the verification of PC); set-up of the secured project website, social media account and press releases; organisation of the final engagement event/workshop bringing together relevant stakeholders from industry, R&D, policy makers for the final demonstration of the core 27 Grant Agreement number: EDIDP-MUGS-2019-002-iMUGS ANNEX 1 technologies. The PC with the support of the MST will implement these actions with contributions from partners (transfer of information on achievements & results, specific actions by partners themselves…). This task can be combined with task for security management. Subtask 0.4.2 Dissemination of the project results: MILREM, all partners (M6-M30) This task is devoted to disclosing and disseminating (in a controlled manner) the iMUGS results to relevant stakeholders and it will follow the indications of the Dissemination Plan. The disclosure of the results is addressed to different audiences. Each new result will be disseminated by the partner(s) who have generated the result(s), when it is not protected or exploited. The PC with the support of the MST will ensure the compliance, regarding IPR & Data, with the dissemination rules from the Consortium Agreement and EU law regarding protection and access to classified information. The research organisations in the consortium can publish articles about scientific and technical achievements of the project in peer-reviewed journals, via presentations at NATO Industrial Advisory Group, EDA fora and other relevant international conferences and workshops. Task 0.5 Data and IPR Management: MILREM, all partners (M1-M30) Subtask 0.5.1 Data management: MILREM (M1-M30) The PC with the support of the MST will prepare with the help of SP leaders the Data Management Plan (DMP) specifying the type of data to be collected throughout the project, the legal base, the codification-anonymization procedures, and the data safety and security measures. Subtask 0.5.2 IPR Management: MILREM, all partners (M1-M30) Throughout the project, the PC with the support of the MST will support partners to identify protectable results and provide them with advice for protection of the results. The PC with the support of the MST will ensure the coordination of the consortium and internal communication on IPR issues. The Consortium Agreement will be the reference point for all IPR processes. Task 0.6 Ethics Management: MILREM (M1-M30) At the beginning of the project, an ethics code of conduct can be prepared by the PC with the support of the MST in which ethical challenges and good practices will be identified. During each reporting period, the PC with the support of the MST will perform ethics checks to verify that adequate measures as noted above have been implemented at the mid-term and final milestones, identify ethical gaps and recommend mitigation actions. The ethics checks conclusions can be included in the Periodic Report (for Period 1) and in D0.4 at the end of the project. An ethics risk assessment of the issue of minimizing collateral damage can be conducted and potential risk mitigation measures that might support further development and technology are identified. The Periodic Report for Period 1 and D0.4 can include a check of the measures (such as potential technical options, approaches to the use of military equipment) suggested within the project to fulfil the gaps in regulations. The Ethics Check will be conducted by person(s) having prior expertise in military ethics and law of armed conflicts. Deliverables D0.1 (M1) iMUGS Project Plan D0.2 (M13) iMUGS Progress Report 1 D0.3 (M25) iMUGS Progress Report 2 D0.4 (M30) iMUGS Final Report D0.5 (M2-28) iMUGS Progress Report In addition, SP leaders will deliver monthly internal reports to the PC. The PC will coordinate security management, risk management, system’s engineering management documentation and produce relevant internal documents. 28 Grant Agreement number: EDIDP-MUGS-2019-002-iMUGS ANNEX 1 4.3. List of deliverables No iMUGS Deliverable Work Short name Type Reporting conditions Dissem Delivery package of lead ination date number participant [in months] D0.1 Project Plan 1 Milrem R Full Release of deliverable to EC CO M1 D1.1 Development and Test Plan 1 Milrem R Full Release of deliverable to EC CO M3 D4.1 Test Report 1 4 Milrem R Full Release of deliverable to EC CO M5 Detailed Design Definition: System’s Integration 2 Milrem Summary Report of deliverable sent to EC D2.1 R CO M7 (Initial) D3.1 Demonstration 1 Ready System Prototype 3 Milrem R Summary Report of deliverable sent to EC CO M8 D3.2 Integration Report 1 3 Milrem R Full Release of deliverable to EC CO M8 D4.2 Demonstration 1 Report (EE) 4 Milrem R Full Release of deliverable to EC CO M8 D4.3 Test Report 2 4 Milrem R Full Release of deliverable to EC CO M10 D3.3 Demonstration 2 Ready System Prototype 3 Milrem R Summary Report of deliverable sent to EC CO M11 D3.4 Integration Report 2 3 Milrem R Full Release of deliverable to EC CO M11 D4.4 Demonstration 2 Report (LV) 4 Milrem R Full Release of deliverable to EC CO M11 D0.2 Progress Report 1 1 Milrem R Full Release of deliverable to EC CO M13 D4.5 Test Report 3 4 Milrem R Full Release of deliverable to EC CO M13 D3.5 Demonstration 3 Ready System Prototype 3 Milrem R Summary Report of deliverable sent to EC CO M14 D3.6 Integration Report 3 3 Milrem R Full Release of deliverable to EC CO M14 D4.6 Demonstration 3 Report (BE) 4 Milrem R Full Release of deliverable to EC CO M14 Detailed Design Definition: System’s Integration 2 Milrem Summary Report of deliverable sent to EC D2.2 R CO M15 (Second) D4.7 Test Report 4 4 Milrem R Full Release of deliverable to EC CO M17 D3.7 Demonstration 4 Ready System Prototype 3 Milrem R Summary Report of deliverable sent to EC CO M18 D3.8 Integration Report 4 3 Milrem R Full Release of deliverable to EC CO M18 29 Grant Agreement number: EDIDP-MUGS-2019-002-iMUGS ANNEX 1 No iMUGS Deliverable Work Short name Type Reporting conditions Dissem Delivery package of lead ination date number participant [in months] D4.8 Demonstration 4 Report (FI) 4 Milrem R Full Release of deliverable to EC CO M18 D4.9 Test Report 5 4 Milrem R Full Release of deliverable to EC CO M21 D3.9 Demonstration 5 Ready System Prototype 3 Milrem R Summary Report of deliverable sent to EC CO M22 D3.10 Integration Report 5 3 Milrem R Full Release of deliverable to EC CO M22 D4.10 Demonstration 5 Report (FR) 4 Milrem R Full Release of deliverable to EC CO M22 D4.11 Test Report 6 4 Milrem R Full Release of deliverable to EC CO M23 D2.3 Detailed Design Definition: System’s Integration (Final) 2 Milrem R Summary Report of deliverable sent to EC CO M24 D3.11 Demonstration 6 Ready System Prototype 3 Milrem R Summary Report of deliverable sent to EC CO M24 D3.12 Integration Report 6 3 Milrem R Full Release of deliverable to EC CO M24 D4.12 Demonstration 6 Report (DE) 4 Milrem R Full Release of deliverable to EC CO M24 D0.3 Progress Report 2 1 Milrem R Full Release of deliverable to EC CO M25 D1.3 Manned-Unmanned Teaming Study Report 1 Milrem R Full Release of deliverable to EC CO M30 D1.2 Study Report 1 Milrem R Full Release of deliverable to EC CO M30 D0.4 Final Report 1 Milrem R Full Release of deliverable to EC CO M30 1 Milrem Full Release of deliverable to EC M2, M4, M6, M8, M10, Continuous reporting (updated project work plan, risk D0.5 R CO M16, M18, and issue report) M20, M22, M28 30 Grant Agreement number: EDIDP-MUGS-2019-002-iMUGS ANNEX 1 4.4. List of milestones No iMUGS Milestone WP Due date Means of verification MS1 System’s Requirements Review 1 M3 SRR report approved MS2 Critical Design Review 2 M6 CDR report approved MS3 Demonstration 1 3-4 M8 Functionality approved and verified; Demonstration 1 Report MS4 Demonstration 2 3-4 M11 Functionality approved and verified; Demonstration 2 Report MS5 Demonstration 3 3-4 M14 Functionality approved and verified; Demonstration 3 Report MS6 Demonstration 4 3-4 M18 Functionality approved and verified; Demonstration 4 Report MS7 Demonstration 5 3-4 M22 Functionality approved and verified; Demonstration 5 Report MS8 Demonstration 6 3-4 M24 Functionality approved and verified; Demonstration 6 Report MS9 Engagement Event 4 M29 Final review; Event Minutes approved 31 Grant Agreement number: EDIDP-MUGS-2019-002-iMUGS ANNEX 1 4.5. Critical risks for implementation Description of risk Proposed risk-mitigation measures Technologies performances Some developed components are not The integration process will be progressive and step by sufficiently performing. step. As soon as an intermediary version of a WP: 1-5. Level of likelihood: Low component is ready, it will be tested in the distributed bench model and/or physical platform. Test driven development is foreseen for hardware and software which inherently lowers the risk of hardware performance and software bugs etc. The issues will therefore be solved gradually and not discovered at the end. In addition, early and clear definition of technologies, interfaces and conventions will help to reduce this risk. Also, emulation of not yet available components by mock-up or simulation can be used. The experimental demonstration could be repeated once the advanced components become available. Unforeseen technical problems that may The situation will be assessed by the Steering not be resolved with the assigned committee of the project, in collaboration with the resources. involved WP/SP leaders to decide about adequate re- WP: 2-5. Level of likelihood: Low planning actions that ensure the overall project result. System inability Non-availability or underestimation of key Regular reviews to ensure availability of the key human resources at key points of the resources. PC and WP leaders will monitor project. continuously the progress, the resource consumption WP: 1-5. Level of likelihood: Low and reallocate work between partners and WPs according to the joint responsibility clause. Difficulties and delays in integration of Careful definition of technical requirements and iMUGS components. especially of module interfaces. Long lead items, e.g. WP: 1-5. Level of likelihood: Low base vehicle component, are specified in the procurement plan (included in the Management Plan). Test driven development approach for hardware and software. Consider user’s interaction and procedures. Active involvement of the project coordinator and early reporting when a risk is recognizable. Due to system complexity, the integration Usage of Model Based systems engineering: Model and reduces overall system performance. continuously measure component and system WP: 2-5. Level of likelihood: Low/Medium performance throughout design, development and integration activities. Concurrent view of system budgets (bandwidth, mass and derived performance indicators) will always be available and can be used for simulating overall system performance. The use of appropriate tools (Model Based Systems Engineering (MBSE) software) will assess potential shortcoming before the actual integration/demonstration of the system. Inability to perform a demonstration. Early planning to ensure availability of facilities. The WP: 5. Level of likelihood: Low consortium will take necessary actions in a timely manner (detailed demonstration preparation plans, pre- demo acceptance reviews, dry-runs, contingency planning, time buffers), well before the actual dates to ensure proper delivery. In the case of a force majeure, 32 Grant Agreement number: EDIDP-MUGS-2019-002-iMUGS ANNEX 1 the use of appropriate tools, e.g. existing simulation environment, can be used for the provision of a synthetic scenario build. Operational value of the demonstrated Clear criteria defined for demonstrability. Close system not evident to audience during/after coordination of the demonstration contents and demonstrations. scenario with Steering Board and consultations with WP: 5. Level of likelihood: Low/Medium PMS. Partner underperforms or leaves the In case of a partner’s departure, pending workload will consortium. be re-distributed among partners based on their WP: 1-5. Level of likelihood: Low/Medium competences. In addition, the Consortium Agreement will foresee such situations and will describe measures to be taken to prevent non-compliance to project activities. Low quality of project results. The internal acceptance reviewing process for all WP: 1-5. Level of likelihood: Low project deliverables and reports, plus the contribution of the Advisory Board, will ensure high quality project results. A Quality Assurance plan will ensure a sound review procedure. Delays in the tasks’ completion due to lack The project work plan has been carefully drafted, and of resources, inability of partners or the partners have extensive experience in participating disharmony in the collaboration. in similar projects. The coordinator and the project WP: 1-5. Level of likelihood: Low/Medium management team will adopt a proactive approach by identifying all critical paths in the project and by performing the necessary rescheduling and crashing. Detailed schedule will be presented at project Kick- Off. Missing communication and preparations Incorporation of the representative of the participating between the participating MoD’s can member states as early as possible. Establishing a endanger the generation of a common central point of contact for the participating MoDs and understanding within the proposed planning with enough spare time. schedule. WP: 1-5. Level of likelihood: Low/Medium System Integration delays or increased Interfaces are specified and developed according to costs resulting from legacy or incoherent widely accepted standards (STANAG, etc). interfaces from subsystems or components. Performance is predicted by system level data WP: 1-5. Level of likelihood: Low/Medium budgeting and modelling and verified at the bench model and after physical assembly. Users acceptance User requirements do not capture user We assume a latent cooperation (engagement of end- intentions. users to the capture process: consultations, requirement WP: 1-2. Level of likelihood: Low verification etc). The developed solution is too expensive to The modular iMUGS system will provide different be affordable by end-users. levels of complexity, so a range of solutions (including WP: 1-5. Level of likelihood: Low different individual components) with varying costs will be available as an end product. Proposed solutions are not aligned with the Societal concerns are taken into account at an early European core values. stage by SP 2. Study prepared. WP: 2. Level of likelihood: Low Legal, Regulatory Limited access to NATO standards could Use national representatives to monitor the sensitive jeopardize interoperability between our standards. Dedicate a person from each partner with solution and the external environment. enough security clearance to act as a Proof of Concept WP: 2-5. Level of likelihood: Low (PoC)with national MoD for compliancy monitoring 33 Grant Agreement number: EDIDP-MUGS-2019-002-iMUGS ANNEX 1 w.r.t sensitive standards. iMUGS solution is not compliant with Early in-depth analyses of legal issues in SP2. EU-level national and EU legislation. developments on AI ethics are monitored and assessed. WP: 2. Level of likelihood: Low Conflicts between upcoming regulations Watch on the technologies and regulations which and our SoS configuration (from the safety impact the architecture definitions, including ground perspective). vehicles’ military and civil regulations. Liaise with WP: 1-5. Level of likelihood: Low/Medium regulatory authorities and apply for permission in due time both for demonstrations and in case of new regulative restrictions. Wide gap between the components’ Expose regularly the risk (list of gaps, and procedure requirements provided by the nations and for agreement based on driving parameters for the the one provided by the consortium. technology) to the MoDs so they can react WP: 1-2. Level of likelihood: Low/Medium appropriately to minimize the risk occurrence. National export authorities do not approve Apply for export licences in due time, prepare export of equipment for a demonstration to authorities with background information and involve in another EU country. project progress at project Kick-Off Meeting (KOM). WP: 1, 5. Level of likelihood: Low Co-financing through procurements Preparing procurement documentation and timely unknown until a too long period. delays on procurement assessment. WP: 1. Level of likelihood: Low/Medium Missing export licenses can delay the Requests for export licenses will be completed in transport and the belonging follow-on advance, implementing time buffer considering the tasks. follow-on tasks. Following the KOM, a review of the WP: 1, 5. Level of likelihood: Low/Medium needs will be realised through the consortium. Dates, deadlines and timelines will be centralized for follow up. 4.6. Summary of staff effort WP1 WP2 WP3 WP4 Beneficiary Studies Design Protot. Testing Total 1.1 Milrem AS 70 241 81 120 512 1.2 SAFRAN Electronics & Defense SAS 11 193 0 28 231 1.3 GT Cyber Technologies OÜ 43 142 31 31 247 1.4 Bittium Wireless Oy 16 266 13 33 329 1.5 Insta DefSec Oy 106 0 2 14 122 1.6 GMV Aerospace and Defence SAU 13 85 46 23 167 1.7 Krauss-Maffei Wegmann GmbH & Co KG 223 4 21 13 261 1.8 Diehl Defence GmbH & Co KG 8 46 2 17 74 1.9 Nexter Systems SA 26 168 7 27 227 1.10 Latvijas Mobilais Telefons SIA 27 0 14 0 41 1.11 (Un)Manned NV 15 132 51 33 232 1.12 Ecole Royale Militaire – Koninkljike Militaire School 12 41 0 15 67 1.13 dotOcean NV 17 50 0 29 96 Planned person months TOTAL 589 1368 268 383 2608 34 Grant Agreement number: EDIDP-MUGS-2019-002-iMUGS ANNEX 1 Part B 5. Project presentation The objective of iMUGS (integrated Modular Unmanned Ground System) is to develop and deploy (through demonstrations) a European technology based ground and aerial vehicle system, and the related infrastructure with the aim of advancing the capabilities of the participating European industries & armed forces. The iMUGS system is modular, cyber secure and capable for manned-unmanned teaming. iMUGS provides core autonomous functions and swarming capabilities. Figure 1: High-level System Diagram of the iMUGS Architecture iMUGS aims to develop a modular, standardized and open system architecture for unmanned ground and aerial platforms; the subsystems described above will be integrated in a modular way in this architecture. This architecture will enable the development of systems composed of different manned and unmanned ground and aerial platforms with high autonomy capabilities, swarming ability and sensors, payloads and intelligent functionalities and assets, all connected through a secured and resilient architecture to a communication network and to a Command and Control (C2), interoperable with external Computerized Command, Control, Communications Intelligence (C4I) systems and joint Intelligence, Surveillance, Reconnaissance (ISR) databases. For the purpose of demonstrating the project at the end, the prototype of the system and the demonstrations of it will be based on one specific Unmanned Ground Vehicle (UGV) (Themis from MILREM) and a specific list of payloads that are described in the implementation part. The project consists in the studies, design, prototyping and testing of the fundamental features of unmanned ground systems: autonomous functions, cyber security, communications, networking, swarming, command and control, interoperability, manned-unmanned teaming and of their integration based on a modular, standardized and open system architecture. These works will pave the way for building a robust, innovative and credible Unmanned Ground Systems (UGS) competency in EU and represent a significant leap over what exists today. The corresponding outcomes of this 30 months project shall provide a very strong basis for the realization of ambitious future UGS (iMUGS will not develop a new platform but will focus on creating added value for an existing one). This unprecedented cross-border cooperation in EU, supported by several Member States and backed by end-users in an advisory capacity, shall advance considerably the ability of the European Industry in this sector including SMEs to deliver systems which meet demanding armed forces priority requirements, and its competitiveness for creating new market opportunities. 35 Grant Agreement number: EDIDP-MUGS-2019-002-iMUGS ANNEX 1 THE GEOPOLITICAL AND SOCIETAL CONTEXTS CALLING FOR IMUGS The rapidly occurring changes in the geopolitical and societal contexts are characterised by:  Reduced acceptance of loss of human life leads to expectations that defence is arranged with the least possible risk to personnel;  Centre of gravity in future defence will be population-related with operations concentrated in and around cities, natural resources, lines of communication, and energy/power;  Operational environment, globalization and international crises require expedited readiness to conduct operations outside of the national boundaries. These changes indicate that integrated, semi-autonomous robotics systems will play a critical role in the future complex operational environments. NEW TECHNOLOGIES ENABLING OPERATIONAL SUPERIORITY ARE AVAILABLE OR DEVELOPABLE To support manned operations, autonomous systems will enable novel capabilities required to counter new threats, based on technology development. Current capabilities of the unmanned systems are limited to the human-in-the-loop, remote-control use of single aerial or ground assets separately by dedicated operators. In order to face the changed role and challenges, several technologies and systems enable an ambitious development:  Accurate, up-to-date common operational picture and adequate information management;  Secured communications to improve the resilience of the systems;  Data fusion to manage the amount of raw data and invert it to actionable intelligence;  Artificial Intelligence (AI) to provide assistance for human controlled decision making;  Electronic warfare and cyber activities to resist to new threats;  Resilient solution to cater denied access to position, navigation and timing;  Rapidly deployable unmanned platforms requiring limited assistance to perform;  Autonomous functions for assets’ mobility and planning;  A modular and secure way to integrate the different scalable capabilities;  Operational modes for manned and un-manned assets cooperation;  Safety features for mobility and payload operation. THE SCOPE OF IMUGS SPANS FROM AUTONOMY TO A PLATFORM-AGNOSTIC MODULAR ARCHITECTURE The project will develop a modular, standardized and open system architecture for unmanned ground and aerial platforms, all connected through a secured and resilient communication network and to a secured command and control capability to safely operate multiple aerial and ground assets by a single operator. This scalable architecture will allow to address multiple types of operational missions with multiple types of payloads, sensors and ground/aerial platforms. Resilient system ensures data integrity, secure communications, cyber and electronic warfare resistance. System has semi-autonomous and autonomous features for operator’s assistance, route and mission planning, requiring limited man- in-the-loop involvement. AI capabilities include unmanned assets working as a group with a single objective. Development includes operational modes for unmanned assets and hybrid operations with manned assets. Added capability for autonomous mobility of the platform and mission planning with human- in-the-loop functionalities include follow-me vehicle/pedestrian, way point navigation, autonomous surveillance and patrolling through intelligent agents supporting the control with task orientation. Autonomous capabilities are furthermore secured with obstacle and human avoidance. The autonomy framework developed will be platform-agnostic, enabling integration to unmanned ground platforms and adaptation to current manned vehicles. Task orientation includes swarming capabilities where heterogenous assets have capability to work as a group with a common objective. System will furthermore be capable of expedited deployment and interoperable with existing command and control and manned operations. 36 Grant Agreement number: EDIDP-MUGS-2019-002-iMUGS ANNEX 1 iMUGS can be remotely controlled in Line Of Sight (LOS) or using Beyond Visual Line Of Sight (BVLOS) communication means on the operating area. Its high processing power and the capability to interact at all layers of the communication spectrum at the tactical edge results in enhancement of friendly forces' capabilities to react faster than the adversary can anticipate, using the advantage from highly capable information systems, cyber domain and artificial intelligence. iMUGS can threaten adversary’s capabilities, cohesion, understanding and offensive behaviour due to cumulative and timed effects because it operates faster in tasks that require human involvement, interaction and decisions. iMUGS (collective) capability can be easily augmented by rapidly configurable specific payloads: ISR capabilities, teaming with Unmanned Aerial Vehicles (UAV), acoustic aggressive fire detection, ballistic protection, medical evacuation (MEDEVAC) equipment, and Electronic Warfare (EW) assets (Signals Intelligence, close-in jamming etc). The project is structured along the features expected as its key outcomes; it will be implemented by a consortium bringing together the best of class in a balanced manner Modular approach allows organizing the development to functional subprojects corresponding to the key elements (sub systems); each subproject includes activities for project management, studies, design, prototyping and testing (see Work breakdown Structure). 1. Systems Integration, led by MILREM, with the support of EMA (EE); 2. Autonomous functions led by SAFRAN (Fr), with the contributions of NEXTER (FR), DIEHL (DE) and MILREM; 3. Cyber security led by GTCT (EE); 4. Communication equipment and network led by Bittium (FI), with the support of LMT (LV); 5. Swarming led by ERM-KMS (Belgium), with the contributions of Insta (FI) and dotOcean (BE).; 6. Command and Control and Interoperability led by (Un)Manned (BE), with GMV (Spain) achieving interoperability; 7. Manned-Unmanned Teaming led by KMW, with the support of NEXTER Participants and their complementarity for the project are further described in the Section 6.1.4.3. Participating project members for the PESCO for Integrated Unmanned Ground System project (UGS) are Germany, France, Spain, Belgium, Finland, Latvia and Estonia. A Letter of Intent of these seven MS is provided as an Appendix of the application (Ref to file “iMUGS Section 3.4 Letter of Intent”). In the event of an action awarded with EDIDP grant, Member States will appoint a project manager. Coordinated by MILREM, the iMUGS Consortium has the capabilities to develop the scalable system for integrating the various unmanned assets and hence provide the solutions to various challenges. Across the Consortium, the added-value is brought both by high-tech SMEs, MidCaps and big companies: indeed, 40% of the development work shares are performed by small and medium size enterprises (SMEs) and 20% by medium capitalized companies (Midcaps), and the coordination between partners and achieving of the results and resources are backed with 40% participation of large capitalized companies representing core knowhow in their fields; SAFRAN, NEXTER, DIEHL, and KMW. Workshares have been balanced with the participating Figure 2: Key partners of the iMUGS project Member States in view. 37 Grant Agreement number: EDIDP-MUGS-2019-002-iMUGS ANNEX 1 THE IMPACTS OF THE PROJECT WILL RISE A NEW DAWN FOR AERO-TERRESTRIAL OPERATIONS iMUGS will contribute significantly to the development of credible operational solutions to armed forces in the medium term, based on leading edge competencies established in the EU, while engaging in a constructive dialog with its end-users. The project will consequently provide a very significant breakthrough potential both in technological and operational terms. It will contribute to placing the European Union at the forefront of the Defence sector and enhance the competitiveness of the European Defence Technological and Industrial Base (EDTIB) due to innovation and cost efficiency. By agreeing on common requirements and harmonized capabilities, the project will facilitate capacity building among partners. iMUGS will also contribute to the industrial autonomy of Europe in a moving geopolitical context. European armed forces will have access to world-class European equipment and systems, securing operational supremacy. A major innovation area will be on mobility autonomy, coupled with cybersecurity and EW resistant secure multi-technology communication solution, preparing for ability of such systems to operate within adverse and unprepared areas, in fully autonomous mode of operation, including in GNSS denied areas. The iMUGS Autonomy Framework is designed in a generic way, based on existing standards and fully adaptable with various type of UGVs for a large range of applications. Also, Autonomy functions can be turned in driver assistance for manned platforms by providing either proximal area awareness or to help the driver in a fine manoeuvre over a short-term horizon. They can also be used to develop an infrastructure protection and inspection system by extending the robotic coordination to infrastructure sensors. Planning and scheduling, but also mobility planning can be extended to include both human and infrastructure sensor activities. iMUGS will allow to rapidly gather, process and disseminate large amounts of information to decision-makers (ISR). Artificial Intelligence evaluates reliability and credibility of the gathered data and provide evidence-based conclusions, situational understanding and recommendations for further collection or exploitation. iMUGS’ modular approach will allow the development and rapid deployment of additional functionalities and payloads over time. The Control Station (CS) allows a single individual to control multiple semi-autonomous systems using the same software suite and controller, therefore, maximizing the use of assets, sensors, payloads, data/information sharing and decision-making. iMUGS will contribute to increasing efficiency across the life cycle thanks to modular design, interchangeability and ease of maintenance. More generally, the project paves the way towards manned-unmanned collaboration in the context of next generation ground capabilities and will open new perspectives of exploitation of UGS and related technologies in operation. IMUGS IS WELL ALIGNED WITH THE EU PRIORITIES A. CAPABILITY DEVELOPMENT PLAN European strategy and co-operation in developing autonomous land systems is mandatory for EU troops to effectively engage, protect, deploy, sustain and command in the future battlefield. The 2018 Capability Development Plan (CDP) by the European Defence Agency (EDA) confirms this by prioritizing developing unmanned ground combat capabilities and systems with evolving levels of autonomy. iMUGS will focus on key functionalities which are critical for ensuring European Strategic Autonomy in order to meet defence capabilities agreed by the Member States in the context of the CDP. The project is consistent with several major priorities defined in the 2018 CDP, namely:  Development of unmanned ground capabilities;  Addressing cyber defence challenges in the air, space, maritime and land domain;  Enhancing Intelligence, Surveillance and Reconnaissance (ISR) capabilities;  Developing systems with evolving levels of autonomy and developing Artificial Intelligence. b. Permanent Structured Cooperation The Integrated Unmanned Ground System (UGS) Project was officially adopted on the updated list of projects for the Permanent Structured Cooperation (PESCO) in November 2018. The project respects the several binding commitments undertaken by participating Member States. The project will help the participating Member States to: 38 Grant Agreement number: EDIDP-MUGS-2019-002-iMUGS ANNEX 1  Increase joint and “collaborative” strategic defence capability projects (commitment 3);  Ensure the availability of the capabilities for achieving the level of ambition in Europe (6);  Procure with identified EU added value (8);  Draw up harmonised requirements agreed by participating Member States (9);  Overcome capability shortcomings identified under the CDP and Coordinated Annual Review on Defence (CARD), increase EU strategic autonomy and strengthen the EDTIB (15);  Take part in at least one project under the PESCO (17);  Confirm that the acquisition strategy will have a positive impact on the EDTIB (20). Results expected for the project are coherent with the European Union capability development plan objectives. Project has been initiated in the PESCO venue by the participating Member States. Estonia, Finland, Latvia, France, Belgium, Germany and Spain have jointly agreed the common requirements for the development and agreed to co-finance and procure the results. Majority of the work is performed by state-of-the-art companies from these countries. Confirmation for signed Letter of Intent by the Ministries of Defence is added to the application as proof of support by the participating Member States (Ref to file “iMUGS Section 3.4 Letter of Intent”). 6. Focus on award criteria 6.1. CONTRIBUTION TO EXCELLENCE 6.1.1. OBJECTIVES AND RELATION TO THE CALL FOR PROPOSALS Relation to the call for proposals iMUGS fully complies with the call EDIDP-MUGS-2019, as shown in the table below. Table 1: relation to the call for proposals Scope [call text] Include a system capable of manned-unmanned and unmanned-unmanned teaming with other robotic unmanned aerial and ground platforms as well as traditional manned vehicles to provide combat support and combat service support to ground forces; [iMUGS’ answer] iMUGS will develop scenarios and a system capable of manned-unmanned and unmanned-unmanned teaming with other robotic unmanned aerial and ground platforms as well as traditional manned vehicles to provide combat support and combat service support to ground forces, as described in iMUGS operational and technical objectives [Ref to OO1]. [call text] Increase situational awareness and force protection of ground units, their combat effectiveness, endurance, mobility and autonomy, and enable faster deployment; [iMUGS’ answer] iMUGS will increase situational awareness of ground units by providing access to observational data (e.g. automated observation) [ref to OO2]. A large set of embedded sensors for distanced observation will provide a better overview of the field of operation, improving overall effectiveness [Ref to OO5, OO6]. In addition, the integrated communication system will allow efficient information exchange with other systems deployed by the troops [Ref to OO4]. iMUGS will improve the endurance of ground units by exposing robots instead of soldiers (through teleoperation and autonomous capabilities) [Ref to OO2]. iMUGS will increase troops’ mobility by enabling fast deployment [Ref to OO1]. [call text] Have the ability to be deployed in support of dismounted troops in all types of geographic and operational environments (including denied environments) with evolving levels of autonomy and robustness for transport and supply delivery, force protection, interdiction, ISTAR (Intelligence, Surveillance, Target Acquisition and Reconnaissance), communication relay, military engineering support, medical evacuation or CBRN protection; [iMUGS’ answer] iMUGS will increase effectiveness of dismounted soldiers through the use of 39 Grant Agreement number: EDIDP-MUGS-2019-002-iMUGS ANNEX 1 unmanned systems and autonomous mission planning tools [Ref to OO2, OO5]. The iMUGS solution will be demonstrated in deployment in a wide range of operational scenarios and concepts [Ref to OO1]. iMUGS solution will support dismounted troops with its flexible architecture that allows a wide range of available and future payloads in its support functions, and it will continue its support role in all types of geographic and operational environments with its robust, resilient architecture and simplify integration of future payload capabilities depending on the evolving battlespace and support needs of the troops [Ref to OO1; OO2; OO3; OO6]. Robust vehicle architecture and communications system will allow continued operations in denied environments [Ref to OO4], manned-unmanned teaming and operations [Ref to TO7]. The autonomy design of iMUGS is evolutive and provides soldier and driver assistance in all types of operation conditions [Ref to OO2]. [call text] Lower workload for UGS operator(s) through maximum use of artificial intelligence and assisted functions in order to assure better awareness of the tactical situation for UGS operator(s); [iMUGS’ answer] The usage of autonomous [Ref to OO2] and swarming [Ref to OO5] functionalities will reduce the workload and significantly reduce reaction time, through automatic planning algorithms, for the operator of UGS [Ref to OO5] Also the possibilities for following the tactical situation will be improved with the C2 of this project [Ref to OO6]. [call text] Include modular design and interoperability of the UGS, in order to ensure transferability of the relevant technology to other platforms (including existing manned vehicles) and simplify payload integration during the follow-up development projects. [iMUGS’ answer] iMUGS will include development of a modular framework for autonomous systems, as well as subsystems that can be deployed independently, enabling transfer of technologies to other platforms than the one used within the project [Ref to OO2; TO1; TO2] [call text] Proposals can also include the integration of an increased number of unmanned systems (swarming) to be remotely operated by human beings. [iMUGS’ answer] iMUGS will develop and integrate swarming capabilities, i.e. heterogeneous agents having capabilities to work as a group with multiple mission objectives. [Ref to OO5] Targeted activities [call text] Cover at least the design of a multipurpose unmanned ground system, not excluding upstream and downstream activities, such as feasibility study or prototyping and testing in an operational environment. [iMUGS’ answer] iMUGS project is concentrating effort on design (56%) but also covering upstream and downstream activities (feasibility study (13%), prototyping (11%) and testing (15%)) [Ref to Section 7.1.4] for a multipurpose unmanned ground system as well as aerial system [Ref to Section 7.1.4.1]. Demonstrations are included in the testing programme (6 based in different European countries and calendar date to address various environments) in a realistic setting [Ref to Section 7.1.4.1]. Main high-level requirements [call text] Designed for operations encompassing the entire spectrum of conflicts from permissive to denied environments, by day, night and in adverse weather conditions; [iMUGS’ answer] iMUGS will integrate a wide range of mission capabilities, both autonomous and remotely operated, in permissive, semi-permissive and denied environments [Ref to OO2]. Autonomous functions developed in iMUGS will allow operation in various conditions: urban and off road, day and night, Global Navigation Satellite System (GNSS) denied, communication unavailable, adverse weather etc. The communications infrastructure will allow resilient connectivity in most operational scenarios. [Ref to OO1; OO2; OO4] [call text] Provide, when necessary, in addition to functioning as part of mechanized troops, advanced mobility and a reduced footprint allowing systems to support dismounted troops in different environments, where traditional manned vehicles are not able to operate; [iMUGS’ answer] Military operational scenarios [Ref to OO1] will describe the possibilities for the usage of iMUGS in different conditions and environments. A subset of these scenarios will be tested during the demonstrations of this project. Scenarios which cannot be considered during this project will be listed in the Manned-unmanned teaming (MUM-T) study [Ref to OO1] for a follow-on 40 Grant Agreement number: EDIDP-MUGS-2019-002-iMUGS ANNEX 1 project. [call text] Support all types of missions of infantry units without compromising their stealth and endurance; [iMUGS’ answer] Through novel tactical Command and Control, Intelligence, Surveillance and Reconnaissance (C2ISR) software, iMUGS will allow approach march, provide support for dismounted troops and include controlled/low emissions’ profile [Ref to OO6]. Moreover, iMUGS will reduce soldier stealth exposure and increase soldier endurance by providing autonomous functions that will perform missions without direct intervention of soldiers in the field [Ref to OO2]. Due to the existing design, the platform has low visible, electromagnetic and acoustic signature (able to operate in silent mode, fully electric) [Ref to TO1]. [call text] According to the UGS weight class, have design elements for protection which address the appropriate threats; [iMUGS’ answer] iMUGS will develop resilience and graceful degradation against cyber, electromagnetic and physical exploitation [Ref to OO3]. The physical reliability of iMUGS is achieved by ruggedization and ballistic protection as a payload [Ref to TO1]. [call text] Be equipped with cyber secure and Electronic Warfare (EW) resilient C2; [iMUGS’ answer] iMUGS has cyber secure & EW resilient C2 both on the platform and on C4I level. iMUGS provides autonomous detection of compromise or a cyber attack with appropriate mitigation recommendations [Ref to TO3]. As part of the C2-entity, the communication solution provides integrated EW functionality such as detection of jamming, end-to-end security, alternative communication channels [Ref to TO4]. [call text] Have a modular, open, scalable and cyber-secure architecture for different manned and unmanned capabilities; [iMUGS’ answer] iMUGS solution has an open and scalable architecture based on industry and military standards and allows capability extension with flexible payload interface and open software architecture. Both UGV and C2 Control System (CS) support a wide range of manned and unmanned capabilities and allow future capability extension with modular software and flexible communications subsystem to serve evolving future needs. [Ref to OO2; OO3; OO6; TO2; TO6] [call text] Provide a modular architecture for future upgrades and implementation of different autonomous functions; [iMUGS’ answer] iMUGS will develop a modular, safe and scalable architecture for autonomy [to OO2] addressing several designs and implementation of autonomous functionalities as described in the previous point. The architecture is designed in a way, which makes it easy to implement updates and upgrades throughout the life cycle of the system [Ref to TO2]. [call text] Be capable of manoeuvring autonomously to pre-planned battle positions and have the ability to carry at least a squad sized unit equipment; [iMUGS’ answer] The autonomous functions will be able to follow a mission plan including pre- planned battle positions to perform various autonomous missions as way point navigation, surveillance, patrolling, follow me [Ref to OO2, OO5]. iMUGS autonomous UGV will enable iMUGS to carry at least a squad sized unit equipment. [call text] Have autonomous functions for unmanned ground systems' LOS (Line Of Sight) and BLOS (Beyond Line Of Sight) missions; [iMUGS’ answer] iMUGS will include an autonomous and safe ground system with “human in the loop” from teleoperation to driving assistance in unknown environment and from driving assistance to mixed interactions and to full autonomy in pre-mapped environment [Ref to OO2]. Its communication solution provides the required connectivity supporting all operational scenarios comprising both local and remote applications including LOS and BVLOS use cases, stand-alone and fully networked system architecture and swarming [Ref to OO4]. [call text] Be based on a ground vehicle on which a variety of payloads can be mounted to support various mission functionalities: transport, fire-support, ISR, EW and cyber, etc. The sensors and communication systems of the ground vehicle shall have the capability to be integrated into broader networks; [iMUGS’ answer] iMUGS is based on a modular framework that will enable integration of different 41 Grant Agreement number: EDIDP-MUGS-2019-002-iMUGS ANNEX 1 types of payloads. The use of an all-over-IP approach within communication subsystem of iMUGS will enable a smooth integration in various types of networks and into broader networks [OO3, TO4]. [call text] Ensure that autonomy related capabilities, that can cause collateral damage, are restricted to human-in-the-loop or human-on-the-loop common control in order to minimize collateral damage risks ensure operations under rules of engagements. [iMUGS’ answer] Safety is a key subject of iMUGS design and will be addressed as part of the modular framework for both human-in-the-loop (such as follow me) and human on the loop (supervising a remote task) through dedicated safety & security activities [Ref to OO2, TO2]. Expected impact [call text] Enhanced interoperability between armed forces of Member States [iMUGS’ answer] iMUGS will use existing standards [Ref to TO1] and define new open interfaces where required, use IP based communication technology [Ref to OO4] and a modular and open system architecture to enhance interoperability on payload as well as vehicle-to-vehicle level [Ref to TO4]. The interoperability will also be enforced by a common understanding of military operational scenario [Ref to OO1]. [call text] Increased situational awareness and force protection of ground units, their combat effectiveness, endurance, mobility and autonomy to enable faster deployment, and to enhance the interoperability and affordability of ground forces; [iMUGS’ answer] iMUGS will increase situation awareness of ground units by providing, within our system, autonomous missions such as automated observation as well as a large set of embedded sensors for distanced observation [Ref to OO6]. The integrated communication solution allows efficient automated information exchange with other systems deployed by the troops [Ref to TO4]. iMUGS will improve the endurance of ground units by exposing robots instead of soldiers (through teleoperation and autonomous capabilities [Ref to OO2]). iMUGS will increase effectiveness of ground soldiers through augmenting sensors to shooter abilities [Ref to OO6]. iMUGS CS will support relevant C2 and ISR interoperability standards [Ref to TO6]. The design will allow for a wider industrial base and the modularity will allow the customer to opt for more affordable options among the selection of payloads [Ref to TO1]. [call text] Faster decision-making and significantly increased resilience and protection of soldiers in any environment; [iMUGS’ answer] By providing autonomous functionalities to the soldier, iMUGS will allow faster decision-making (through surveillance missions and autonomy sensors, soldiers will get better situation awareness to take faster decision, particularly in difficult environment as night or certain weather conditions) and also increase protection of soldiers (by sending iMUGS unmanned system for reconnaissance and securisation before sending soldiers in a zone) [Ref to OO2; OO6] Decision making functionalities are integrated in the autonomy framework, such as planning, scheduling, resource allocation, diagnosis, perception. The system will propose options to the soldiers, facilitating human decision making. [call text] Contribution to rebuild a credible deterrent in terms of land combat capability, by introducing in the shortest time the right number of advanced logistic and combat vehicles in general as well as CSPS and introducing the unique capabilities of UGS to operate in high risk scenarios [iMUGS’ answer] Fast deployability and transportation to hostile environments will enable the creation of deterrent UGS at the tactical level, reinforcing reactivity with better force protection [Ref to OO6]. [call text] Reduction, through commonality and mass production, of the acquisition and life-cycle costs for each Member State [iMUGS’ answer] The modular architecture of iMUGS allows multiple potential suppliers to propose production to increase acquisition efficiency and potential localisation objectives. The use of industry standards and commonality of the C2 station over a wide range of unmanned systems (ground or air) will simplify life cycle costs by increasing production volume of components, combining central control, and simplifying future unmanned system integration through commonality. The presence of large-scale ground system manufacturers in the iMUGS consortium will allow guiding of mass production and commonality objectives and reuse of existing capital investments and cost control 42 Grant Agreement number: EDIDP-MUGS-2019-002-iMUGS ANNEX 1 constraints throughout the project lifecycle. [Ref to OO6; TO1; TO2; TO7] The main European defence industries in the ground vehicle domain are working together in this project to propose a common solution, enabling mass production and the reduction of life cycle costs. [Ref to TO1]. [call text] Contribution to the strategic autonomy of the European Union. [iMUGS’ answer] iMUGS will help to establish and improve the industrial capabilities within the European Union for all aspects of unmanned ground systems. This starts with the design of unmanned ground systems, ideas of the ways how to use these systems, building a prototype and testing it in the end [Ref to OO1-OO6]. Objectives of iMUGS From the previous requirements that are covered by iMUGS, the project has identified the following operational and technical objectives. iMUGS will reach this overall objective through several SMART (Specific, Measurable, Achievable, Realistic, Timebound) operational and technical objectives. The operational objectives are related to the way the end-user operates with the System. The technical objectives reflect the innovative aspects of the project. IMUGS Operational Objectives (OO) OO1: Develop, analyze and define military operational scenarios and concepts for deploying iMUGS and engaging with iMUGS with a focus on man-unmanned teaming. The analysis covers teaming with other unmanned systems, soldiers and manned systems and with combinations of these. This will be done, based on workshops with the participating member states from the EU, with the help of virtual and constructive simulation and with tests and demonstrations. The tests and demonstrations will use systems and developments from this project. The project will provide an analysis on the ethical use of autonomous UGVs and on the compliance with applicable legislation.  KPI.O1.1: Military operational scenarios and concepts. Target: Definitions written and reviewed. Measure: Demonstrations and study/report  KPI.O1.2: Deployment of unmanned systems. Target: Prototypes built. Measure: Demonstrations and reports. OO2: Develop and integrate an autonomous and safe ground system with “human in the loop” (for both mobility and mission autonomy) from teleoperation to driving assistance in unknown environment and from driving assistance to mixed interactions and to full autonomy in pre-mapped environment. The autonomous capabilities as well as the ground vehicle capabilities will be developed considering the following environments: urban and off-road, day and night, GNSS denied, normal and degraded communication, and various environmental conditions (winter and summer). It will perform safe operations, including fail-safe behaviours, helping fratricide prevention through increased ISR capabilities.  KPI.O2.1: Number of successful autonomous missions in environments relevant to the project Member States (pMS) climatic conditions. Target: 80%. Measure: Simulation, Demonstrations and reports.  KPI.O2.2: Detection of humans. Target: >90% Measure: Simulation and reports. OO3: Develop a modular cyber defence system delivering resilience against cyber, electromagnetic and physical exploitation attacks of concern.  KPI.O3.1: Response to cyber-attacks. Target: Detection of 3 different types of cyber-attacks; isolation of affected components; mission success in presence of cyber-attacks. Measure: Demonstration showing that a compromised component is detected and addressed by the Cyber Defence System, resulting in mission success. OO4: Develop a communication solution that provides the required connectivity supporting all operational scenarios comprising both local and remote applications including LOS and BLOS use cases, stand-alone and fully networked system architecture and swarming. The solution is interoperable 43 Grant Agreement number: EDIDP-MUGS-2019-002-iMUGS ANNEX 1 with other communication systems deployed by the troops allowing efficient information transfer and supports both manned and unmanned operations.  KPI.O4.1: Connectivity. Target: The communication solution provides the required connectivity supporting all operational scenarios comprising both local and remote applications including LOS and BLOS use cases, stand-alone and fully networked system architecture and swarming. Measure: Demonstrations and field tests.  KPI.O4.2: Interoperability. Target: Communication system provides integrated services for manned and unmanned operation. The same system can be used for all ground communications required by the combat unit. Measure: Demonstration and Field tests OO5: Develop and integrate swarming capabilities (heterogeneous agents having capabilities to work as a group with multiple mission objectives) aiming to operate multiple vehicles by a single operator.  KPI.O5.1: Number of agents in the loop (real-time) in a fully structured environment. Target: 3 platforms and 10 smaller vehicles. Measure: Demonstration.  KPI.O5.2: Generate solutions for multi-agent scenarios, that are optimized against a common set of objectives. Target: Near to real-time proposal of possible solutions for the agents to C2. Measure: Demonstration of control of multiple platforms (10 to 15) through a swarming interface; report. OO6: Provide situation awareness information to the soldier through Command and Control (C2), thanks to different sensors and payloads (as ISR) and advanced intelligent perception algorithms.  KPI.O6.1: Integration of ISR sensor payload software on the C2 platform. Target: Control of at least one ISR payload from iMUGS C2 platform. Measure: Demonstration and reports.  KPI.O6.2: Presentation of threats detected by iMUGS sensors on the C2. Target: Dissemination of threats: at least 3 levels of threat identification flags. Measure: Demonstration and reports. iMUGS Technical Objectives (TO) TO1 – SP Integration: Develop an open, modular, interoperable architecture for UGV systems supporting existing standards.  KPI.T1.1: Open, modular, interoperable, standards-based system architecture inherently encompassing operational safety and cyber security properties and optimized towards foreseen mass production of the Systems (upgradeability, sensor agnostic architecture) resulting in reduction of life cycle costs and increased physical reliability. Target: Standards based interfaces between subsystems and standards-based architecture specification (STANAGs, NAFv4, NATO General Vehicle Architecture) Measure: Design specification and interfaces specifications are based on existing relevant standards, production scalability, safety and cyber security targets.  KPI.T1.2: Exposure of system capabilities to users for enabling operational assessment and concept definitions. Target: Operator centric functionality demonstrated to end-users in relevant environment. Measure: Demonstration activities performed; feedback received. Final report. TO2 – SP Autonomy: Develop a modular and cyber secure computer (backbone) for autonomous safe architecture scoping existing standards.  KPI.T2.1: Safe and secured autonomy solution integrated (UGV integration and sensors integration). Target: Common autonomy services are available. End-to-end security provided. Measure: According to test plans: Integration tests. Validation tests.  KPI.T2.2: Autonomy algorithms from 4 partners integrated in the autonomy backbone. Target: Containers in place within the backbone. Measure: According to test plans: Integration tests. Validation tests. TO3 – SP Cyber: Design a Cyber Defence System capable of detecting and responding to cyber-attacks. 44 Grant Agreement number: EDIDP-MUGS-2019-002-iMUGS ANNEX 1  KPI.T3.1: Design of a Cyber Defence System capable of autonomously detecting a compromise or an attack against onboard components, such as cyber-attacks coming from other entities in the same communication network, components compromised in the supply chain, and attempts to load malicious code onto the system through physical exploitation. Target: Design fulfils the requirements. Measure: Cyber Defence Review (CDR) report.  KPI.T3.2: Prototyping of a cyber-attack response controller capable of issuing an appropriate mitigating recommendation. Target: Successful integration into the iMUGS platform. Measure: Demonstration showing that an appropriate recommendation is generated. TO4 – SP Communications: Develop a secure and scalable multiple channel network communications capable of deploying both commercial and tactical mesh network technologies, with support to swarming.  KPI.T4.1: Secure network services solution integrated. Target: Secure network services for mobile Virtual Private Newtork (VPN) and Mobile Device Management (MDM) are available. End-to-end security provided. Communications can be routed over multiple channels (e.g. commercial / tactical networks) seamlessly. Measure: According to test plans: Integration tests. Validation tests. Field tests and demonstrations.  KPI.T4.2: Integration of the selected communications means including commercial, vehicle- to-vehicle and tactical Internet Protocol (IP) mesh networks including relayed and multi-hop scenarios Target: Seamless and transparent communications can be provided over the selected communications means. Measure: According to test plans: Integration tests. Validation tests. Field tests and demonstrations.  KPI.T4.3: Integration of selected EW capabilities. Target: Detection of jamming and localization of the jammer are available. Resistance to defined jamming (applies to only tactical mesh / Vehicle-to-Vehicle (V2V) communications). Measure: According to test plans: Integration tests. Validation tests. Field tests and demonstrations. TO5 – SP Swarming: Develop architectures, methods and algorithms to optimize a multi-agent system against multiple objectives.  KPI.T5.1: Capability to solve multi-objective problems and perform multi-objective missions Target: Performing multi-objective missions (up to 5) Measure: Simulation  KPI.T5.2: Setting up simulations for development, testing and the demonstration of the targeted capabilities, as well as field testing global swarming. Target: According to test plans: validation tests and demonstrations Measure: demonstration TO6 – SP Command, Control & Interoperability: Ensure interoperability and standardisation of interfaces with existing Command and Control (C2) as well as C4I and Battlefield Management System (BMS) and databases.  KPI.T6.1: Communication system interface compatibility. Target: All relevant subsystems can interface to the communication system and transfer IP-data transparently over the communication system. Measure: Integration tests. Tests according to the validation plan. Field tests and demonstrations.  KPI.T6.2: Development of a Control and Data Model specific to UAV and UGV systems. Target: Development of a reconfigurable land and air vehicle control and user C2, interface definition and prototyping. Measure: Demonstration and reports.  KPI.T6.3: Interoperability with existing C4ISR systems. Target: Implementation of two (2) interoperability protocols in iMUGS C2. Measure: Demonstration and reports. TO7 – SP MUM-T: Simulation & supporting infrastructure for manned-unmanned teaming  KPI.T7.1: Integration of unmanned systems into existing virtual and constructive simulation. Target: Generic unmanned systems can be used for the evaluation of military operation scenarios. Measure: Tool for workshops (military operational scenarios)  KPI.T7.2: Integration of transportation means and C2 equipment for UGV to a manned vehicle (Boxer). Target: Unmanned systems will be deployed and controlled with the help of manned systems (Boxer). Measure: Demonstration. 45 Grant Agreement number: EDIDP-MUGS-2019-002-iMUGS ANNEX 1 6.1.2. CONTRIBUTION TO EXCELLENCE 6.1.2.1. Key iMUGS features iMUGS will develop 6 features, corresponding each to one subproject (SP): C2, Communications, Autonomy, Swarming, Cybersecurity, MUM-T. System architecture will ensure the technical and operational coherency of the outcomes of the project. For each of these features, the iMUGS consortium will start from a documented state-of-the-art, and go significantly beyond during the implementation of the project. Open, modular, technology agnostic architecture (SP1 System’s Integration) State-of-the-art: Until now, UGVs have been largely stand alone, bespoke, designed and built for single mission, introducing a various set of solutions with proprietary interfaces and dreadful “logistics, training and operational challenges”. There is a permanent increasing need for networked information technology in and between UGVs, which enables better Operational Capabilities and faster, more efficient and precise effects during missions. This requires a common/standardised approach so that devices constituting an unmanned ground system can exchange information with each other and can be integrated more easily, ie an approach aligned to manned platforms as identified in the EDA LAVOSAR I&II studies and thereafter the development of NATO STANAG 4754 – requiring a modular, interoperable and open architecture approach and enabling lowering development and life-cycle costs. (Unmanned Ground systems roadmap, Unmanned Systems Integrated roadmap) Beyond the state-of-the-art: The capability development roadmaps envision a fully network centric, multi mission reconfigurable approach with the stepwise introduction of a wide range of customer defined payloads and system components throughout the life cycle of a vehicle. The architecture proposed for iMUGS will enable, through following the implementation of respective standards (STANAG, NATO Generic Vehicle Architecture (NGVA), etc), open, modular architecture (interface descriptions and modularity specification) the widest selection of customer selected system capabilities and payloads from a large industrial base and will accommodate new sensors and components as these become available from several suppliers. The architecture will also inherently include safety features and include ad hoc a dedicated aspect on cyber security and defence (especially EW considerations). The open modular architecture is developed end-to-end, encasing safety critical and non-safety critical components from tactical C2, real-time control of vehicle, fleet and teaming control, multiple communications networks to autonomous functions, platform and cyber defence system. The openness and modularity are applied in each component of the architecture through standards-based interface definitions and interoperability requirements. Representation of the architecture and verification of the implementation is provided by the iMUGS domain models (and the whole system model) – through Model Based Systems Engineering methods using NATO Architecture framework v4 and Concept Development and Experimentation (CD&E) principles. Extensive end-user engagement is planned during the requirements engineering through consultation process for input to Mission Definition Review (MDR), System Requirement Review (SRR) and CDR. The project activities will be conducted in coherence with NATO IST Panel Activity „Interoperability for Semi-Autonomous Unmanned Ground Vehicles“, activities funded Under „PADR-US-03-2019: Interoperability standards for military unmanned Systems“ and other relevant calls for proposals and other relevant coordinating activities. 46 Grant Agreement number: EDIDP-MUGS-2019-002-iMUGS ANNEX 1 Autonomous functions (SP2) State-of-the-art: Various types of autonomous systems have been developed in aeronautics and space domains, involving various forms of automated reasoning. Autonomous architectures were defined by automatic planning, scheduling and diagnosis, while execution was managed by a smart executive. The 123 Remote Agent Experiment (RAX) architecture is one of the first examples with those components. In the land domain, various Defense Advanced Research Projects Agency (DARPA) Challenges (2004 4 to 2007) addressed autonomous mobility, with teams opposed in environments from desert to urban context. The Boss architecture, demonstrated by Carnegie Mellon University (CMU), combines perception, planning and behavioural executive functions in a modular and scalable software environment. It won the last challenge in the more difficult urban context. Software/system objectives were to allow incremental development, to minimize impact of changes and to support alternate 5 6 algorithms . Modern implementations of such architectures extend the different functionalities: complex environment, uncertainty and more complex missions. Unmanned capabilities for military missions have been successfully developed in Europe during the recent years. These capabilities are 789 successfully demonstrated from 2006 at European Land Robotic Trials (ELROB) . In Europe, robotized platforms projects rely on proprietary hardware and software architectures and are poorly interconnected with other UGVs. They operate in a closed environment which make them protected from cyber-attacks. Beyond the state-of-the art: iMUGS aims at improving autonomous functions in Europe by developing a fully tested Autonomy Framework (AF). From the hardware point of view, the Framework is composed of Autonomy computers (including Safety Integrity Level (SIL) and non SIL components) as well as a dedicated set of sensors necessary to perform autonomy missions. The iMUGS concept is based on a fully modular and open backbone located on the UGV platform and connected to its actuators and its proprioceptive sensors. The backbone includes the Hardware components as well as a Software Architecture allowing easy development and deployment of autonomy functions. The backbone is also interfaced to C2 through secured communication means to provide the operator with the robot and mission data and is connected to cybersecurity components to be able to react to detected Cyber Attacks or another artefact. The autonomy functions (based on different and redundant algorithms for resilience) will be hosted in the autonomy backbone through containers. This provides an easy modularity, avoids fault propagation from one container to the other (segregate) and offers a better system/resources monitoring. The backbone will be designed to be platform agnostic even if it will be demonstrated on the THEMIS platform. Within the AK development, 6 main autonomy missions will be addressed: Line of Sight 1 Remote Agent Experiment, http://rax.arc.nasa.gov, February 8-9, 2000 Pasadena, CA 2 Remote Agent Experiment, http://rax.arc.nasa.gov, February 8-9, 2000 Pasadena, CA 3 Brat and al. A Robust Compositional Architecture for Autonomous Systems IEEEAC paper #1499, Version 9, Updated Dec 16, (2005) 4 Sebastian Thrun & Al. Stanley: The Robot that Won the DARPA Grand Challenge, Journal of Field Robotics 23(9), 661– 692 (2006) 5 Philip Polack, Florent Altché, Brigitte d'Andréa-Novel, Arnaud de la Fortelle. A Real-time Safe Planning and Control Architecture for Autonomous Driving Adapting to Slippery Roads, jan 2019 6 Sagar Behere, Martin Törngren (2016), Information and software Technology, Information and Software Technology 73 (2013) 7 ELROB – The European Land Robot Trial, https://www.elrob.org/ 8 Philip Polack, Florent Altché, Brigitte d'Andréa-Novel, Arnaud de la Fortelle. A Real-time Safe Planning and Control Architecture for Autonomous Driving Adapting to Slippery Roads, jan 2019 9 C Guettier, B Bradai, F Hochart, P Resende, J Yelloz, G Alexandr, Standardization of Generic Architecture for Autonomous Driving: A Reality Check, Energy Consumption and Autonomous Driving / Lecture Notes in Mobility, 57- 68, sep 2015 47 Grant Agreement number: EDIDP-MUGS-2019-002-iMUGS ANNEX 1 Teleoperation, Beyond Line of Sight Teleoperation, Follow-me vehicle and pedestrian, Way point navigation, Patrolling & Reconnaissance and Surveillance. The decision layer will use a common subset of Hierarchical Task Networks (HTN) and Action Notation Modelling Language (ANML) to model and describe robotic actions at mission or manoeuvre levels. Based on these representations, several solving techniques will be used to compute on-line robot activities on a time horizon. These planning techniques will be coupled with low level control, such as model predictive control (MPC) or adaptive control. A combination of temporal task network at execution combined with automata representations will be considered for the project and scheduling strategies will have to be defined on-line. The situation awareness is critical for combat mission. Three different Simultaneous Localization and Mapping (SLAM) techniques will be envisaged for the project. Several hybridizations of outdoor SLAM will also be evaluated, including for example stereovision, inertial navigation and vision-based techniques. The SLAM technique can be complemented with a high-performance obstacle map, optimized on Graphical Processing Unit and delivering real-time performances when needed. A mission payload dedicated to observation will also provide additional useful tactical information in the command chain. Based on deep learning techniques, the processing stage will be able to provide target detection and Figure 3: Autonomous backbone architecture reconnaissance. Payload activity will be tasked on-line by the mission planning system. This is an efficient approach to deal with environment dynamics and to pinpoint relevant information according to mission objectives and context. A proximal 360° vision for autonomous mobility will also be provided to enable real-time obstacle map processing. The architectural framework for autonomy will also address safety, cyber-security and resilience in a transverse way, by providing either specific system components or generic containers (for instance, safety components will impact only execution control and trajectory management, while a set of specific guarantees –real time, atomicity, integrity- will be encapsulated by their containers). Cybersecurity (SP3) State-of-the-art: At present, the level of autonomy for vehicles on the market is limited, but the capability is rapidly growing. Current state-of-the-art vehicles offer little design considerations in the way of security to the information and control signals present throughout the vehicle. Most vehicle instrumentation and control designs make use of the Controller Area Network (CAN) bus standard. This system is a widely adopted standard but was never designed to secure the information shared on the 10 platform and lacks even some of the most basic security items such as encryption and authentication . 10 Sagong, S. U. (n.d.). ESCAR Europe 2018. In ESCAR Europe 2018. Retrieved from https://labs.ece.uw.edu/nsl/papers/Bushnell_escar2018_CameraReady.pdf 48 Grant Agreement number: EDIDP-MUGS-2019-002-iMUGS ANNEX 1 The current method of securing vehicles from cyber threats is based on adherence to non- mandatory guidelines, although many governments around the world have adopted a control-oriented 11 strategy, introducing legislation to address cyber risks . Several voluntary guidelines have been published from organizations such as Society of Automotive Engineers (SAE) and National Highway Traffic Safety Administration (NHTSA), and the US has recently introduced the Security and Privacy 12 in Your (SPY) Car Study Act of 201714 . This law mandates NHTSA to conduct a study to identify measures to implement standards for mitigating cyber security risk in vehicles. Specifically, these standards will require segregation of systems with differing security and criticality requirements and require the system to autonomously monitor, detect and prevent malicious code attempting to stop or take control of the vehicle15. In the EU, there have been measures to address the risk of cyber threats in general, but nothing with direct applicability to autonomous vehicles14. There has been much research to further the development of intrusion detection systems for vehicles, raising an alert in the event of a potential compromise or attack. Efforts have been directed toward securing the highly vulnerable CAN bus network through very economical and simple means. One design focuses on monitoring for abnormally high frequency of message transmission on the CAN 13 14 bus, indicating a potential attack . Other research attempts to apply a more generic method of behavioural modelling of autonomous vehicles. Although this technology has much more maturity as applied to conventional IT systems, current research strives to adopt this for autonomous vehicles. This model establishes an operational baseline by monitoring communication between subsystems and the resulting physical actions the vehicle takes. The system autonomously monitors for deviations from this baseline, 15 presenting anomalies to a human user to analyse for evidence of an attack . Beyond the state-of-the art: As autonomous functions advance, there is an exceedingly growing demand for computing performance and the number of subsystems required to accomplish this. The increase in computing resources directly correlates to a larger cyber-attack surface and therefore increased risk of cyber-attacks. Unlike the automotive sector, this military platform is exposed to a completely different plane of threats. As forces incorporate this asset into their battle plans, enemies will look for vulnerabilities to exploit or deny its capabilities; the large cyber-attack surface will require extra attention to safeguard from multiple attack vectors. The ability to secure and monitor for an attack will exceed the capabilities of a human operator, especially with consideration of autonomous operations outside the range of communication. Therefore, autonomous monitoring and detection is needed. Our solution draws from similar concepts that leading cyber threat detection research has proven but will address threats with a holistic model that includes cyber, electromagnetic, and physical attacks to the system, autonomously monitoring for evidence of a compromise or an attack from these vectors. In the event of detection, our system will provide an appropriate response for the platform to make without human interaction, mitigating an attack and ensuring resiliency for the platform to accomplish its assigned mission. 11 Taeihagh , A., & Si Min Lim, H. (2018). Governing autonomous vehicles: emerging responses for safety, liability, privacy, cybersecurity, and industry risks. Retrieved from https://papers.ssrn.com/sol3/papers.cfm?abstract_id=3211839 12 Security and Privacy in Your Car Study Act of 2017, H.R. 701, 115th Cong. (2017). 13 Moore, M. R., & Bridges, R. A. (2017). Modeling inter-signal arrival times for accurate detection of CAN bus signal injection attacks: a data-driven approach to in-vehicle intrusion detection. Retrieved from https://dl.acm.org/citation.cfm?id=3064816 14 Young, C., & Olufowobi, H. (2019). Automotive Intrusion Detection Based on Constant CAN Message Frequencies Across Vehicle Driving Modes. Retrieved from https://lib.dr.iastate.edu/ece_conf/67/ 15 Bezemskij, A., & Loukas, G. (2016). Behaviour-based anomaly detection of cyber-physical attacks on a robotic vehicle. Retrieved from https://ieeexplore.ieee.org/document/7828584 49 Grant Agreement number: EDIDP-MUGS-2019-002-iMUGS ANNEX 1 Communications (SP4) State-of-the-art: Current tactical C2 communication systems have been designed for leading tactical operations with voice and short messages, which requires low data rates. Although modern high data rate links are already been deployed, these solutions in general have been designed for manned operations supporting the current warfare, e.g. way the troops operate and organize themselves. In addition, each military branch often deploys their own solutions, which may not be interoperable with each other. The result of all this is that there are multiple parallel communication systems deployed, none of them in particular designed for supporting the deployment of UVs. 16 Current high-end solutions for remote control applications are typically based on proprietary technology optimized for the specific solution, up to deploying military satellite services to allow control of Unmanned Vehicles (UVs) in international operations. Although integrated and networked solutions including relayed solutions are becoming available, point-to-point system architecture is still typical for a remote-control link. In addition, video, control and telemetry data have traditionally deployed separate dedicated links. Alternatively, low-end consumer solutions may deploy WiFi-based and other similar technologies, inadequate for harsh environments such as the battlefield (interference, jamming…) and do not either support networking. Current state-of-the art mobile networks such as LTE and 5G provide capacity and connectivity and may play some role in unmanned communications but are dependent on the network infrastructure and will fail in the battlefield (jamming…). Deploying dedicated proprietary solutions for UVs is a straightforward way to implement the required UV data links. However, this increases the total complexity and cost of the communications throughout the entire logistics chain even further. In addition, in joint manned/unmanned operations the troops have to carry extra equipment in addition to their normal tactical C2 communication devices. Furthermore, current data link solutions for UVs are not usually interoperable and do not support information transfer with command systems deployed by ground forces, which means that in addition to less flexible applicability the current systems do not support building joint situational awareness due to incompatibility and lack of interfaces. Beyond the state-of-the art: iMUGS will develop and demonstrate a flexible and efficient communications concept, based on a fully networked solution combining all available resources (tactical and commercial networks, and networks with future expansion possibilities, like satellite communication) into a single entity allowing the unmanned system to be operated from the forward area to the support lines. Several features will be developed under this concept: A joint Tactical C2 and Communication network: The core of the proposed communication solution is based on modern tactical communications technologies including self-forming and self-healing tactical mesh network. The solution will form a single entity connecting both troops and UVs to each other and to the C2 system through a unique IP network providing the users the required data transfer and security services. The solution will support both manned and unmanned operations by adapting the parameters of the radio interface such as bandwidth and the waveform as required. This is based on the deployment of SDR technology. The use of the communication network by UGV and C2 Command Posts in a transparent way will make the UGV and the C2 systems network agnostic. This feature will facilitate the adoption of new communication network technologies by iMUGS components including the vehicle, the payloads and the C2 applications. In addition to information transfer, the communication solution shall provide selected EW/Electronic Support Measures functionality integrated to the same system to support combat operations and establishing joint situational awareness. One of the key ideas is to deploy the entire network as a sensor having the communications equipment providing information about the 16 DTC website: http://www.domotactical.com/solutions/?robotic-communications, Silvus Technologies website: https://silvustechnologies.com/applications/unmanned-systems/, Aero defence technologies: https://www.aerodefensetech.com/component/content/article/adt/features/articles/22651 50 Grant Agreement number: EDIDP-MUGS-2019-002-iMUGS ANNEX 1 radio environment and processing the information with distributed AI computing. In addition, the standard IP-interfaces allow connecting EW payloads to the system providing functionality such as spectrum monitoring and jamming. The integrated all-IP solution supports information exchange between various C2 and battle management systems that allows sharing, for example, joint situational awareness information. Vehicle-to-vehicle communication solution: Based on mesh-networking, the novel communication solution will support convoy-type of applications and future free formed large swarms. The concept consists of a tactical waveform design/implementation and an antenna solution combining a 360° coverage and connectivity of omnidirectional antennas to superior link performance of directional antennas. UGVs communication will be low power (LPD), resistant to jamming (AJ) and the signal will be difficult to be intercepted (LPI). Wide deployment of SDR: Secure Software Defined Radio technology will allow the proposed solution to be updated and further developed based on the requirements and evolving concepts of operation. This greatly enhances the overall life-cycle management and system maintenance. The deployment of SDR is also a key to wide interoperability and ability to flexibly support various applications with the same equipment. For example, the SDR communication equipment can be configured to carry out EW/ESM tasks and many other functionalities. Novel way of secure networking: The connections will be routed seamlessly via the best available channel including commercial mobile networks, satellite connections and tactical networks. In such a complex hybrid network the quality of service is enhanced using Artificial Intelligence/ Machine Learning-aided system level control. In addition, when opening up channels to the public telecom network, cyber threats must be properly addressed and eliminated. The system will ensure end-to-end security by deploying for example encryption, mobile VPN technology and mobile device management. The interoperability between systems supports full information transfer and joint operations, including wide-scope situational awareness and support to EW. Swarming (SP5) State-of-the-art: During the last two decades, extensive research has been executed in the field of 17 optimization strategies and search algorithms . Some of these algorithms have been demonstrated to bring value to multi-objective function solvers (MOFS), both on autonomy level as on the level of 18 vehicle collaboration or swarming . Most of the applications on swarm MOFS, today, run on simulators, and the first demonstrators (ex: DARPA, OceanAlpha-PLAN) are being deployed today. A common approach used in MOFS is to describe a physical model of the vehicle and parameterize the model, translate the environment to a data structure and to describe the optimization problem in terms 19 of constraints using a descriptive language (Constraint Programming) . Models and environments 20 resemble those in the gaming industry . In the industrial world, the Industrial Internet of Things (IIoT) 21 and digital twins, have become more generally deployed approaches . These digital twins can substitute the models used in the MOFS simulation environment, theoretically linking a physical asset to a swarm optimization algorithm. The large volumes of captured data must be reduced and rendered into data structures making the data available to search algorithms. Hence another essential discipline emerges, feature extraction and data structuring. Optimizations are currently executed on fleets of aerial and 17 Ebenhart R.C, Shi Y., Kenndy J., Swarm intelligence, 2001 18 F. Lucas, C. Guettier, P. Siarry, A.-M. Milcent and A. de la Fortelle Constrained Navigation with Mandatory Waypoints in Uncertain Environment Journal of Information Sciences and Computer Engineering, 2010 19 C. Guettier, B. Patin and J.-F. Tilman. Validation of Autonomous Concepts using the ATHENA Environment. In Proceedings of the International European Space Agency Workshop on On-Board Autonomy. Noordwijk, The Netherlands, October 2001 20 Luebke D. et al, Level of Detail for 3D graphics, 2002 21 F. Tao, H. Zhang, A. Liu and A. Y. C. Nee, "Digital Twin in Industry: State-of-the-Art," in IEEE Transactions on Industrial Informatics, vol. 15, no. 4, pp. 2405-2415, April 2019 51 Grant Agreement number: EDIDP-MUGS-2019-002-iMUGS ANNEX 1 seaborne vehicles, where a world can be described in binary logics, the challenge for ground vehicles is that they operate in complex environments that cannot be described as such. Beyond the state-of-the-art: iMUGS aims to bridge existing practical gaps between theory and implementation of scalable multi-agent collaboration and optimization which should ensure operations in mission-critical unstructured outdoor environments. In order to execute such complex missions, the challenging existing gaps relate to the timely and compact rendering and structuring of data needs to be solved. Two types of swarming optimizations are envisaged: local and global optimization. Local optimization relies upon local (edge) limited computational power and local information, where global optimization relies upon many data sources on many different levels (edge-fog-cloud) and virtually unlimited computational resources. Global swarming: iMUGS will provide a global swarming solution having access to many data sources. Except for data captured on the edge, most information and computational power are not hard real-time available. With respect to that constraint, the first challenge is to subdivide the problem statement into real-time until non-real-time requirements. Secondly, a hierarchic, type ‘level of detail’ or resolution world model approach, aims to subdivide the problem into parallel datasets that can be outsourced to computational power on each level of the architecture and solutions are progressively refined. Low resolution and hard-real-time problems are solved on the edge, near-real-time solutions using larger sections of available world information are solved on massively parallel computational power available in the fog, other non-real-time calculations are handled in the cloud. The local swarming: iMUGS will provide a local swarming solution. Local swarming approach is a swarming modality, that is active when all connections to C2 (command and control) or fog or cloud, are broken or very limited. In that case, the agents must be able to optimize their tasks based upon computational power and data sources available in their local network or stand-alone in the edge and a collaborative behaviour is aimed to emerge. Local swarming will thus optimize a local problem. Due to the low starting Technology Readiness Level (TRL) of local swarming and lack of a priori information of the equipment that local swarming is using, this swarming mode will only be developed and demonstrated on simulation level. The iMUGS swarming framework should also support an intelligent mixed interaction between the local and global swarming functionalities depending on the operational constraints and the complexity of the mission. Command and control / Control station (SP6) State-of-the-art: Remote control stations (CS) for UGVs exist today (Oshkosh, ST Kinetics) but they are typically non-standard, specific to the UGV manufacturer’s vehicle where design parameters driven by vehicle manufacturers and without regards for control of or interaction with other unmanned vehicles. In addition, no ground CS combines air and land unmanned operations: a CS to operate medium-altitude long-endurance (MALE) and tactical UAV’s beyond line of sight within European skies require airworthiness certifiable systems when the UAV exceeds 150 kg per European Union Aviation Safety Agency (EASA) regulations, whereas USA and other countries are more lenient and laxer with military use exceptions on such certification. Also, current CS solutions focus in the control of a single UGS in basic teleoperation modes, in many cases using proprietary interfaces and protocols. Today’s integrated operations require close coordination with the air and land segments and strong collaboration between them necessitate a joint view and control of the ground and airborne unmanned assets, which is not possible at the moment and thus require operator level coordination with increased work on human operators and reduced performance envelope. The experience of previous defence programs has shown that airworthiness certification is to be considered and embedded as soon as the design of the system, and has important impact on performances, costs, operational use and calendar. Beyond the state-of-the art: iMUGS aims to develop a modular heterogenous fleet UGS Control Station capable of commanding multiple UGS from a centralized C2 position, thus minimizing operator workload by combination of Control Station features with UGS autonomy and swarming capabilities. iMUGS will integrate air component to unmanned ground systems in design, and thus allow joint force operations and acquisition and provide long term design stability. Aerospace certification is an aspect that cannot be added to a product later on, it must be integrated and planned from the initial design 52 Grant Agreement number: EDIDP-MUGS-2019-002-iMUGS ANNEX 1 phases and high-level requirements should be traced throughout the project cycle from design to hardware and software to certify the final product. For this reason, the C2 station of iMUGS will be an integrated one, designed to allow future UAV airworthiness certification. iMUGS control station will meet the same strict aerospace safety critical design rules for airworthiness certification with the use of (Un)Manned’s Sol technology base, for eventual co-operation of UGS with UAS systems and control of UAS and UGS from the same control station. Furthermore, it will conform with relevant standards such as existing Standardization Agreement (STANAG) 4586 for UAV operations, derive a standard UGV operations concept based on it. The control station design will also comply with the upcoming STANAG 4817 for Multi Domain Control Station (MDCS) and NGVA compatible mobile vehicle control interfaces. At its release iMUGS C2 station will be at the forefront of the control stations for control of multiple unmanned systems: on the ground and in the air. iMUGS CS will take a modular approach to capabilities, allowing the development and rapid deployment of additional functionality and payloads over time in phases of MUGS project. A flexible control station architecture with different unmanned vehicle profiles will be created, that can be expanded later to any Unmanned System. Eventually all unmanned systems will be controllable from the same C2 station and integrated into battlefield tactical environment. Instead of the typical company vehicle specific implementations a common standard station will allow many European nations and companies to cooperate in system design, later European cooperation in operation and potentially asset sharing. iMUGS system architecture can be deployed over a variety of ground and air systems that are interlinked via same communication means. The Control Station allows a single individual to control multiple semi-autonomous systems using the same software suite and controller, therefore, maximizing the use of assets, sensors, payloads, data/information sharing and decision-making. Manned-Unmanned Teaming (SP7) State of the-art: Unmanned flight systems have already been in use for several years. Scenarios for using these systems exist, as well as the belonging infrastructure, logistics and training concepts. The whole development of unmanned ground systems, e.g. Concept of Operations (ConOps), military operational scenarios, virtual simulation of ground systems or studies about the ways to deploy them are at their premises. Today there are no common concepts on how to handle Manned-Unmanned Teaming (MUM-T) within the participating nations inside the European Union (EU). Beyond the state-of-the art: Within the iMUGS project, working groups with military representative from the participating countries will be organised to define and assess concepts of operation for MUM- T in connection to iMUGS. The workshops planned within MUM-T will help to build a European base for the future development of the topics connected to MUM-T. These topics are military operational scenarios to be considered for this project, the deployment of unmanned ground and aerial systems and possible future scenarios. The military operational scenarios will describe how iMUGS can be used and what the current restrictions are. A subset of these military operational scenarios will be shown during the demonstrations of this project and will help to update these scenarios already during the realisation of this project. The investigations about the deployment of unmanned systems will summarize the current possibilities and what will be necessary and helpful in the future. Examples for the deployment of unmanned systems will be presented during the demonstrations. The possible future scenarios will summarize the points of the discussions which cannot be considered for this project, a roadmap will explore possible middle-term developments. It will cover main interests for the time being and what might be helpful and necessary for the future. A second outcome will be that the possibilities of the constructive and virtual simulation in respect to iMUGS in different combinations will be evaluated. The constructive simulation will integrate an iMUGS and test possible military operational scenarios within the workshops mentioned above. These scenarios will consider different combinations of iMUGS with manned vehicles and with soldiers. As a side effect, the opportunities for the virtual simulation as a training equipment for iMUGS will also 53 Grant Agreement number: EDIDP-MUGS-2019-002-iMUGS ANNEX 1 be visible within this project. Deliver operator-centric and efficient design as well as production of the individual components and the whole System. 54 Grant Agreement number: EDIDP-MUGS-2019-002-iMUGS ANNEX 1 6.1.2.2. Overall concept of iMUGS As shown in enclosed figure, iMUGS aims to develop a modular, standardized and open system architecture for unmanned ground and aerial platforms; the subsystems described above will be integrated in a modular way in this architecture. This architecture will enable the development of systems composed of different manned and unmanned ground and aerial platforms with high autonomy capabilities, swarming ability and sensors, payloads and intelligent functionalities and assets, all connected through a secured and resilient architecture to a communication network and to a C2, interoperable with external C4I systems and joint ISR databases. For the purpose of demonstrating the project at the end, the prototype of the system and the demonstrations of it will be based on one specific UGV (MILREM THeMIS) and a specific list of payloads that are described in the implementation part. The iMUGS system architecture is depicted in figure below and described in detail in section 6.1.2.1 [Open, modular, technology agnostic architecture (SP1 System’s Integration)]. The architecture allows efficient deployment of unmanned ground and aerial vehicles to be operated in parallel with manned platforms in various combat situations and tasks supporting the operation. The iMUGS system is highly modular and interoperable with other land, - sea- and air-based systems (manned or not) to provide the users the flexibility of mission configuration, timely and safe availability of situational information and capabilities of system control. Hence, we are specifying the core architecture and allowing a wide variety of payloads to be configured in a cyber-secure manner with the system to achieve mission objectives. These payloads range from a simple specific sensor to a full-fledged integration with another type of asset to enable teaming and information analysis, -distribution etc. In the context of iMUGS we foresee the integration of payloads into the system to be flexible and cost efficient– so that new types or significantly improved missions/capability are available to the users of the technology. As today the state-of-the-art technology portfolio of iMUGS components contains items sourced or of which development relies on technology from outside of EU. The project clearly identifies the components and technologies with existing or potential non-dependence issues and proposes either alternative non-dependent EU sources/technologies or formulates a suggestion for achievement of (at- least) non-dependence to be utilized in an EU-wide measure such as the European Non-Dependence Process or similar. Figure: iMUGS overall architecture 55 Grant Agreement number: EDIDP-MUGS-2019-002-iMUGS ANNEX 1 6.1.2.3. Added value of the expected outcome iMUGS paves the way towards manned-unmanned collaboration in the context of next generation ground capabilities, it will open a new era of use of UGS and related technologies in the operations, particularly advanced autonomous functionalities, and in-between will provide the credible basis to progressively introduce it in operational capacities. iMUGS will contribute significantly to the development of credible operational solutions to armed forces in the medium term, based on leading edge competencies established in the EU, while engaging in a constructive dialog with its end-users. The project will consequently provide a very significant breakthrough potential both in technological and operational terms. iMUGS project will improve several key technologies up to TRL 7 as listed in 22 the following table . Table 2: iMUGS TRL progress End of the Project items/components Initial project SP1.Integration Fast deployment for unmanned aerial and ground systems TRL 4 TRL 7 Secured sensor and payload gateway TRL 3 TRL 7 SP2.Autonomy Fratricide avoidance and safety TRL 3 TRL 5 Autonomous functions for off-road operations and tasks:  Way point navigation TRL 4 TRL 7  Follow me for pedestrian and vehicle TRL 4 TRL 7  Obstacle avoidance TRL 4 TRL 6  Shuttle service TRL 4 TRL 7 Mission planning:  Path planning TRL 4 TRL 7  Multi horizon task solver TRL 3 TRL 6  Autonomous patrolling TRL 2 TRL 5  Autonomous surveillance TRL 2 TRL 5  Autonomous reconnaissance TRL 2 TRL 5 SP3.Cyber Cyber Defence System (CDS) Detection Subsystem TRL 2 TRL 6 CDS Response Controller TRL 0 TRL 7 SP4.Communication Integrated communications solution for voice and data, operators and TRL 4 TRL 6 equipment including vehicle to vehicle communications SP5.Swarming Local Swarming behaviour TRL 1 TRL 4 Global Swarming Behaviour TRL 2 TRL 5 SP6.C2 Secured and standardized approach for interoperability TRL 3 TRL 6 Certifiable Mission Control Station TRL 3 TRL 5 SP7.MUM-T Simulation of iMUGS TRL 1 TRL 5 Deployment of iMUGS TRL 2 TRL 6 22 Horizon 2020 technology readiness levels issued for the work programme 2014-2015 https://ec.europa.eu/research/participants/data/ref/h2020/wp/2014_2015/annexes/h2020-wp1415-annex-g-trl_en.pdf 56 Grant Agreement number: EDIDP-MUGS-2019-002-iMUGS ANNEX 1 The development of operational concepts (SP7) and the testing of the iMUGS in demonstrations (WP5), the project will provide input for the European Defence Forces’ operational assessment and concept definition. Milrem robotics THeMIS platform (https://milremrobotics.com/defence/) – a medium weigh class UGV - will be used for demonstrations and development on concepts for teaming with dismounted troops. THeMIS mobility platform is tracked hybrid mobility platform vehicle with sufficient payload capacity, pulling force and top speed. In addition, the iMUGS project will have a strong impact on future defence systems. 6.1.3. CONTRIBUTION TO INCREASING EFFICIENCY ACROSS THE LIFE CYCLE iMUGS will also contribute to efficiency with its use of modular and integrated design approach, in both vehicles, payloads and C2 software, which in turn will enable existing capital investments to be reused and to remain up to date with modular changes. Reuse of mass-produced base platforms with reconfigurable payloads in many roles will provide benefits of economies of scale in acquisition. In addition, continuous constrictive dialogue with the end-users will deliver operator-centric and efficient design as well as production of the individual components and the whole System. 6.1.4. QUALITY OF IMPLEMENTATION, ORGANISATION AND RESOURCES 6.1.4.1. Quality and effectiveness of the work plan – Work packages, deliverables and milestones Methodology i Figure: CD&E lifecycle iMUGS project methodology is based on an CD&E agile concept with demonstrations, lifecycle through the following items: a. Operational concepts: requirements and military scenarios are captured through high level simulation with the participation of end-users; b. Iterative V-cycle development covering system requirement increments as well as iterative design cycles (using Model Based system engineering); c. Experimentation through technical simulations and demonstrations. 57 Grant Agreement number: EDIDP-MUGS-2019-002-iMUGS ANNEX 1 It ensures the participation and contribution of end-users on an iterative way all along the project through the first phase (operational concepts: requirements and military scenarios capture involve end- users) and the last phase of the CD&E methodology (test and demonstrations: field tests will be performed together with end-users and results of end-users evaluations will be used to close the loop of the methodology back to operational concepts phase). a. Operational concepts through high level simulation The constructive simulation will use MASA SWORD, a (NATO) HLA certified tool, which is a complete wargame solution with automated forces for high-level training and analysis. For example, with the help of MASA SWORD armies prepare their operational engagements and use it also for direct support during operations. The virtual simulation of KMW is used for all kinds of training, starting with driving and shooting simulators up to high-end combat simulators. Armed forces around the world use these simulators to educate and train their soldiers and will be used within iMUGS to build operational scenarios with end-users. This will ensure the operational scenarios will be defined close to the needs and conditions of the later engagements. b. Iterative V-cycle development The project will be developed through an agile incremental development process with multiple deliveries – this implies a rapid system requirements model development from mission requirements and operational scenarios. Respective interfaces between subsystems/modules will be specified early in the project. Adherence to military NATO STANAGs will be pursued, NATO Architecture Framework v4 is used for architecture representation and communication. To achieve rapid integration cycles a geographically distributed bench model (connected through secured network) will be established. This will enable test driven development approach to be fully utilised as newly developed functionality will be integrated to the bench model for early verification and testing (running automated tests at the subsystem and system level). This will include the Figure: Iterative V-cycle with multiple deliverables 58 Grant Agreement number: EDIDP-MUGS-2019-002-iMUGS ANNEX 1 integration of simulation environments. Testing and verification will follow as the components are prototyped. Available hardware and software functionality will be integrated into the system and functionality verified (accepted) before commencing with demonstrations (formalized with pre- and post-demonstration reviews). This will make up a Continuous Delivery pipeline to feed the demonstration events with increasing verified functional capabilities. Within the development cycle, Model Based Systems Engineering and Task tracking software solutions will be used to track project work and make a model of the system available for all project partners. c. Experimentations through simulation and demonstrations Low level simulation (technical level for autonomous functions and swarming functions) iMUGS development is based on the use of simulation within the development of some functions like autonomy and swarming. Autonomy functions will be implemented first in simulated environment based on hardware in the loop simulator, in order to ensure proper integration but also to test autonomy algorithms before implementation (to increase efficiency of the implementation as well as to increase security during tests and demonstrations). Also swarming functions will be first implemented and tested through a simulator environment. Demonstrations & engagement To showcase the capabilities of the system, an operator-centric functionality demonstration approach is taken where we plan to have demonstrations (in different climatic and seasonal conditions, in several countries) based on the functionalities available at that point in time. 6 demonstrations are scheduled within the project, in line with the iterative methodology in place in the iMUGS project. Each demonstration will receive its own scenario, where the core functionality and payloads fitting into that scenario are demonstrated (on the field or hangar demonstrations) – operated by the end-user where applicable (for higher TRL functionality and possibly taking part to a military exercise for example). Five main scenarios would list as: autonomous Intelligence, Surveillance, Target Acquisition, & Reconnaissance (ISTAR) missions, force protection, logistics activities, Medical Evacuation (MEDEVAC) and Area patrolling. Demonstration locations are chosen to cover several climatic and seasonal conditions. Demonstrations are built upon an operator-centric functionality exposure giving an overview and first- hand experience on how operators and commanders are able to exploit the system capabilities – gradually extending the capability spectrum as functionality is being delivered by consortium members. Demonstration 1, Estonia, M6 Operator control scope: Line of Sight Missions planning: ISR, Forward Operating Base (FOB) logistics’ scenarios (Line of sight control)  Logistics’ mule at the base  Deployment with an Armoured Personnel Carrier (APC) and return to base – Maintenance + Cyber: logfile analysis Missions:  Tethered UAV ISR  Secure communications for unmanned and manned missions based on a tactical mesh network including radio relay / multi-hop scenarios  Providing power to troops.  Beacon based follow-me pedestrian and/or vehicle – simplistic approach march and preparation for Shuttle service Demonstration 2, Latvia, M11 Operator control scope: Line of Sight and Beyond Visual Line of Sight Missions planning: SIGINT, aggressive fire detection and alternative networks:  iMUGS systems integration with BMS (Viedsargs)  Troop and UGV use of tactical Long-Term Evolution (LTE) mobile communications networks 59 Grant Agreement number: EDIDP-MUGS-2019-002-iMUGS ANNEX 1  Performing Signal Intelligence (SIGINT) (communications and electronic intelligence) mission: SIGINT solution Skudra capabilities  Performing aggressive fire detection and source recognition with an ISR system (ISOA)  Performing Close-in jamming (approach march) Demonstration 3, Belgium, M14 Environment: Coastal Operator control scope: Beyond Visual Line of Sight Missions planning: Area patrol, ISR mission, ISR mission kit integration procedures:  Performing area patrol mission (inc. swarming – i.e. more than one UGV)  Performing BVLOS reconnaissance mission (silent mode). Demonstration 4, TBD, M18 Operator Control scope: Beyond Visual Line of Sight – standalone C2 Mission planning: Area exploration, MEDEVAC, Cyber hostile environment, EW  Detecting Cyber-attack detection  Standalone C2 control station: functionality demonstration (Single, multiple UGV control, Tethered UAV integration)  Performing MEDEVAC mission  Advanced tactical mesh communications with optimized network functionality and integrated EW functionality (e.g. detection and localization of jamming)  Performing Area exploration Demonstration 5, Germany, M22 Operator control scope: BVLOS – mobile C2 Mission planning: Force protection, ISR (feed to joint intelligence surveillance reconnaissance database) Servicing and mission configurations: Supply chain security design; compromised software injection, detection and reaction.  Deployment with APC  Performing force protection missions (ballistic protection, area exploration)  Follow me pedestrian and aggressive fire detection during an approach march  Collective resupply and MEDEVAC to/from front line  Performing an ISR mission with waypoint navigation and geo-localisation in with EW hostile environment elements (GNSS-denied, occasional jamming and occasional radio silence,).  Teaming with multirotor UAV (including reconditioning and storage)  C2: Multiple UGV, UAV display (health and usage full monitoring system, inc. cyber and autonomy flags), display of payload information/control Demonstration 6, Germany, M24 Full system and capability demonstration – end-to-end demonstrations: all missions re-run, mixed control scope (handover from Control Station to LOS control, etc, maintenance of a dynamic relay network, enhanced V2V functionality) Engagement Event, Belgium, M29 The engagement event is held at the end of the project to expose the outcomes of the development and is foreseen to be held close or integrated to a conference or other EU-level event in Brussels. The events would also serve as opportunity for discussions on future developments and relevant aspects (such as ethics and technology non-dependence) with stakeholders and policymakers. Invited parties include the European Commission, European Defence Agency, NATO Science and Technology Organisation, etc. 60 Grant Agreement number: EDIDP-MUGS-2019-002-iMUGS ANNEX 1 Overall structure of the project As iMUGS project is a significant project in terms of budget and in terms of participants, organisation is key to secure proper implementation of it. In order to ensure iMUGS quality of implementation, iMUGS will be structured into two axes:  Sub project axis (horizontal axes on following figure, ensuring coherence of the development of each subsystem of the project above the different activities)  Work package axis (vertical axis on figure ensuring coherence within each activity to report to EU). These two axes will form the organisation matrix of the project with main axis based on SP management. As described above, main management project axis of iMUGS is based on “Subprojects” (SP), which will constitute the global architecture of the project:  SP1 System integration will provide the overall system engineering and system architecture development, reference UGV platforms (MILREM THeMIS) and will integrate the developed technologies to a system demonstrator,  SP2 Autonomous functions will establish the framework (including sensors and software) and functionalities for navigational and mission autonomy,  SP3 Cybersecurity will deliver analysis, design and reference implementation of a Cyber secure system design, secure supply chain and Cyber Defence System on a UGV system,  SP4 Communications equipment and networks will provide an interoperable (tactical and commercial networks), EW resilient communications solution (hardware and software),  SP5 Swarming will deliver global and local swarming technologies for collaborative robotic behaviour and rapid rescheduling and re-tasking of agents.  SP6 Command, Control and Interoperability will develop a C2 control station airworthiness certifiable for expansion and has tactical component that interoperable with C4I and Joint Intelligence, Surveillance and Reconnaissance (JISR) systems.  SP7 Manned-Unmanned Teaming will cater for global operational scenarios for the system capability development. Figure: iMUGS Project workplan 61 Grant Agreement number: EDIDP-MUGS-2019-002-iMUGS ANNEX 1 Each of these SPs will be divided into different tasks per activities (management, studies, design, prototyping, testing) and these tasks report to the corresponding WP:  WP1 Studies  WP2 Design  WP3 Prototyping  WP4 Testing This leads to the following breakdown structure of the project (Figure): Figure: iMUGS Work breakdown structure 62 Grant Agreement number: EDIDP-MUGS-2019-002-iMUGS ANNEX 1 iMUGS Gantt Chart The Master Schedule is as follows. The detailed schedule at SP level is available and will be presented at project kick-off, synchronized to M1. The subtask durations are shown in the work package tables. Figure: iMUGS Gantt chart 63 Grant Agreement number: EDIDP-MUGS-2019-002-iMUGS ANNEX 1 6.1.4.2. Appropriateness of the management structure and procedures, including risk management Management structure and bodies Figure: iMUGS management structure The organisational structure and decision-making mechanisms are established taking into account the scale of the project (medium size consortium, highly collaborative and interrelated SPs and WPs). Organizational structures and decision-making mechanisms are defined in the Consortium Agreement between the beneficiaries. Project and Quality Management have been further developed and described in the respective plans as Attachments 2 and 6 to the Consortium Agreement. Similar roles and responsibilities of the management bodies are described below. Project Coordinator (PC) MILREM (Mr Markku RAUTIO) The project will be managed by a Project Coordinator from MILREM. The PC is the legal entity acting as the intermediary between the Parties and the Funding Authority, the European Commission (EC). The PC is responsible for:  Ensuring the punctual compliance by the partners with their obligations;  Ensuring that all SPs and WPs maintain the overall project vision with a common approach for technical decisions;  Collecting, reviewing and submitting reports and other deliverables (including financial statements and related certification) to the EC;  Preparing meetings (Executive Board, Steering Group), chairing the meetings and monitoring the implementation of the decisions taken;  Ensuring flows of project information and documents between the partners;  Administering the EC financial contribution in accordance with the Grant Agreement Management support team (MST) Project coordinator, administrative support, specific roles The MST provides support for the day-to-day project management activities. The MST personnel will be under the responsibility of the Project Coordinator and support him for the general management of the project and communication with EC. The MST will be in charge of the daily coordination of the project (organisation and minutes of meetings, conference calls…). It will support the coordinator for the risk management, the preparation of periodic and final reports, and the financial management. Besides, MST can comprise in particular the following roles (people in charge to be appointed):  The Project Security Officer will manage the practical aspects related to security, together with the security officers of the partners of the project.  The Data Manager will support the partners for questions related to the protection and collection of data. 64 Grant Agreement number: EDIDP-MUGS-2019-002-iMUGS ANNEX 1  The IPR Manager will be in charge of implementing the IPR policy set forth in the consortium agreement and the grant agreement, and bring support to the partners when it comes to IP  The Ethical and Legal Manager will be in charge of the Ethics Check to verify the implementation of the ethical issues as stated in WP1 description.  Communication Manager will plan, establish and update communication strategy and raise target groups awareness about project results. The Communication manager will be responsible for the implementation and follow-up of communication activities Project Architect MILREM The Project Architect will lead the definition of iMUGS system architecture and subsystems, draft the requirements and system models, coordinate multiple design alternatives together with SP leaders, coordinate trade-off analysis on system budgets, interface with subsystem and payload providers and participating member states project team. Sub Projects Leaders SP1: MILREM, SP2: SAFRAN, SP3: GTCT, SP4: Bittium, SP5: ERM-KMS, SP6: GMV, SP7: KMW SP leaders are responsible for production of SPs deliverables and their submission to the PC; they report on the progress of their SPs and present detailed and updated work plans to contribute to maintenance of the quality assurance plan. They contribute to management decisions within the EB (see below) scope and implement the decisions that impact their respective SPs. SP leaders exercise technical coordination of the project according to the directives of the PC, maintain alignment in time and content between the different tasks, and support the PC with risk assessment. SP leaders will organize specific meetings bringing together partners involved in their SP as often as necessary and at least every 6 months to follow SP progress or discuss any technical issue within their SP. These may be physical meetings or conference calls. SP leader will be responsible for the interrelations between the different tasks of the WPs. They will bring recommendations to the WP coordinators regarding the global management within the WP and work with the WP coordinators to develop the different reports to the EC. WP WP1: MILREM, WP2 KMW WP3: SAFRAN, WP4: NEXTER, WP5 DIEHL coordinators WP coordinators supports the coordination, coherence and good implementation of the project within their respective WP. WP coordinators supports technical coordination of the project according to the directives of the PC, support alignment in time and content between the different activities and support the PC with risk assessment. WP coordinators can organize specific meetings bringing together partners involved in their WP as often as necessary to follow WP progress or discuss any technical issue within their WP. These may be physical meetings or conference calls. Steering Group (SG) PC + 1 representative of all partners The SG is composed of the PC and one representative from each partner. The SG is responsible for the high-level decision making on all issues that can have an impact on the project. The SG takes any major decision affecting the execution of the project, such as a change in the consortium composition, a transfer of resources between partners or between WPs or SPs, or a change in the planning or in the technological choices. Matters within the SG scope of decisions are defined in the CA and include:  Major changes in work, particularly termination, creation, or reallocation of activities;  Amendments of the Consortium Agreement (CA);  Requests for an amendment of the Grant Agreement to the EC;  Actions to be taken in case of default of a project partner or of force majeure events;  Requests to the EC for admission of other partners to the iMUGS project;  Access Rights of the project partners. The SG is the highest level of authority in the project and will meet at the kick-off of the project, M12, M24 and M30, and upon any specific occasion requiring decisions at its level, according to CA. SP leaders and partners PC, SP leaders, WP coordinators, project architect Executive boards (EB) The EBs are composed of the PC, the SP leaders, the WP coordinators, the PA, respectively. 65 Grant Agreement number: EDIDP-MUGS-2019-002-iMUGS ANNEX 1 It acts in the supporting of the consortium, as supervisory for the execution of the project and as internal support by:  Actively managing deliverables in accordance with the schedule and requirements of the Grant Agreement;  Detecting potential issues and deviation from the work plan and identifying, proposing and implement corrective actions;  Deciding upon major changes in SPs if the need to do so arises;  Deciding on specific technical (re)orientations of the project whenever the need arises;  Ensuring the application of standard quality assurance practices and performing risk management;  Managing and controlling the data required and generated by the project;  Securing the appropriate dissemination and exploitation of Project results;  Supporting the PC in preparing meetings with the EC. The EBs will meet face-to-face at least once a year during the project duration. Besides, every 3 months conference calls will be organised to monitor the project progress, to assure the proper execution of the project and proactively identify and address potential problems that could impact key deliverables of the project. Ad hoc meetings of the EB are convened whenever specific issues arise. Every EB meeting will include in its agenda the list of relevant specific topics and conduct a proper review and programme activity status evaluation and take management decisions at the level that does not require approval by all partners. Each SP Leader reports to the PC on the progress of current activities of its SPs. Roles and task for the EB will be further defined at the beginning of the project. Advisory Board (AB) PC, representatives and high-level experts from the end-users, policy advisors, industrial stakeholders, SMEs The AB is composed of the PC and external participants of the project: representatives and high-level experts from the end-users, policy advisors (think tanks, academies, doctrine makers) and industrial stakeholders (including SMEs). The AB is in charge of reviewing the project progress, the operational/use cases choices as well as technical choices, and to provide recommendations. The AB will meet face to face once a year. PC will be in charge of organising the AB with the support of the MST. Although the AB members are not partners of the consortium, they can have access to selected project deliverables after signature of NDAs. It is envisaged that all SP’s can additionally have their own specific AB’s due to the different technological nature of the SP’s and their individual needs for such support. The principles for the AB’s including the composition of the external experts within will be agreed in the Consortium Agreement. Several stakeholders have already expressed their intent to support the project. Board of participating member states Participating project members for the PESCO for Integrated Unmanned Ground System project (UGS) are Germany, France, Spain, Belgium, Finland, Latvia and Estonia (see § 6.6). Bringing together representative of these 7 countries in a board will foster the control of the implementation of the project: fulfilment of the common requirements, insight on the procurement perspectives, development of operational scenarios. The board will be chaired by the project manager appointed by the Member States and meet once a year during the project. Management tools These management bodies will have the following tools at their disposal to insure a smooth and resilient implementation of the project. Consortium Agreement define the roles of each partner, the rules of collaboration among partners (roles, responsibilities and mutual obligations for the project life), IPR protection (see dedicated section), rules for budget re-allocation, etc. Project will ultimately be defined and run in compliance to the Grant and Consortium Agreements. These agreements with the contracting authorities identify and define the plans, processes and deliverables for the project. 66 Grant Agreement number: EDIDP-MUGS-2019-002-iMUGS ANNEX 1 Project Work Plan (Description of Work). This operational document narrowly relies on section 6.1 of this application document; it encompasses the concept, methodology and work organisation (in particular SPs and WPs). Project Quality Assurance Plan define quality assurance and management procedures, templates for the documents, internal review processes to ensure the quality of deliverables and of any other publication, complying with formal requirements established by the Consortium Agreement; A (secured) Documents Repository will be implemented to assist in the management of documents. Meetings will be planned and agreed at the Consortium level (see above EB and SG descriptions). Sub- Project Meetings will be organized by the SP Leaders, according to the needs of each SP. The meetings dates and locations will be selected in order to minimize the number of travels (synchronized meetings); the use of teleconferences will be maximised to limit the use of face-to-face meetings, for cost and environmental stakes. Decision process Occurrence of conflicts will be prevented by strong partner commitments, complementarity of contributions and interests, detailed work plan with accurate task allocation, and an effective internal communication process. As a general rule, all decisions will be taken by consensus at the management level (Tasks, SPs, EB) at which the need for decision arises. Ultimate decision level is the SG. Procedures will be defined in the Consortium Agreement. Project reporting The procedure for the preparation of formal Periodic and Final Reporting will be coordinated by the PC and will be explained to the partners to ensure that the procedure is clear for each partner and respected by them. The procedure is built on the collaboration and collection of the input from each partner orchestrated at different levels: SP leaders will coordinate the reporting for their SP, consolidate and complete the information they collect from partners and send the information per activity to the corresponding WP coordinator. The WP coordinator will send the report to the PC within the planned time schedule. Based on the inputs of the partners, the PC will consolidate and complete the report before submitting to the EC. Continuous monitoring and reporting will also be ensured through key milestones that have already been identified for the project implementation. They will be carefully monitored by the corresponding SP leaders and at project level by the PC. When the date of milestones review is achieved, the results verification will be conducted against set objectives and a short explanation will be issued regarding the milestone’s assessment. If a milestone is delayed or is not achieved, the impact on project and SPs will be assessed and a back-up plan will be proposed by the concerned SP leaders. Reporting will be defined in the Consortium Agreement to be in full compliancy to the Grant Agreement. Details for reporting will be agreed with the EC with the first report. Financial management The coordinator is responsible for the transfer of the EU funding to the partners. The EC’s rules on financial issues, taking into account the specificities of EDIDP, will be presented to the partners by the PC at the Kick-off Meeting. During reporting periods, the Project Coordinator will provide partners with the necessary information so that they could undertake their financial reporting in compliance with the EC rules. The person-month and budget consumption will be followed during each reporting in order to monitor its compliance with the planned amounts in the Grant Agreement. Selected approaches for decision making, management and reporting are according to the EU governance model and the EDIDP guidelines for organizing the project according to different activities performed during the project. Risk management iMUGS risk management will be viewed as a circular process in which risks are identified, analysed, managed and monitored. Risk Management reviews are agile and regular. System level reviews will take place every 6 months, monthly intervals are foreseen at SP level.  Risk identification. During the project implementation, the PC, with the support of the SP leaders, will review the risks at regular intervals to re-state current priorities as project priorities 67 Grant Agreement number: EDIDP-MUGS-2019-002-iMUGS ANNEX 1 may shift over time (deadlines, budget re-forecasts, and performance expectations) and unforeseen difficulties might arise. They will also identify further risks that can occur.  Risk analysis. iMUGS will use estimates of likelihood and impact against the key risks. iMUGS will try to quantify risks wherever possible by using a scoring system to ensure comparison of risks across the different project work-streams.  Risk management. Risk responses in iMUGS will fall under one of the types: a) Avoid the risk: This can be done by avoiding use of technologies where feasible alternatives exist; b) Mitigate the risk: If a risk cannot be avoided, management will try to reduce the risk by making it either less likely or less consequential. This will include the development of contingency plans for those risks which cannot be avoided, c) Accept or retain the risk: For the risks that can’t be 23 mitigated, controlled or avoided, NATO Architecture Framework v4 can be used to convey the system architecture to all stock and stakeholders to provide a uniform, standards based architectural view.  Risk monitoring. iMUGS will run a well-maintained risk register for monitoring risk- management performance. The register defines mitigating actions for each risk, citing who will do what and by when. Risks are reassessed after every 3- or 6-month period or at certain milestones or completion of certain tasks. A sprint cycle is used so that we reassess in sync with some regular management meetings. A risk burndown chart will be used to visualize the residual risk during the course of the project.  Risk Contingency Plans. In order to monitor and minimize iMUGS’ risks, the consortium will prepare a list of risks and propose contingency plans as early as possible. The provided risk table proposes a first analysis of the main risks and the proposed risk mitigation measures. 4 mains categories of risks: Technologies performance; System inability; Users’ acceptance; Legal, regulatory. As iMUGS will not be dependant from another project or program, it will thus not potentially be indirectly impacted by risks encountered in the frameworks of such projects. 6.1.4.3. Complementarity of the participants and consortium Table: iMUGS consortium complementarity table Un-Manned ERM-KMS DotOcean MILREM SAFRAN NEXTER Bittium DIEHL GTCT KMW GMV LMT Insta System’s Architecture X X X X X X X & Integration Autonomy X X X X Cyber X Communication X X Swarming X X X C2 &Interoperability X X MUM-T X X X Management X X X X X iMUGS is built on a close interaction between industries, research & technology organizations, academia and end-users and brings together 13 partners from 7 European countries, ensuring a large coverage and representation of the European Members States in the project. Each participant brings a specific expertise and added value to the consortium, ensuring a large complementarity of consortium partners and the interdisciplinary of the approach. 23 NATO Architecture Framework, Version 4, April 2019 https://www.nato.int/cps/en/natohq/topics_157575.htm? 68 Grant Agreement number: EDIDP-MUGS-2019-002-iMUGS ANNEX 1 1.1 MILREM is a leading developer of unmanned ground systems and experienced integrator of various payloads to unmanned systems. Inhouse capabilities include also autonomy development, particularly with state-of-the-art machine learning. MILREM has an experience as payload integrator and will provide its mid-size unmanned platform for iMUGS demonstrations. MILREM has an experience as manager and coordinator of different consortia performing the projects based on the financial resources made available within different programs. 1.2 SAFRAN has a wide experience in robotics and autonomous systems. Its expertise extends to all the necessary capabilities for developing various autonomous functionalities for unmanned systems as well as to safety and security aspects of ground and aerial systems. 1.3 GTCT has the experience and network for identifying expected future cyber threats, evaluating novel anomaly detection techniques, and in cyber defence system integration. 1.4 Bittium is well established tactical and secure communications technology and solution provider with long experience for software defined radio development, mobile cellular and satellite handsets and base station products. Bittium’s expertise and references comprise also special communication solutions from underground mines to industrial applications. Bittium will provide the multi-channel integrated communication solution suitable for both machine and operator use. 1.5 Insta has a specific experience for developing collaborative operating robots for local swarming environment. 1.6 GMV has the knowhow for securing the interoperation of the supervised unmanned assets with command and control and joint intelligence, surveillance and reconnaissance and also dismounted soldier systems. 1.7 KMW leads the European market for highly protected wheeled and tracked vehicles. More than 50 nations armed forces rely on tactical systems by KMW. KMW has wide-ranging system competence in civil and military simulation, as well as in command and information systems and remote-controlled weapon stations with reconnaissance and observation equipment. 1.8 DIEHL provides expertise for the system safety of the autonomy development. DIEHL has wide experience in the integration of robotic systems and autonomy development for them. 1.9 NEXTER has wide experience in the integration of robotic systems and autonomy development for them. More generally, NEXTER Systems has a wide expertise of defence land systems design and integration, notably around vehicles. 1.10 LMT has established a reputation as the most trusted mobile operator in Latvia. It has specific knowledge to utilize 4G/5G/LTE public networks for military use. 1.11 (Un)Manned is the only European company with experience in developing airworthiness certifiable MALE UAV ground control stations with state-of-the-art user interfaces and has unique know-how in flexible generic (air-land-marine) unmanned vehicle Ground Control Surveilliance (GCS) design. 1.12 ERM-KMS has wide experience in developing and experimenting robotic systems and their single and group behavioural capabilities. 1.13 dotOcean is the leading developer of autonomous and secure interconnected collaborative systems where many devices combine into one or multiple robots or sub-robots based on End-To-End Encryption (E2EE), IIoT and digital twin technologies in global scale. 6.1.4.4. Appropriateness of the allocation of tasks Table: iMUGS, Other direct cost (‘travel’, ‘equipment’, and ‘goods and services’) 1.1/MILREM Cost (€) Justification Travel 338482 Travel cost for the facilitating and participation to the project meetings, milestones, integration activities and testing/demonstrations. Abroad co- operation with other work packages partners and stakeholders. Equipment 599020 Platform HW purchases, simulation and data warehousing computers, Payloads and sensors for integration. EMC and safety testing services. Other goods 507124 Purchases of SW kits and licenses and support for data warehousing and and services diverse mission kit components and development and testing services. Total 1444986 69 Grant Agreement number: EDIDP-MUGS-2019-002-iMUGS ANNEX 1 1.12/ERM- Cost (€) Justification KMS Travel 87360 Travel cost for the participation to the project meetings, milestones, integration activities and testing/demonstrations. Abroad co-operation with other work packages partners. Equipment 88667 Swarming development infrastructure and tools, including Fog Graphics Processor Unit (GPU) server CUDA simulation and development, small mobile robot platforms and payload for testing and validation, mobile computing devices and work-stations for developments and simulation. Other goods - - and services Total 176027 6.2. CONTRIBUTION TO INNOVATION 6.2.1. CONTRIBUTION TO INNOVATION Seven Major Innovative concepts will emanate from iMUGS: Two types of innovations are expected as the outcomes of the project:  Incremental innovations (using existing technologies but in a new environment or usage)  Major or disruptive innovations (providing new technologies) These innovations echo the key objectives of the project as stated in §6.1.1., i.e. operational objectives (OO) and technical objectives (TO). 1. Autonomy backbone: modular, sensor & platform agnostic, able to host an important variety of algorithms coming from different providers for defence uses [ref to to2] Beyond prototyping, no existing robotic kit on the market can be used in a Defence context where safety and integrity levels expectations are high, especially when we target autonomous operation and/or fire support, i.e. weaponized robotics. None of the existing middleware either comply with IEC 61508 norm or allow SIL and non SIL hardware and software components to work together in a same framework. iMUGS project will develop an autonomy framework including a hardware SIL2 or SIL3 platform in order to support an appropriate safety level where necessary and a non SIL hardware with higher computational resources and memory for more complex autonomy functions. The IEC 61058 will be the starting point of iMUGS safety design. The quality plan for implementation will result in the development of SIL algorithms and backbone using Motor Industry Software Reliability Association (MISRA) coding rules and right tooling: static code analysis, unit testing, coverage tests. The certification of the complete iMUGS systems is not the aim of the project and some existing algorithms will not be rewritten to cover SIL execution or will run on non-SIL platform (typically GPU boards). The safety analysis will be enforced to support future developments, thus a major step forward to existing technologies. iMUGS publish subscribe middleware associated with a Data Model will facilitate algorithms integration and ensure the system modularity and scalability. The backbone design is based on a plugin approach, algorithms are included in containers which are hosted and executed by iMUGS backbone. The data Model enables an abstraction of the Sensors data and the platform data, for the autonomy functions. 2. Military operational scenarios taking into account the use of autonomous systems and manned-unmanned teaming [ref to oo2 and to7] At the moment there are a lot of discussions and ideas about what can be done with autonomous and unmanned ground systems in a military context. But there is no common understanding within the participating member states or in the EU about possible ways to deploy these systems, or to engage with such systems, or how military operational scenarios with these systems may look like. Furthermore, there are also reservations and constraints regarding the usage of autonomous and unmanned systems, which have to be considered. 70 Grant Agreement number: EDIDP-MUGS-2019-002-iMUGS ANNEX 1 iMUGS project will develop and define in a first step bases for military operational scenarios together with the representative of the participating member states, taking, where possible, national specifics, wishes or limits into account. Based on this, basic military operational scenarios will then be defined and evaluated with the help of high-end simulation and demonstrations. At the end of this project these scenarios will be the base for the further engagements of unmanned ground systems, alone or together with other manned or unmanned systems, or also with one or more soldiers. 3. Detection and resilience to cyberthreat [ref to oo3 and to3] While there is a lot of research into cyber-attack detection on vehicular platforms, there is currently no market product available to address this threat. Most of the research in this area are focusing on a one- dimensional attack vector or otherwise does not consider the widest scope of potential cyber threats. None of this research has considered the idea of implementing an automated response to detection of attacks. The iMUGS Cyber Defence System (CDS) strives to fill these gaps, acting as an intrusion detection platform capable of monitoring for evidence of a compromise or an attack from cyber, physical exploitation, and electromagnetic threat vectors. In the event of a potential attack, the system will provide an appropriate mitigating response to secure or contain the threat autonomously, ensuring resiliency of the platform while in a military operational environment. 4. A certifiable control station commanding several ugs and uas [ref to to6] iMUGS project aims to develop an UGS Control Station (CS) capable of commanding several UGS types and UAVs from a centralized C2 position, also with UGS autonomy and swarming capabilities, thus maximizing operational efficiency and coordination and minimizing operator workload. Future operations will combine UGS and UAS in support of forces and iMUGS CS innovative approach will enable this kind of joint operations. Taking into account the end-user recommendations, iMUGS CS will be designed to be ready for a future integration of certifiable MALE UAS to the CS, and thus ready by its architecture and design able to meet strict airworthiness certification requirements like DO-178C/ED-12C and able to operate in non-segregated European skies. iMUGS C2 station will be unique in that operational capability. Also, the CS is innovative in being reconfigurable to control any generic unmanned vehicle. A standard based open architecture and reconfigurable ‘vehicle profile’ based CS will allow integration of future unmanned systems (land-air-sea) through software updates only, to rapidly introduce into service new unmanned systems, reduce future acquisition and integration/logistics/support costs for military and allow flexible and innovative approaches for future UGV manufacturers. iMUGS will allow a reconfigurable human interface in both static and NGVA compatible vehicular installations. 5. Learning and planning for autonomous missions with difficult environments and swarming capabilities [ref to oo1, to5, oo5 and oo6] a. Planning and scheduling for autonomous missions within difficult environments Autonomous system architectures are challenging when integrating mobility and mission planning, especially because some mission data (terrain, objectives, available resources) are known offline and others are acquired on-line. Still, some uncertainty remains at execution time. The planning problem involves technical actions (measurements, communications, etc.) and operational actions to realize on some specific 24 terrain areas or along the navigation plan . Actions must be executed according to timing and resources constraints despite situation awareness and objectives updates. In modern autonomous architectures, planning and scheduling is performed on the fly, responding to an operator demand (mission update), terrain obstacles, or using free space discovery. To achieve high operational efficiency, planning and scheduling must be solved just in time when state-of-the-art solvers may involve heavy processing loads. iMUGS innovative approach is to guide the problem solving with machine learning techniques. iMUGS approach combines a Constraint Programming (CP) method with novel machine learning techniques. CP provides a powerful baseline to model and solve combinatorial and constraint satisfaction problems 24 The Ripsaw UGV, https://special-ops.org/11986/ripsaw-ugv/, retrieved 16th May 2019 71 Grant Agreement number: EDIDP-MUGS-2019-002-iMUGS ANNEX 1 25 26 (CSP). This approach has several applications for real-world autonomous system in space , aeronautics 27 and defence . Planning problems are dealing with graphs representing manoeuvres or off-road navigation. Graph convolutional neural networks (GCNNs), a recent variant for learning complex patterns in graph data, will be used to make decisions and to solve planning problems. Using feedback from the neural network, a model-based planner and scheduler can efficiently solve new problem instances. One novel advantage is to accelerate drastically the processing by guiding the search algorithm. Another advantage is to consider problem variables with uncertainties either due to temporal, resources or spatial considerations. Learning from terrain data can be performed offline, such that the knowledge acquired can be used on-line to accelerate the on-board planner. The planning and scheduling are considered at different levels of mission and mobility. On one side, it can deal with coordination and swarming constraints. On the other side, it can deal with short term navigability constraints such as terrain obstacles. iMUGS will provide an adaptive problem scale control to address high level mission goals as well as short terms mission contingencies. b. Local and global swarming experimentation Swarm intelligence is a ground-breaking concept unseen on the battlefield. Demonstrations and applications have been mainly confined to simulation or tightly controlled conditions in the case of physical platforms28 29, especially for ground vehicles. The main challenge today is to create robust and useful controllers for swarms of real robots that need to be safety critical in realistic conditions. iMUGS project aims to work on local and global swarming for practical purposes. Local swarming will be realized using suitable parametrized robot controllers, just as with traditional autonomous systems. Global swarming will be realised using a new approach of exploiting an interacting group of autonomous robots. The first challenge of swarming is to subdivide the problem statement into real-time until non-real- time requirements. Secondly, a hierarchic, type ‘level of detail’ or resolution world model approach, aims to subdivide the problem into parallel datasets that can be outsourced to computational power on each level of the architecture and solutions are progressively refined. Low resolution and hard-real-time problems are solved on the edge, near-real-time solutions using larger sections of available world information are solved on massively parallel computational power available in the fog, other non-real-time calculations are handled in the cloud. The outputs of these development will be used to provide new requirements for supporting solutions and human provided solution fitness. Although the project focuses on ground-based systems, the work and results will provide important insight regarding autonomous air and sea vehicles as well. 6. Network agnostic concept: transparent access to c2 and ugv through communication network [ref to oo4 and to4] Currently, UGS have dedicated communication links devoted to the teleoperation from a Control Station. These communication links are not integrated with other networks, which increases the number of communication equipment and systems required. In addition, information exchange between different systems is not typically supported, which is a major limitation in modern warfare. iMUGS project aims to combine various tactical and commercial communication technologies into a single entity allowing the users (vehicles & troops) to connect easily and transparently to the services through a unique IP network. The same single solution shall support both manned and unmanned operations with ground and aerial vehicles e.g. UAVs, which makes maintenance & support operations easier and enable seamless information exchange between different applications. The use of the communication network in a transparent way will make the UGV and the C2 systems network 25 Roldán Gómez, Juan Jesús (2018). Adaptive and Immersive Interfaces to Improve Situational Awareness in Multi-Robot Missions. Doctoral Thesis, E.T.S.I. Industriales (UPM). https://doi.org/10.20868/UPM.thesis.52353 & George Leu, Jiangjun Tang (2019). Survivable Networks via UAV Swarms Guided by Decentralized Real-Time Evolutionary Computation 26 The MQ-9 Reaper UAV, www.airforce-technology.com/projects/predator-uav/, retrieved 16/05/19 9 27 The Dragon Runner UGV, https://qinetiq-na.com/products/unmanned-systems/dragon-runner/, retrieved 16/05/19 28 L. Bayindir, A review of swarm robotics tasks, Neurocomputing 172, 292-321 (2016) 29 “Gremlins are coming: DARPA enters Phase III of its UAV programme”, by Talal Husseini (July 2018) https://www.army-technology.com/features/gremlins-darpa-uav-programme/, retrieved 16th May 2019 72 Grant Agreement number: EDIDP-MUGS-2019-002-iMUGS ANNEX 1 agnostic. This feature will facilitate the adoption of new communication network technologies by iMUGS components including the vehicle, the payloads and the C2 and end-users. iMUGS Communication Network will be developed with a focus on interoperability and standards, minimizing barriers related with regulation, allowing EU member states or any customer worldwide to integrate directly the solution into their defence systems. The network agnostic concept would enable the application of cutting-edge communication technologies from the civil domain to the military domain in a future. 7. Novel tactical c2isr software to make imugs interoperable with c4isr systems [ref to to6] Current UGV Control Stations are standalone systems not integrated with Tactical C2 Systems nor Joint ISR networks. This limits Tactical Commander from exploiting the full capabilities of UGS in military operations. STANAG 4559 CSD has so far been applied to integrated Medium-Altitude Long- Endurance (MALE) and High-Altitude Long-Endurance (HALE) UAS GCS in JISR networks, it will be quite innovative to apply it to UGS. The iMUGS project aims to develop a Tactical C2ISR software that will be used by the tactical commander for conducting the mission assigned to the dismounted soldiers and UGS and at the same time being interoperable with C2 systems of lateral and higher echelons. The Tactical C2ISR system will provide the commander a complete integrated view of the battlefield including dismounted soldiers and UGS fleet. Within iMUGS project, the focus on the Tactical C2ISR is mainly in the conduct capability of the mission. iMUGS Tactical C2ISR could be extended to provide additional functionality for the planning phase of the mission. The Tactical C2ISR will make iMUGS fully interoperable with JISR networks through a STANAG 4559 Coalition Shared Database, enabling iMUGS C2 to be used by any NATO country. Patenting A patent application process will be introduced based on needs arising during the project. In the defence industry technology is typically classified information. For the same reason, defending a patent may be difficult. However, if there are commercial applications for the solutions developed, IPR protection measures will be applied. 6.2.2. POTENTIAL SPIN-OFFS OF THE TECHNOLOGIES Due to the very demanding requirements of iMUGS and -in particular- the interoperability requirements, the technologies developed within the project have a tangible potential for spin-offs, i.e. to be integrated into other defence systems/capabilities or even into mission critical civil systems. iMUGS Control Station technologies supporting UGS and ready to integrate UAS could be applied to any project where an unmanned system needs to be controlled, remotely or autonomously, with real time safety criticality requirements, in both civil and military applications. A derivative of iMUGS control station, may be used in defence operations or logistics systems using UAS and UGS. Furthermore, the trend in the defence sector for fleet management of unmanned systems (ref. STANAG 4817 currently in development) will be influenced by the iMUGS project (contribution to requirements and best practices), bringing Europe back at the forefront of unmanned systems technologies. On the civilian market, use of unmanned systems in public service for distribution and transportation services and municipal management can be controlled with an iMUGS combined control centre. iMUGS Communications network concept is network agonist and could be used for other defence and civil applications, C4I systems in general, security/safety-critical applications and more specific applications like for example unattended sensor networks. iMUGS Network technologies can also be applied for EU civil-military operations requesting a combination of communication means and/or enhanced security. In addition to network-based approach, the solution also supports local deployment, which allows providing the connectivity and services locally, for example, for rescue missions in rural areas. iMUGS Cyber Defence System (CDS) can be fully commercialised for any ground-based and maritime autonomous military system. 73 Grant Agreement number: EDIDP-MUGS-2019-002-iMUGS ANNEX 1 In addition, part of the technology could be easily adapted to the cyber defence of space systems and other autonomy applications in the civilian sector (e.g. automotive, mining, energy, etc.) Some of the data processing algorithms can be applied to cyber defence of conventional IT systems as well. iMUGS autonomy Framework is designed in a generic way, based on existing standards and fully adaptable with various type of UGVs for a large range of applications (military and civil applications: logistics, transportations or industrial civil applications as mining industry, construction sites...). Also, Autonomy functions can be turned into driving assistance functions for manned platforms (main battle tank, infantry fighting vehicles) by providing either proximal area awareness or by helping the driver in a fine manoeuvre over a short-term horizon. They can also be used to develop an infrastructure protection and inspection system by extending the robotic coordination to infrastructure sensors. Planning and scheduling, but also mobility planning can be extended to include both human and infrastructure sensor activities. iMUGS swarming functions could be used in other defence capabilities in the long run but also for civil applications (maritime, search and rescue, security, logistics for heavy charge, …). Robots swarming is an emerging domain that raises a large panel of activities as it is expending the capability of a unique robot. 6.2.3. CONTRIBUTION TO INCREASING EFFICIENCY ACROSS THE LIFE CYCLE iMUGS will contribute to a common ground for technology development among European Industry. Within iMUGS, new combinations of technologies and systems, and their utilisation doctrines will be implemented, tested and assessed. The concept (see §7.1.2.2) fosters by essence the efficiency across the lifecycle. The project will enable a variety of new ways of utilizing UGVs supporting future innovations. The Autonomy Framework will be based on existing standards be fully adaptable with various type of UGVs. Works on MUM-T will provide an outlook of future developments within a kind of roadmap indicating the main interests at the moment and what might be helpful and necessary for future innovations. The integrated and secure communications combining commercial technologies together with tactical communications solutions in the same network will ease future uses of the C2 system by enhancing scalability and flexibility. In addition, the communication solution can be deployed in multiple applications minimizing the need for multiple dedicated non-interoperable systems and equipment. Moreover, the UGS Command Post is fully interoperable with recognized standards for C2 systems and JISR networks to facilitates its integration It will greatly reduce the initial investment cost as well as the maintenance cost as there is no need for separate systems for each actual and future application. The deployment of SDR technology will allow continuous development and system level maintenance throughout the entire life cycle of the product to keep the system up to date with the evolving warfare and operations. The cyber defence system implements graceful degradation which allows the system to continue operations in a degraded state and prevents complete mission failure or disruption of operations. This will allow greater efficiency for the duration of system life for operations in the presence of attackers compromising portions of the system or even noncritical systems. 6.3. Contribution to the competitiveness and growth of defence undertakings in the Union 6.3.1. Contribution to the competitiveness and growth Before developing the contribution of the iMUGS’ outcomes to competitiveness and growth, it is worth displaying the consortium’s vision on the midterm roadmap. This roadmap is coherent with the targeted TRL landscape (§6.1.2.3) at the end of the project and the consortium, which masters all the dimensions of UGS systems, prefigures a future European added-value chain and industrial sector. The contribution of iMUGS to competitiveness of the EDTIB relies on 4 key outcomes of the project:  A standardized architecture  Enabling integration to unmanned ground platforms and adaptation to current manned vehicles  Standardized interfaces between systems and features  Scalability and modularity  Development and use of European based technologies 74 Grant Agreement number: EDIDP-MUGS-2019-002-iMUGS ANNEX 1 Figure: iMUGS and beyond roadmap In turn, these 4 outcomes will foster the admission of newcomers – particularly SMEs – into the defence ecosystem, thus enhancing competition and innovation throughout the entire value chain. This consortium mastering all the critical dimensions of UGS prefigures a future European added-value chain and industrial sector. Competitiveness and growth thanks to standardization (architecture, interfaces) Many international surveys show the contribution of standards to the competitiveness of undertakings and thus to their sustainability, turnover, job creation, etc. Among others, a survey by the ISO (Economic benefits of standards, 2014) highlighted three compelling findings which are totally relevant in the iMUGS context: 1. Streamlining internal operations: this first key benefit impacts more the cost competitiveness of the players concerned Figure: iMUGS component and providers 2. Innovating and scaling up operations: this key benefit will pave the way to fill the innovation and technology gap between the EDTIB and its US and Chinese counterparts 3. Creating and entering new markets: this key benefit will impact all the players of the value chain sketched above, i.e. many players of the EDTIB Competitiveness and growth thanks to scalability and modularity Scalability and modularity of defence systems will be leveraged by the solutions developed in the frame of iMUGS. The industrial adopters of these solutions will gain competitiveness on the international markets (tenders, Request for Information (RFI), Request for Proposals (RFP)…) for 2 reasons:  modularity and scalability are of high value to the end users, including national defence procurement authorities which anticipate streamlined procurement processes  this valuable feature is obtained without additional costs; in the contrary, the costs remain under control thanks to the standardisation mentioned above 6.3.2. Market opportunities 75 Grant Agreement number: EDIDP-MUGS-2019-002-iMUGS ANNEX 1 The robotic and UAV market in 2018 is 30 valued at $116 bn by HIS market and is expected to reach $210 bn in 2022 for a CAGR of 20%. The sub-market of UGV is valued $2.35bn in 2018 and will have a CAGR of 15% for the forecast period. 31 The International Federation of Robotics estimated the defence robot market value at $902 m in 2017 and will continue to become a well- established technology as more and more units are sold. Moreover, 1,300 UGVs have been installed worldwide in 2017 representing an increase of 33% Figure 4: UGV 10-year sales forecast (2017- compared to 2016. The possibilities of companies 26) by supplier (Source HIS market) from the EU, to become a part of the market outside the EU, depend strongly on international cooperation on an industrial and political level. As shown on the following figure, about 75% of the market share are not identified in terms of suppliers. The addressable markets that have currently been identified within the European Union are as follows: Netherlands, Norway, Germany, United Kingdom, France, Poland, Spain, Italy, Czech Republic, Finland, Sweden, Denmark, Greece. The total addressable market in these countries is a total of €722.2M. Figure 5: UGV 10-year total sale forecast by end-user country in USD m (Source HIS market 2017) Defence robots aim to enhance armies’ capabilities while protecting soldiers or replacing them on dangerous operations. Autonomous vehicles will slowly take over the battlefield and UGS will contribute to 32 military superiority by giving troops an advantage at the ground level. Autonomy of UGV is today still limited to simple functions. But UGS market opportunities will increase with new development alloying new and efficient uses (swarming, etc.) and a growing understanding of these systems. Based on this, also the market opportunities for the manned platforms for the control of the iMUGS and the vehicles and systems to engage together with iMUGS will increase. In Europe,  the French army is looking forward to use UGVs for the future battlefield with its Scorpion programme with a planned procurement of around 100 vehicles.  At short term (end of 2020) France will deploy Mule UGVs in external operations.  At long term (operational in 2035) Germany and France plan to have built Mobile Ground Control Station (MGCS) that will include manned and unmanned vehicles operated in teaming conditions.  In March 2019, Poland revealed its new Tank Destroyer Programme, where UGS´s can also take part in. 30 “Follow the leader: US Army unmanned ground vehicle programmes”, JANE’s by HIS market, https://www.janes.com/images/assets/925/87925/Follow_the_leader_US_Army_unmanned_ground_vehicle_programmes.pdf 31 Executive Summary World Robotics 2018 Service Robots (2019), https://ifr.org/downloads/press2018/Executive_Summary_WR_Service_Robots_2018.pdf 32 “Remote defence: ground systems: Paving the way for autonomy in land systems”, EDA, https://eda.europa.eu/webzine/issue16/cover-story/paving-the-way-for-autonomy-in-land-systems 76 Grant Agreement number: EDIDP-MUGS-2019-002-iMUGS ANNEX 1  The United Kingdom has also announced the Platoon Robotics programme planning to expand robotics to platoon sized units within their military.  The Netherlands also has a Robotics and Autonomous Systems (RAS) Unit within the 13th Light Brigade of the Royal Netherlands Army. The main emphasis of these programmes is on supply, logistics and Casualty Evacuation (CASEVAC) support operations that can be conducted via UGVs providing more safety for the human operator. The aforementioned armed forces are testing the vehicles alongside existing force structures and in addition developing doctrines involving robotics in swarm configurations and in solo operations. Outside the union,  the United States has the agenda to comprehensively integrate robotic systems into every branch of 33 its Armed Forces by 2025 .  The Russian Federation also has multiple Unmanned Ground Systems for military application, such 34 as the Uran-9, which has been deployed to combat operations in Syria .  High-level support and generous funding for robotics and unmanned systems R&D have created a myriad of research institutes within China’s defense industry and numerous universities, both civilian and military. Rapid deployments of increasingly capable systems present challenges to U.S. military forces operating in the Asia-Pacific region, particularly as U.S. defence planners implement 35 the Third Offset strategy. Inside and outside the EU, UGVs are now mainly used for trials and tests. Military engagements of UGVs, independently if these engagements are for training purposes or if these are real military engagements, the number will be not of significance in the next future. The producers of the most prominent UGVs for both the military and commercial market within the European Union fall in to small and mid-sized categories: MILREM THeMIS, DOK-ING MV-4, Shark Robotics Colossus. Foreign markets are also very proactive in the development of Unmanned Ground Systems, the most prominent of these are: Rheinmetall (Canada) Mission Master, Howe&Howe Thremite, HDT Hunter WOLF, Polaris MRZR X and the Lockheed Martin 36 Fire-Ox. In July 2019, ST Engineering presented an unmanned teaming (UGS) between an autonomous Next generation Armoured Fighting Vehicle (HGAFV), a Probot UGV and a UAV. The same year, 37 Rheinmetall Defence presented a demonstrator of its Mission Master UGV for surveillance, protection, etc. uses. ECA Group manufactures a Multi-missions UGV for Inspection, IEDD/EOD and CBRN and Leonardo sells its TRP-2 Combat a small, light, tracked UGV platform for use in tactical situations where the human presence is not advisable. MILREM has developed several UGVs as the THeMIS (Tracked Hybrid Modular Infantry System) a multi-mission UGV with the Estonian Ministry of Defence support or 38 the Titan Unmanned Ground Vehicle (UGV) in collaboration with QinetiQ North America. MILREM Robotics is also collaborating with ST Engineering since 2017 to increase the ability of the THeMIS to 39 operate under beyond-visual-line-of-sight (BVLOS) conditions . A live fire exercise was performed in 2019. 33 “ARMY POISED TO TRANSFORM GROUND ROBOTICS INDUSTRY”, DEFENSE NEWS BY JEN JUDSON , APRIL 2017, HTTPS://WWW.DEFENSENEWS.COM/SMR/UNMANNED-UNLEASHED/2017/04/12/ARMY- POISED-TO-TRANSFORM-GROUND-ROBOTICS-INDUSTRY/ 34 Russia confirms its armed robot tank was in Syria, c4isrnet, by Kelsey D. Atherton, May 2018,, https://www.c4isrnet.com/unmanned/2018/05/07/russia-confirms-its-armed-robot-tank-was-in-syria 35 „China’s Industrial and Military Robotics Development”, U.S-China economic & security review commission, 2016 https://www.uscc.gov/sites/default/files/Research/DGI_China's%20Industrial%20and%20Military%20Robotics%20Develop ment.pdf 36 “ST Engineering shows off unmanned teaming with NGAFV”, Shephard Media, July 2019 https://www.shephardmedia.com/news/uv-online/st-engineering-shows-unmanned-teaming- ngafv/?dm_i=4GWN,MFOK,2FZCP7,2MVCV,1 37 Rheinmetall-defence website, “Rheinmetall Mission Master – The ultimate Unmanned Ground Vehicle” https://www.rheinmetall-defence.com/en/rheinmetall_defence/systems_and_products/unbemannte_fahrzeuge/index.php 38 Army-technology website, Titan Unmanned Ground Vehicle (UGV) https://www.army-technology.com/projects/titan-unmanned-ground-vehicle-ugv/ 39 Army technology, „Milrem and ST Engineering demonstrate BVLOS armed combat UGV“, May 2019 https://www.army-technology.com/news/MILREM-armed-combat-ugv/ 77 Grant Agreement number: EDIDP-MUGS-2019-002-iMUGS ANNEX 1 6.3.3. Contribution to increasing efficiency across the life cycle The outcomes of iMUGS will support future military developments, collaborations and more effective cooperation between Member States armed forces on the battlefield. iMUGS Control Station could be potentially used with any UXS system with safety and certification requirements, as is expected for a broad spectrum of UXS Defence applications, and also for dual use systems. iMUGS Tactical C2ISR and Autonomy Framework could be potentially used by any EU MS. Tactical C2ISR use prevalent interoperability standards and could be integrated with the EU MS Computer Information systems (CIS). iMUGS Autonomy Framework could be potentially used as technological basis to any UGV within industry domain (demining, construction, logistic in severe environment). Proposed as technological bricks, it will facilitate future cooperation ground vehicle systems project by providing a modular solution enabling a variety of new ways of utilizing UGVs. In general, standard interfaces based (S-DDS) open architecture implementation will allow reconfigurability and adaptability in both UGV vehicles and command/control infrastructure. Modular approach in design and software architecture will allow use of large-scale production in vehicle and CS units for cost reduction and to serve many niche functions with change of payload of software, some future functions which may not be foreseen today. Modular approach will also serve national needs and local payloads and software to be integrated into a cost-effective base platform. Flexibility in use will allow base units to serve many functions through its economic service life. The deployment of SDR-technology will make it possible to continuously develop and maintain the system throughout the entire life cycle. Communications: The deployment of SDR-technology will make it possible to continuously develop and maintain the system throughout the entire lifecycle. In addition, the same equipment can be used for several applications - voice or data, manned or unmanned, vehicles, troops etc. This is a major advantage and it reduces the maintenance cost over the lifecycle of the system. A common integrated control station will allow future unmanned systems integration into an existing CS structure by only updating software. Standardisation will directly improve acquisition, introduction to service and maintenance costs, incl. military operator training costs but also simplify future unmanned systems designs. The effort spent in proprietary and non-interoperable CS developments can be spared or directed to innovative UGV vehicle functionalities in future systems. 6.4. Contribution to the industrial autonomy of the European defence industry and to the security and defence interests of the union 6.4.1. Contribution to the industrial autonomy of the European defence industry and defence interests of the union Today, for the development of unmanned systems, whether they are autonomous or man-cooperative, European defence industry depends on third countries, which creates vulnerabilities at the geopolitical level (ITAR regulations…) and tactical level (potential trapdoors in software or operating systems):  Autonomy. EU and China have a good advance in the frame of autonomy capabilities for vehicles (civil or military); most available computers and tools for such applications are US or China based. An EU-sourced Autonomy Framework and Autonomy capability know-how is crucial regarding the future battlefield. iMUGS autonomy framework will be fully based on SW items (algorithms, simulation tools, data warehouse, Middleware and autonomy common services) developed within EU. The goal to get a fully European based autonomy framework (including HW items) will be reached in a future step of the project through the implementation of Kalray processing capabilities.  Communications. The deployment of European SDR waveforms will support both interoperability and joint operations between the member states as well as reduces the dependence to non-EU sources.  Cyber security. Securing autonomous systems is a critical capability for defence but also civil applications. Most secure processing platforms available today are not from the EU. An EU-sourced secure hardware platform and OS for cyber defence would ensure that systems built in Europe are more resilient to cyber-attacks (non-EU system could include trapdoors).  Swarming. An internal capability and know-how for swarming is crucial regarding the future battlefield. With ever increasing and faster access to data impossible to grasp by humans, automated methods to optimally use and exploit available data real-time, to make rational and optimal decisions, will become a key technology to the European defence in general. 78 Grant Agreement number: EDIDP-MUGS-2019-002-iMUGS ANNEX 1  C2. The availability of interoperability standards for unmanned systems that can be used without restrictions by EU countries, is key for the development of European C2 and C4I solutions integrating unmanned systems in the operations. iMUGS will use existing and in development standards and foster the development of emerging standards for UGVs C2.  Availability of electronic components. Most hardware comes from outside EU. iMUGS will not make Europe fully non-dependent but will limit their number and impact on design criticality. A preliminary EU critical technologies analysis has been undertaken in order to maximize iMUGS impact. Stating European non-dependency means that all fundamental aspects are covered by EU solutions. In the scope of Ground systems, iMUGS has identified key technologies (table below), where solutions availability is limited or absent at EU level. This is precisely one of the features of iMUGS to address all these aspects as shown in the table below. Table 3: iMUGS critical mapping table Technological Addres- Avai- Research sed in Impact lability Domains iMUGS Subsystem level Artificial New AI solutions specific to ground vehicles Intelligence Swarming Advancement of local and global swarming technologies Cyber security Novel systematic approach to cyber threat analysis and development of novel Cyber Defence Systems Manned New operational scenarios for the use of autonomous Unmanned unmanned systems Teaming Communication Advancement of network-centric architecture and unified network solution Command and Development of control system for simultaneous control of a Control heterogenous fleet of multi domain UxS (land-air-sea). Including innovative and flexible human factors design. Development of an interoperable C2 system. System level Standardisation Advancement of UGV system of systems architecture Integration Rapid integration of heterogenous technologies for multi- mission capable system; enhanced system level validation Legend: Availability: Green = Sources in EU; Yellow = Non-satisfactory performances in EU; Red = No EU existing source. Technology assessment is fully (green) or partially (yellow) addressed for most critical technologies. 79 Grant Agreement number: EDIDP-MUGS-2019-002-iMUGS ANNEX 1 6.4.2. Contribution to the security and defence interests of the Union iMUGS corresponds to the Capability Development Plan through the following aspects: Information superiority. The extensive data collecting performed by iMUGS will contribute to achieve battlefield information superiority, being fully interoperable with ISR networks. In particular:  The C2 solution will provide a tactical CIS combining different technologies into a single entity allowing the users to connect transparently and easily to the services through a unique IP network. The solution will also include a routine to ensure a quick and safe communication. Uses of recognized standards for C2 systems and JISR networks will increase the solution interoperability and integration into the MS armies’ systems.  The communication solution will use a highly flexible hybrid solution for radio communications, mapped to armed forces’ ability to use Radio Spectrum (RS) for military activities.  Autonomy sensors and perception algorithms will extend situational combat zone awareness. Ground combat capabilities. The project will have a positive impact on capacity preparations, protection, deployment and sustainability.  iMUGS is focusing on future use of unmanned and autonomous systems to accomplish missions with the least possible risk to soldiers. The use of autonomous robots will limit friendly soldier exposure, increasing force protection, facilitate permanent observation and the deployment of various sensors without endangering soldiers and increasing their workload.  The project will also contribute to swarming and manned-unmanned teaming future developments to face potential technically advanced adversaries. Enhanced logistics and medical supporting capabilities. The innovative and resilient architecture resulting from the project will contribute to improved logistic capabilities such as resupply and medical evacuation, including UAVs and UGVs.  The development of autonomous mobility software and intuitive manned-unmanned teaming solutions will alleviate soldier workload and simplify operation control by using the platform for carrying unit equipment during long dismounted tactical movements.  The interoperable C2 solution will speed up deployment by moving the platform quickly and affordably to the battlefield by using the pre-existing logistics systems.  The autonomous functions will help in collecting soldiers for rescue missions without exposing other soldiers or by limiting the number of soldiers necessary for the rescue mission. same point for logistic capabilities. Enabling capabilities for cyber resilient operations. The innovative solution for securing the platform from cyber threats will ensure continued, reliable and safe operation of highly advanced UGVs.  The holistic approach to detect cyber, electromagnetic and physical exploitation threats considers all angles from which an attack can originate.  Providing the ability to autonomously respond to threats enhances resilience during military operations.  Use of risk assessments for the supply chain and for the design of the subsystems helps identify and mitigate risks. Cross-domain capabilities. The project addresses the real and existing need for EU to develop capability and know-how in the area of autonomous unmanned vehicles on the battlefield by merging defence and civil EU expertise. It builds cross-domain capabilities contributing to achieving EU’s ambition through:  Autonomous and automated guidance, navigation and control (GNC).  Decision-making techniques: Extensively applying artificial intelligence to UGV, developing efficient multi-robot control through swarm intelligence. During iMUGS project, future technology development will be anticipated and some solutions to support them will be proposed as vehicle to vehicle communication to support swarming and MUMT implementations. 80 Grant Agreement number: EDIDP-MUGS-2019-002-iMUGS ANNEX 1 The development of unmanned systems is a R&T priority worldwide, both in the civil and the military domains, and a large proportion of unmanned systems critical technologies are shared among both domains. The availability of EU core technologies for defence unmanned systems are key to the autonomy in defence of EU but can also have a multiplier effect with the applicability of them to the civil domain, enabling EU to be major player in the growing unmanned business. No national policy stands against the solutions developed within the project nor their use cases. The project outcome will indeed help European forces improve their situation awareness and their efficiency while reducing the risk of loss of human lives. 6.5. The proportion of the overall budget of the action to be allocated to SMEs More than 40% of the overall budget of the action is allocated to the SMEs established in the European Union. More than 60% of the budget of the action allocated to the SME’s is allocated to SMEs which are established in Member States other than those where the in the consortium which are not SMEs are established (Cross Border SMEs). Figure: Allocation of the budget to SMEs and participating project Member States 81 Grant Agreement number: EDIDP-MUGS-2019-002-iMUGS ANNEX 1 The added value of each SMEs involved in iMUGS consortium are provided in the following table: Table 4: iMUGS SMEs added value N° SME Industrial or technological added value 1.1 MILREM MILREM AS focuses on designing and producing remotely controlled unmanned ground vehicles utilizing hybrid power; combining combustion engine with military-logistically available fuels with electric propulsion. MILREM has an experience as payload integrator and will provide its mid-size unmanned platform for iMUGS demonstrations. MILREM also has the experience and knowhow to manage the system architecture and integration and the overall coordination of the iMUGS project with partners. 1.3 GTCT GTCT focuses on cyber range and security solutions. GTCT will deliver a comprehensive plan to secure the iMUGS system. The centrepiece of this is the development of the cyber defence system (CDS), which is a novel approach that seeks to actively detect and provide recommendations to respond to live cyber- attacks. 1.11 (Un)Manned (Un)Manned develops highly reliable software and systems for aerospace and defence sectors, for manned and unmanned platforms, with a particular expertise in certifiable avionics development. Its unique Sol technology automates airworthiness certification of safety critical embedded computer systems to DO-178C and DO-254 norms. In the iMUGS project, its technology will allow standardisation in the military sectors and strengthen European Defence industry with the most recent methods of safety critical system development. 1.13 dotOcean DotOcean is active in autonomous system design since 2012. DotOcean systems, as AES256-E2EE interfaced, hence safely controllable world-wide. Systems utilize digital twin technology, merging multi-system situational awareness and mapping information to provide solutions in complex problems on several complexity levels. Approach enables to operate fleets of autonomous vehicles and to develop and deploy algorithms for swarm and collaborative behaviour. 3.1 Rantelon Rantelon is a subcontractor to MILREM. Rantelon specializes in design and engineering of radio frequency electronic equipment. Rantelon will integrate and demonstrate Electronic Warfare (EW) payloads during the iMUGS project. 3.2 DA-Design DA-Design is a subcontractor to Bittium Wireless Ltd within the communications work share and focuses on microwave technologies and waveform implementation. The work shall contribute to vehicle-to-vehicle communication solution. Together with Bittium, DA-Design shall provide the project an innovative solution that not only improves the system functionality but creates a novel capability for V2V communications. 3.3 AVQ AVQ is an independent consulting company with a focus on functional safety and system safety of complex technical systems. Company is subcontractor to Diehl Defence for the system safety development for the autonomy work share. 3.5 Threod Threod Systems produces unmanned aircraft systems and sub-systems for intelligence collection and surveillance tasks. In the iMUGS project, Threod Systems Systems will provide the tethered UAV and will contribute into the development of the one hand-controller. 82 Grant Agreement number: EDIDP-MUGS-2019-002-iMUGS ANNEX 1 6.6. Contribution to the further integration of the European defence industry iMUGS project has strong support within the members of the Permanent Structured Cooperation in the European Union. Participating project members for the PESCO for Integrated Unmanned Ground System project (UGS) are Germany, France, Spain, Belgium, Finland, Latvia and Estonia. A Letter of Intent of these seven MS is provided as an Appendix of the application (Ref to file “iMUGS Section 3.4 Letter of Intent”).  These MS have made an agreement for the common requirements for the equipment and the functionalities to be developed during the iMUGS project.  These MS have agreed to co-finance the system prototyping based on national industry share for the EDIDP-MUGS-2019 action. This initial agreement includes commitment through joint procurement of the equipment. In the event of an action awarded with EDIDP grant, Member States will appoint a project manager. These seven co-financing and jointly procuring members represent more than 60% of the total contribution to European Defence Fund budget.  These MS will actively participate to the workshops for operational scenarios development and will furthermore participate to the testing (d) with in-kind contributions in a form of testing areas and facilities when feasible. Further decisions for procurement will be made during and after the qualification (e) and certification (f) activities of the tested and demonstrated functionalities. Figure: Wide interest and potential for further integration of European defence industry The PESCO UGS project has furthermore four observing participants adding to the European wide interest; The Netherlands, Czech Republic, Hungary and Poland, representing additional 10% of the total contribution to European Defence Fund budget. In 2017, 25 Member States established PESCO to jointly invest in shared capability projects and enhance operational readiness and contribution of their armed forces. Standards are key enablers of interoperability and further integration of the European defence industry. The architecture developed during the project has the potential to become a European standard. Member States cooperation with the Industry will in its turn support optimizing the available resources and improve their overall effectiveness, with a view to the most demanding missions and operations and contributing to the fulfilment of the Union level of ambition. 83  Koostatud:21.10.2025 16:44:45 Konto väljavõte Organisatsioon: KAITSEMINISTEERIUM E-konto number: 2800082844 EUR tulukonto KV10415,10230-10236 Kaitsevägi K600 Töökood Kuupäev Dokumendi Maksja/saaja Maksja/saaja konto Maksja/saaja nimi Viitenumber Summa Kande Kande Summa number regsitrikood kande valuuta valuuta konto valuutas kurss valuutas Panga arhiveerimiskood Eelarve Selgitus 20230213000289459119 13.02.2023 2390506450 DE59700202700655468722 EUROPEAN 5 292.50 EUR 1.0000000 5 292.50 COMMISSION RMI16976591 2370025781 24-JAN-2023/10883825 Periood 13.02.2023 - 13.02.2023 Perioodi algjääk: 3 119 128.18 Perioodi kreeditkäive: 0.00 Perioodi deebetkäive: 5 292.50 Perioodi lõppjääk: 3 124 420.68 Hetkeseisuga 21.10.2025 kell 16:44 Vabad vahendid: 5 712 965.90 Reserveeritud:: 0.00 Kinnitan: Kinnitan: asutuse juht juhataja raamatupidamise eest vastutav isik peaspetsialist pitsat pitsat UI lillil IIIIIlillIIIII lillil <|SS > EESTI VABARIIK oo EE 01564 UI 0EE1564 ( i 9) J 8§& (m) ( PATENDIAMET (51) IntCl. H03G 3/30 (2022.01) H03F 1/02 (2022.01) (12) KASULIKU MUDELI KIRJELDUS (21) Registreerimistaotluse (73) Kasuliku mudeli omanik: number: U202100027 Kaitsevägi (22) Registreerimistaotluse Juhkentali 58, 15007 Tallinn , EE esitamise kuupäev: 22.06.2021 (72) Kasuliku mudeli autorid: (24) Registreeringu kehtivuse alguse kuupäev: 22.06.2021 Jaanus Kalde Nooruse 1, 50411 Tartu, EE (45) Kasuliku mudeli kirjelduse avaldamise kuupäev: 18.04.2022 Kalle-Gustav Kruus Nooruse 1, 50411 Tartu, EE Veiko Dieves Riia 12, 51010 Tartu, EE (74) Patendivolinik: Jü rgen Toome AAA Patendibü roo OÜ Tartu mnt 16, 10117 Tallinn , EE (54) Meetod raadiosagedusvõimendi transistori eelpinge digitaalseks reguleerimiseks suletud tagasisideahelaga kontrolleriga (57) Leiutis käsitleb meetodit eelpinge digitaalseks reguleeri ¬ miseks suletud tagasisideahelaga kontrolleriga, mis on 102 108 konfigureeritud juhtima raadiosagedusvõimendi transistori voimsus - - RF i väl- jundport eelpingestuspunkti. Digitaalne süsteem, mis mõõdab mitmeid voolutugevuse süsteemi tööparameetreid, sealhulgas transistori võimsus- vf mõõtmise skeem tarvet ja raadiosagedussignaaii sisendvõimsuse taset. Digi¬ taalse süsteemi puhul kasutatakse algoritmi, et muuta eelpinge taset sisendsignaalide ja mällu salvestatud väärtuste järgi. 101 mikro- kontrolier < — 109 103 yvõimendi / transistor A Automaatne eelpingestuspunkti reguleerimine või võimsuse \ vähendamine on võimalik juhul, kui s üsteem tuvastab, et 104 X transistori sisendis ei ole raadiosagedussignaaii. Kõiki mõõde- eelpinge tase / tavaid väärtusi on võimalik digitaalselt jälgida mikro - kontrolleri abil ja parameetreid on võimalik tarkvara abil reguleerida. 106 105 (57) The invention relates to a method for a digital bias võimsus < andur - suuns- kompleks control by a closed loop feedback controller configured to drive the bias point of the radio frequency amplifying 107 transistor. Digital system that measures multiple parameters of system operations, including transistor power consumption - - RF i Si sendport and input radio frequency signal power level. Digital system uses an algorithm to change the bias level according to input signals and values recorded in the memory. Automatic bias point tuning or power down can be done when system detects no RF signal present on the input of the transistor. All the measurements can be digitally monitored from the micro¬ controller and parameters tuned from the software. EE 01564 U1  EE 01564 UI Meetod raadiosagedusvõimendi transistori eeipinge digitaalseks reguleeri¬ miseks suletud tagasisideahelaga kontrolleriga TEHNIKAVALDKOND Leiutis käsitleb raadiosagedusvõimendite programmeeritava eelpingestamise mee- 5 todit, teiste sõnadega meetodit raadiosagedusvõimendi (RF-võimendi, ingl radio frequency ) transistori eeipinge digitaalseks reguleerimiseks võimendi viimases või- mendamisetapis. Leiutise kontekstis tähendab väljend „võimendi eeipinge muutmine raadiosagedus¬ 11 võimendi (RF-võimendi) transistori alalisvoolu (DC, ingl direct current ) eeipinge 10 muutmist võimendi viimases võimendamisastmes. TEHNIKA TASE Raadiosignaalide võimendamise valdkonnas kasutatakse transistoreid signaalide võimendamiseks. Need transistorid peavad parimal võimalikul viisil toimimiseks olema õigesti eelpingestatud. Täpne optimeeritav parameeter võib olla iga raken- 15 duse puhul erinev, aga tavaliselt hõlmavad nimetatud parameetrid v õimendust, võimsuse maksimaalset taset või kasutegurit. Täpne eelpingestuspunkt ei ole kind¬ laks määratud. See oleneb mitmetest teguritest, kasutatava transistori mudelist, transistori eriomastest lubatud piirhälvetest, temperatuurist, signaali modulatsioo¬ nist, nõutavast võimsusest jne. 20 Kõige lihtsam kasutatav eelpingestustehnika on kindla eeipinge rakendamine - transistor eelpingestatakse tootmise ajal seadistatud konstantse pinge tasemega. Veidi arenenuma meetodi puhul kasutatakse temperatuuri tagasisidet, et muuta eel- pinget koos temperatuuri muutumisega. Kui transistorite temperatuuriga seotud omadused on tuntud ja lihtsad, on seda võimalik saavutada lihtsate analoogskee- 25 mide abil. Need meetodid ei tööta hästi, kui eeipinge omadused peavad muutuma kooskõlas sisendvõimsuse tasemetega või kui seda juhitakse eemalt. Ühendriikide patendis US6563385B2 (Xicor, inc., avaldatud 13.05.2003) on kirjel¬ datud meetodeid ja seadmeid raadiosagedusvõimendi (RF-võimendi) alalisvoolu 30 eeipinge reguleerimiseks töötingimuste muutmise eesmärgil, näiteks hulgimodulat-  EE 01564 UI 2 sioonitehnikaid , kui RF puudub. Digitaalselt reguleeritav pingeallikas on program ¬ meeritud sä ilitama võ imendi eelpinget. Pingeallikas võib olla digitaalselt juhitav po- tentsiomeeter. Võimendi alalisvooluvä ljundi voolutugevuse alusel võib leida pinge ja seda võib võ rrelda optimaalse võ imendi eelpinge programmeeritava esindusliku 5 võ rdlusn ä itajaga. Komparaatori vä ljund mää rab kindlaks pingeallika juhtimise suu ¬ na. Digitaalset kella rakendatakse selleks, et juhtida pingeallikat siis, kui RF puudub. Teise võimalusena võib võimendi vä ljundvoolu lugeda protsessori abil , mis mää rab kindlaks optimaalse eelpinge. See eelpinge võ ib olla kirjutatud andmeregistrisse, mis seadistab pingeallika pinge. Sü steem kompenseerib automaatselt võ imendi op¬ 10 timaalse eelpinge muutused , mis on põ hjustatud vananemisest , temperatuurist ja modulatsiooniskeemist. See süsteem loeb informatsiooni vä lisest allikast rakendatud sisendsignaali kohta , seega ei ole seda võimalik h õlpsasti kasutada tundmatute või s ü nkroniseerimata signaalide puhul. 15 LEIUTISE OLEMUS Leiutis käsitleb digitaalse raadiosagedusvõimendi eelpingestamise meetodit. Käesoleva meetodit puhul kasutatakse raadiosagedusvõimendi ( RF-võimendi) tran ¬ sistori eelpinge digitaalseks juhtimiseks võ imendi viimases võimendamisastmes mikrokontrollerit. Digitaalse juhtimise rakendamine muudab võimalikuks muuta tran ¬ 20 sistori eelpinget kooskõlas erinevate andurite sisenditega - temperatuuriga , võim ¬ sustarbega , sisendsignaali taseme ja teiste teguritega . See võ imaldab transistori eelpingestamist ja jä lgimist seoses sisendsignaalidega . See võimaldab n ä iteks seadistada eelpinge signaali puudumise tingimustes ja hoida seda samana , kui signaal on olemas. See on parem kui konstantse vooluga eelpin - 25 gestuslahendused , sest see ei muuda erinevate sisendsignaalide puhul transistori võimendust ja maksimaalset võimsust. Võimalik on kasutada lihtsat , kindlaksmää ¬ ratud eelpinget, et muuta transistor tundetuks signaali tasemete suhtes, aga kind ¬ laksmää ratud eelpingega seadmestikud n õ uavad iga toodetud transistori eelpinge taseme käsitsi h ää lestamist, et see sobiks iga transistori variatsiooniga . 30 Selle meetodi uudsus tuleneb eelpinget juhtiva algoritmi muutmisest võimendi si - sendsignaali jä rgi. Leiutisekohase s üsteemi puhul kasutatakse anduri tagasisidet, et muuta eelpinget siis, kui signaali pole, ja kui signaal on olemas, siis kasutab  EE 01564 UI 3 võimendi mällu salvestatud väärtusi, kuna mõned anduritest, näiteks voolutugevuse puhul, muutuvad koos rakendatava signaaliga. See meetod on kasulik nende süsteemide puhul, mille korral on võimendi saatjast eraldi süsteem. Kontrollerid, mis juhivad transistori eelpinget, võivad tuvastada või¬ 5 mendisse sisse tuleva signaali ja eelpingestada võimendi transistori selle järgi. Va ¬ rasemad signaalist sõltuvad eelpingestamise meetodid nõuavad eraldi signaale, mis näitavad, kas signaal on olemas ja milline on sisendsignaali võimsuse tase. Leiutisekohast meetodit kasutatakse selleks, et reguleerida suure võimsusega mik ¬ rolainete impulssvõimendit. Transistori eelpingestuspunkt määrata kindlaks seeläbi, 10 et mõõdeti toiteallika voolutarvet signaali puudumise tingimustes. Transistori eelpin¬ gestuspunkt salvestatakse säilmälus ja seda on võimalik hiljem meelde tuletada. Digitaalne reguleerimine võimaldab ka rikkeolukordade, näiteks liigvoolu ja liigtem- peratuuri jälgimist. Need rikkeolukorrad võivad põhjustada transistori tõrke, kui neid ei kõrvaldata, Rikkeolukordade kõrvaldamine võimaldab transistori turvaliselt blo ¬ 15 keerida enne pöördumatute kahjustuste ilmnemist. Selleks, et ületada ülalpool selgitatud tehnika taseme kohaseid puudusi, puudutab leiutis meetodit eelpinge digitaalseks reguleerimiseks suletud tagasisideahelaga kontrolleriga, mis on konfigureeritud reguleerima raadiosagedusvõimendi (RF-või- mendi) transistori eelpingestuspunkti, mis hõlmab etappe, 20 mille puhul mõõdetakse pidevalt transistori voolutarvet ja seda võrreldakse eel ¬ nevalt kindlaks määratud voolutugevuse tasemete vahemikuga, mis otsitakse välja kontrolleri mälust, ja nimetatud kontrolleri abil jälgitakse raadiosagedussig- naali (RF-signaali) olemasolu võimendi sisendis, kus raadiosagedussignaali (RF-signaali) olemasolu korral võimendi sisendis ot¬ 25 sitakse kontrolleri mälust välja eelnevalt kindlaks määratud eelpingestuspunkt ja seda rakendatakse transistorile ning jätkatakse transistori voolutarbe mõõtmist ja kus raadiosagedussignaali (RF-signaali) puudumise korral jätkatakse transistori voolutarbe mõõtmist ja seda võrreldakse kontrolleri mälust välja otsitud eelnevalt kindlaks määratud voolutugevuse tasemete vahemikuga jõudeolekus, 30 kus olemasolevat eelpingestuspunkti säilitatakse ja transistori voolutarbe mõõt ¬ mist jätkatakse, kui mõõdetud voolutarve on kontrolleri mälust välja otsitud eel¬ nevalt kindlaks määratud vahemikus, ja  EE 01564 UI 4 kui transistori voolutarve on väljaspool nimetatud eelnevalt kindlaks määratud va ¬ hemikku, siis reguleeritakse nimetatud transistori eelpinget kontrolleriga kontrol¬ leri mälust välja otsitud eelnevalt kindlaks määratud eelpingestuspunkti järgi ja voolutarvet mõõdetakse uuesti. 5 Leiutise veel ühe teise teostuse kohaselt jälgib nimetatud kontroller lisaks transistori temperatuuri ja reguleerib eelpinget kontrolleri mälust välja otsitud eelnevalt kind¬ laks määratud eelpingestuspunkti järgi. Leiutise veel ühe teise teostuse kohaselt jälgib nimetatud kontroller lisaks transistori voolutarvet ja reguleerib eelpinget ning lülitab toiteallika iiigvoolu esinemise korral 10 välja. Leiutise veel ühe teise teostuse kohaselt peab nimetatud kontroller digitaalsete lii ¬ deste vahenduse! lisaks sidet teiste süsteemidega, et anda tagasisidet ja võtta vastu käske, mis muudavad kontrolleri mälu sisu. JOONISTE LÜHIKIRJELDUS 15 Joonisel fig 1 on näidatud leiutisekohase süsteemi skemaatilist elektroonilist ülevaa ¬ det - peamise raadiosagedussignaali teed on näidatud rasvases kirjas noolte abil, digitaalseid signaale on näidatud katkendjoontega noolte abil. Joonisel fig 2 on illustreeritud leiutisekohaselt rakendatavat algoritmi. LEIUTISE TEOSTAMISED 20 Joonise fig 1 kohaselt on sellel kujutatud leiutisekohase süsteemi skemaatilist elekt ¬ roonilist ülevaadet. Järgnevalt on toodud kirjelduses ja joonistel kasutatud elementide viitenumbrid, kus 101 on mikrokontroller, 102 on võimsuslüliti, 103 on võimendi transistor, 104 on eel- pinge tase, 105 on võimsusandur, 106 on suunakompleks, 107 on RF-i sisendport, 25 108 on RF-i väljundport ja 109 on voolutugevuse mõõtmise skeem. RF-signaal siseneb joonisel RF-i sisendpordi 107 kaudu. Siis liigub signaal läbisuu- nakompleksi 106, mis suunab ümber väikse, aga hästituntud osa sisendsignaali võimsusest. Suurem osa signaalist liigub edasi võimendi transistorisse 103. Võimendatud signaal väljub süsteemist transistori kaudu läbi RF-i väljundpordi 108. 30 Suunakompleksi 106 abil ümber suunatud signaal liigub võimsusandurisse 105.  EE 01564 UI 5 Võ imsusandur 105 koosneb logaritmilisest võ imendist, et lineariseerida võ imsuse tase ja analoog-digitaalmuundur. Informatsioon digitaliseeritud võ imsuse taseme kohta liigub sisendina kasutamiseks algoritmi kä itavasse mikrokontrollerisse 101. Mikrokontroller võ ib kasutada võ im ¬ 5 suse taset ja muud informatsiooni , et juhtida transistori võ imsusl ü litit 102 ja eelpinge taset 104. Võimsusl ü litil 102 on sisseehitatud temperatuuri- ja liigvoolukaitse ning see on transistori peavoolutoite l ü liti. VÕimsusl ü liti 102 ja transistori 103 energiaga varustamise sisendi vahel asub voolutugevuse mõõtmise skeem 109. See mõõdab transistori voolu tarbimist, et mikrokontroller saaks seda käsutada al¬ 10 goritmi sisendina . Eelpinge taseme kontroller 104 koosneb digitaalanaloogmuundu - rist , võimendist, et reguleerida pinge tasemed vahemikku , mis on vajalik transistori ja signaali n õutava filtreerimise jaoks. Joonisel fig 2 on illustreeritud rakendatud algoritmi , mille puhul kasutatakse transis¬ tori eelpingestamiseks sisendsignaali võimsuse taset. Programm alustab stabiilses 15 olekus (etapp 201 ). Siis kontrollib see seda , kas transistori sisendis esineb m õ ni RF- signaal (etapp 202). Kui signaali olemas ei ole , rakendab see transistorile salvestatud eelpingestuspunkti (etapp 203). Kui signaali olemas ei ole (etapp 202) , mõõdab see transistori voolutarvet (etapp 20 204) ja võ rdleb seda soovitud voolutugevuse tasemega jõ udeolekus (etapp 205). Kui mõõdetud voolutugevuse tase on vastuvõetavas vää rtuste vahemikus , siis voo¬ lutugevuse eelpingestuspunkt salvestatakse (etapp 207) ja algoritm jä tkab eelpinge seadistamisega (etapp 203) ning liigub tagasi algusesse (etapp 201). Kui transistori voolutarve on soovitud vahemikust vä ljas (etapp 205) , siis eelpinge 25 kompenseeritakse (etapp 206) ja voolutarvet m õõdetakse uuesti (etapp 204). See eelpingestusmeetod on kasulik selleks , et ehitada suure võ imsusega ja RF- võ imendeid eelkõ ige tundlike ja ü lesannete tä itmiseks oluliste rakenduste jaoks. See meetod on eriti kasulik võ imendite puhul , mida kasutatakse koos signaaliallika- tega , mida ei ole võ imalik muuta võ i h õlpsasti vä liste s üsteemidega ü hendada .  EE 01564 UI 6 KASULIKU MUDELI NÕUDLUS . 1 Meetod raadiosagedusvõimendi transistori eeipinge digitaalseks reguleerimi ¬ seks suletud tagasisideahelaga kontrolleriga, mis on konfigureeritud juhtima raadio¬ sagedusvõimendi transistori eelpingestuspunkti, mis hõlmab etappe, mis erinevad 5 selle poolest , et transistori voolutarvet mõõdetakse pidevalt ja seda võrreldakse kontrolleri mälust välja otsitud eelnevalt kindlaks määratud voolutugevuse tasemete vahemikuga ja nimetatud kontrolleri abil jälgitakse raadiosagedussignaali olemasolu transistori sisendis, io kus raadiosagedussignaali olemasolu korral transistori sisendis otsitakse kontrol¬ leri mälust välja eelnevalt kindlaks määratud eelpingestuspunktja seda rakenda¬ takse transistorile ja transistori voolutarbe mõõtmist jätkatakse ja kus raadiosagedussignaali puudumise korral jätkatakse transistori voolutarbe mõõtmist ja seda võrreldakse kontrolleri mälust välja otsitud eelnevalt kindlaks 15 määratud voolutugevuse tasemete vahemikuga jõudeolekus, kus olemasolevat eelpingestuspunkti säilitatakse ja transistori voolutarbe mõõt¬ misega jätkatakse, kui mõõdetud voolutarve on kontrolleri mälust välja otsitud eelnevalt kindlaks määratud vahemikus, ja kui transistori voolutarve on nimetatud eelnevalt kindlaks määratud vahemikust 20 väljas, siis reguleeritakse nimetatud transistori eelpinget kontrolleriga kontrolleri mälust välja otsitud eelnevalt kindlaks määratud eelpingestuspunkti järgi ja voo¬ lutarvet mõõdetakse uuesti. 2. Meetod vastavalt nõudluspunktile 1, mis erineb selle poolest , et nimetatud kontrolleriga jälgitakse lisaks transistori temperatuuri ja reguleeritakse transistori 25 eelpinget kontrolleri mälust välja otsitud eelnevalt kindlaks määratud eelpingestus¬ punkti järgi. 3. Meetod vastavalt nõudluspunktile 1, mis erineb selle poolest , et nimetatud kontrolleriga jälgitakse lisaks transistori voolutarvet ja reguleeritakse transistori eel¬ pinget ning lülitatakse liigvoolu esinemise korral toiteallikas välja. 30 4. Meetod vastavalt nõudluspunktile 1 , mis erineb selle poolest , et nimetatud kontrolleriga peetakse digitaalsete liideste abil lisaks sidet teiste süsteemidega, et anda tagasisidet ja võtta vastu käske, mis muudavad kontrolleri mälu sisu. Koostatud:21.10.2025 16:41:35 Konto väljavõte Organisatsioon: KAITSEMINISTEERIUM E-konto number: 2800082844 EUR tulukonto KV10415,10230-10236 Kaitsevägi K600 Töökood Kuupäev Dokumendi Maksja/saaja Maksja/saaja konto Maksja/saaja nimi Viitenumber Summa Kande Kande Summa number regsitrikood kande valuuta valuuta konto valuutas kurss valuutas Panga arhiveerimiskood Eelarve Selgitus 20220405000265194265 05.04.2022 12494266 EE247700771003613370 Milrem AS 10415107493823 35 800.00 EUR 1.0000000 35 800.00 FF08E4DBD8B4EC11A2E400155DA95D0B Arve 10749382 Periood 05.04.2022 - 05.04.2022 Perioodi algjääk: 3 913 196.73 Perioodi kreeditkäive: 0.00 Perioodi deebetkäive: 35 800.00 Perioodi lõppjääk: 3 948 996.73 Hetkeseisuga 21.10.2025 kell 16:41 Vabad vahendid: 5 712 965.90 Reserveeritud:: 0.00 Kinnitan: Kinnitan: asutuse juht juhataja raamatupidamise eest vastutav isik peaspetsialist pitsat pitsat Koostatud:21.10.2025 16:51:38 Konto väljavõte Organisatsioon: KAITSEMINISTEERIUM E-konto number: 2800082844 EUR tulukonto KV10415,10230-10236 Kaitsevägi K600 Töökood Kuupäev Dokumendi number Maksja/saaja Maksja/saaja konto Maksja/ Viitenumber Summa Kande Kande Summa regsitrikood saaja nimi kande valuuta valuuta konto valuutas kurss valuutas Panga arhiveerimiskood Eelarve Selgitus 20221202000283610151 02.12.2022 960535924353161671 12494266 EE247700771003613370 Milrem AS 10415108269108 116 200.00 EUR 1.0000000 116 200.00 RO3274488602L02 10826910 Periood 13.05.2022 - 13.12.2022 Perioodi algjääk: 4 351 757.46 Perioodi kreeditkäive: 0.00 Perioodi deebetkäive: 116 200.00 Perioodi lõppjääk: 4 467 957.46 Hetkeseisuga 21.10.2025 kell 16:51 Vabad vahendid: 5 712 965.90 Reserveeritud:: 0.00 Kinnitan: Kinnitan: asutuse juht juhataja raamatupidamise eest vastutav isik peaspetsialist pitsat pitsat TEADUS- JA ARENDUSTÖÖ LEPING Käesoleva teadus- ja arendustöö lepingu (Leping) on selle digiallkirjastamise kuupäeval sõlminud: (1) Milrem AS, registrikood 12494266, asukoht Betooni tn 1, Tallinn 13619 (Tellija), mida esindab juhatuse liige Kuldar Väärsi ja (2) Kaitseväe Akadeemia, asukoht Riia 12, Tartu 51010 (Töövõtja), mida esindab Kaitseväe põhimääruse § 20 lg 3 p 3 ja Kaitseväe Akadeemia põhimääruse § 5 lg 2 p 3 ja § 6 lg 1 alusel akadeemia ülem kolonel Vahur Karus, edaspidi eraldi nimetatud ka kui Pool või koos kui Pooled, VÕTTES ARVESSE A. Tellija kuulub Euroopa ettevõtete konsortsiumisse, mis on sõlminud toetuse lepingu Euroopa Komisjoniga, eesmärgiga viia läbi Euroopa kaitsevaldkonna tööstusliku arendamise programmi projekti “Development of an integrated Modular Unmanned Ground System“ (iMUGS projekt), kus Tellija tegutseb konsortsiumi koordinaatorina; B. Vastavalt Euroopa Komisjoniga sõlmitud toetuse lepingule toimub projekti tööde vastuvõtmine ja kvaliteedi hindamine projektis osalevate liikmesriikide esindajate poolt loodud komisjonis (Project Office), mis kinnitab tingimustele vastava töö vastava sertifikaadiga nn Certificate of Conformity; C. Tellija on iMUGS projektis registreerinud Töövõtja oma ametlikuks alltöövõtjaks ning käesoleva Lepinguga soovivad pooled kokku leppida alltöövõtu täpsemates tingimustes. POOLED ON SÕLMINUD LEPINGU ALLJÄRGNEVATEL TINGIMUSTEL: 1. LEPINGU ESE JA TÖÖ TEOSTAMISE TÄHTAEG 1.1 Tellija tellib ja Töövõtja viib läbi Lepingu tingimuste kohaselt teadus ja arendustöö, mille sisuks on uuringute läbiviimine mehitamata maismaasõidukite süsteemide kasutamise osas. Uuringud tuleb teostada inglise keeles ning läbi viia vastavalt iMUGS-i toetuse lepingus sätestatud tingimustele (Lisa 1: Toetuse lepingu lisa 1) ning projekti partnerite vahel eraldi kokku lepitud tingimustele (Lisa 2: Tingimused, ID viited 183, 184 ja 185) (Töö). Töö on jaotatud kolmeks eraldiseisvaks uuringuks: 1) Uuring 1: “Study on the use of UGS in the context of customary law of war and applicable to EU and national legislation”; 2) Uuring 2: “Study of attitudes of military personnel and general population towards the use of unmanned platforms”; 3) Uuring 3: “Study of ethical aspects regarding MUGS employment in operational context” 1.2 Töö raames teostatavad uuringud esitatakse Tellijale hiljemalt: 1) Uuring 1 – 01.06.2022; 2) Uuring 2 – 01.02.2022; 3) Uuring 3 – 01.06.2022. Lk 1 / 5 2. LEPINGU DOKUMENDID 2.1 Leping koosneb Lepingu tekstist, selle lisadest ja Poolte kirjalikest kokkulepetest mistahes Lepingu muudatuste või täienduste kohta, mis sõlmitakse pärast Lepingu jõustumist. Kui Lepingu ja sellele allkirjastamise hetkel lisatud lisade vahel esineb lahknevusi, on ülimuslik Lepingu tekst. Kui Lepingu ja selle lisade ning hiljem allkirjastatud Lepingu lisade või hilisemate kirjalike lepingute vahel esineb lahknevusi, on ülimuslikud hilisemad lisad ja kirjalikud lepingud. 2.2 Lepingu allkirjastamisel on sellel järgmised lisad: 1) Lisa 1 – Toetuse lepingu lisa 1; 2) Lisa 2 – Tingimused. 3. TÖÖ ÜLEANDMINE JA VASTUVÕTMINE 3.1 Töö raames teostatavad uuringud antakse Tellijale üle eraldiseisvalt ning iga uuringu üleandmine ja vastuvõtmine toimub käesolevas peatükis sätestatud korras. 3.2 Töövõtja teavitab uuringu valmimisest viivitamata Tellijat ning esitab uuringu ülevaatamiseks Tellijale elektroonselt e-posti teel. Töövõtja kohustub koos uuringuga Tellijale üle andma kõik olemuslikult uuringu juurde kuuluvad dokumendid. 3.3 Tellija korraldab mõistliku aja jooksul pärast seda, kui Töövõtja on Tellijat uuringu valmimisest teavitanud uuringu vastavuse hindamiseks koosoleku koos Project Office’ga, kus Töövõtja esitleb uuringu tulemusi. 3.4 Uuring loetakse Tellija poolt vastuvõetuks kui Project Office kinnitab uuringu Certificate of Conformity’ga. 3.5 Kui Project Office esitab pretensioone uuringu kohta kohustub Töövõtja kõrvaldama puudused uuringus mõistliku aja jooksul peale puudustest teavitamist ning esitama uuringu uuesti üle vaatamiseks Tellijale ja Project Office’le. 4. TASU 4.1 Tellija maksab Töövõtjale nõuetekohase Töö teostamise eest kokku 152 000 eurot (Tasu), millele lisandub seaduses sätestatud käibemaks. Tasu jaotub uuringute vahel järgmiselt: 1) Uuring 1 - 58 700 eurot (ilma KM-ta); 2) Uuring 2 - 35 800 eurot (ilma KM-ta); 3) Uuring 3 - 57 500 eurot (ilma KM-ta) 4.2 Tellija maksab Töövõtjale Tasu iga nõuetekohaselt tehtud uuringu eest eraldi vastavalt Töövõtja poolt esitatud arvele, mille maksetähtaeg ei ole lühem kui 30 kalendripäeva. 4.3 Töövõtjal on õigus esitada Tellijale arve alates vastava uuringu kinnitamisest Certificate of Conformity’ga vastavalt punktile 3.4. Arve loetakse tasutuks, kui kogu arvel näidatud summa on laekunud Töövõtja arveldusarvele. 5. POOLTE ÕIGUSED JA KOHUSTUSED 5.1 Töövõtja kohustub: 5.1.1 teostama Töö vastavalt Lepingule, kehtivatele õigusaktidele ja Tellija juhistele; 5.1.2 järgima Töö teostamisel ja korraldamisel Tellija mõistlikke huve ja eesmärke ning kõiki Tellija poolt antud seaduslikke juhiseid; 5.1.3 viivitamata pöörduma Tellija poole juhiste saamiseks, kui need on vajalikud Töö teostamiseks; Lk 2 / 5  5.1.4 teavitama Tellijat viivitamatult kõikidest asjaoludest, mis mõjutavad Töö teostamist või Töövõtjapoolsete muude Lepinguliste kohustuste täitmist ning mille vastu on Tellijal mõistlik huvi; 5.1.5 hankima kõik Töö teostamiseks vajalikud materjalid; 5.1.6 ilma eraldi kokkuleppeta teostama ka sellised tööd ja toimingud, mis ei ole Lepingus ega selle lisades selgesõnaliselt ette nähtud, kuid mille tegemine on tavapäraselt vajalik Lepingu kohaseks täitmiseks ja eesmärgi saavutamiseks ning mis olemuslikult kuuluvad Töö hulka; 5.1.7 tagama Töö käigus valmivate dokumentide vastavuse kehtivatele õigusaktidele ja Lepingule; 5.1.8 mitte rikkuma Tellijale või kolmandatele isikutele kuuluvaid õigusi, sh intellektuaalse omandi õigusi ning tagama, et Töövõtjal oleks kõik õigused anda Töö Tellijale üle vastavalt käesolevas Lepingus sätestatule; 5.2 Töövõtjal on õigus: 5.2.1 nõuda Tellijalt juhiseid, kui need on vajalikud Töö teostamiseks; 5.2.2 peatada Töö teostamine, kui Töövõtja on nõudnud Tellijalt juhiseid ja Tellija ei ole mõjuva põhjuseta neid mõistliku aja jooksul andnud; 5.2.3 saada Töö teostamise eest tasu vastavalt Lepingule. 5.3 Tellija kohustub: 5.3.1 andma Töövõtjale viivitamata juhiseid, kui need on vajalikud Töö teostamiseks; 5.3.2 andma viivitamata Töövõtjale üle kõik Töö teostamiseks vajalikud lähteandmed; 5.3.3 Töö valmimisel korraldama Töö üle vaatamise ja koos Project Office’ga selle vastu võtma või vastuvõtmisest keelduma mõistliku aja jooksul pärast seda, kui Töövõtja on Tellijat Töö valmimisest teavitanud ning seda Tellijale ja Project Office’le esitlenud; 5.3.4 maksma Töövõtjale valminud Töö eest tasu vastavalt Lepingule; 5.3.5 teavitama Töövõtjat koheselt kõikidest asjaoludest, mis mõjutavad Tellijapoolsete Lepinguliste kohustuste täitmist ning mille vastu on Töövõtjal mõistlik huvi; 5.3.6 Töös puuduse avastamisel teavitama Töövõtjat avastatud puudusest mõistliku aja jooksul pärast puuduse avastamist; 5.3.7 Töös avastatud puudusest teavitamisel kirjeldama avastatud puudust võimalikult täpselt. 5.4 Tellijal on õigus: 5.4.1 igal ajal tutvuda Töö käiguga, välja arvatud juhul, kui see segaks oluliselt Töö teostamist; 5.4.2 Töös esinevate puuduste korral nõuda Töö vastavusse viimist Lepingu tingimustega; 5.4.3 kõrvaldada Töös esinev puudus ise või lasta see kõrvaldada kolmandal isikul juhul, kui Töövõtja ei kõrvalda Töös esinevat puudust mõistliku aja jooksul pärast Tellijapoolset puudusest teavitamist; 5.4.4 nõuda Töövõtjalt Töö puuduse kõrvaldamisega seotud kulutuste hüvitamist; 5.4.5 jätta Töö vastu võtmata, kui Töös esineb puudusi, välja arvatud pisipuudused, mis ei takista Töö tulemuse kasutamist; 5.4.6 keelduda Töö eest tasumast kui Töö ei vasta Lepingutingimustele, muuhulgas kui Lepingutingimustele ei vasta Töö juurde kuuluvad dokumendid või sellised dokumendid on Tellijale üle andmata. Lk 3 / 5 6. INTELLEKTUAALNE OMAND 6.1 Töövõtja annab Lepingu täitmise käigus loodud Töö omandiõiguse ja loovutatavad intellektuaalomandiõigused (sh autori varalised õigused, õigus esitada taotlus kaubamärgi, patendi, kasuliku mudeli, tööstusdisainilahenduse või mikrolülituse topoloogia registreerimiseks, samuti õigused tundmatutele kasutusviisidele, mis tekivad tulevikus) Lepingus või Eesti Vabariigi seadustes sätestatud maksimaalses ulatuses Töö üleandmisega üle Tellijale mistahes täiendava toimingu või tahteavalduseta. 6.2 Töövõtja annab Töövõtjale kuuluvate või temale litsentsi alusel kasutusse antud võõrandamatute, ent litsentseeritavate õiguste osas Tellijale tagasivõetamatu ainulitsentsi Töövõtjale kuuluvate võõrandamatute õiguste kasutamiseks ja/või teostamiseks maksimaalses kohalduva õiguse alusel lubatud ulatuses ilma geograafiliste piiranguteta ning ilma piiranguteta kasutamise viisi, eesmärgi ja kasutajate ringi suhtes. Litsents on ülemaailmne ja loovutatav ning sisaldab õigust luua teoste põhjal tuletatud teoseid, väljastada all-litsentse nii kolmandatele isikutele kui ka üldsusele, süstematiseerida ja lülitada teosed kogumikku, kasutada teost kollektiivse teose või andmebaasi loomiseks, samuti kasutada teose eri osi ja elemente tulemusest eraldi isegi juhul, kui need on salvestatud koos ja moodustavad ühtse terviku. Ainulitsents kehtib alates vastava õiguse tekkimisest kuni litsentsitud intellektuaalse omandi õiguse kehtivuse tähtaja lõppemiseni. 6.3 Kahtluste vältimiseks on Pooled kokku leppinud, et Töövõtja kohustub piirama oma intellektuaalse omandi õiguste teostamist järgmiselt: 6.3.1 kui Töövõtja on Töö Tellijale üle andnud või muul moel Tellijale kättesaadavaks teinud, võib Tellija otsustada, kas Töö on sellisel kujul valmis avaldamiseks kolmandatele isikutele või avalikkusele. Töövõtja ei tee Tellijale takistusi Töö avaldamiseks. Töövõtja ei või ise ilma Tellija eelneva kirjaliku nõusolekuta Tööd avaldada; 6.3.2 Nii Tellija kui ka kolmandad isikud võivad Tellija nõusolekul või heakskiidul muuta, parandada ja täiendada Tööd ning lisada Tööle teiste autorite loomingut ja muid materjale, mida Tellija peab vajalikuks. 6.4 Töövõtjal on õigus kasutada Tööd enda teadustöödes ja/või publikatsioonides tingimusel, et avalikustatava teabe sisu, koht, viis ja aeg kooskõlastatakse eelnevalt kirjalikult Tellijaga. Tellija vastab Töövõtja vastavasisulisele päringule 20 tööpäeva jooksul alates päringu saamisest. Kui Tellija päringule ei vasta, loetakse, et Tellija nõustub Tulemi kasutamise lubamisega päringus märgitud viisil. 6.5 Pooled on leppinud kokku, et tasu intellektuaalse omandi ja kaasnevate õiguste Tellijale loovutamise ja litsentsi andmise eest sisaldub Tasus. 6.6 Töövõtja kohustub tagama, et tema poolt Töö tegemisel loodavad intellektuaalse omandi objektid on loodud Töövõtja poolt ega kahjusta mistahes kolmanda isiku autori- või mistahes muid intellektuaalse omandi õigusi. Kui Töövõtja on teose loomisel rikkunud kolmandate isikute õigusi ning Tellija on sellega seoses kohustatud hüvitama kolmandale isikule tekitatud varalise ja/või mittevaralise kahju, on Töövõtja kohustatud Tööandja poolt maksmisele kuuluvad summad ning sellega seoses kantavad kulutused ja kahju Tellijale hüvitama. 7. POOLTE VASTUTUS 7.1 Kui Tellija viivitab Töövõtjale tasu maksmisega, siis on Töövõtjal õigus nõuda Tellijalt viivist 0,05% päevas viivitatud summalt iga tasumisega viivitatud päeva eest. 7.2 Töö valmimise, üleandmise või Töös esineva puuduse kõrvaldamisega viivitamisel kohustub Töövõtja tasuma Tellijale leppetrahvi 0,05% valmimata, üle andmata või puudusega Töö maksumusest päevas iga viivitatud päeva eest. Tellija kohustub leppetrahvi nõudmisest Töövõtjat teavitama mõistliku aja jooksul pärast seda, kui ta Töövõtjapoolsest viivitusest teada sai. Lk 4 / 5 8. KEHTIVUS JA LÕPPEMINE 8.1 Kumbki Pool võib Lepingust taganeda, kui teine Pool on Lepingut oluliselt rikkunud ja rikkuv Pool ei ole heastanud rikkumist täiendava mõistliku tähtaja jooksul, mis ei tohi olla lühem kui 30 kalendripäeva. 8.2 Kui Tellija ütleb käesoleva Lepingu üles või loobub Töö edasisest tellimisest, on Töövõtja õigustatud saama tasu enne katkestamise hetke faktiliselt teostatud Töö eest. 9. TEATED 9.1 Kõik Lepingu kohased teated, nõuded, pretensioonid või muud teated edastatakse eesti keeles, ning kirjalikku taasesitamist võimaldavas vormis teisele Poolele järgmistel kontaktandmetel: Kaitseväe Akadeemia: Milrem AS: Raul Järviste Silver Lätt Riia 12, Betooni tn 1 51010 Tartu Tallinn 13619 e-mail: [email protected] e-mail: [email protected] või mõnele muule kontaktaadressile, mille vastav Pool võib edaspidi teisele Poolel täpsustada kirjalikult. 9.2 Pooled teatavad teineteisele viivitamata kõigist muudatustest oma kontaktandmetes. Kuni sellise teate kättesaamiseni loetakse ülal nimetatud kontaktandmetele edastatud teated nõuetekohaselt edastatuks. 10. LÕPPSÄTTED 10.1 Leping jõustub selle digiallkirjastamise hetkest mõlema Poole poolt ning on kehtiv kuni Poolte kohustuste täitmiseni Lepingu alusel. 10.2 Töövõtja peab hoidma saladuses talle seoses Lepingu täitmisega teatavaks saanud asjaolusid, mille saladuses hoidmiseks on Tellijal õigustatud huvi (sealhulgas, kuid mitte ainult asjaajamist ja majandustegevust puudutavat teavet) arvestades Poolte äritegevuses väljakujunenud tavasid ja praktikat. 10.3 Lepingut võib muuta või täiendada ainult Poolte sellekohasel kirjalikul kokkuleppel. Kirjaliku vormi järgimata jätmine on tühine. Kõik Lepingu muudatused vormistatakse kirjalikult Lepingu lisana, mis on Lepingu lahutamatuks osaks. 10.4 Kumbki Pool ei tohi käesolevast Lepingust tulenevaid õigusi ja kohustusi üle anda kolmandale isikule ilma teise Poole kirjaliku nõusolekuta. 10.5 Lepingu suhtes kohaldatakse Eesti Vabariigi õigust. 10.6 Pooled lahendavad Lepingust tulenevad vaidlused heas usus läbirääkimiste teel. Kokkuleppe mittesaavutamise korral lahendatakse vaidlused Harju Maakohtus. 10.7 Lepingu tingimusteks ei loeta Poolte varasemaid tahteavaldusi ega kokkuleppeid, mis ei ole Lepingus otseselt sätestatud. Samuti ei oma Lepingu suhtes tähendust Poolte varasem käitumine. KINNITAMAKS EELTOODUT on Pooled allkirjastanud käesoleva Lepingu /allkirjastatud digitaalselt/ /allkirjastatud digitaalselt/ Milrem AS Kaitseväe Akadeemia Kuldar Väärsi kolonel Vahur Karus Lk 5 / 5  iMUGS-Decomposition of MUGS Requirements EDIDP-MUGS-2019-002-iMUGS COMPANY CONFIDENTAL iMUGS: Decomposition of the MUGS high level requirements as agreed in the 23.08.2019 signed Letter of Intent between participating Member States Decomposed Sections: VII Operational Requirements for MUGS VIII Technical Requirements for MUGS IX Requirements for development activities Sections V and VI not addressed Prepared by S.Lätt/SA/PCO Reference 10PCO005 Issue 2 Revision 0 Date of issue 07.12.2020 Status Issued for approval Document type Requirements specification Classification COMPANY CONFIDENTIAL 10PCO005 Iss 2 Rev 0 Page i of ii  iMUGS-Decomposition of MUGS Requirements EDIDP-MUGS-2019-002-iMUGS COMPANY CONFIDENTAL Decomposed Requirements Specification Reference 10PCO005 – iMUGS - ORS Document type Requirements Specification Classification COMPANY CONFIDENTIAL Location iMUGS PDM Approval Title 10PCO005 iMUGS: Decomposed Requirements Specification (Compliancy Matrix) Issue 2 Revision 0 Author S.L./SA/PCO Date 07.12.2020 Change log Reason of change Issue Rev Date Issued for acceptance to pMS QAM 1 0 30.10.2020 Template update; added legend and missing SP no, removed empty lines 162.6 and 86.3, renumbered 086.4-.6 to .3-.5. Issued for acceptance to pMS QAM and iMUGS Consortium 2 0 07.12.2020 Distribution Receiver Issue Rev Date pMS QAM PM and consequent reviewers 2 0 07.12.2020 iMUGS Consortium Partners (Industry) 2 0 07.12.2020 Initial Issue Signatures Date: __________________ Date: __________________ ________________________________ ________________________________ PCO pMS QAM PM 10PCO005 Iss 2 Rev 0 Page ii of ii EDIDP-MUGS-2019-002-iMUGS Original pMS definition is identifed as cells with background color, contrary to respective decomposed requirements without color. COMPANY CONFIDENTIAL DEMO MoM ID / ID Ref. MR ID pMS High Level Requirements (HLR) iMUGS Decomposed Mission (Operational) Requirement Req Type SOC SP NO Date Accepted 001 V.A. Section V – OPERATIONAL CHALLENGES Heading Noted 002 V.A. Known and unknown emerging technologies create a wide range of opportunities and possibilities to employ new ways and means on the battlefield. Heading Noted 003 V.A. New technologies are developed simultaneously in every continent and therefore, industry-academia-state cooperation, innovation, agility, investments in Heading Noted technology and critical thinking are substantial factors to create a competitive technological advantage to protect national and European interests. 004 V.B. Specific challenges to be taken into consideration within the scope of the Project include, without necessarily being limited to: Heading Noted 005 V.B.a. The reduced acceptance of the loss of human life in society leads to the expectation that future wars should be fought using combined unmanned and autonomous Heading Noted systems to accomplish missions with the least possible risk to soldiers. 006 V.B.b. Interoperability complexity will increase due to human-machine collaboration, a growing number of assets, processing power needed, big data analytics, throughput Heading Noted challenges and other communication/information systems limitations. 007 V.B.c. It is highly likely that the center of gravity in future wars will be population-related with military activities concentrated in and around cities, natural resources Heading Noted (including water), lines of communication, and energy/power. 008 V.B.d. The “face” of warfare may look hybrid, and it is becoming extremely hard to distinguish enemy from friend while operating in complex environments. Heading Noted 009 V.B.d. Meaningful human control over all autonomous systems remains critical. Note Noted 010 V.B.d. However, assistance from machine learning and AI for effective decision-making (e.g. positive identification, rules of engagement, etc.) will deliver a competitive Note Noted advantage on the battlefield. 011 V.B.e. Collateral damage risks increase due to the population density in operational theatres and require an accurate, up-to-date common operational picture and adequate Heading Noted information management for precise targeting. 012 V.B.f. Information is power. Heading Noted 013 V.B.f. Sensors and information gathering tools are more accessible than before. Note Noted 014 V.B.f. The amount of raw data and information continues to increase and requires enormous information systems to enable data fusion to obtain actionable intelligence. Note Noted 015 V.B.f. Artificial intelligence, machine learning and processing power are the key enablers to establish a common situational understanding and timely-made, informed Note Noted decisions. 016 V.B.g. Modern battlefield is based on co-operating units and systems creating network-enabled capabilities. Heading Noted 017 V.B.g. Thus networking is an essential force multiplier. Note Noted 018 V.B.h. Increasing Electronic Warfare and Cyber (EW&C) threats require capabilities to detect jamming and intrusion and to protect (limit and recover) the MUGS from their Heading Noted effects. 019 V.B.i. Access to position, navigation and timing is and will be more crucial than ever before, making autonomy and alternative navigation methods mission critical Heading Noted elements. 020 V.B.j. System autonomy has developed significantly over the last decade, thus minimizing the need for direct control over assets. Heading Noted 021 V.B.j. The nature of the human-machine interaction will continue to evolve in the future. Note Noted 10PCO005_2 Sub-Project for responsibility; SP1 = Integ.; SP2 = Aut.; SP3 = Cyber; SP4 = Comms; SP5 = Swarm.; SP6 = C2; SP7 = MUM-T. Demo No is for indication only. 1 / 29 EDIDP-MUGS-2019-002-iMUGS Original pMS definition is identifed as cells with background color, contrary to respective decomposed requirements without color. COMPANY CONFIDENTIAL DEMO MoM ID / ID Ref. MR ID pMS High Level Requirements (HLR) iMUGS Decomposed Mission (Operational) Requirement Req Type SOC SP NO Date Accepted 022 V.B.k. Globalization and international crises require readiness to conduct operations outside of the home country (expeditionary force). Heading Noted 023 V.B.k. New capabilities will be rapidly deployable, independent and require limited assistance to perform their duties. Note Noted 024 V.B.l. Use of off-the-shelf products increases among the Participants involved in combat activities. Heading Noted 025 V.B.l. It increases security risks for the users but also introduces exploitation opportunities. Note Noted 026 V.B.l. Off-the-shelf products may give enormous advantage in specific situations. Note Noted 027 V.B.l. The ability to control third-party, off-the-shelf resources in the operational environment works as a capability multiplier. Note Noted 028 V.B.m. New weapon systems (laser, acoustic, railguns, etc.) provide new opportunities, but on the other hand lead to new requirements and demands for force protection Heading Noted and operational security. 029 V.B.n. Psychological Operations and Internet Influence Operations are increasing and target primarily non-combatant audiences to tailor their preferences, giving both Heading Noted friendly and adversary forces an ability to quickly change the permissiveness of an operations area. 030 V.B.o. The need for longer endurance challenges the energy sector and technology development. Heading Noted 031 V.B.o. The introduction of alternative energies may change the battlefield and require readiness to adopt and implement new power systems. Note Noted 032 V.B.p. Emerging technologies allow to build greater overmatch distances to affect adversaries and, on the other hand, require advanced force protection measures from Heading Noted adversaries’ assets. 033 VI. Section VI – MUGS DESIGN PRINCIPLES AND OPERATIONAL USE CASES Heading Noted 034 VI.A. The MUGS will be a modular unmanned systems with autonomous and semi-autonomous features and deployable capability that provides the battle group or Heading Noted company commander CSS, which requires only limited/minimum man-in-the-loop involvement. 035 VI.A. MUGS will be designed for operations encompassing the entire spectrum of conflict from permissive to denied environments. Note Noted 036 VI.A. Depending on the payload, MUGS will fight battles and engagements by employing the tactical advantages of unmanned arms structure and will be used as an Note Noted enabler for supporting missions like resupply and Medical Evacuation (MEDEVAC). 037 VI.A. MUGS will accomplish its mission by integrating the actions of manned and unmanned ground vehicles, UAS, unmanned sensing systems, EW&C, AI, autonomy, Note Noted swarming, manned-unmanned teaming, and other capabilities derived from emerging technologies. 038 VI.B. MUGS ISTAR assets and automated intelligent information systems will give information superiority over threat forces. Heading Noted 039 VI.B. These assets will enable MUGS to gather large amounts of information, process them rapidly into intelligence, and disseminate them to decision-makers quickly. Note Noted 040 VI.B. AIl elements in the information systems will evaluate reliability and credibility of the gathered data and provide evidence-based conclusions, situational Note Noted understanding and recommendations for further collection or exploitation. 041 VI.C. The MUGS Project will take a fused view of EW&C and fully leverages MUGS' semi-autonomous approach, thereby significantly increasing tactical intelligence for Heading Noted greater situational understanding and informed decision-making effectiveness. 10PCO005_2 Sub-Project for responsibility; SP1 = Integ.; SP2 = Aut.; SP3 = Cyber; SP4 = Comms; SP5 = Swarm.; SP6 = C2; SP7 = MUM-T. Demo No is for indication only. 2 / 29 EDIDP-MUGS-2019-002-iMUGS Original pMS definition is identifed as cells with background color, contrary to respective decomposed requirements without color. COMPANY CONFIDENTIAL DEMO MoM ID / ID Ref. MR ID pMS High Level Requirements (HLR) iMUGS Decomposed Mission (Operational) Requirement Req Type SOC SP NO Date Accepted 042 VI.C. MUGS will take a modular approach to cyber capabilities, allowing the development and rapid deployment of additional functionality and payloads over time. Note Noted 043 VI.D. By providing processing power and the capability to interact at all layers of the communication stack in the spectrum at the tactical edge, MUGS' cyber capabilities Heading Noted will enhance friendly forces' combat power. 044 VI.D. In terms of cyber protection, the MUGS Project will deliver data integrity protection to protect sensor fusion functions, resilience to cyber-attack through Note Noted autonomous reconfiguration, and cyber supply chain security for all technology providers. 045 VI.E. MUGS will exercise common control over a variety of ground and air systems that are interlinked to the same architecture. Heading Noted 046 VI.E. A Common Control and Management System (CCMS) will allow a single individual to control multiple semi-autonomous systems using the same software suite (user Note Noted interface) and controller, therefore, maximizing the use of assets, sensors, payloads, weapon systems, data/information sharing and decision-making. 047 VI.F. MUGS will be an addition to a platoon- or company-sized infantry unit with the purpose of supporting the infantry unit’s primary role, combat, which may occur in Heading Noted any type of mission, in any theatre or environment. 048 VI.F. MUGS will be capable of moving with an infantry unit in most demanding conditions while raising the unit’s maneuverability by reducing rifleman’s individual Note Noted equipment load required to carry out the mission, making MEDEVAC drills more efficient and less manpower-dependent, and raising unit’s level of readiness, security, firepower, Intelligence, Surveillance, Reconnaissance (ISR) and EW&C capabilities. 049 VI.F. MUGS with a reduced combat payload may be used for resupply missions in a minimum man-in-the-loop mode. Note Noted 050 VI.G. MUGS will have the ability to raise asymmetric effects of use of infantry units on modern battlefield, by providing strategic, operational and tactical advantages, also, Heading Noted will make more complicated and demanding tasks available and possible for light combat and maneuver units. 051 VI.H. Specifically, the possible use cases for MUGS may include, without being limited to: Heading Noted 052 VI.H.a. Remotely-controlled combat activity using Line of Sight (LOS) control. Heading Noted 053 VI.H.a. In this mode, MUGS will be closely working together with fighting unit of platoon size, providing them transportation support and additional sustainability. Note Noted 054 VI.H.a. MUGS will have plenty of options for that, as modular design would enable multiple mission sets, which are all easily serviceable by the unit itself. Note Noted 055 VI.H.a. MUGS will manoeuvre as well as the infantry unit and will not restrict its freedom of manoeuvre or speed. Note Noted 056 VI.H.a. The control of the system will be easily switched from remote-control to semi-autonomous mode (e.g. follow-me, path/trail following, etc), making operating the Note Noted system as seamless as possible. 057 VI.H.a. In both modes, a fratricide avoidance system will provide extra safety for the fighting unit. Note Noted 058 VI.H.b. Remotely-controlled combat activity using Beyond the Line of Sight (BLOS) control. Heading Noted 059 VI.H.b. In this mode MUGS will be used for high-risk missions in the area of responsibility of an infantry company, in order to gather and provide information, security and Note Noted protection for the fighting unit. 060 VI.H.b. By use of various autonomous and automated functions for manoeuvring and data fusion, including swarm intelligence, MUGS will make operating and decision- Note Noted making for the operator as fast as possible. 061 VI.H.b. This will enable the operator to command multiple platforms, on land and in air, at the same time. Note Noted 062 VI.H.b. MUGS will have multiple passive measures for self-protection in order to operate in denied environments, while also not excluding the development of active Note Noted protection measures. 10PCO005_2 Sub-Project for responsibility; SP1 = Integ.; SP2 = Aut.; SP3 = Cyber; SP4 = Comms; SP5 = Swarm.; SP6 = C2; SP7 = MUM-T. Demo No is for indication only. 3 / 29 EDIDP-MUGS-2019-002-iMUGS Original pMS definition is identifed as cells with background color, contrary to respective decomposed requirements without color. COMPANY CONFIDENTIAL DEMO MoM ID / ID Ref. MR ID pMS High Level Requirements (HLR) iMUGS Decomposed Mission (Operational) Requirement Req Type SOC SP NO Date Accepted 063 VI.H.c. Autonomous mode for Logistics, Medical evacuation and force protection missions. Heading Noted 064 VI.H.c. In this mode, MUGS will provide for company-sized unit transportation services from the rear area to the battle area or force protection by screening the unit’s Note Noted perimeter. 065 VI.H.c. For that purpose, MUGS will be able to autonomously operate between multiple checkpoints, as long as the area is pre-mapped by the system before. Note Noted 066 VI.H.c. MUGS may be used for carrying either combat casualties or unit equipment. Note Noted 067 VII Section VII – OPERATIONAL REQUIREMENTS FOR MUGS Heading Noted 068 VII.A. Minimum operational requirements for MUGS developed under the Project are as Heading Noted follows: 069 VII.A.a. Increased situational awareness by using the platform for autonomous and Heading Noted unmanned ISR missions 070 VII.A.a.i. Exploit terrain to expedite tactical movements Heading Noted 071 VII.A.a.i.1. Capable of autonomous multihorizon path planning using data from pre-mapped Requirement Comply 2 5 environment 071.1 iMUGS operators shall be able to import maps from different sources and formats Derived Requirement 071.2 iMUGS shall be capable of mapping its environment during remotly controlled Derived operations within or without line of sight from remote operator. Requirement 071.3 iMUGS operators shall be able to record the maps which has been mapped. Derived Requirement 071.4 iMUGS shall autonomously find a path to one or several waypoints within pre- Derived mapped environment, when it is feasible Requirement 071.5 iMUGS local swarming functions shall use multi-horizon path planning with Derived interface to lower level path planner and with pre-mapped data. Requirement 071.6 Interfaces between different levels of path planners shall be defined. Derived Requirement 071.7 iMUGS global swarming shall deploy multi-horizon path planner as a single Derived process within the network, using shared data of the swarm to coorindate the Requirement swarm as a whole. 072 VII.A.a.ii. Navigate from one point to another Heading Noted 073 VII.A.a.ii.1. Capable of maneuvering autonomously from the Line of Departure to the tasked Requirement Comply 2 5 location. 073.1 iMUGS mobility platofm shall locate itself within pre-mapped environement using Derived GNSS sensor. Requirement 073.2 iMUGS operators shall be able to define the tasked location (a geolocated target Derived waypoint). Requirement 10PCO005_2 Sub-Project for responsibility; SP1 = Integ.; SP2 = Aut.; SP3 = Cyber; SP4 = Comms; SP5 = Swarm.; SP6 = C2; SP7 = MUM-T. Demo No is for indication only. 4 / 29 EDIDP-MUGS-2019-002-iMUGS Original pMS definition is identifed as cells with background color, contrary to respective decomposed requirements without color. COMPANY CONFIDENTIAL DEMO MoM ID / ID Ref. MR ID pMS High Level Requirements (HLR) iMUGS Decomposed Mission (Operational) Requirement Req Type SOC SP NO Date Accepted 073.3 iMUGS operators shall be able to set the maximum speed between each Derived waypoints. Requirement 073.4 iMUGS shall autonomously elaborate actions to move from a point to another, Derived respecting the maximum speed, with performances depending on the Requirement environment and conditions. 073.5 Local swarming shall be developed for maneuvering autonomously from the Line Derived of Departure to the tasked location. Requirement 073.6 The global route planner shall generate individual trails to be followed by Derived individual agents. Requirement 074 VII.A.a.ii.2. Capable of using alternative Global Navigation Satellite System (GNSS) capable of Requirement Comply 2 6 detecting GNSS jamming and spoofing, positioning and navigating in GNSS denied environment, simultaneous location and mapping (SLAM) 074.1 iMUGS shall re-locate itself within pre-mapped environement using passive or Derived active non GNSS sensors, with performances depending on the environment and Requirement conditions. 074.2 iMUGS shall position and navigate within pre-mapped environement using Derived passive or active non GNSS sensors, with performances depending on the Requirement environment and conditions. 074.3 iMUGS shall detect GNSS jamming. Derived Requirement 074.4 iMUGS shall detect GNSS spoofing. Derived Requirement 074.5 iMUGS shall detect inconsistencies between GNSS fleets. Derived Requirement 074.6 iMUGS shall be capable of simultaneous location and mapping, with Derived performances depending on the environment and conditions. Requirement 074.7 Local swarming shall be developed for navigating also in GNSS denied Derived environment using positioning and mapping information from platform sensors. Requirement 074.8 Global swarming shall be designed to use the UWB distance mesh of the fleet and Derived other on board sensors to provide GNSS free positioning, the aim is to have a Requirement sufficiently accurate positioning to enable navigation. 075 VII.A.a.ii.3. Allow a single operator to control multiple systems using the same software suite Requirement Comply 6 6 and controller 075.1 Local swarming shall be developed to act upon operator controls when receiving Derived them. Requirement 075.2 An interface shall be developed to control the fleet as a whole using global Derived swarming Requirement 10PCO005_2 Sub-Project for responsibility; SP1 = Integ.; SP2 = Aut.; SP3 = Cyber; SP4 = Comms; SP5 = Swarm.; SP6 = C2; SP7 = MUM-T. Demo No is for indication only. 5 / 29 EDIDP-MUGS-2019-002-iMUGS Original pMS definition is identifed as cells with background color, contrary to respective decomposed requirements without color. COMPANY CONFIDENTIAL DEMO MoM ID / ID Ref. MR ID pMS High Level Requirements (HLR) iMUGS Decomposed Mission (Operational) Requirement Req Type SOC SP NO Date Accepted 075.3 iMUGS C2 shall allow a single operator to control and monitor several UGVs from Derived the same position. Requirement 075.4 iMUGS Control Station shall be designed to allow integration of a control station / Derived control elements into an Armoured Fighting Vehicle. (Command Vehicle Requirement Configuration) 076 VII.A.a.iii. Conduct a zone reconnaissance Heading Noted 077 VII.A.a.iii.1. Capable of sensing battlefield elements using, for example, onboard, dispersed or Requirement Comply 1 4 tethered electro-optical, thermal, infrared, acoustic, Signal Intelligence (SIGINT) and radar sensors 077.1 Local swarming shall be developed to use available data from the sensors. Derived Requirement 077.2 The global swarming controller shall collect available data on board and forward Derived the necessary information to the global planner Requirement 077.3 iMUGS shall have standardised interfaces for sensors on mobility platform and as Derived payloads. Requirement 078 VII.A.a.iv. Conduct targeting Heading Noted 079 VII.A.a.iv.1. Capable of detecting, classifying, positioning and tracking autonomously different Requirement Comply 2 5 types of pre-determined objects on the battlefield using data from different platforms 079.1 iMUGS operators shall be able to select objects types to detect on the battelfield, Derived among a list of pre-determined objects. Requirement 079.2 iMUGS shall autonomously detect and classify the different types of pre- Derived determined objects using data from different sensors or platforms. Requirement 079.3 iMUGS shall autonomously position different types of static pre-determined Derived objects using data from different sensors or plateforms, if needed Requirement 079.4 MUGS shall autonomously track different types of pre-determined objects Derived (vehicles, pedestrians, etc), using data from different sensors or platforms. Requirement 079.5 iMUGS C2 shall receive information of battlefield objects detected by UGV(s) Derived autonomous functions. Requirement 079.6 iMUGS C2 shall send information of battlefield objects to the UGV(s) autonomous Derived functions. Requirement 079.7 iMUGS C2 shall receive and display information from UGV sensors/payloads. Derived Requirement 10PCO005_2 Sub-Project for responsibility; SP1 = Integ.; SP2 = Aut.; SP3 = Cyber; SP4 = Comms; SP5 = Swarm.; SP6 = C2; SP7 = MUM-T. Demo No is for indication only. 6 / 29 EDIDP-MUGS-2019-002-iMUGS Original pMS definition is identifed as cells with background color, contrary to respective decomposed requirements without color. COMPANY CONFIDENTIAL DEMO MoM ID / ID Ref. MR ID pMS High Level Requirements (HLR) iMUGS Decomposed Mission (Operational) Requirement Req Type SOC SP NO Date Accepted 079.8 Local swarming shall be developed to use available labelled object data. Derived Requirement 079.9 The global swarming controller shall collect available data on board and forward Derived the necessary information to the global planner Requirement 080 VII.A.a.v. Provide tactical intelligence overwatch Heading Noted 081 VII.A.a.v.1. Capable of processing and classifying collected data autonomously and Requirement Comply 2 6 distributing near-real-time and fused robot-centric battlefield information over the network following “need to know” principles, making probability assessments 081.1 iMUGS shall be able collect, date, label, manage and store data. Derived Requirement 081.2 iMUGS shall autonomously process and classify (label) the collected data. Derived Requirement 081.3 iMUGS shall distribute near-real-time and fused platform-centric battlefield Derived information over the network following "need to know" principles. Requirement 081.4 iMUGS shall assess distributed data confidence with probabilities. Derived Requirement 081.5 The global swarming shall forward necessary data to subscribes on DDS nodes. Derived Requirement 082 VII.A.a.v.2. Capable of interacting and integrating with a larger hub vehicle for receiving Requirement Comply 1 4 logistics support (including transportation, refueling and power supply), and support for Command and Control (C2) data link and EW capacities. 082.1 Local swarming shall be developed for driving MUGS vehicles on low energy level Derived to refuel or recharge to a preknown larger hub vehicle. Requirement 082.2 The global swarming presumes being networked, either local or in a large scale Derived network Requirement 082.3 Vehicle shall have standardised interfaces for interacting with hub vehicles. Derived Requirement 083 VII.A.a.vi. Perform electronic protection actions Heading 084 VII.A.a.vi.1. Capable of detecting jamming, locating jammer and operating in jammed Requirement Comply 4 3 environment. 10PCO005_2 Sub-Project for responsibility; SP1 = Integ.; SP2 = Aut.; SP3 = Cyber; SP4 = Comms; SP5 = Swarm.; SP6 = C2; SP7 = MUM-T. Demo No is for indication only. 7 / 29 EDIDP-MUGS-2019-002-iMUGS Original pMS definition is identifed as cells with background color, contrary to respective decomposed requirements without color. COMPANY CONFIDENTIAL DEMO MoM ID / ID Ref. MR ID pMS High Level Requirements (HLR) iMUGS Decomposed Mission (Operational) Requirement Req Type SOC SP NO Date Accepted 084.1 The communication network status shall be monitored. Derived Requirement 084.2 The tactical communication network shall monitor network and link statuses, Derived provide quality and alarms in real-time. Requirement 084.3 Communication shall provide an external interface to extract network status data. Derived Requirement 084.4 Communications system shall provide a tool for recording network events for Derived collecting big data to later analysis. Requirement 084.5 The communicationns shall provide intelligent methods to detect and report Derived jamming at node level Requirement 084.6 Jamming may be detected by using information from multiple sources and OSI Derived layers. Requirement 084.7 Jamming source may be located with the help of multiple nodes. Derived Requirement 084.8 The network nodes shall be capable of monitoring the radio spectrum and Derived processing the measurement results with AI-based methods to detect e.g. Requirement anomalities and to reduce the data that needs to be transferred to network management 084.9 Local swarming is developed for operating in jammed environment according to Derived local swarming's rules. Requirement 084.10 Global swarming will immediatly notice deteriorating network conditions Derived Requirement 085 VII.A.a.vi.2. Capable of avoiding detection by enemy EW assets. Requirement Comply 1 3 085.1 Tactical communication equipment shall be able to operate lowest possible Derived output power level. Requirement 085.2 The tactical communication equipment shall use electronically controlled Derived directive antennas with the beam control synchronized to the transmission / Requirement reception of the nodes. 085.3 The tactical network shall use Low Probability of Intercept (LPI) waveforms Derived capable of, for example, frequency hopping. Requirement 085.4 Vehicle shall have RF and active sensor emission control functionality interface. Derived Requirement 085.5 Local swarming shall be developed for avoiding known locations of enemy EW Derived assets. Requirement 10PCO005_2 Sub-Project for responsibility; SP1 = Integ.; SP2 = Aut.; SP3 = Cyber; SP4 = Comms; SP5 = Swarm.; SP6 = C2; SP7 = MUM-T. Demo No is for indication only. 8 / 29 EDIDP-MUGS-2019-002-iMUGS Original pMS definition is identifed as cells with background color, contrary to respective decomposed requirements without color. COMPANY CONFIDENTIAL DEMO MoM ID / ID Ref. MR ID pMS High Level Requirements (HLR) iMUGS Decomposed Mission (Operational) Requirement Req Type SOC SP NO Date Accepted 085.6 Global swarming takes known EW assets into account in the optimization. Derived Requirement 086 VII.A.a.vi.3. Capable of operating in crowded and hostile electromagnetic spectrum by Requirement Comply 4 3 cognitive use of electromagnetic spectrum. 086.1 The tactical communication equipment shall support multiple frequencies and Derived frequency hopping Requirement 086.2 The tactical communication equipment shall be able to change frequency or the Derived FH pattern when needed Requirement 86,3 The tactical communication system shall support multiple modulation and coding Derived schemes in order to reduce the jamming effects. Requirement 86,4 The tactical communication system shall be capable of deploying directional Derived antennas. Requirement 86,5 The tactical communication system may use other anti-jamming methods. Derived Requirement 087 VII.A.a.vii. Conduct risk management Heading Noted 088 VII.A.a.vii.1. Capable of recording and preserving the system data for at least 3 days Requirement Comply 1 4 088.1 Vehicle shall be equipped with a data storage to store 72 hours of set of recorded Derived sensor and telemetry data Requirement 089 VII.A.a.vii.2. Capable of evaluating reliability and credibility of the gathered data and provide Requirement Comply 1 6 evidence-based conclusions, situational understanding and recommendations for further collection or exploitation 089.1 Vehicle shall have datalogger with comprehensive fault logging capability. Derived Requirement 090 VII.A.a.viii. Develop and implement command safety program Heading Noted 091 VII.A.a.viii.1. Capable of applying preprogrammed action plans in case of data link is cut down Requirement Comply 2 5 or overloaded, by use of preprogrammed action plans until the first decision- making point 091.1 Local swarming shall be developed for applying its rules in case of data link Derived malfunctions. Requirement 091.2 Global swarming shall include fallback strategies in case of data link loss Derived Requirement 10PCO005_2 Sub-Project for responsibility; SP1 = Integ.; SP2 = Aut.; SP3 = Cyber; SP4 = Comms; SP5 = Swarm.; SP6 = C2; SP7 = MUM-T. Demo No is for indication only. 9 / 29 EDIDP-MUGS-2019-002-iMUGS Original pMS definition is identifed as cells with background color, contrary to respective decomposed requirements without color. COMPANY CONFIDENTIAL DEMO MoM ID / ID Ref. MR ID pMS High Level Requirements (HLR) iMUGS Decomposed Mission (Operational) Requirement Req Type SOC SP NO Date Accepted 091.3 iMUGS shall detect data link cut down. Derived Requirement 091.4 iMUGS shall detect data link overload. Derived Requirement 091.5 iMUGS operators shall be able to choose an action plans to conduct among the Derived pre-programmed possibilities. Requirement 091.6 iMUGS shall be able to apply the pre-programmed actions until the first decision- Derived making point. Requirement 091.7 iMUGS shall be able to stop autonomously Derived Requirement 092 VII.A.a.viii.2. Capable of automated detection and response to cyber-attacks Requirement Comply 6 092.1 iMUGS shall encompass Cyber Defence System to automatically detect and Derived respond to cyber-attacks. Requirement 092.2 The Cyber Ddefense System shall detect known cyber-attacks that originate within Derived the iMUGS platform. Requirement 092.3 The Cyber Defense System shall detect known cyber-attacks that originate from Derived connected external systems. Requirement 092.4 The Cyber Defense System shall help detect physical actions taken against the Derived system to enable cyber-attacks. Requirement 092.5 The Cyber Defense System shall help detect EW actions taken against the system Derived to enable cyber-attacks. Requirement 092.6 The Cyber Defense System shall recommend a response to a detected cyber Derived attack that allows a graceful degradation of the platform where possible. Requirement 092.7 The Cyber Defense System shall recommend the actions to disconnect Derived components from networks, reset components, or power off components in Requirement order to implement a decided response. 092.8 The Cyber Defence System shall provide a human interface. Derived Requirement 092.9 The Cyber Defence System shall have interfaces to other components as required Derived to achieve its purpose. Requirement 093 VII.A.b. Lightened soldier workload by using the platform for carrying squad sized unit Heading Noted equipment during tactical movements on foot and by using autonomous mobility software and intuitive control pad 10PCO005_2 Sub-Project for responsibility; SP1 = Integ.; SP2 = Aut.; SP3 = Cyber; SP4 = Comms; SP5 = Swarm.; SP6 = C2; SP7 = MUM-T. Demo No is for indication only. 10 / 29 EDIDP-MUGS-2019-002-iMUGS Original pMS definition is identifed as cells with background color, contrary to respective decomposed requirements without color. COMPANY CONFIDENTIAL DEMO MoM ID / ID Ref. MR ID pMS High Level Requirements (HLR) iMUGS Decomposed Mission (Operational) Requirement Req Type SOC SP NO Date Accepted 094 VII.A.b.i. Conduct an approach march Heading Noted 095 VII.A.b.i.1. Capable of moving autonomously with infantry troops on foot over rugged and Requirement Comply 2 1,5,6 heavily vegetated terrain 095.1 iMUGS shall move over rugged and heavily vegetated terrain, with performances Derived depending on the conditions. Requirement 095.2 iMUGS shall move autonomously with infantry troops on foot, when the leader is Derived visible, and with performances depending on the conditions. Requirement 095.3 Local swarming shall be developed for moving with dismounted infantry speed. Derived Requirement 095.4 Global swarming shall include the swarm behavior to track and follow a beacon Derived carried by the infantry troops Requirement 096 VII.A.b.ii. Perform fratricide avoidance Heading Noted 097 VII.A.b.ii.1. Capable of avoiding harming humans, vehicles and equipment, in order to provide Requirement Comply 1 5 additional safety compared to remote-controlled platforms 097.1 Mobility platofrm shall have interfaces to receive obstacle avoidance data and Derived perform safety actions (emergency stop, etc) and alert the operator Requirement 097.2 Mobility platform shall have obstacle detection algorithm to stop the vehicle if Derived close to stationary or moving objects and report to the operator about the Requirement obstacle 097.3 Local swarming shall be developed for avoiding harming humans, known vehicles Derived and equipment within its functions. Requirement 097.4 Global swarming shall include high-level safety mechanisms, but relies on Derived Autonomy features for the real-time safety-critical aspects. Requirement 098 VII.A.b.iii. Overcome barriers and obstacles and other features to be defined Heading Noted 099 VII.A.b.iii.1. Capable of planning the route to overcome obstacles Requirement Comply 2 5 099.1 Local swarming is developed for planning routes avoiding known obstacles. Derived Requirement 099.2 Global swarming is developed for planning routes avoiding known obstacles. Derived Requirement 10PCO005_2 Sub-Project for responsibility; SP1 = Integ.; SP2 = Aut.; SP3 = Cyber; SP4 = Comms; SP5 = Swarm.; SP6 = C2; SP7 = MUM-T. Demo No is for indication only. 11 / 29 EDIDP-MUGS-2019-002-iMUGS Original pMS definition is identifed as cells with background color, contrary to respective decomposed requirements without color. COMPANY CONFIDENTIAL DEMO MoM ID / ID Ref. MR ID pMS High Level Requirements (HLR) iMUGS Decomposed Mission (Operational) Requirement Req Type SOC SP NO Date Accepted 099.3 iMUGS shall identify static obstacles Derived Requirement 099.4 iMUGS shall find a crossing or bypassing strategy to overcome static obstacles, Derived when it is feasible Requirement 099.5 iMUGS shall adapt its mobility strategy to overcome obstacles (speed, etc.) Derived Requirement 100 VII.A.b.iv. Provide transportation support Heading Noted 101 VII.A.b.iv.1. Capable of carrying squad-sized troop equipment during the foot march Requirement Comply 1 1 101.1 iMUGS shall be capable of carrying squad-sized troop equipment during a foot Derived march. Requirement 102 VII.A.b.iv.2. Capable of sustaining the foot march over 8 hours in most difficult terrain one day Requirement Comply 1 1 period without any need for fuel resupply 102,1 iMUGS shall be capable of sustaining the foot march over 8 hours in respective Derived terrain over one day period without any need for fuel resupply. Requirement 103 VII.A.b.v. Provide information support for operator Heading Noted 104 VII.A.b.v.1. Share system status and problems with controller through one-hand intuitive Requirement Comply 1 3 controller pad. 104.1 Vehicle shall send telemetry information in real-time to one-hand operator Derived control unit Requirement 105 VII.A.c. Increased force protection by using the system for autonomous navigation and Heading Noted unmanned missions to threat areas to discover and remotely controlled neutralize or provide cover for fighting units and remote systems from possible threats 106 VII.A.c.i. Conduct Area and Base Security Operations Heading Noted 107 VII.A.c.i.1. Capable of moving autonomously along a preplanned patrol route Requirement Comply 2 4 107.1 iMUGS shall be able to record its route in different modes Derived Requirement 107.2 iMUGS shall be able to import route from different sources and formats. Derived Requirement 10PCO005_2 Sub-Project for responsibility; SP1 = Integ.; SP2 = Aut.; SP3 = Cyber; SP4 = Comms; SP5 = Swarm.; SP6 = C2; SP7 = MUM-T. Demo No is for indication only. 12 / 29 EDIDP-MUGS-2019-002-iMUGS Original pMS definition is identifed as cells with background color, contrary to respective decomposed requirements without color. COMPANY CONFIDENTIAL DEMO MoM ID / ID Ref. MR ID pMS High Level Requirements (HLR) iMUGS Decomposed Mission (Operational) Requirement Req Type SOC SP NO Date Accepted 107.3 iMUGS shall be able to move autonomously along a preplanned route (i.e. a set of Derived waypoints) Requirement 107.4 Local swarming is developed for area patrolling function. Derived Requirement 107.5 Global swarming will include a route patrolling modus Derived Requirement 108 VII.A.c.ii. Protect against enemy hazards in the area of operations Heading Noted 109 VII.A.c.ii.1. Capable of employing modular ballistic protection for fighting units and systems. Requirement Comply 1 3 109.1 iMUGS shall be capable of employing modular ballistic protection for fighting Derived units and systems. Requirement 110 VII.A.c.ii.2. Capable of employing smoke/obscurant/close-in jamming Requirement Comply 1 3 110.1 iMUGS shall have functionality and interfaces to deploy obscurant. Derived Requirement 110.2 iMUGS shall have interface to a close-in jamming device. Derived Requirement 111 VII.A.c.ii.3. Capable of identifying hazards from the battlefield such as, but not limited to, Requirement Comply 1 1 detection of direct fire rounds fired at the vehicle, detection of mortar and artillery impacts in close vicinity of the vehicle, laser targeting and ranging 111.1 Local swarming uses information of hazard from the battlefield in its force Derived protection function. Requirement 111.2 Global swarming uses information of hazard from the battlefield in its force Derived protection function. Requirement 111.3 Vehicle shall be able to interface acoustic shot detection, laser targeting and Derived ranging detection system Requirement 112 VII.A.c.ii.4. Capable of providing real-time, fused and sufficient information to controller to Requirement Comply 1 4 make decisions, to assess precision and effects of countermeasures 112.1 Local swarming is developed for sharing its status information to operator when Derived possible. Requirement 112.2 iMUGS shall have capability to sharing its sensor and system information to Derived operator when possible. Requirement 10PCO005_2 Sub-Project for responsibility; SP1 = Integ.; SP2 = Aut.; SP3 = Cyber; SP4 = Comms; SP5 = Swarm.; SP6 = C2; SP7 = MUM-T. Demo No is for indication only. 13 / 29 EDIDP-MUGS-2019-002-iMUGS Original pMS definition is identifed as cells with background color, contrary to respective decomposed requirements without color. COMPANY CONFIDENTIAL DEMO MoM ID / ID Ref. MR ID pMS High Level Requirements (HLR) iMUGS Decomposed Mission (Operational) Requirement Req Type SOC SP NO Date Accepted 113 VII.A.d. Increased sustainability of the fighting unit by using the platform for autonomous Heading Noted and unmanned resupply missions of fighting unit, as a power bank and by providing communications support 114 VII.A.d.i. Provide MEDEVAC and supplies Heading Noted 115 VII.A.d.i.1. Capable of carrying minimum of two casualties and/or total payload of 600 kg of Requirement Comply 1 1 supplies 115.1 Capable of carrying minimum of two casualties and/or total payload of 600 kg of Derived supplies Requirement 116 VII.A.d.ii. Provide electricity Heading Noted 117 VII.A.d.ii.1. Capable of producing electric power for charging troop's batteries and tethered Requirement Comply 1 1 Unmanned Aerial System (UAS) 117.1 Vehicle shall have NATO standard interfaces for charging troop's batteries and Derived tethered Unmanned Aerial System (UAS). Requirement 118 VII.A.d.iii. Provide network transport and information services Heading Noted 119 VII.A.d.iii.1. Capable of increasing communications distances by acting as relay station Requirement Comply 4 1 119.1 The tactical networks shall support relaying and routing feature as per mobile ad Derived hoc or other selected network protocols allowing multi-hop relaying. Requirement 119.2 The network shall be able to reliably route IP packets via multiple routes Derived Requirement 119.3 The communication system shall be capable of relaying IP packets over all Derived available radio networks including commercial mobile networks. Requirement 119.4 Local swarming shall include a relay network behavour. Derived Requirement 119.5 Global swarming will include a relaying behavior. Derived Requirement 120 VII.A.d.iii.2. Capable of utilizing multiple wireless communications technologies, including Requirement Comply 4 3 tactical and commercial networks 10PCO005_2 Sub-Project for responsibility; SP1 = Integ.; SP2 = Aut.; SP3 = Cyber; SP4 = Comms; SP5 = Swarm.; SP6 = C2; SP7 = MUM-T. Demo No is for indication only. 14 / 29 EDIDP-MUGS-2019-002-iMUGS Original pMS definition is identifed as cells with background color, contrary to respective decomposed requirements without color. COMPANY CONFIDENTIAL DEMO MoM ID / ID Ref. MR ID pMS High Level Requirements (HLR) iMUGS Decomposed Mission (Operational) Requirement Req Type SOC SP NO Date Accepted 120.1 The communication system is capable of handling multiple simultaneous Derived connections via different networks including tactical, special V2V and commercial Requirement networks (e.g. mobile / satellite etc), and capable of routing data over the available channels in an intelligent manner. 120.2 When commercial network is used, the data shall be protected with stronger Derived encryption - VPN. Requirement 120.3 The stronger encryption solution (VPN) shall include: Derived - Block ciphers Requirement - Hash functions - Authenticated encryption with integrity check - Digital signature algorithms - Key exchange algorithms 120.4 The interface point between tactical and commercial network shall be protected Derived by a firewall solution. Requirement 121 VII.A.e. Facilitated deployability by deploying the system quickly and cheaply to the Heading Noted operation area by using the preexisting logistic system or manned combat vehicle. 122 VII.A.e.i. Prepare Forces for Movement. Heading Noted 123 VII.A.e.i.1. Capable of assembling or dissembling system in a fast and easy manner by one Requirement Comply 1 1 person in one hour 123.1 iMUGS mobility platform shall be capable of being assembled or dissembled in a Derived fast and easy manner by one person in one hour. Requirement 124 VII.A.e.ii. Conduct operational deployment and redeployment activities Heading Noted 125 VII.A.e.ii.1. Capable of moving system by sling load or in a cargo department of preexisting Requirement Comply 1 1 helicopters of Partners 125.1 iMUGS shall be capable of being moved by sling load or in a cargo department of Derived preexisting helicopters of Partners. Requirement 126 VII.A.e.ii.2. Capable of moving system in a cargo department of preexisting transport plane of Requirement Comply 1 1 Partners 126.1 iMUGS shalle be capable of being moved in a cargo department of preexisting Derived transport plane of Partners. Requirement 127 VII.A.e.ii.3. Capable of moving system by towing and in a cargo area of preexisting trucks of Requirement Comply 1 1 Partners 127.1 iMUGS shall be capable of bein moved in a cargo area of preexisting trucks of Derived Partners. Requirement 10PCO005_2 Sub-Project for responsibility; SP1 = Integ.; SP2 = Aut.; SP3 = Cyber; SP4 = Comms; SP5 = Swarm.; SP6 = C2; SP7 = MUM-T. Demo No is for indication only. 15 / 29 EDIDP-MUGS-2019-002-iMUGS Original pMS definition is identifed as cells with background color, contrary to respective decomposed requirements without color. COMPANY CONFIDENTIAL DEMO MoM ID / ID Ref. MR ID pMS High Level Requirements (HLR) iMUGS Decomposed Mission (Operational) Requirement Req Type SOC SP NO Date Accepted 127.2 iMUGS shall be capable of towed deployment with a larger vehicle. Derived Requirement 128 VII.A.e.ii.4. Capable of moving system by rail or sea lift. Requirement Comply 1 1 128.1 iMUGS shall be capable of being moved by rail or sea lift. Derived Requirement 129 VII.A.f. Increased interoperability and affordability of the force, by using the standardized Heading Noted technology and modular and open system architecture for the platform 130 VII.A.f.i. Use standard fuel for engine operation Requirement Comply 1 1 130.1 iMUGS shall use standard fuel for engine operation. Derived Requirement 131 VII.A.f.ii. Use radio-agnostic solutions for data links and encryption to provide connectivity Requirement Comply 4 2 with different communication systems 131.1 All iMUGS communication links shall support IP traffic. Derived Requirement 131.2 Any encryption methods shall be applied so, that any IP traffic can pass through it. Derived Requirement 132 VII.A.f.iii. Possibility to use wired control Requirement Comply 1 1 132.1 Vehicle shall be controllable by using a wired connection. Derived Requirement 133 VII.A.f.iv. Use standardized modality to code sensor data Requirement Comply 2 4 133.1 iMUGS sensor data shall be coded with standardized data formats. Derived Requirement 133.2 iMUGS sensor data shall be collected and shared through a dedicated backbone, Derived with a well defined standardized interface Requirement 134 VII.A.f.v. Use standardized and open system architecture, including NATO Generic Vehicle Requirement Comply 1 4 Architecture (STANAG 4754), Unmanned Ground Vehicle (UGV) Interoperability Profile (STANAG 4818) and Robot Operating System (ROS) 134.1 iMUGS shall use standardized and open system architecture, including NATO Derived Generic Vehicle Architecture Requirement 10PCO005_2 Sub-Project for responsibility; SP1 = Integ.; SP2 = Aut.; SP3 = Cyber; SP4 = Comms; SP5 = Swarm.; SP6 = C2; SP7 = MUM-T. Demo No is for indication only. 16 / 29 EDIDP-MUGS-2019-002-iMUGS Original pMS definition is identifed as cells with background color, contrary to respective decomposed requirements without color. COMPANY CONFIDENTIAL DEMO MoM ID / ID Ref. MR ID pMS High Level Requirements (HLR) iMUGS Decomposed Mission (Operational) Requirement Req Type SOC SP NO Date Accepted 134.2 iMUGS shall follow (UGV) Interoperability Profile (STANAG 4818) - when Derived promulgated. Requirement 134.3 iMUGS shall use Robotic Operating System framework. Derived Requirement 134.4 Local swarming is developed using ROS where possible. Derived Requirement 134.5 Global swarming will be based on the ROS2 framework Derived Requirement 135 VII.A.f.vi. Exchange information with preexisting Battlefield Management System (BMS) and Requirement Comply 6 5 Command and Control Information Systems (C2I) systems via standardized interface 135.1 iMUGS C2 shall implement NATO NFFI and NATO ISR interoperability standards. Derived Requirement 135.2 iMUGS C2 shall send UGVs positions to external C2/C4I as NFFI tracks. Derived Requirement 135.3 iMUGS C2 shall be interoperable with a NATO STANAG 4559 CSD server for Derived dissemination of ISR data received from UGV sensors/payloads. Requirement 136 VII.A.f.vii. Use modular payloads and standardized connections Requirement Comply 1 5 136.1 iMUGS shall use modular payloads and standardized connections Derived Requirement 137 VII.A.f.viii. Use standardized digital battlefield data links and encryption Requirement Comply 6 5 137.1 All data links shall be digital. Derived Requirement 137.2 Standardized data links deployed by the manned ground forces shall be Derived supported. The system is capable of deploying European standard IP-data Requirement waveforms such as as the ESSOR waveforms. 137.3 Commercial data links shall be implemented using standardized 3GPP (4G/5G) Derived and/or IEEE (WIFI) links. Requirement 137.4 The data link encryption shall be implemented using standardized solutions for Derived example, but not limited to, those mentioned in NIST SP 800-175B Requirement 137.5 iMUGS C2 will support IP conectivity with communication equipment. Derived Requirement 10PCO005_2 Sub-Project for responsibility; SP1 = Integ.; SP2 = Aut.; SP3 = Cyber; SP4 = Comms; SP5 = Swarm.; SP6 = C2; SP7 = MUM-T. Demo No is for indication only. 17 / 29 EDIDP-MUGS-2019-002-iMUGS Original pMS definition is identifed as cells with background color, contrary to respective decomposed requirements without color. COMPANY CONFIDENTIAL DEMO MoM ID / ID Ref. MR ID pMS High Level Requirements (HLR) iMUGS Decomposed Mission (Operational) Requirement Req Type SOC SP NO Date Accepted 138 VII.A.f.ix. Use standardized data format for geoinformation, mapping, positioning etc. Requirement Comply 1 5 138.1 iMUGS C2 will support standardized data format for geoinformation, mapping and Derived positioning data. Requirement 138.2 Local swarming is developed for sharing its status information with standardized Derived geoinformation. Requirement 138.3 Global swarming is developed for sharing its status information with standardized Derived geoinformation. Requirement 139 VII.B. All autonomy related capabilities will ensure a sufficient degree of human control Heading Noted as well as the ability to conduct operations in compliance with national and international law, in particular international humanitarian law, where applicable. 140 VIII Section VIII – TECHNICAL SPECIFICATIONS FOR MUGS Heading Noted 141 VIII.A. The development of MUGS will be conducted according to the following inter- Note Noted linked and transferable technological packages: 142 VIII.A.a. Modular, multi-mission-capable UGV on which a variety of payloads can be Heading Noted mounted to support various mission functionalities (transport, fire-support, ISR, EW&C, etc.) and integration for required sensors and communication systems. 143 VIII.A.a. The package will include: Note Noted 144 VIII.A.a.i. Development of the base mobility platform. Requirement Comply 1 1 144.1 iMUGS shall develop a base mobility platform. Derived Requirement 145 VIII.A.a.i. Assessed and assigned TRL rating for the solution will be at least TRL 6. Requirement Comply 1 1 145.1 The TRL of the base mobility platform shall be 6. Derived Requirement 146 VIII.A.a.ii. Development of a logistics solution using a pre-existing combat vehicle Requirement Comply 7 2 (transporting combat units) for safely and quickly dispatching unmanned ground and aerial vehicles, with minimal human effort. 146.1 Integration of the UAV transport/take-off/landing box and the belonging Derived components to a pre-existing combat vehicle. Requirement 10PCO005_2 Sub-Project for responsibility; SP1 = Integ.; SP2 = Aut.; SP3 = Cyber; SP4 = Comms; SP5 = Swarm.; SP6 = C2; SP7 = MUM-T. Demo No is for indication only. 18 / 29 EDIDP-MUGS-2019-002-iMUGS Original pMS definition is identifed as cells with background color, contrary to respective decomposed requirements without color. COMPANY CONFIDENTIAL DEMO MoM ID / ID Ref. MR ID pMS High Level Requirements (HLR) iMUGS Decomposed Mission (Operational) Requirement Req Type SOC SP NO Date Accepted 146.2 Integration of components for the deployment of a UGV to a pre-existing combat Derived vehicle. Requirement 146.3 Integration of control stations for UGV and UAV in a pre-existing combat vehicle. Derived Requirement 147 VIII.A.a.ii. The method should avoid slowing down dispatching troops and thereby Requirement Comply 1 1 exacerbating risks. 147.1 iMUGS deployment method should avoid slowing down dispatching troops and Derived thereby exacerbating risks. Requirement 148 VIII.A.a.ii. The method should be as autonomous as possible, in particular for dull, Requirement Comply 1 3 dangerous and dirty missions. 148.1 iMUGS deployment method should be as autonomous as possible, in particular Derived for dull, dangerous and dirty missions. Requirement 149 VIII.A.a.ii. Assessed and assigned TRL rating for the solution will be at least TRL 5. Requirement Comply 1 3 149.1 Assessed and assigned TRL rating for the deployment solution will be at least TRL Derived 5. Requirement 150 VIII.A.a.iii. Demonstration of at least three pre-existing payload integration to the base Requirement Comply 1 4 mobility platform. 150.1 iMUGS shall demontrate at least three pre-existing payload integration to the Derived base mobility platform. Requirement 151 VIII.A.a.iii. Mission kits for autonomous ISR and force protection missions and tethered UAS Requirement Comply 1 4 solution are considered as mandatory. 151.1 iMUGs shall demonstrate mission kits for autonomous ISR and force protection Derived missions and tethered UAS. Requirement 152 VIII.A.b. EW resistant networking Command, Control & Communications (C3) solution. Heading Noted 153 VIII.A.b. This package will capture multiple integrated elements: Note Noted 154 VIII.A.b.i. Development of the secure mesh service layers for predefined local or wide-area Requirement Partial 4 3 radio systems for IP-based information exchange and C2 of multiple platforms. 154.1 iMUGS shall demonstrate a secure service mesh service layer for predefined local Derived or wide-area radio systems for IP-based information exchange. Requirement 10PCO005_2 Sub-Project for responsibility; SP1 = Integ.; SP2 = Aut.; SP3 = Cyber; SP4 = Comms; SP5 = Swarm.; SP6 = C2; SP7 = MUM-T. Demo No is for indication only. 19 / 29 EDIDP-MUGS-2019-002-iMUGS Original pMS definition is identifed as cells with background color, contrary to respective decomposed requirements without color. COMPANY CONFIDENTIAL DEMO MoM ID / ID Ref. MR ID pMS High Level Requirements (HLR) iMUGS Decomposed Mission (Operational) Requirement Req Type SOC SP NO Date Accepted 155 VIII.A.b.i. Assessed and assigned TRL rating for the solution will be at least TRL 5. Requirement Comply 4 3 155.1 The TRL rating for the secure service mesh layer solution will be at least TRL 5. Derived Requirement 156 VIII.A.b.ii. Development of enabling software for Common Operational Picture purpose, Requirement Comply 6 5 capable of transferring codified messages from the platform to pre-defined BMS solutions. 156.1 iMUGS C2 will present a Tactical Situation Map with battlefield information to the Derived operator. Requirement 156.2 iMUGS C2 Situation Map will present tactical information entered by C2 Operator, Derived UGVs position and operational status, and information received from external Requirement C2/C4ISR systems (through interoperability protocols supported by iMUGS C2). 156.3 iMUGS C2 will enable operator to define in the Situation Map routes for UGVs, Derived patrolling areas for UGVs, obstacles and threats for UGVs. Requirement 157 VIII.A.b.ii. Assessed and assigned TRL rating for the solution will be at least TRL 5. Requirement Comply 6 5 157.1 iMUGS C2 shall reach a TRL-5 Derived Requirement 158 VIII.A.b.iii. Development of digitalized C2 interface for the hub (“command-pad”) and Requirement Comply 6 6 integration with sensor data and artificial intelligence enabled software for BLOS missions. 158.1 iMUGS C2 will enable operator to create and send orders to UGV(s) autonomous Derived functions for BLOS missions. Requirement 158.2 iMUGS C2 will enable operator to monitor UGV BLOS autonomous missions Derived execution. Requirement 158.3 Local swarming is developed for sharing its status information to operator and Derived receiving operator commands when possible. Requirement 158.4 Global swarming is developed for sharing its status information to operator and Derived receiving operator commands when possible. Requirement 159 VIII.A.b.iii. Assessed and assigned TRL rating for the solution will be at least TRL 5. Requirement Comply 6 6 159.1 iMUGS C2 interface shall reach a TRL-5. Derived Requirement 160 VIII.A.b.iv. Development of intuitive one-hand Command & Control interface for dismounted Requirement Comply 1 3 troops (“control-pad”) for LOS and Close Support missions. 10PCO005_2 Sub-Project for responsibility; SP1 = Integ.; SP2 = Aut.; SP3 = Cyber; SP4 = Comms; SP5 = Swarm.; SP6 = C2; SP7 = MUM-T. Demo No is for indication only. 20 / 29 EDIDP-MUGS-2019-002-iMUGS Original pMS definition is identifed as cells with background color, contrary to respective decomposed requirements without color. COMPANY CONFIDENTIAL DEMO MoM ID / ID Ref. MR ID pMS High Level Requirements (HLR) iMUGS Decomposed Mission (Operational) Requirement Req Type SOC SP NO Date Accepted 160.1 iMUGS shall develop a intuitive one-hand Command & Control interface for Derived dismounted troops (“control-pad”) for LOS and Close Support missions. Requirement 160.2 Local swarming is developed for sharing its's status information to operator and Derived receiving operator commands when possible. Requirement 160.3 Manual control and override will always be possible for the global swarming Derived functions Requirement 161 VIII.A.b.iv. Assessed and assigned TRL rating for the solution will be at least TRL 6. Requirement Comply 1 3 161.1 The TRL for intuitive one-hand Command & Control interface for dismounted Derived troops (“control-pad”) for LOS and Close Support missions shall be 6. Requirement 162 VIII.A.b.v. EW resistance instrumentation against detection, interception, suppression, Requirement Comply 1 3 deception and spoofing. 162.1 iMUGS shall be designed for EW resistance instrumentation against detection, Derived interception, suppression, deception and spoofing. Requirement 162.2 The tactical communication system shall be capable of deploying LPD/LPI/AJ Derived techniques. Requirement 162.3 All communication must be encrypted with sufficient key length Derived Requirement 162.4 When (commercial network) COTS devices are used, they must be hardened Derived against various cyber security threads. Requirement 162.5 When (commercial network) COTS devices are used, they should be centrally Derived managed by MDM system. Requirement 163 VIII.A.b.v. Detection of different forms of jamming. Requirement Comply 1 3 163.1 iMUGS Radio system shall have jamming detection and avoidance functionality by Derived switching to another communication frequency/channel Requirement 164 VIII.A.b.v. Assessed and assigned TRL rating for the solution will be at least TRL 6. Requirement Comply 1 3 164.1 iMUGS jamming detection solution shall have a TRL of 6 Derived Requirement 165 VIII.A.c. Cyber secure autonomous functions solution. Heading Noted 10PCO005_2 Sub-Project for responsibility; SP1 = Integ.; SP2 = Aut.; SP3 = Cyber; SP4 = Comms; SP5 = Swarm.; SP6 = C2; SP7 = MUM-T. Demo No is for indication only. 21 / 29 EDIDP-MUGS-2019-002-iMUGS Original pMS definition is identifed as cells with background color, contrary to respective decomposed requirements without color. COMPANY CONFIDENTIAL DEMO MoM ID / ID Ref. MR ID pMS High Level Requirements (HLR) iMUGS Decomposed Mission (Operational) Requirement Req Type SOC SP NO Date Accepted 166 VIII.A.c. This package will capture the following elements: Note Noted 167 VIII.A.c.i. Development for machine learning-based autonomous mobility solution for BLOS, Requirement Comply 2 6 LOS and autonomous missions. 167.1 Local swarming navigation is developed with machine learning in local swarming Derived functions. Requirement 167.2 Global swarming navigation relies on the autonomy for the local planning and Derived applies machine learning for optimising the global planning. Requirement 167.3 iMUGS should implement a common data base well adapted to the machine Derived learning. Requirement 167.4 iMUGS's autonomous mobility solution should be machine learning-based for the Derived autonomous missions. Requirement 168 VIII.A.c.i. The solution will provide an interoperable operating system for MUGS with at Requirement Comply 2 6 least waypoint navigation, fratricide avoidance, obstacle avoidance and follow-me (vehicle and pedestrian) functionalities as well as automated multi-horizon planning and scheduling for route and mission management. 168.1 iMUGS shall run an interoperable operating system enabling the different Derived autonomous functionalities Requirement 168.2 iMUGS shall have waypoint navigation functionality Derived Requirement 168.3 iMUGS shall have fratricide avoidance functionality Derived Requirement 168.4 iMUGS shall have obstacle avoidance functionality Derived Requirement 168.5 iMUGS shall have follow-me (vehicle and pedestrian) functionality Derived Requirement 168.6 iMUGS shall have automated multi-horizon planning and scheduling for route and Derived mission management Requirement 168.7 Local swarming is developed for co-operating with autonomy functionalities. Derived Requirement 168.8 Global swarming will include waypoint navigation capabilities and relies on Derived autonomy for solving the local motion planning Requirement 10PCO005_2 Sub-Project for responsibility; SP1 = Integ.; SP2 = Aut.; SP3 = Cyber; SP4 = Comms; SP5 = Swarm.; SP6 = C2; SP7 = MUM-T. Demo No is for indication only. 22 / 29 EDIDP-MUGS-2019-002-iMUGS Original pMS definition is identifed as cells with background color, contrary to respective decomposed requirements without color. COMPANY CONFIDENTIAL DEMO MoM ID / ID Ref. MR ID pMS High Level Requirements (HLR) iMUGS Decomposed Mission (Operational) Requirement Req Type SOC SP NO Date Accepted 169 VIII.A.c.i. A combination between several alternative algorithmic approaches will be Requirement Comply 2 6 considered to increase performance and robustness of the autonomous navigation modes. 169.1 iMUGS should be able to run several algorithms in parallel, with the same Derived interfaces and high-level functionalities Requirement 169.2 iMUGS should be able to combine outputs from multiple algorithms when similar Derived algorithms are running in parallel. Requirement 169.3 iMUGS operators should be able to select algorithms to run in order to increase Derived performance and robustness, dependending on the context. Requirement 169.4 Local swarming is developed for co-operating with autonomy functionalities. Derived Requirement 169.5 Global swarming is developed for co-operating with autonomy functionalities. Derived Requirement 170 VIII.A.c.i. Assessed and assigned TRL rating for the solution will be at least TRL 6. Requirement Comply 2 6 170.1 iMUGS solutions for alternative algorithm execution shall be developet to TRL 6 Derived Requirement 171 VIII.A.c.ii. Development of standardized data labeling and storage architecture to support Requirement Comply 2 6 implementation of machine learning based algorithms based on both real world and simulations data for MUGS. 171.1 Standard data formats shall be defined for labeled data exchange and storage Derived Requirement 171.2 Data warehouse architecture shall be defined for storage and sharing of iMUGS Derived data. Requirement 171.3 Data processing and filtering architecture shall be defined. Derived Requirement 171.4 Data labeling pipeline architecture shall be defined. Derived Requirement 171.5 Architecture for machine learning model training shall be defined. Derived Requirement 172 VIII.A.c.ii. At least TRL 5. Requirement Comply 2 6 172.1 Data labelling and storage architecture shall be developed to TRL 5. Derived Requirement 10PCO005_2 Sub-Project for responsibility; SP1 = Integ.; SP2 = Aut.; SP3 = Cyber; SP4 = Comms; SP5 = Swarm.; SP6 = C2; SP7 = MUM-T. Demo No is for indication only. 23 / 29 EDIDP-MUGS-2019-002-iMUGS Original pMS definition is identifed as cells with background color, contrary to respective decomposed requirements without color. COMPANY CONFIDENTIAL DEMO MoM ID / ID Ref. MR ID pMS High Level Requirements (HLR) iMUGS Decomposed Mission (Operational) Requirement Req Type SOC SP NO Date Accepted 173 VIII.A.c.iii Development of autonomous swarming capabilities with a solution using Requirement Comply 5 6 autonomous features developed for individual UGVs. 173.1 Local swarming capabilities are developed for defined use cases. Derived Requirement 173.2 Global swarming capabilities are developed for defined use cases and rely on the Derived autonomy functionality or solving the local problems and to harvest information Requirement for the global planner. 173.3 Local swarming and Global swarming interface and co-operation is defined. Derived Requirement 174 VIII.A.c.iii. Moreover, the solution will include swarm intelligence, autonomous swarm Requirement Comply 5 6 manoeuvring and one or more of the following swarming functions: area patrolling, maintaining a relay network, and area exploration and reconnaissance as part of the use cases. 174.1 Local swarming capabilities are developed for defined use cases. Derived Requirement 174.2 Global swarming will include behaviors reated to relaying, area exploration, Derived reconnaissance. Requirement 175 VIII.A.c.iii. The assessed and assigned TRL rating for the solution will be TRL 5. Requirement Comply 5 6 175.1 Local swarming is developed to TRL 5 Derived Requirement 175.2 Global swarming technologies will be developed to TRL 5 Derived Requirement 176 VIII.A.c.iv. Development of the platform-based system and data integrity instrumentation Requirement Comply 1 6 (“Black Box”) for intended and continuous operations of the autonomous units. 176.1 iMUGS shall be capable of house platform-based system and data integrity Derived instrumentation (“Black Box”) for intended and continuous operations of the Requirement autonomous units. 177 VIII.A.c.iv. Assessed and assigned TRL rating for the solution will be at least TRL 6. Requirement Comply 1 6 177.1 The platform-based system and data integrity instrumentation shall be developed Derived to TRL 6 Requirement 178 VIII.A.c.iv. Cloud-based solution will stay as optional for development. Note Noted 179 IX Section IX – REQUIREMENTS FOR DEVELOPMENT ACTIVITIES Heading Noted 10PCO005_2 Sub-Project for responsibility; SP1 = Integ.; SP2 = Aut.; SP3 = Cyber; SP4 = Comms; SP5 = Swarm.; SP6 = C2; SP7 = MUM-T. Demo No is for indication only. 24 / 29 EDIDP-MUGS-2019-002-iMUGS Original pMS definition is identifed as cells with background color, contrary to respective decomposed requirements without color. COMPANY CONFIDENTIAL DEMO MoM ID / ID Ref. MR ID pMS High Level Requirements (HLR) iMUGS Decomposed Mission (Operational) Requirement Req Type SOC SP NO Date Accepted 180 IX.A. The Project will include several development actions as follows: Note Noted 181 IX.A.a. feasibility study, which will include, without being limited to: Heading Noted 182 IX.A.a.i. operational and cost-effectiveness analyses study to specify conditions and Requirement Comply 1 5 criteria for each operational use case defined in Section VI H within the framework of Section VII 182.1 iMUGS shall deliver an operational and cost-effectiveness analyses study to Derived specify conditions and criteria for each operational use case defined in Section VI Requirement H within the framework of Section VII 183 IX.A.a.ii. study the use of UGS in the context of customary law of war and applicable EU Requirement Comply 1 2 and national legislation 183.1 iMUGS shall deliver a study on the use of UGS in the context of customary law of Derived war and applicable EU and national legislation. Requirement 184 IX.A.a.iii. study attitudes of military personnel and general population towards the use of Requirement Comply 1 2 unmanned platforms 184.1 iMUGS shall deliver a study of attitudes of military personnel and general Derived population towards the use of unmanned platforms. Requirement 185 IX.A.a.iv. study on ethics of MUGS employment in operational context Requirement Comply 1 2 185.1 iMUGS shall deliver a study on ethics of MUGS employment in operational Derived context Requirement 186 IX.A.a.v. definition of relevant scenarios and use cases Requirement Comply 7 6 186.1 iMUGS shall define operational scenarios in workshops with participants from Derived pMS and industry partners. Requirement 186.2 iMUGS shall define defining test cases based on the operational scenarios. Derived Requirement 187 IX.A.a.vi. definition of key capability requirements, main system requirements and Requirement Comply 1 6 constraints 187.1 iMUGS shall define key capability requirements, main system requirements and Derived constraints Requirement 188 IX.A.a.vii. definition of CONOPS Requirement Comply 7 6 10PCO005_2 Sub-Project for responsibility; SP1 = Integ.; SP2 = Aut.; SP3 = Cyber; SP4 = Comms; SP5 = Swarm.; SP6 = C2; SP7 = MUM-T. Demo No is for indication only. 25 / 29 EDIDP-MUGS-2019-002-iMUGS Original pMS definition is identifed as cells with background color, contrary to respective decomposed requirements without color. COMPANY CONFIDENTIAL DEMO MoM ID / ID Ref. MR ID pMS High Level Requirements (HLR) iMUGS Decomposed Mission (Operational) Requirement Req Type SOC SP NO Date Accepted 188.1 Definition of CONOPS based on the results of the workshops for operational Derived scenarios and the outcomes of the belonging tests/demonstrations. Requirement 189 IX.A.b. designing, which will include, without being limited to: Heading Noted 190 IX.A.b.i. integration of MUGS into simulation systems Requirement Comply 2 6 190.1 Integration of MUGS autonomy functions into specific simulation system (physics Derived simulation) 190.2 Integration of UGV into the virtual and constructive simulation of KMW for the Derived test of the outcome of the workshops for operational scenarios. Requirement 191 IX.A.b.ii. development of modular, multi-mission capable UGS Requirement Comply 1 2 191.1 iMUGS shall develop a modular, multi-mission capable UGS. Derived Requirement 192 IX.A.b.iii. development of cyber secure autonomous mobility software suite Requirement Comply 2 6 192.1 iMUGS shall develop a cyber secure autonomous mobility software suite Derived (backbone). Requirement 193 IX.A.b.iv. development of EW and cyber resistant C3 solution Requirement Comply 6 6 193.1 iMUGS C2 hardware platforms running COTS Operational System will be subject Derived to an Operating System Hardening process. Requirement 193.2 iMUGS C2 software development will consider security requirements and Derived guidelines. Requirement 193.3 iMUGS C2 will monitor the status of: Derived - UGV(s) GNSS signal availabilty (loss of navigation) Requirement - Datalink among C2 and UGV (loss of comms) - UGV cyber threat warnings and indicators (loss of control) - UGV operational warnings and indicators (system failure) 194 IX.A.b.v. testing MUGS concept in simulated environment Requirement Comply 7 5 194.1 iMUGS autonomy concept shall be tested in simulated environment Derived Requirement 10PCO005_2 Sub-Project for responsibility; SP1 = Integ.; SP2 = Aut.; SP3 = Cyber; SP4 = Comms; SP5 = Swarm.; SP6 = C2; SP7 = MUM-T. Demo No is for indication only. 26 / 29 EDIDP-MUGS-2019-002-iMUGS Original pMS definition is identifed as cells with background color, contrary to respective decomposed requirements without color. COMPANY CONFIDENTIAL DEMO MoM ID / ID Ref. MR ID pMS High Level Requirements (HLR) iMUGS Decomposed Mission (Operational) Requirement Req Type SOC SP NO Date Accepted 194.2 iMUGS operational scenarios shall be tested in the virtual and constructive Derived simulation of KMW Requirement 195 IX.A.c. prototyping, which will include, without being limited to: Heading Noted 196 IX.A.c.i. integration of three development packages Requirement Comply 1 6 196,1 integration of three development packages Derived Requirement 197 IX.A.c.ii. demonstration of MUGS in operational environment Requirement Comply 1 6 197.1 iMUGS shall test the appropriate selected outcomes of the workshops for Derived operational scenarios. Requirement 197.2 Local swarming is demonstrated in an internal simulation system. Derived Requirement 197.3 Global swarming will be validated and demonstrated in a relevant environment Derived Requirement 198 IX.A.d. testing, which may include, without being limited to: Heading Noted 199 IX.A.d.i. testing in artic environment Requirement Partial 1 3 199.1 iMUGS concept should be demonstrated close to arctic latitudes, in winter season Derived (pending on demonstration plan approval). Requirement 200 IX.A.d.ii. testing in urban environment Requirement Partial 1 4 200.1 iMUGS concept should be demonstrated in representative urban environment Derived (pending on demonstration plan approval). Requirement 201 IX.A.d.iii. testing in forested and rugged environment Requirement Partial 1 2 201.1 iMUGS concept should be demonstrated representative forested and rugged Derived environment (pending on demonstration plan approval). Requirement 202 IX.A.d.iv. testing in coastal areas Requirement Partial 1 4 10PCO005_2 Sub-Project for responsibility; SP1 = Integ.; SP2 = Aut.; SP3 = Cyber; SP4 = Comms; SP5 = Swarm.; SP6 = C2; SP7 = MUM-T. Demo No is for indication only. 27 / 29 EDIDP-MUGS-2019-002-iMUGS Original pMS definition is identifed as cells with background color, contrary to respective decomposed requirements without color. COMPANY CONFIDENTIAL DEMO MoM ID / ID Ref. MR ID pMS High Level Requirements (HLR) iMUGS Decomposed Mission (Operational) Requirement Req Type SOC SP NO Date Accepted 202.1 iMUGS concept should be demonstrated in representative coastal environment Derived (pending on demonstration plan approval). Requirement 203 IX.A.d.v. testing in desert environment Requirement Partial 1 6 203.1 iMUGS concept should be demonstrated in representative desert environment Derived (pending on demonstration plan approval). Requirement 204 IX.A.d.vi. testing in a hostile electromagnetic environment (EW) to find key features how to Requirement Partial 1 6 protect the communication systems against EW/cyber countermeasures 204.1 testing in a hostile electromagnetic environment (EW) to find key features how to Derived protect the communication systems against EW/cyber countermeasures. Requirement 205 IX.A.d.vii. testing the performance of autonomous navigation modules in various Requirement Partial 1 6 environments seen above 205.1 iMUGS operators shall be able to monitor MUGS performance. Derived Requirement 205.2 iMUGS autonomous navigation capabilites shall be reached in urban Derived environmment. Requirement 205.3 MUGS autonomous navigation capabilites shall be reached in forested and rugged Derived environment. Requirement 205.4 MUGS autonomous navigation capabilites shall be reached in various other Derived environments. Requirement 206 IX.A.d.viii. testing of possibilities and limitations of swarming technologies in various Requirement Comply 5 6 environments seen above 206.1 Local swarming shall tested in an internal simulation system in various Derived environments. Requirement 206.2 During the validation of the global swarming system, possibilities and limitations Derived in various environments shall be assessed Requirement 207 IX.A.d.ix. testing possibilities of utilizing different radio systems (local, commercial, tactical, Requirement Comply 4 3 etc) and waveforms (e.g. ESSOR 2D and 3D) 207.1 Various military radio waveforms shall be tested using SDR solution. Derived Requirement 207.2 Commercial waveforms may be tested using COTS equipment. Derived Requirement 10PCO005_2 Sub-Project for responsibility; SP1 = Integ.; SP2 = Aut.; SP3 = Cyber; SP4 = Comms; SP5 = Swarm.; SP6 = C2; SP7 = MUM-T. Demo No is for indication only. 28 / 29 EDIDP-MUGS-2019-002-iMUGS Original pMS definition is identifed as cells with background color, contrary to respective decomposed requirements without color. COMPANY CONFIDENTIAL DEMO MoM ID / ID Ref. MR ID pMS High Level Requirements (HLR) iMUGS Decomposed Mission (Operational) Requirement Req Type SOC SP NO Date Accepted 208 IX.A.d.x. testing and measuring of antenna propagations and emissions Requirement Comply 4 3 208.1 Antenna emissions and sensitivity shall be measured in a laboratory Derived Requirement 208.2 Antenna emissions shall be measured around the antenna to achieve the 3D Derived radiation pattern. Requirement 208.3 The antenna measurement shall be done using intented frequency. Derived Requirement 209 IX.A.d.xi. testing and measuring the possibilities offered by utilizing different power Requirement Comply 1 6 sources (fuel cells, solar-power, performance of different battery types, total energy consumption of the system chosen) 209.1 iMUGS assesses the possibilities offered by utilizing different power sources. Derived Requirement 210 IX.A.d.xii. testing and measuring of the integrated fire control and aiming systems offered Requirement Comply 1 6 by MUGS and UAS in order to benefit from the increased SA in the optimization of the artillery and mortar fire 210.1 iMUGS assesses the integrated fire control and aiming systems offered by Derived mobility platform and UAS. Requirement 211 IX.A.d.xiii. testing and measuring of the integrated damage assessment systems in MUGS Requirement Comply 1 2 and UAS to benefit from the use of resources in artillery fire 211.1 iMUGS assesses the possibilities offered by damage assessment systems utilizing Derived UAS. Requirement 212 IX.A.d.xiv. testing and measuring the combined performance produced by MUGS and UAS to Requirement Comply 1 2 gain maximal Situational Awareness (SA). 212.1 iMUGS assesses the possibilities offered by situational awareness systems Derived utilizing UAS. Requirement 213 IX.A.d.xiv. This data will be used for taking the initiative in the battle space. Note Noted EOF EOF End Of File EOF 10PCO005_2 Sub-Project for responsibility; SP1 = Integ.; SP2 = Aut.; SP3 = Cyber; SP4 = Comms; SP5 = Swarm.; SP6 = C2; SP7 = MUM-T. Demo No is for indication only. 29 / 29  Grant Agreement number: EDIDP-MUGS-2019-002-iMUGS ANNEX 1 DESCRIPTION OF THE ACTION Part A 1. General Information 2. Identification of the beneficiaries, linked third parties, subcontractors involved in the action and associated partners 3. Bonuses 3.1. SMEs and mid-caps participation 3.2. Permanent Structured Cooperation 4. Tables 4.1. List of work packages 4.2. Work package description 4.3. List of deliverables 4.4. List of milestones 4.5. Critical risks for implementation 4.6. Summary of staff effort Part B 5. Project presentation 6. Focus on award criteria 1 Grant Agreement number: EDIDP-MUGS-2019-002-iMUGS ANNEX 1 Part A 1. General Information Call identifier: EDIDP-MUGS-2019 (Multipurpose unmanned ground system) Topic identifier: EDIDP-MUGS-2019 Activities: Studies; Design; Prototyping; Testing Acronym of the proposal: iMUGS Title of the proposal: Integrated Modular Unmanned Ground System Duration in months: 30 Abstract: The iMUGS (integrated Modular Unmanned Ground System) project consists in the studies, design, prototyping and testing of the fundamental features for unmanned systems and of their integration based on a modular, standardized and open software system. The project will develop a modular and scalable architecture for hybrid manned-unmanned systems in order to address a large range of missions and to enable easy update or modification of assets and functionalities within the system: aerial and ground platforms, command, control and communication equipment, sensors, payloads and algorithms. The project is structured along 7 sub-projects that all cover studies, design, prototyping, testing and technical coordination: 1. System Integration 2. Autonomous Functions 3. Cyber Security 4. Communication 5. Swarming 6. Command, Control and Interoperability 7. Manned-Unmanned Teaming To be in synergy with the forces’ needs and requirements, and foster their engagement, 6 demonstrations performed throughout Europe and a final engagement event will punctuate the project. The governing bodies of the project also comprise end-users. The consortium, led by MILREM AS, comprises some of the best in class European players in their respective fields: SAFRAN Electronics & Defense SAS, GT Cyber Technologies OÜ, 2 Grant Agreement number: EDIDP-MUGS-2019-002-iMUGS ANNEX 1 Bittium Wireless Oy, Insta DefSec Oy, GMV Aerospace and Defence SAU, Krauss-Maffei Wegmann GmbH & Co KG, Diehl Defence GmbH & Co KG, Nexter Systems SA, Latvijas Mobilais Telefons SIA, (Un)Manned NV, Ecole Royale Militaire – Koninkljike Militaire School and dotOcean NV. It is fully committed to make the project a success and demonstrate the added-value of EU-funded defence research. It also offers a large place to SMEs. iMUGS fully complies with the call EDIDP-MUGS-2019. The work will pave the way for building a robust, innovative and credible competency in Europe. The overall budget of iMUGS is 32,6 M€, of which up to 30,6 M€ are funded by the EDIDP and up to 2 M€ by the participating Member States. Free keywords: Unmanned platforms; unmanned ground systems; UGVs; autonomy; autonomous functions; cyber security; swarming; command and control; communication networks; manned unmanned teaming 2. Identification of the beneficiaries, linked third parties, subcontractors involved in the action and associated partners 2.1. BENEFICIARIES Country of No Legal name PIC number establishment 1.1 Milrem AS 915338270 Estonia 1.2 SAFRAN Electronics & Defense SAS 999954668 France 1.3 GT Cyber Technologies OÜ 902919069 Estonia 1.4 Bittium Wireless Oy 999647372 Finland 1.5 Insta DefSec Oy 973303918 Finland 1.6 GMV Aerospace and Defence SAU 999905004 Spain 1.7 Krauss-Maffei Wegmann GmbH & Co KG 902829247 Germany 1.8 Diehl Defence GmbH & Co KG 998381813 Germany 1.9 Nexter Systems SA 901314301 France 1.10 Latvijas Mobilais Telefons SIA 906133746 Latvia 1.11 (Un)Manned NV 911717842 Belgium 1.12 Ecole Royale Militaire – Koninkljike Militaire School 999831575 Belgium 1.13 dotOcean NV 940929392 Belgium 3 Grant Agreement number: EDIDP-MUGS-2019-002-iMUGS ANNEX 1 2.2. LINKED THIRD PARTIES National Country of No Legal name registration Applicant to which it is linked establishment number 2.1 Bittium Safemove Oy 1855598-7 Finland Bittium Wireless Ltd. 2.2 Nexter Robotics SAS 538115684 France NEXTER Systems SA 2.3. SUBCONTRACTORS INVOLVED IN THE ACTION Applicant, linked third party or National Country of subcontractor involved in the No Legal name registration establishment action to which it is number subcontracted 3.1 Rantelon OÜ 10496551 Estonia GT Cyber Technologies OÜ 3.2 DA-Design Oy FI10094047 Finland Bittium Wireless Oy 3.3 AVQ GmbH HRB201209 Germany Diehl Defence GmbH & Co KG 3.4 Threod Systems OÜ 12323903 Estonia Milrem AS 3.5 FN Herstal NV 0441.928.931 Belgium Milrem AS NL822622762 The 3.6 RHEA System B.V GT Cyber Technologies OÜ B01 Netherlands Kaitseväe Akadeemia 3.7 (Estonian Military EE101272342 Estonia Milrem AS Academy) DefSecIntel Solutions 3.8 14514582 Estonia Milrem AS OÜ 3.9 Hentschel System GmbH DE115646189 Germany Diehl Defence GmbH & Co KG 3.10 Nedaciana Holdings Ltd ΗΕ 289151 Cyprus Diehl Defence GmbH & Co KG 3.11 Hensoldt Sensors GmbH HRB 219393 Germany GT Cyber Technologies OÜ 3.12 FY-Composites Oy 1611395-8 Finland Milrem AS FR078023559 3.13 4D-VIRTUALIZ France Milrem AS 33 2.4. ASSOCIATED PARTNERS Not applicable. 4 Grant Agreement number: EDIDP-MUGS-2019-002-iMUGS ANNEX 1 3. Bonuses 3.1. SMEs and mid-caps participation iMUGS Budgeted Work Shares Studies Design Prototyping Testing Non-cross-border SMEs 9% 15% 14% 21% Cross-border SMEs 8% 24% 34% 26% SMEs 17% 38% 48% 48% Mid-caps 17% 20% 13% 18% 3.2. Permanent Structured Cooperation The action is developed in the context of the Permanent Structured Cooperation (PESCO). 4. Tables 4.1. List of work packages No Work Package (WP) Start Month End Month 1 Studies 1 30 2 Design 1 26 3 Prototyping 1 30 4 Testing 1 28 5 Grant Agreement number: EDIDP-MUGS-2019-002-iMUGS ANNEX 1 4.2. Work package description WP number Activity covered Start month M1 1 Studies End month M30 Participant number 1.1 1.2 1.3 1.4 1.5 1.6 1.7 Short Name MILREM SAFRAN GTCT Bittium Insta GMV KMW PM per participant 70 11 43 16 106 13 223 Participant Number 1.8 1.9 1.1 1.11 1.12 1.13 1.14 Short name DIEHL NEXTER LMT UnManned ERM-KMS dotOcean EMA PM per participant 8 26 27 15 12 17 0 Objectives The objective of this WP is to provide the high-level architecture for the whole system of systems, as well as for its components and features. This high-level approach will also lead to identify the critical points for the design, whichever their nature: technological, integration, use-case… This overall objective is divided according to the main tasks of this WP:  Based on end user experience and workshops, and with the help of virtual and constructive simulation, a common understanding for military operational scenarios, as a base for upcoming ConOps with iMUGS will be established. These scenarios will define and describe how to deploy and operate iMUGS with different combinations of other military systems and soldiers. Furthermore, possibilities MUM-T will be described.  State the systems engineering approach, define the systems engineering management plan, integration schedule and define system requirements and preliminary design and interfaces;  Define the Operational Concept and Technical Requirements Specification of the C2 subsystem  Specify the high-level architecture of the autonomy subsystem (Autonomy framework), taking into account all available and applicable standards as well as use cases and environments  Gain a better understanding of the current cyber-threats autonomous vehicles are subject to, and thus find the optimal solution in addressing these threats; Define the Cyber-secured solutions to be implemented in the global architecture of the system.  Provide an architecture of the subsystem communication that meets the call requirements, allows the system to perform all the missions and functions identified in ConOps, and a corresponding to systems engineering management plan;  Provide architectures and methods for swarming operations in various interconnectivity conditions as well as methods to structure data inputs and efficient search algorithms capable of dealing with structured dynamic data. Description of work Task 1.1 System engineering and platform studies: MILREM, subcontractor EMA (M1-M12) The goal of this task is to provide system engineering management and deliver global architecture and preliminary system requirements and preliminary interface definitions for iMUGS (including requirements for a novel single-handed controller and THeMIS platform). In addition, a system level safety package will be delivered together with legal, ethical and perception analysis on the use of unmanned ground systems. Subtask 1.1.1 System engineering and architecture development: MILREM (M1-M7) In this task, System engineering management activities consist of requirements engineering, system architecture development and -design specification. Requirements engineering will consist of specifying a requirements model, reviewing and releasing requirements specifications. System architecture development activities will map and specify the high-level system architecture (model) and coordinate the specification of Interface Control Documents (ICDs). Requirement traceability is continuously provided by the system engineering team. System engineering management plan, integration plan, system budgets and documentation requirements definition will be drafted and issued. MILREM, through the Project Architect, will be responsible for systems engineering management with the support from SP leaders. 6 Grant Agreement number: EDIDP-MUGS-2019-002-iMUGS ANNEX 1 Subtask 1.1.2 Requirements Reviews: MILREM (M1-M4) The high-level requirements for iMUGS are to be synthesized into Mission requirements and released after validation in a MDR, to be completed before M1. From these Mission requirements, System and subsystem requirements are derived and accepted by Preliminary Requirements Review. This task will be led by MILREM with responsibilities on coordinating and conducting Mission Definition and Preliminary Requirements Reviews and delivering respectful reports. Subtask 1.1.3 Safety & securities studies: MILREM (M1-M7) As safety and ethical aspect of the iMUGS is of crucial importance, several Safety assessment studies will be foreseen. Safety & security analysis on the core functions iMUGS System of Systems (SoS) covering the transport mission, the ISR mission, the MEDEVAC mission and related C2 aspects. The safety analysis process (based on approved ARP/MIL standards) will apply AEP-4754/ARP 4754 specified methodology to evaluate iMUGS System of Systems (SoS) core functions and the development of the systems performing these functions. To determine that the associated hazards have been properly addressed, the safety & security assessment process takes into account any additional complexities and interdependencies which arise due to integration. The SoS safety & security process defines safety & security requirements for high- level iMUGS functions based on the functional analyses made at subsystem level by the iMUGS partners as well as security recommendations for the demonstrations performed during the project. FN Herstal will deliver a System of Systems level safety & security analysis package following AEP- 4754/ARP 4754 methodology including guidelines for subsystem safety assessments and recommendations for security of the demonstrations. Subtask 1.1.4 Legal, ethical and attitude studies towards the use of unmanned platforms: MILREM (M1-M12) Specific studies will investigate ethical concerns with regards to iMUGS employment in operational context and legal concerns for autonomous unmanned ground systems. In a BVLOS scenario, with a situational awareness limited to the UGV sensors with increasing use of autonomy, under the lead of MILREM, subcontractor FN Herstal will analyse and propose ethical rules of engagement of iMUGS. A study on military and social attitudes towards the use of unmanned platforms will be provided along with inputs to the development of Operational Scenarios and on user experience, general design and safety principles. The study will contribute to EU-wide guidelines regarding ethical use of AI in military UGS in the context of customary law of war and applicable legislation. Subcontractor EMA will deliver a study on legal aspects of UGVs and on attitudes of general population and military on UGV. Subcontractor FN Herstal will deliver a study on ethical and legal concerns of UGVs. Subtask 1.1.5 Single-handed remote-control requirements engineering: MILREM (M1-M3) Requirements for an intuitive single-handed control pad for high cognitive load situations for dismounted troops will be developed to provide control over iMUGS system functions (autonomy, lights, obscurant deployment etc) during troop advancement. This serves as a primary remote for logistics and maintenance activities. The activity will cater for deriving requirements for the control pad and preparing for design phase. Under the lead of Milrem, subcontractor THREOD will be deliver the requirements for single-handed remote controller. Subtask 1.1.6 Requirement analysis for THeMIS platform production: MILREM (M1-M3) Since the design of Autonomy functions requires validation of sensor placement and driving dynamics as early as possible an iteration of requirements for producing THeMIS platforms will be commenced. The analysis and review will accommodate the requirements towards THeMIS platform for iMUGS functionality. MILREM will be responsible for requirements analysis for THeMIS platform and delivery of platform requirements. Task 1.2 Studies Autonomous functions: SAFRAN, DIEHL, NEXTER, MILREM (M1-M6) This task will consist in specifying the high-level architecture of the Autonomy framework as set in the objectives of the WP. Available and applicable standards, autonomy use cases and environments from military operation scenarios will be determined and used in the architecture process. Task 1.2 will study the interfaces between the Autonomy framework and other subsystems as cybersecurity 7 Grant Agreement number: EDIDP-MUGS-2019-002-iMUGS ANNEX 1 unit (task 1.3), Communications system (task 1.4), C2 system (task 1.6) and MILREM THeMIS Platform (task 1.1). Subtask 1.2.1 Autonomy subsystem Normative Framework: DIEHL (M1-M3) DIEHL will lead this subtask. Based on military operation scenarios and iMUGS requirements, DIEHL will define together with MILREM, SAFRAN and NEXTER the Autonomy use cases and will derived autonomy functions (as Follow me vehicle/pedestrian, Way point navigation, surveillance, patrolling, …). Use cases and operational requirements for autonomy functions will be derived from UGV scenarios analysis. The existing normative repository and the required capabilities and available technologies will be identified. Subtasks 1.2.2 Autonomy subsystem External interfaces: DIEHL, SAFRAN, NEXTER, MILREM (M1-M6) DIEHL will lead this subtask. From the selected use cases, together with SAFRAN, NEXTER, MILREM and DIEHL, the high-level specification and the interfaces between Autonomy Subsystem and other subsystems (e.g. communication, UGV, C2, …) will be identified. Subtask 1.2.3 Autonomy subsystem User-Robot interactions: DIEHL, SAFRAN, NEXTER, MILREM (M1-M3) DIEHL will lead this subtask. From the selected use cases, together with SAFRAN, NEXTER, MILREM and DIEHL, from the high-level specification of the autonomy subsystem User-Robot interactions will be defined. To do so, they will identify and analyse system requirements regarding user-robot interface for autonomy functions (including operations, ergonomic, adjustable autonomy, …), Man-Machine interfaces and mission planning/supervision tools (including inputs/specifications to C2 SP regarding autonomy SP). Subtask 1.2.4 Autonomy subsystem Safety & Security: DIEHL (M1-M6) DIEHL will lead this subtask and perform a subsystem Autonomy framework safety and security analysis. This analysis will consider soldier support vehicles as the MILREM Themis platform but also larger platforms (e.g. trucks) in order to guarantee an adaptability of the Autonomy framework to other types of ground vehicles. Based on this safety & security Analysis and input from other SPs (particularly Cybersecurity) the High-Level Hardware and Software Architecture will be defined as well as the interfaces towards other subsystems (communications, Swarming, C2, Ground vehicle). Subtask 1.2.5 Hardware and Software architecture of Autonomy framework: DIEHL (M1-M3) DIEHL will lead this subtask. With partners, DIEHL will define subsystem requirements for hardware architecture (including PC system, network, sensors and power infrastructure based on system requirements and capabilities of partners within the project) and for software architecture (including services, taxonomy, internal interfaces, data model, UGC-assessment) of Autonomy framework. DIEHL with the other partners will also define the Autonomy framework central services by identifying the services which are used by all means within autonomy subsystems (common definitions/models, common tools and means) and redacting the central services high level specification. Task 1.3 Studies of Cybersecurity: GTCT (M1-M15) The objective of Studies of Cybersecurity will be to understand the types of cyber threats that iMUGS will face when in an operational military environment. Furthermore, risk assessments will consider these threats and evaluate vulnerabilities introducing risk in designs by the consortium partners for individual subsystems of iMUGS. Subtask 1.3.1 Study on the Security of Unmanned Military Ground Systems: GTCT (M1-M7) GTCT will conduct a study that will focus on the risks surrounding the use of autonomous unmanned ground vehicles (UGV) from nation state and military level cyber threats and postulate the most probable attack vectors to a UGV, including the effects of cyber related attacks. With the consortium partners, GTCT will study the technological design of the MUGS platform and autonomous systems in general. The study will consist of interviews, technical discussions and desk research to gain a better understanding of the architecture of autonomous systems, how they could be exploited with cyber weapons, and what are the most probable attack vectors from a cyber-attack. Subtask 1.3.2 Risk Assessment for iMUGS operations: GTCT (M1-M7) 8 Grant Agreement number: EDIDP-MUGS-2019-002-iMUGS ANNEX 1 GTCT will use the service of their subcontractor, RHEA, for conducting the risk assessment, focusing on military operations for the iMUGS. The purpose of this risk assessment is to evaluate the cyber risks of the platform while operating in a military environment and identifying risk mitigation measures. Subcontractor RHEA will communicate with the consortium partners and coordinate closely with GTCT and each partner in the process of assessing cyber risk and determining a method of treating or mitigating each risk. The risk assessment will consist of in person visits and questionnaires of at least three different partners. Subtask 1.3.3 Risk Assessment of the iMUGS Supply Chain: GTCT (M8-M15) GTCT will again work with their subcontractor RHEA to perform a second risk assessment of the iMUGS platform. This risk assessment will focus on the supply chain of the partners, in order to evaluate cyber risks, present in the fabrication and long-term maintenance of the vehicle. Task 1.4 Studies Communication equipment and network: Bittium, LMT (M1-M3) The goal of the task is to analyse the use cases and select proper technologies and functionalities to be implemented and integrated to the iMUGS. In addition, further study on the utilization of commercial networks shall be carried out. The work starts with use cases analysis and a preliminary system design including definition of the interfaces between module sub-systems and sub- components. Then, technologies shall be analysed and selected. The last task is to provide a detailed plan for the design and development steps. Subtask 1.4.1 Communication and network Use case definition and analysis: Bittium (M1-M2) This subtask will analyse the end-user requirements, study application of modern commercial networks, and define the use cases in detail. The outcome of the task is the updated and detailed use case description. Subtask 1.4.2 Communications and network Preliminary system design: Bittium (M1-M2): Based on the use cases definition and customer requirements, preliminary system design shall be carried out. The preliminary system design comprises system requirements consolidation and system architecture description, which consists of the needed details such as a block level architecture design and interface description as well as functional description. Subtask 1.4.3 Communication and network Technology analysis and selection: Bittium, LMT(M2- M13) Based on the results of Subtask 1.4.1 and partially jointly with Subtask 1.4.2, the technologies to be deployed in the iMUGS communications sub-system will be selected. The subtask covers both tactical and commercial communication technologies and services. Technological dependency on third party components will be taken into account in the design. Subtask 1.4.4 Detailed planning: Bittium (M1-M13) To carry out the design and implementation successfully, a detailed plan shall be provided. Required updates based on the on-going work with focus on Phase 3 topics shall be provided as part of WP2 (Design) work. Task 1.5 Studies Swarming: ERM-KMS, DotOcean, INSTA (M1-M7) The objective of this task is to explore and find ways of integrating existing technologies into building blocks usable for real-time swarming capabilities, addressing the use cases. Subtask 1.5.1 Swarming Integration and adaptation: ERM-KMS, DotOcean, Insta (M1-M4) Under the lead of ERM-KMS, ERM-KMS and DotOcean will modify the DotOcean multi-agent toolbox for IIoT digitally twinned robotic systems, to enable the use within the iMUGS swarming framework. Insta will update existing in-house simulation environment to develop local swarming of iMUGS. Subtask 1.5.2 Swarming use case definition and analysis: ERM-KMS, DotOcean, Insta (M1-M7) The aim is to define principles and methods to maximally reduce the problem dimensions, maximally structure data and to define search strategies. ERM-KMS will lead this subtask, map possible concepts of swarm operation and identify possible scenarios and strategies. DotOcean and Insta will define possible solutions to the combined set of concepts of operation, DotOcean within an unconstrained context regarding communications, data and computational power (Global) and Insta within a constrained context regarding communications, data and computational power (Local). 9 Grant Agreement number: EDIDP-MUGS-2019-002-iMUGS ANNEX 1 Subtask 1.5.3 Swarming Technology analysis and selection: ERM-KMS, DotOcean, Insta (M4- M7) Based upon the findings of subtask 1.5.2, technologies and algorithms with the potential to solve individual and combined use cases, within the constraints set, will be analysed and selected. ERM- KMS and DotOcean will define possible architecture and algorithms of swarming systems, centralized optimization of swarming systems. Insta will focus on decentralized collaborative methods and algorithms for swarming systems. Technological dependency on third party components will be taken into account in the design. Subtask 1.5.4 Swarming Iterations and optimally solving increasing complexity: ERM-KMS, DotOcean, Insta (M7-M24) Optimally solving combined swarm objectives will surface specific needs, restrictions or adaptations to the individual objective function solvers. Within this subtask a specific focus will be laid on how to optimize the algorithms, data structures and solvers towards enabling multi objective swarm function solvers. ERM-KMS and dotOcean will work on solutions for centralized decision making in order to achieve the swarm objectives, Insta on solutions for decentralized decision making in order to achieve the swarm objectives. Task 1.6 Studies Command and Control and interoperability: GMV, (Un)Manned, LMT (M1-M2) The objectives of this task are to define the Operational Concept of the C2 subsystem and to elaborate the Technical Requirements Specification of the C2 subsystem. Subtask 1.6.1 Preparation of the Operational Concept Description: GMV, (Un)Manned, LMT (M1- M2) The aim is to develop an operational description of the C2 subsystem, including the elaboration of C2 System NATO Architecture Framework (NAF) views, identification of interfaces and of conformance requirements to appropriate standards, STANAGs etc. GMV will lead this subtask. GMV will focus on the tactical C2 component. (Un)Manned will focus on real time safety critical C2 component and its high-level design aspects, including definition of a flexible architecture for generic unmanned system control covering multi domain control station and allowing future expansion with different unmanned systems and safety critical payloads. LMT will participate as interoperability test case with their C2 system. Subtask 1.6.2 C2 Technical Requirements Specification: (UN)Manned, GMV (M1-M2) (Un)Manned, with GMV contribution, will lead the preparation of the Technical Requirements Specification of the C2 subsystem. Task 1.7 Manned-Unmanned Teaming Studies: KMW, NEXTER, MILREM (M1-M30) Goal of this task is to define military operational scenarios for the development of MUGS and the engagement with iMUGS in different combinations with soldiers and other systems. Subtask 1.7.1 Initial MUM-T study: KMW, NEXTER, MILREM (M1-M14) First aim of this subtask is to develop military operational scenarios to be used as global definitions for a set of ConOps master scenarios for iMUGS phase 1. Second aim of this subtask is to analyse deployment methods with already existing means of transport and to describe requirements on the deployment of iMUGS. KMW will lead this subtask and will be the meeting coordinator. As part of this initial MUM-T study, KMW will organize three meetings (workshops in M4, M8 and M12) of five working days in its Munich facilities (Germany). These workshops shall help to develop the military operational scenarios on one side and to discuss ways of deployment of iMUGS on the other side. These workshops will take place with the help of the virtual and constructive simulation of KMW where applicable (see corresponding subtasks 1.7.3 and 1.7.4). It shall support the discussions, deliver pictures of possible engagements and allow the visualization of concepts and ideas. KMW will deliver in M14 the initial MUM-T study containing: a summary of the workshops, the first version of military operational scenarios which can be used as a base for the demonstrations and an analysis of deployment methods for iMUGS. NEXTER and MILREM will participate to the meetings, bring in their expertise for military operational scenarios, review the outcomes and work as a first point of contact for the French army, respectively the Estonian army. Participating Ministries of Defence (MoD’s) shall bring in knowledge and own tactical goals in terms of deployment and operational use of iMUGS now and in future. 10 Grant Agreement number: EDIDP-MUGS-2019-002-iMUGS ANNEX 1 Subtask 1.7.2 MUM-T evaluation study: KMW, NEXTER, MILREM (M14-M30) The initial MUM-T study will be updated and actualised based on the results from the design, prototyping and the demonstration phases. As a first step, test cases for the military operational scenarios will be written as helping guideline for the upcoming demonstrations. The handover to the participating MoD’s and discussion of the test cases will be done in the context of a status meeting at KMW in Munich, 16 months after project’s start. KMW will note and evaluate the results, according to the outcomes and requirements of the initial MUM-T study. KWM will update and actualise the initial MUM-study. Ideas and concepts not considered for this project will be collected for a possible follow-on project. NEXTER and MILREM will participate during the meeting and support the preparation of the study. Subtask 1.7.3 MUM-T virtual simulation: KMW (M1-M20) The subtask MUM-T virtual simulation will support the initial and the evaluation MUM-T studies as described above. KMW will enlarge the existing simulation, integrate the iMUGS and a generic UAV as new simulated units, adapt the user interfaces (generic optic and control unit) in the simulation and investigate possible operations in different environments under different conditions, like e.g. different weather conditions. For the different environments, four existing terrain databases will be used. A damage model for the iMUGS will be implemented. The damages can be caused by collisions and/or enemy fire. Damages of the iMUGS will be based on problems with the engine, the camera, the tracks or a lost radio connection. Autonomous or semi-autonomous operating modes will be to follow a unit (vehicle/human), return to the starting point, drive towards a target point. Simulated problems with the digital/analogue radio connection will be latencies, transmission errors (loss of pictures or data) or a complete breakdown. It is foreseen to use the existing AI in the simulation tool and adjust the capabilities to the assumed and predicted capabilities of the iMUGS. The use of the original iMUGS AI in the simulation is not foreseen. Main focus for this project will be the use cases LOS and BVLOS. Subtask 1.7.4 MUM-T constructive simulation: KMW (M1-M20) KMW will lead this task and integrate a simplified iMUGS in the simulation environment to support the MUM-T studies evaluation. KMW will generate scenarios with different combinations of forces and with different settings in a high-level analysis tool (MASA SWORD) KMW will realise three military operational scenarios based on the initial MUM-T study and evaluate them, with the support of Participating MoD’s, to determine iMUGS advantages and necessary improvements. Deliverables D1.1 iMUGS Development and Test Plan. Design & development goals for all Sub Projects. D1.2 iMUGS Study Report. Each subproject provides at least one section to the document. It includes the system architecture, subsystem architecture, ICD (interfaces definition between all subsystems). D1.3 Manned-Unmanned Teaming Study Report. 11 Grant Agreement number: EDIDP-MUGS-2019-002-iMUGS ANNEX 1 WP number Activity covered Start month M1 2 Design End month M26 Participant number 1.1 1.2 1.3 1.4 1.5 1.6 1.7 Short Name MILREM SAFRAN GTCT Bittium Insta GMV KMW PM per participant 241 193 142 266 0 85 4 Participant Number 1.8 1.9 1.1 1.11 1.12 1.13 1.14 Short name DIEHL NEXTER LMT UnManned ERM-KMS dotOcean EMA PM per participant 46 168 0 132 41 50 0 Objectives This WP will include all design activities of the project and also elaborate subsystem level engineering plans / specifications as configuration management, test and integration plans. The development will follow the iterative process described in section 6.1.4.1 allowing then to demonstrate all along the project some developed functions (performed in WP4). This overall objective is divided according to the main tasks:  to prepare and perform the System Requirements Review  to prepare and perform the Preliminary Design Review (PDR) and Customer Consultation / Critical Design Review (CDR).  to develop all the components that are composing the Autonomy subsystem (Autonomy Framework): the backbone, the autonomous algorithms and functions, the related means and tools for autonomy functions and mission’s development (data warehouse, simulation for autonomy, data labelling tool, collection of data for IA algorithm training, ...).  to provide a field-test ready communications system for the UGV application for all use cases.  to focus on the design phase of C2 software, including the design of user interfaces and human factors, and to maximize the use of Commercial-off-the-Shelf (COTS) hardware  to develop a generic framework for the design of a CDS allowing the system to be adapted to other autonomous vehicles for military or civilian uses and to design a solution for securing the supply chain from cyber threats.  to develop the results of the Swarming studies and tests within maritime domain into adaptations and improvements of algorithms to support UGV multi-agent collaboration.  to define the design for UGV and UAV integration into a Boxer for tests and demonstrations of military operational scenarios with focus on deployment and MUM-T. Description of the work Task 2.1 System and UGV/UAV design: MILREM (M2-M7) The objective of the task is to perform system requirements and design reviews, design and interface specifications (including single handed controller and THeMIS platform) for iMUGS system. Subtask 2.1.1 Design Reviews: MILREM (M4-M7) The objective of this task is to collect input, prepare and perform SRR, Customer consultations and Preliminary and Critical Design Reviews. MILREM will lead this task according to the requirements (derived in subtask 1.1.2) and will coordinate and conduct the design reviews with the engagement of relevant subproject leads and customer representatives. After SRR, an incremental design development process (throughout the consortium) with multiple deliveries will enable subsystems to finalize the design and continue into prototyping asynchronously, lowering risk and dependencies between subsystems. This will lead to multiple Preliminary Design reviews and Critical Design reviews concluding with a system level PDR and CDR. A Customer consultation is envisioned to be held before system prototyping (M6). Subtask 2.1.2 Design of a single-handed controller: MILREM (M2-M7) Under the lead of MILREM, subcontractor THREOD will develop and approve the design for intuitive one-handed remote controller for UGV system. Subtask 2.1.3 Design of iMUGS customized THeMIS platform: MILREM (M2-M7) A STANAG 4370/AECTP-500 (EMC) certifiable THeMIS UGV platforms will be provided to enable as- early-as-possible testing and verification of autonomy and other relevant system testing. Platforms will 12 Grant Agreement number: EDIDP-MUGS-2019-002-iMUGS ANNEX 1 reside at relevant partner locations for agile hardware-in-the-loop testing and verification campaigns. MILREM will be responsible for design implementation of THeMIS platform. Task 2.2 Design Autonomous Functions: SAFRAN, NEXTER, DIEHL, MILREM (M1-M18) Autonomy subsystem (Autonomy framework) is composed of Autonomy Backbone (HW, OS/Middleware/common services, autonomy sensors) and autonomy algorithms/functions. The design of such an Autonomy framework is based on specific tools as Data Warehouse (populated with data collected during specific campaign to address use cases defined by the project, to train Artificial Intelligent algorithms of Autonomy functions), autonomy simulation (with Hardware in the loop, for development and integration purpose), ... Subtask 2.2.1 Detailed specification and development of Autonomy Backbone: NEXTER, SAFRAN, MILREM, DIEHL (M1-M12) From the high-level specification of autonomy framework (Subtask 1.2.1), the objective of this subtask is to specify and develop the autonomy backbone that will be used as basis within the project to host all the algorithms and modules for the autonomous functions described in high level specification. Autonomy backbone will be divided into 2 parts: one SIL part for safety critical functions of autonomy and one non SIL part for non-safety critical functions of the autonomy. SAFRAN will lead the subtask. SAFRAN, DIEHL, NEXTER and MILREM will specify the detailed architecture of the autonomy backbone and will choose the adequate HW (computers and sensors) and SW (OS, tools) components. DIEHL will specify and purchase a certifiable computer system (SIL 3/4) based on existing standards (if no existing standards, DIEHL will make a proposal for standardisation). NEXTER will participate to the SIL software development on the SIL platform together with DIEHL. MILREM will develop the low- level drivers for selected autonomy sensors. SAFRAN will also develop the Non SIL computer part of the Autonomy framework, the common backbone services that will be used by all Autonomy functions and will propose a generic container for autonomy algorithms. Finally, SAFRAN will set up the Backbone together with the other partners as specified. Subtask 2.2.2 Detailed specification and development of Autonomy Data Warehouse: NEXTER, MILREM, DIEHL (M1-M12) The objective of this task is to specify, develop and populate a specific Data Warehouse for Autonomy Algorithms training. It also includes the specification of the data formats to be used within the Autonomy framework development and tools for data labelling. MILREM will lead this subtask and will buy the data Warehouse. MILREM will define, together with DIEHL, NEXTER and SAFRAN, the Data Warehouse architecture and will specify the collected data (in line with data regulations and existing data format definition). MILREM will, with NEXTER, develop the Autonomy Algorithms labelling and training tools together and organize data collection campaigns together with partners. DIEHL and NEXTER will provide recorded data from their own test campaigns for the warehouse. Subtask 2.2.3 Detailed specification and development of a simulation tool for Autonomy: NEXTER, SAFRAN, MILREM, DIEHL (M1-M12) The objective of this subtask is to specify and buy an adequate simulation tool in order to perform simulation of the Autonomy framework. The simulation tool will be used to integrate all Autonomy algorithms of the partners within the Autonomy Backbone (with the principle of Hardware (HW) in the loop simulation). It will also be used to test the Autonomy framework following the use cases selected in the Task 1.2 before integration and testing of the Autonomy framework in the global system within WP5. MILREM will lead this subtask. MILREM together with NEXTER, SAFRAN and DIEHL, will lead the specification of the simulation environment based on the use cases defined in task 2.2 and on the objective of the integration phase. For this, the simulation environment will be purchased and installed in each companies’ laboratories. Subtask 2.2.4 Detailed specification of Autonomy for Mobility: NEXTER, SAFRAN, MILREM, DIEHL (M6-M18) The objective of this subtask is to specify and develop the algorithms that will be used for the autonomy demonstrations according to specified Use Cases. The latter will refactor them to allow them to work seamlessly within the backbone. Several algorithms achieving the same function will be implemented to challenge the autonomy backbone containers definition and to provide a better final result through algorithm concurrency. 13 Grant Agreement number: EDIDP-MUGS-2019-002-iMUGS ANNEX 1 NEXTER will lead this subtask. NEXTER, SAFRAN and DIEHL will provide some existing state-of-the- art algorithms that are running on their existing platforms (NextMapping3D for localization based on lidar as well as obstacle map management, Path following on rough terrain based on vision, Object detection algorithms – already trained to detect soldiers, vehicles and weapons, way point navigation and patrolling, person follow, vehicle follow). These algorithms will be adapted to the new autonomy backbone and modified with respect to safety & security requirements in order to be employed to demonstrate the specified Use Cases. Subtask 2.2.5 Detailed Specification of Autonomy for Mission: NEXTER, SAFRAN, MILREM, DIEHL (M6-M18) The objective of this subtask is to specify and develop the building blocks necessary to fulfil the selected missions or capabilities. This task includes mission planning, live supervision features, specifications of man-robot interactions and Human Machine Interface (HMI):  formalisation of the planning and scheduling problem, identification of uncertainties in problem variables and parameters.  formalisation of mission constraints, objectives and operational resources. This formalisation is elaborated according to use cases.  Automatic generation of executable scripts based on planning formalisms  modelling, definition and development of solving techniques wit search algorithms, proposition and trials of heuristics.  development of machine-learning techniques, based on convolution graph neural networks to learn heuristics  verification, experimentation and evaluation on small and real scale operational scenario, extracted from use cases. NEXTER will lead this subtask. NEXTER, SAFRAN and DIEHL will provide and adapt some existing state-of-the-art algorithms running on their platforms and develop some new ones. MILREM will develop an interface to send information from THeMis platform to Autonomy framework and C2. Task 2.3 Design Cyber Security: GTCT (M1-M24) The objective of this task is to create the design of the CDS. This will begin with a generic framework that can be applied to any autonomous vehicle and then refined to incorporate the scope of the iMUGS vehicle. Mitigating measures to secure the supply chain will also be developed, as presented from the cyber risk assessment. Subtask 2.3.1 Design of Security Measures for UGVs: GTCT (M1-M12) This task will focus on the design of a generic framework that can be used as a cyber defence system for any military autonomous vehicle. GTCT will design the generic framework, in collaboration with all consortium partners in order to address every issue that must be solved by the generic design for any type of autonomous vehicle. Subtask 2.3.2 Design of the Security of the iMUGS Supply Chain: GTCT (M12-M24) The objective of this task is to analyse cybersecurity issues related to the supply chain used in the iMUGS project. With the information provided from RHEA’s Cyber risk assessment tool, GTCT will formulate a design document for addressing cyber risks and collaborate with the three companies selected for conducting the cyber risk assessment to address the issues presented from the assessment and to implement a solution from the design document. Subtask 2.3.3 Design of the iMUGS Cyber Defence System (CDS): GTCT, SAFRAN, GMV, Bittium, MILREM (M1-M24) GTCT will lead the effort in refining the scope of the generic security framework into a design which is tailored to the iMUGS project. This will primarily consist of incorporating the mission and specific architectural features (Autonomy, C2, Communications, and Swarming) into the design. GTCT will work in close collaboration with other partners to understand the specifics architectures of the subsystems, as the CDS must monitor the network traffic between the system components to observe for malicious activity. The system software will run on a high assurance Operating System (OS) that will be provided from a subcontractor, chosen after completion of the Cyber Risk Assessment. Subtask 2.3.4 Design of EW Capabilities: GTCT (M8-M24) The objective of this task is to design a subsystem capable of managing all aspects of Electronic Warfare (EW), to include the status of Emissions Control (EMCON) of radiating equipment, detection of GNSS 14 Grant Agreement number: EDIDP-MUGS-2019-002-iMUGS ANNEX 1 spoofing, and the security and control of EW based payloads, such as portable jammers. This will be designed with the assistance of GTCT’s subcontractor, Rantelon. Task 2.4 Design Communication equipment and network: Bittium (M2-M23) The design work comprises development and implementation activities and, in addition, required testing and integration activities. The integration shall be carried out in module, sub-system and system level (cross-WP). Manufacturing and integration of the physical prototype shall be carried out in Activity Prototyping. The work shall be carried out in 3 incremental steps with the 1st step focusing on demonstrating a concept based on existing capabilities (basic) and the 2nd demonstrating new more advanced capabilities as defined in the Feasibility Study. The 3rd step develops and integrates the full functionality to the communications module. The work comprises the following subtasks for all steps: Subtask 2.4.1 Secure network solution (SNS): Bittium (M2-M23) Developed jointly by Bittium and subcontractor Safemove, the secure network solution provides the required distributed services including Mobile VPN and MDM for end-to-end security, seamless networking and remote device management. It gathers various communication technologies in a single IP- entity. The SNS supports mobility with system level handovers, e.g. from mobile 4G network to tactical network and vice versa. A novel solution is to deploy AI/Machine Learning (ML)-based technology to add intelligent control and routing functionality to the system. Subtask 2.4.2 Enhanced V2V communications: Bittium (M6-M22) Bittium shall develop novel functionality integrated to the selected tactical waveform supporting an antenna solution that combines the connectivity of an omnidirectional antenna to high gain of directional antennas to support full mobility and swarming with superior combat sustainability Low Probability of Intercept/Low Probability of Detection (LPD, LPI) in V2V comms applications. Subcontractor DA-Design will develop the microwave RF front-end that will be integrated to the tactical communications equipment to support the short-range broad band V2V communications. Together these technologies will provide the capability for the vehicles to transfer broadband data between each other required to support joint operations and swarming. Subtask 2.4.3 Tactical waveform development for UGS: Bittium (M6-M21) Based on the results of the technology selection carried out in the feasibility study, Bittium develops new functionality integrated to selected tactical waveform that enhances the system performance with the aim to support mobility, combat sustainability and to meet the data transfer requirements of the iMUGS. As a result, this task provides a fully functional and high-performance tactical mesh network solution for the UGV communications, fully interoperable with systems deployed by the forces for manned operations. The solution will also fully support relayed multi-hop and tethered drones to extend the comms coverage. Subtask 2.4.4 Technology integration: Bittium (M6-M23) Together with subcontractors Safemove and DA-Design, Bittium carries out the integration of communications technologies; tactical, commercial, special etc. into a functional communications module (subsystem). The work also comprises integration/interfacing of the communications system to other systems (autonomy, C2, platform, cyber). Subtask 2.4.5 EW support: Bittium (M2-M22) Based on the results of the prestudy and technology selection, Bittium shall develop and integrate to the selected tactical waveform (Subtask 3.4.4) EW/ESM capabilities that enhance the performance of the UGV communications in the battlefield conditions. The functionality may include, for example, jamming detection, LPD, LPI, AJ, localization and countermeasures to the communications system. Task 2.5 Design Swarming: ERM-KMS, dotOcean, Insta (M1-M24) Design efforts related to architecture, interfaces, data structuring, search algorithms as well as solvers and optimizers needed to address the use cases shall be carried out in the following subtasks. The subtasks consist of spins with increasing complexity, considering system and controller constraints, data structures and data structuring and increasing dimensions, search and optimization algorithms and MOFS to translate objectives to tasks that fulfil the overall optimized objective of the swarming system within given constraints. Subtask 2.5.1 Architecture, internal interfaces and system design: dotOcean, ERM-KMS (M1-M7) This task aims at structuring all requirements into architectures, interaction methods and concrete technical solutions. DotOcean and EMR-KMS focus on edge-fog-cloud linked architectures supporting centralized decision making in a sufficiently timely manner. Insta focusses on architectures supporting decentralized decision making relying on local computational resources and data. 15 Grant Agreement number: EDIDP-MUGS-2019-002-iMUGS ANNEX 1 Subtask 2.5.2 External interface design: Insta, dotOcean, ERM-KMS (M5-M14) Partners will jointly agree on how to interface to a swarm, predominantly from the end-user perspective and the autonomy perspective should be designed and will define interfaces between C2, Comms and autonomy and define the interaction boundaries with the autonomy module. Define methods of controlling the vehicles as well as sharing data and metadata for optimization purposes. Subtask 2.5.3 Data capturing, annotations, structuring and search algorithms: Insta, dotOcean, ERM- KMS (M5-M19) Define generic and non-proprietary methods to organize and securely share data between agents or internal modules (ex: autonomy). Insta will focus on developing algorithmic solutions within constraints of the available computing power and data. DotOcean and ERM-KMS will focus on algorithms using distributed massive parallel computational resources. Define methods to distribute and outsource computations to other resources available in the network. Subtask 2.5.4 Solvers and optimizers: dotOcean, ERM-KMS (M8-M24) Solvers and optimizers will be defined and implemented. DotOcean and ERM-KMS will focus on solvers that can be distributed over edge-fog-cloud, in order to optimize all agents and objectives combined. Insta will focus on developing individual solvers within constraints of the available computing power and data. Task 2.6 Design Command and Control and Interoperability: GMV, (Un)Manned, MILREM (M3-M20) The objective of this task is to design the C2 subsystem components. Design considers three activities:  Software and hardware requirements specification.  C2 components preliminary design.  C2 components detailed design. This task will also address the elaboration of subsystem test plans and procedures. Subtask 2.6.1 UGV Control Station design: (Un)Manned, GMV, MILREM (M3-M20) The task aims to provide a Preliminary Design and Detailed Design of C2 components including software design, UGV CS GUI and human factors design, COTS HW specification and definition of test procedures. A focus on Systems interfaces and implementation, software design and conformance requirements and hardware computing requirements on the C2 components will be done. (Un)Manned will lead this task and work on real time safety-critical component of the C2 station to drive the UGV and its design aspects, including definition of flexible architecture with modifiable vehicle profiles to allow for modularity and expandability of the design. Further contributions/interactions with the UGV manufacturer and other specialists will be used to further clarify the HMI aspects. Design feasibility within DO-178C development framework will be analysed and the platform will be expanded if necessary. GMV with (Un)Manned will identify data and control exchange with the Tactical C2ISR, overall architecture and other human factors engineering work. Subtask 2.6.2 Tactical C2ISR design: GMV, (Un)Manned (M3-M20) This subtask aims to define system interfaces and implementation, including both software and hardware C2 components. Preliminary Design and Detailed Design of C2 components including software design, GUI design, COTS HW specification and test procedures. GMV works on the Tactical C2ISR design, including external interfaces, handling of data and clarification of computing and communication needs. GMV will collaborate with (Un)Manned and other actors on control and data handling and exchange between components, including non-real-time or safety critical payloads. (Un)Manned works on the data exchange and collaborates with GMV in data and control signals handling. (Un)Manned will also work on safety critical payloads so handling and operator control of those will be designed into the software architecture. Subtask 2.6.3 Interface design: GMV, (Un)Manned, KMW (M3-M7) The task is devoted to the design of interfaces between these components, interfaces with vehicle and interfaces with other system WP as Platform, Communications, Autonomy, Swarming and Cybersecurity. GMV will lead this sub-task with the contribution of (Un)Manned. KMW will provide contributions for HW and human factors requirements and C2 design, in relation with the integration of C2 in Boxer vehicle. Task 2.7 Design MUM-T: KMW, MILREM (M1-M23) With this task the design for the connection between an unmanned air or ground system and a Boxer, and the belonging integration will be written. Subtask 2.7.1 Design UGV and UAV deployment with Boxer: KMW, MILREM (M1-M23) Here the following topics will be defined: design for the integration of the UGV control elements in the Boxer, design for the integration of the UAV transport/starting/landing box and the antenna on the top of 16 Grant Agreement number: EDIDP-MUGS-2019-002-iMUGS ANNEX 1 the Boxer, design for the integration of the UAV control station with belonging connecting cables in the Boxer and finally how to test the development of the UAV integration at the Boxer at the EMC chamber of KMW. A Boxer driving module will be requested as provision of GFE by the BAAINBw (Federal Office of Bundeswehr Equipment, Information Technology and In-Service Support) for the demonstrations and tests (preliminary positive confirmation has been received). KMW will lead this subtask and be responsible for the definitions. MILREM will provide the UGV with control elements for its deployment with the Boxer, deliver UGV interfaces to get towed by the Boxer and provide a corresponding technical support. MILREM, together with the responsible for the UAV, will do the provision of the UAV with belonging transport/starting/landing box, control station, antenna and connecting cables for the deployment with the Boxer, deliver the interfaces for the provisioned UAV with belonging components and give technical support for the integration. Deliverables Synchronized with CDR meetings. Each Sub Project will have its own CDR. D2.1 iMUGS Detailed Design Definition: System’s Integration (Initial version). It includes input from all SPs. D2.2 iMUGS Detailed Design Definition: System’s Integration (2nd version). It includes input from all SPs. D2.3 iMUGS Detailed Design Definition: System’ Integration (Final version). It includes input from all SPs. 17 Grant Agreement number: EDIDP-MUGS-2019-002-iMUGS ANNEX 1 WP number Activity covered Start month M1 3 Prototyping End month M24 Participant number 1.1 1.2 1.3 1.4 1.5 1.6 1.7 Short Name MILREM SAFRAN GTCT Bittium Insta GMV KMW PM per participant 81 0 31 13 2 46 21 Participant Number 1.8 1.9 1.1 1.11 1.12 1.13 1.14 Short name DIEHL NEXTER LMT UnManned ERM-KMS dotOcean EMA PM per participant 2 7 14 51 0 0 0 Objectives This overall objective is divided according to the main tasks of this WP:  to build, from the components developed in the design activity, the Autonomy Framework (delivering autonomy backbone and sensors);  to build a functional prototype of the CDS and integrate it with the platform and other functional prototyped components of autonomy and C2;  to build, from the components developed in the design activity, the C2 subsystem including: Software for the Control Station and Tactical C2 components, Software/Hardware integration and C2 Subsystem Integration;  to assemble and integrate THeMIS platforms for testing by integrating subsystems and payloads at system level and prepare system functionalities for testing.  to provide a demonstration ready and validated integrated prototype.  to integrate an UAV and the control elements for an UGV and an UAV into a Boxer. Description of work Task 3.1 System prototyping: MILREM (M1-M30) The objective of this task is to manufacture the prototypes of Platform, single-handed remote controller and integrate payloads (including tethered UAV) with the system. Subtask 3.1.1 Prototype production of the platform: MILREM (M1-M12) A STANAG 4370/AECTP-500 (EMC) certifiable MILREM THeMIS UGV platform will be manufactured to enable as-early-as-possible testing and verification of autonomy and other relevant system testing. Platforms will reside at relevant partner locations for agile Hardware in the loop testing and verification campaigns. The service life of the vehicles is consumed by test-driving in various climatic environments and weather conditions to compile and fine-tune a dynamic model of the platform and assessment of the system traversability and provide maximum amount of real-life dynamic mobility data for development and verification of autonomy algorithms. No life-cycle management costs (extending the service life of the produced platforms) are foreseen during the projects. This activity caters for production of the units and concludes with an acceptance review. MILREM will be responsible to produce the THeMIS platform units. Subtask 3.1.2 Continuous system level integration: MILREM, All project partners (M5-M26) Purpose of the subtask is to coordinate the system level integration and verification efforts and ensure timely availability of the system components and verified subsystems. This will include the set-up and coordination for the distributed bench model - including the autonomy functions simulator - to enable rapid testing, inclusion on components and technologies, and to enable agile system level test driven development approach. MILREM will be responsible for leading system level integrations and leading respective reviews, with the support of relevant subsystem providers and SP leaders. Subtask 3.1.3 Integration of a Tethered UAV payload: MILREM (M4-M6) Purpose of the subtask is to integrate tethered UAV solution with the system and prepare for testing and demonstration. MILREM will be responsible for tethered UAV integration, with the support of THREOD (subcontractor and UAV provider). Subtask 3.1.4 Single-handed controller prototype: THREOD, MILREM (M8-M10) Purpose of the subtask is to manufacture the prototype of the intuitive single-handed remote controller for UGV system and prepare for testing and verification. Under the lead of MILREM, subcontractor THREOD will be responsible for the prototyping of the single- handed remote. Subtask 3.1.5 Continuous payload integration: MILREM, All payload partners (M2-M26) 18 Grant Agreement number: EDIDP-MUGS-2019-002-iMUGS ANNEX 1 The objective of this subtask is to integrate payloads to the system for functionality testing and demonstration. The activity will consist of integration planning, execution, verification and relevant pre- and post- integration reviews and will deliver the relevant iMUGS functionality augmentation to the respective demonstration events for ex: integrated ISR (kit, with electro-optical imagers, object detection capabilities and links to C4I infrastructure), MEDEVAC (relevant equipment with telemedicine capabilities) and force protection (ranging from ballistic protection, laser ranging detection etc) capabilities. MILREM will be responsible for payload integration (inc. verification) and relevant reviews with the support from payload providers. Task 3.2 Prototyping Autonomous Functions: SAFRAN, MILREM, DIEHL, NEXTER (M1-M18) The objective of this task is to provide within the project an autonomy sensor kit and a full autonomy framework for testing and integration within the THeMIS. Subtask 3.2.1 Integration of the autonomy sensor kit: SAFRAN, NEXTER, DIEHL, MILREM (M1- M6) The objective of this subtask is to buy all autonomy sensors identified in feasibility activity, to adapt them and integrate them to an autonomy sensor kit that will be tested within WP5 and integrated at system level on the THeMIS platform within WP4. All partners of autonomy SP will purchase together the sensors identified for dedicated autonomy functions (one set of sensors will be purchased by each partner). The sensors are selected taking into account the global cost of the autonomy sensor kit in order to reach the lowest cost for the needed performances. DIEHL, SAFRAN, MILREM and NEXTER will integrate the selected sensors in the autonomy framework (integration activities, sensor tuning) that will be tested then within the autonomy simulator. The resulting Autonomy sensor kit will be used by all partners of the autonomy SP for the tests and demonstrations realized within WP4. Subtask 3.2.2 Integration of Autonomy framework: SAFRAN, DIEHL, MILREM, NEXTER (M12- M18) The objective of this subtask is to take all components developed within Design activities (autonomy backbone, autonomy for mobility and mission algorithms) as well as the previously integrated autonomy sensor kit, and to integrate those components to the autonomy framework. The, so integrated, prototype of autonomy framework will then be tested within autonomy simulation in WP4 and integrated on THeMIS platform at system level within WP3. DIEHL, SAFRAN, MILREM and NEXTER will all purchase the components (HW and SW) needed for the Autonomy Framework and will integrate components developed within WP2 (each partner will purchase one set of components to build an autonomy framework). DIEHL, SAFRAN, MILREM and NEXTER will work together to integrate the backbone, autonomy sensor kit and autonomy algorithms within the autonomy framework (each partner will be in charge of integrating its own development within the autonomy backbone). The resulting Autonomy framework will be used by all partners of the autonomy SP for testing and demonstrations within WP4. 4 Autonomy Frameworks will be available for the project: 2 in France, 1 in Germany and 1 in Estonia. Task 3.3 Prototyping Cybersecurity: GTCT, SAFRAN, MILREM, Bittium, GMV, INSTA, DotOcean (M8-M20) The objective of this task is to prototype the Cyber Defence System’s Response Controller. This part of the system will be mounted within the THeMIS and provide recommendation of actions for the iMUGS to take in response to a compromise or cyber-attack. Subtask 3.3.1 Cyber Defence System Response Controller (CDS-RC) Prototyping: GTCT, SAFRAN, GMV, Bittium, MILREM (M8-M20) The objective of this subtask is to build the prototype of the CDS-Response Controller (CDS-RC). The software of this component will be developed using a high assurance Operating System (OS). GTCT will build the prototype with support from a subcontractor which will provide the high assurance OS; GTCT will develop the software that will run with the OS on the hardware platform. GTCT will coordinate with partners working on the autonomy, C2, communications, and swarming capabilities in order to ensure proper integration of the CDS-RC prototype for the monitoring and logging of communication between the networked components via physical taps. The hardware platform to run the software will be chosen to withstand the extreme conditions necessary to survive in an operational military environment. The chosen subcontractor used for development of the high assurance OS will assist with the selection of an appropriate hardware platform, ensuring functional correctness in the pairing of this hardware platform with the high assurance OS. Finally, GTCT will 19 Grant Agreement number: EDIDP-MUGS-2019-002-iMUGS ANNEX 1 collaborate closely with partners from the platform and autonomy sub-projects for physical integration of the CDS-RC hardware and network taps into the iMUGS platform and will build additional external hardware components to complete the prototype. Task 3.4 Prototyping Communication equipment and network: Bittium (M1-M22) Prototyping comprises physically constructing the demonstration system as well as integration of the sub- systems to form a functional entity that meets the defined requirements. The work comprises manufacturing the demonstration system components if required, system integration and system testing tasks. Although the HW-solution is based on existing products, the “prototype” equipment must be manufactured or purchased. Existing HW shall be deployed, if available. The task comprises the following subtasks: Subtask 3.4.1 Manufacturing & Assembly: Bittium (M1-M21) Together with subcontractor DA-Design, Bittium shall provide the required system components ready for assembly & integration. The subtask comprises procurement and/or manufacturing of the required equipment and materials etc. and assembly of the hardware components as well as installing the required soft- and firmware. Subtask 3.4.2 System integration: Bittium (M1-M22) This subtask, done together by subcontractor DA-Design and Bittium, will integrate the system components provided by T3.4.1 together. The task comprises both mechanical assembly work as well as testing as a joint effort with other project members. The work shall be carried out step-by-step adding new components to the entity until the system is ready for validation tests. Collaboration with other project participants and subprojects is essential in this task. Subtask 3.4.3 System validation: Bittium (M4-M22) Together with subcontractor DA-Design, Bittium validate the functionality of system components of the demo system through Initial testing. The tests shall be planned beforehand. As a result, an internal acceptance report shall be provided in addition to the demonstration ready system. Task 3.5 Prototyping Swarming: Insta (M21-M24) Subtask 3.5.1 Simulation environment for demonstrations of local swarming: Insta (M21-M24) A demonstration in a local swarming simulation will be finalized to allow demonstration of the developed algorithms. The simulation application will be able to simulate vehicles and military personnel. Insta will structure the data in a simulation application to enable demonstration of the developed algorithms. Task 3.6 Prototyping Command and Control and Interoperability: GMV, (Un)Manned, KMW, MILREM (M8-M24) The objectives of this task are to prototype the C2 components including the following activities:  Finalize software development.  Software/Hardware integration.  C2 Subsystem Integration. Subtask 3.6.1 UGV Control Station Prototyping: (Un)Manned, GMV (M8-M23) (Un)Manned will lead the prototyping of Control Station real time safety critical component and its adaptation to the mobile control environment. Subtask 3.6.2 Tactical C2ISR Prototyping: GMV, (Un)Manned (M8-M23) GMV will lead the prototyping of Tactical C2ISR components and manage and coordinate the C2 integration activities and ensure overall coordination. Subtask 3.6.3 C2 subsystem integration: GMV, (Un)Manned, KMW (M14-M24) This subtask is divided into 4 main activities: COTS hardware setup, installation and configuration of SW components in the HW, assembly of C2 HW deployable kit for Demo #3 and the integration of C2 HW Deployable Kit in Boxer Vehicle for Demos #4 and #5. All the activities related to the installation of the C2 HW Kit in the Vehicle and the use of additional vehicle HW devices or equipment are part of this subtask. Integration will be performed in 3 increments: Increment 1 for the scope defined in Demo #3 (Control Station and Tactical C2ISR: Version 1 + C2 HW in deployable kit). Increment 2 for the scope defined in Demo #4 (Control Station and Tactical C2ISR: Version 2 + C2 HW in Mobile Command Post (Boxer vehicle)). Increment 3 for the scope defined in Demo #5 (Control Station and Tactical C2ISR. Version 3 + C2 HW in Mobile Command Post (Boxer vehicle). Also, feedback from the operators/UV manufacturers point of view will be collected even at the prototype definition stage at each increment and lessons learned will be used in incremental updates of both tactical 20 Grant Agreement number: EDIDP-MUGS-2019-002-iMUGS ANNEX 1 C2ISR station and UGV control station. GMV will manage and coordinate the C2 integration activities. KMW will lead integration in Boxer vehicle for increment 3. Task 3.7 Prototyping MUM-T: KMW, MILREM (M1-M23) Objective of this task is the connection of the control elements of an unmanned air or ground system to a Boxer, and the belonging integration. Subtask 3.7.1 Integration of UGV control elements in the Boxer: KMW, MILREM (M1-M6) Within this subtask the UGV control elements will be integrated in the Boxer. KMW will lead this subtask and be responsible for the integrations in the Boxer. MILREM will provide the UGV with belonging control elements for the deployment with the Boxer and help with technical support. Subtask 3.7.2 Integration of an UAV box on, and an UAV control station in the Boxer: KMW, MILREM (M17-M23) Within this subtask the UAV transport/starting/landing box and the antenna on the top of the Boxer and the UAV control station with the belonging connecting cables in the Boxer will be integrated. MILREM, together with the responsible for the UAV, will provide the UAV with belonging transport/starting/landing box, control station, antenna and connecting cables for the deployment with the Boxer and help with technical support. Deliverables D3.1 iMUGS Demonstration 1 Ready System D3.7 iMUGS Demonstration 4 Ready System Prototype Prototype D3.2 iMUGS Integration Report 1 D3.8 iMUGS Integration Report 4 D3.3 iMUGS Demonstration 2 Ready System D3.9 iMUGS Demonstration 5 Ready System Prototype Prototype D3.4 iMUGS Integration Report 2 D3.10 iMUGS Integration Report 5 D3.5 iMUGS Demonstration 3 Ready System D3.11 iMUGS Demonstration 6 Ready System Prototype Prototype D3.6 iMUGS Integration Report 3 D3.12 iMUGS Integration Report 6 21 Grant Agreement number: EDIDP-MUGS-2019-002-iMUGS ANNEX 1 WP number Activity covered Start month M1 4 Testing End month M28 Participant number 1.1 1.2 1.3 1.4 1.5 1.6 1.7 Short Name MILREM SAFRAN GTCT Bittium Insta GMV KMW PM per participant 120 28 31 33 14 23 13 Participant Number 1.8 1.9 1.1 1.11 1.12 1.13 1.14 Short name DIEHL NEXTER LMT UnManned ERM-KMS dotOcean EMA PM per participant 17 27 0 33 15 29 0 Objectives This overall objective is divided according to the main tasks of this WP:  to test Autonomy Framework, based on Autonomy Framework prototype from WP3, through a dedicated autonomy simulation environment (developed in WP2, before the delivery of Autonomy Framework to the vehicle) and perform 3 demonstrations of autonomy functions;  to test the Cyber Defence System (CDS) in an operational setting, demonstrate security measures implemented to secure the supply chain, and to test Electronic Warfare (EW) payloads aboard the iMUGS platform in an operational setting as well as the platform’s resistance to EW type attacks;  to test the C2 components. C2 component testing, will ensure that each component meets the component SW requirements and provide traceability to the component SW requirements from Design WP. The C2 Subsystem Testing, with all C2 components jointly operating will provide traceability to subsystem technical requirements from Studies WP;  to demonstrate the UGV and UAV deployment with the Boxer and the integration of UGV/UAV control elements (HW/SW) in an existing vehicle/shelter for demonstration and as a test object for military operational scenarios;  to check and identify algorithm performance and identify additional data needs overseen in the swarm algorithm simulations;  to coordinate and support demonstration events: agreements on the venues, acquiring permissions and licenses from relevant authorities and ensuring safety requirements are met.  to ensure the certifiability of the relevant components and systems in iMUGS, including compiling certifiability assessments and roadmaps and performing relevant test campaigns;  to carry out the specified field tests and demonstrations for the communication modules. Description of the work Task 4.1 System Testing: MILREM, all project partners (M4-M28) The objective of this task is to prepare, conduct the system level testing campaign and provide input for verification if system functionality with regards to the system and mission requirements. MILREM will be responsible for the system level test campaigns, relevant reviews with the support from relevant subsystem and payload providers. Subtask 4.1.1 System level test reviews: MILREM, All project partners (M5-M28) The objective of this subtask is to prepare and conduct the system level testing reviews (acceptance of the system functionality) and confirm the system’s performance to the requirements. MILREM will be responsible for the system level test campaign and relevant reviews with the support form relevant subsystem and payload providers. Subtask 4.1.2 Demonstration events: MILREM, All project and partners (M4-M28) The objective of the ST is to prepare and organize operator-centric system functionality demonstrations as per project master schedule. The presence of participating Member States’ representatives and observers is planned. The selection of the venue and specific demonstration scenarios, the coordination and logistics and scenario verification will be catered for in this task. MILREM will be responsible for coordinating the demonstration events with the support from subsystem and payload providers and cater for communication with and pMS representatives and observers. Task 4.2 Testing Autonomous Functions: SAFRAN, NEXTER, DIEHL, MILREM (M12-M24) 22 Grant Agreement number: EDIDP-MUGS-2019-002-iMUGS ANNEX 1 This task focuses on Autonomy Framework testing and demonstrations. The task ensures the testing of the Autonomy Framework integrated in WP3 through autonomy simulator and validates its performances for the targeted autonomy missions. The integration will be carried out in stages: integration of baseline solution (backbone and sensors), intermediate level (as way point navigation, patrolling and surveillance missions). Each partner of the Autonomy SP is in charge of testing the Autonomy Framework for some dedicated autonomy missions, to perform a detailed analysis of the test campaigns regarding the performance and provide dedicated report. SAFRAN will be in charge of way point navigation and surveillance functions. NEXTER will be in charge of an alternative waypoint navigation, and patrolling functions. DIEHL will work on the follow me functions. MILREM will be the main contributor to demonstration regarding teleoperation LOS and BLOS. Task 4.3 Testing Cybersecurity: GTCT, SAFRAN, NEXTER, DIEHL, Bittium, MILREM (M18- M24) The objective of this task is to perform an operational demonstration of the cyber defence system in order to verify its functional correctness in identifying and responding to threats, as well as testing its robustness in the rigors of a military environment. Testing of the cyber risk assessment mitigating measures will also be conducted. Subtask 4.3.1 Test of Resilience to Communications Jamming: GTCT, Bittium (M18-M24) This test will validate the resiliency of the iMUGS communications system while operating in a hostile and contested Electromagnetic (EM) environment. The communications system will be subjected to jamming of specified frequency bands to ensure continued and normal operation. Subtask 4.3.2 Test of Resilience to GNSS Attacks: GTCT, SAFRAN (M18-M24) With the support of SAFRAN, GTCT will perform this test. It continues the validation of resiliency for iMUGS to operate in an EM contested environment. The test will focus on providing a spoofed or denied GNSS signal to iMUGS to validate capability of detecting and continuing operation in this environment. Subtask 4.3.3 Test of Cyber-Attack Detection: GTCT, LMT, SAFRAN, NEXTER, DIEHL Bittium, MILREM (M18-M24) With the support of LMT, SAFRAN, NEXTER, DIEHL, Bittium and MILREM, GTCT will perform this test. It will focus on validating the complete CDS, using a red team provided from LMT. A real vulnerability will be inserted into the system and the red team will exploit this to demonstrate a potential system compromise, however the CDS will not be active or installed. Following this, the same test with the same exploit will be conducted on an iMUGS platform with the CDS installed and activated. The second test will demonstrate the capability of the system to detect the compromise, alert the Response Controller, and for the Response Controller to recommend to autonomy the appropriate action to take. GTCT will develop, plan, and test with assistance from LMT’s red team. Subtask 4.3.4 Supply Chain Security Demonstration: GTCT, MILREM (M18-M24) This test will demonstrate a security risk discovered through the cyber risk assessment. The test will demonstrate how this vulnerability in the supply chain could introduce malicious activity into the platform, and how measures implemented from the risk assessment will stop this action. GTCT will develop, plan, and execute the test with support from their subcontractor RHEA. Subtask 4.3.5 Test of high assurance Cyber Defence System Response Controller (CDS-RC): GTCT, MILREM, SAFRAN, NEXTER, DIEHL (M18-M24) WIth the support of SAFRAN, NEXTER, DIEHL and MILREM, GTCT will perform this test. It validates the functionality of the CDS-RC in an operational setting by providing a test signal to the Response Controller (RC), indicating a potential compromise. The test will also validate the hardening of the RC in withstanding the rigors required to operate aboard the iMUGS platform in an operational setting. GTCT will develop, plan, and execute the test in the operational environment. Task 4.4 Testing Communication equipment and network: Bittium (M5-M26) Testing is a joint activity with selected consortium members comprising system level integration of ready modules (system components) and testing activities required to ensure the proper functionality of the developed system. In addition, the task comprises preliminary field testing and demonstrations. Finally, the results of the activity shall be analysed and documented. 23 Grant Agreement number: EDIDP-MUGS-2019-002-iMUGS ANNEX 1 Subtask 4.4.1 Field tests: Bittium (M5-M23) The 1st step towards demonstrations is to test the validated system in limited/specific environments and use cases. The work shall be carried out by arranging field tests with specific goals. With the support of subcontractor DA-design, Bittium will perform the tests. It shall be planned beforehand and will be continued until all required system functionality has been tested. Subtask 4.4.2 Demonstrations: Bittium (M6-M26) With the support of subcontractor DA-design, Bittium will perform the demonstrations. It shall be arranged as a joint effort with selected project members. The content and other practical details for the demonstrations shall be planned together with the end-customer. It is assumed, there will be multiple demonstrations with possibly different project members with different focus; functionality, use cases, equipment and implementation. Subtask 4.4.3 Analysis & Reporting: Bittium (M7-M26) With the support of subcontractor DA-design, Bittium will perform the task. It analyses the results of the field tests and demonstrations and provides the documentation. Task 4.5 Testing Swarming: dotOcean, ERM-KMS, Insta (M1-M24) Verification and demonstrations of the implemented designs and joint integrations. Understanding the boundary conditions of the performance of the designs and identifying improvements to be taken to the next design spin. Subtask 4.5.1 Hardware tests: dotOcean, MILREM (M1-M5) Test the integration of dotOcean AYB with multiple MILREM AGV’s and 10 small vehicle platforms. The objective is to have several vehicles available for future algorithm testing and demonstration. DotOcean will integrate and test in close cooperation with MILREM. Subtask 4.5.2 Field tests of dual objective swarms: dotOcean, ERM-KMS, MILREM (M12-M14) Field testing algorithms to optimize a multi-agent system against 2 objectives in a fully structured world (combined patrol and resupply use cases). The aim is to match theory (swarming simulations) on the practical world and to analyse for possible gaps in the available structured data given to the optimization algorithms. DotOcean will be supported by ERM-KMS during the field tests in close cooperation with MILREM. Subtask 4.5.3 Field tests on constraint control and multi objective swarms: dotOcean, ERM-KMS (M19-M23) Testing use cases including constraints on the vehicle dynamics (accelerations, rotations) or vehicle trajectory, such as MEDEVAC, will be tested. A multi-agent system optimized against multiple objectives simultaneously is aimed to be demonstrated. ERM-KMS will provide their equipment and support to dotOcean during the field tests. Subtask 4.5.4 Demonstrations: dotOcean, ERM-KMS, Insta (M21-M24) Multi objective swarms in a fully structured world will be demonstrated. The local swarming will also be demonstrated in simulated environment. DotOcean, ERM-KMS and Insta will participate in the demonstrations. Subtask 4.5.5 Reporting: Insta, dotOcean, ERM-KMS (M21-M26) Performance and requirements of local and global swarming will be analysed and reported based on the demonstrations. ERM-KMS will coordinate the reporting activities of SP4. Task 4.6 Testing Command and Control and Interoperability: GMV, (Un)Manned, KMW (M17-M26) This task in general focuses on verification of the developed command and control station, interworking of developed components at module level and interworking with the UGV system, in both controlled environments and field testing with a manned vehicle-based control platform. Subtask 4.6.1 UGV Control Station Testing: (Un)Manned, GMV (M17-M23) It will cover individual software component testing at UGV control station level. Testing activities include development of the test rigs, specific test software and test procedures, report formats and associated meetings/demonstration activities. UNMANNED will lead the test planning, execution and reporting of C2 test procedures at the UGV Ground station level. Identification and integration of feedback and change requests from users/other stakeholders will be part of the subtask. Subtask 4.6.2 Tactical C2ISR Testing: GMV, (Un)Manned (M17-M23) 24 Grant Agreement number: EDIDP-MUGS-2019-002-iMUGS ANNEX 1 It will cover individual software component testing at tactical C2ISR level. GMV will lead the test planning, execution and reporting of C2 test procedures at the Tactical C2ISR level. Identification and integration of feedback and change requests from users/ stakeholders will be part of the subtask. Subtask 4.6.3 C2 subsystem testing: (Un)Manned, GMV, KMW (M17-M26) This subtask covers overall integrated testing of the Command and Control subsystem and its integration into the demonstration platform as an integrated C2 function. Subsystem Testing will be performed in 3 increments: Increment 1 for the scope defined in Demo #3; Increment 2 for the scope defined in Demo #4; Increment 3 for the scope defined in Demo #5. (Un)Manned will lead the test execution and test reporting of C2 test procedures. KMW will provide support for the Boxer vehicle command post during demonstrations and tests and evaluate the results of the C2 tests for the MUM- T evaluation study to advance on the military operational scenarios with test feedback. Task 4.7 Testing MUM-T: KMW, MILREM (M1-M24) The military operational scenarios of the initial MUM-T study will be tested and demonstrated for evaluation within this task. Subtask 4.7.1 Demonstration of the UGV deployment with the Boxer: KMW, MILREM (M1-M6) This subtask will test and show with the help of a demonstration, what a possible way of deployment may look like with the following activities: preparing the UGV to get towed by a Boxer. Towing the UGV, releasing the UGV from the tow rope, controlling the UGV from the Boxer in LOS and BLOS mode. The steering of the UGV will be one by the control elements installed in the Boxer. This test will be made as part of the upcoming demonstrations, where representatives of the EU and the participating member states can attend. The results will be considered in the MUM-T evaluation study. MILREM and KMW will be responsible for the organisation. KMW will be responsible for the Boxer. MILREM will be responsible for the UGV. Subtask 4.7.2 Demonstration of the UAV deployment with the Boxer: KMW, MILREM (M10-M24) This subtask will consist in several activities. The first one will consist in starting the UAV from the top of the Boxer. The partners will also control the flight of the UAV from the control station inside the Boxer, show the information exchange between the UAV and the control station inside the Boxer, and land the UAV on the top of the Boxer. These tests will be made as part of the upcoming demonstrations, where representatives of the EU and the participating member states will attend. MILREM and KMW will be responsible for the organisation, KMW will be responsible for the Boxer, and MILREM together with a subcontractor will be responsible for the UAV. Deliverables D4.1 iMUGS Test Report 1 D4.7 iMUGS Test Report 4 D4.2 iMUGS Demonstration 1 D4.8 iMUGS Demonstration 4 D4.3 iMUGS Test Report 2 D4.9 iMUGS Test Report 5 D4.4 iMUGS Demonstration 2 D4.10 iMUGS Demonstration 5 D4.5 iMUGS Test Report 3 D4.11 iMUGS Test Report 6 D4.6 iMUGS Demonstration 3 D4.12 iMUGS Demonstration 6 25 Grant Agreement number: EDIDP-MUGS-2019-002-iMUGS ANNEX 1 Description of Management and Coordination (effort included into activities) Objectives  To ensure an efficient coordination of the consortium throughout the whole project duration;  To enable fluid communication among participants, with European Commission and towards relevant stakeholders;  To monitor the progress of the tasks and deliverables of WPs and SPs;  To foresee any risks of delay and set up mitigation plans and corrective actions;  To prepare the special reports and facilitate the end-user’s involvement through the EAB, to guarantee user-driven results;  To communicate and disseminate the project results;  To ensure the management of the data collected within technical WPs;  To ensure the ethics management; For an overview, kindly refer to section 6.1.4.2. Description of work Task 0.1 Project coordination and management: MILREM (M1-M30) Subtask 0.1.1 General coordination of the consortium: MILREM (M1-M30) This task consists of general management of the consortium and communication among partners, with the European Commission (EC) and other stakeholders. The Project Coordinator (PC) will be the contact point for the EC and will ensure the communication between the Consortium and the EC as well as among consortium members. The PC will ensure that all procedures implemented within iMUGS are in line with the Grant Agreement and the Consortium Agreement. He will ensure that each partner is well informed of the project progress, understands its role and contractual obligations in the project, and is aware of the requests and information from the EC. Regular phone meetings between the Project Coordinator and EC project officer will be organized to ensure the correct monitoring of the action. The coordinator will submit a monthly project status report to the project officer based on a template to be provided by EC. The coordinator will also ensure the correct update of the Workspace in EC Collaboration Platform. Subtask 0.1.2 Monitoring of the progress and daily management: MILREM, all partners (M1-M30) The monitoring of the project progress will be made through regular meetings and conference calls. A - In addition to the Kick-off Meeting and the Final Meeting of the project, the periodical meetings of the Steering Group (SG) will allow a thorough monitoring and operational management of the project. The internal monthly Progress Reports provided by each partner will allow the SG to monitor the project’s progress, foresee any risk of delay, set up any mitigation plan accordingly and finally make information-based decisions. The project coordinator, with the support of the project management team, will be in charge of the organisation of the meetings and conference calls as well as the preparation of the meeting minutes. SP leaders will organise meetings of their SPs. B - Daily management of the project includes the coordination among partners to ensure timely delivery of the project reports and deliverables to the EC. The project coordinator and sub-projects lead the procedure and deadlines, will create and use specific tools such as deliverable and milestone follow-up tables, templates for minutes and deliverables, keep contact list up to date, web conference tools and so on for the daily management of the project. Management procedures (preparation of the reports, validation procedure of deliverables, financial aspects, etc.) will be presented to the participants by the Project Coordinator during the meetings. Subtask 0.1.3 Quality assurance, risk management: MILREM, all partners (M1-M30) A - To ensure a high quality of deliverables produced by iMUGS, a quality assurance loop for all relevant documents will be established. The Project Coordinator will set a quality and risk management policy validated by the SG covering all aspects related to practical management of the project. The main issues addressed can include project SWOT, technical and non-technical risk management incl. critical path of the project and associated contingency plans, communication and quality control activities. For instance, it will clearly state internal processes related to standards of documents, proof- reading, validation workflow for the approval of deliverables, reports and communication activities. 26 Grant Agreement number: EDIDP-MUGS-2019-002-iMUGS ANNEX 1 B - Regarding the risk management, the risks identified (see section 6.1.4.2.) will be logged in a Risk Register created at the beginning of the project and updated during the lifetime of the project. These risks will be structured along each SP and classified in several categories, such as structural, managerial, operational, technical, scientific, financial or legal. The risks will be assessed and prioritised by the SG and monitored by the PC. In each SG meeting, a risk management session will be held, the list of the risks will be updated, each risk will be reviewed and new mitigation measures and partners responsible for implementing mitigation measures will be defined. Subtask 0.1.4 Reporting and financial management: MILREM, all partners (M1-M30) A - Preparation of Periodic and Final reports will be coordinated within this task. The procedure will be explained to the partners by the Management Support Team (MST). All partners will get support and necessary information regarding how to prepare their technical and financial reports. Basically, each SP leader will report the progress within his/her SP to the PC, who will consolidate all the data, complete the management aspects of the report and send it to the coordinator. The coordinator will complete and inspect the report before submission to the EC. B - Financial procedures include the plan for the transfer of the European funding to the consortium, the transfer of payments, guidance on costs declaration, etc. Person-month (PM) and over-all budget consumption by partners will be monitored in order to comply with the planned PM effort. This task will also be carried out by PC who will consolidate and analyse financial data at the end of each reporting period to compare the actual costs vs. budget figures and anticipate any deviations (over or under consumption), with the PC. The PC will check the quality (completeness, correctness, requested format...) of information from all partners and review all individual financial statements to ensure the consistency with the planned and real technical tasks and to verify each partners’ engagement. Subtask 0.1.5 Security management: MILREM, all partners (M1-M30) A Security Management Board (SMB) can be established with the participation of one Security Officer per partner. The SMB, chaired by MILREM, will deal with all the issues related to the security and provide advice and recommendations on the security aspects of the project. The Consortium will try, if possible, to concentrate the use of classified background information in specific parts of the relevant deliverables (e.g. annexes) and mark them accordingly. This task can be combined with task for communication. Task 0.2 Subprojects Coordination: MILREM, SAFRAN, GTCT, Bittium, ERM-KMS, GMV, KMW (M1-M30) The subprojects will be coordinated by leaders: MILREM (SP1), SAFRAN (SP2), GT Cyber Technologies (SP3), Bittium (SP4), RMA (SP5), GMV (SP6), KMW (SP7). They will be in charge of monitoring the progress of each technical tasks which they will be responsible of. Each SP leader will organise periodical meetings with the technical tasks' leaders. Regular phone meetings will also be held. Coherently to the projects’ reporting plan, the SP leaders will be in charge of producing reports to the respective WP coordinators to monitor the progress. The coordinator will gather the inputs in order to prepare the global reports. Task 0.3 Management of the Advisory Board (AB): MILREM, all partners (M1-M30) An AB gathering end-users (military subject matter experts, policy advisors and national and EU stakeholders) can be set-up for the project. AB will be consulted during workshops in order to gather inputs on the military scenarios, operational requirements and on the prioritization and alignment of the development roadmap with national and multinational initiatives. Task 0.4 Communication and dissemination of project results: MILREM, all partners (M1-M30) Subtask 0.4.1 Communication: MILREM, all partners (M1-M30) At M6, MILREM can provide a plan for communication including the adopted strategy, target audience, type of actions, and persons responsible for the implementation and planning of the actions. Based on our preliminary plan and taking into account EU law on protection and access to classified information, following communication activities will be undertaken: a project identity set including a logo; an A4 brochure; elaboration of Releasable Information, classification of Releasable Information and confidentiality (with the verification of PC); set-up of the secured project website, social media account and press releases; organisation of the final engagement event/workshop bringing together relevant stakeholders from industry, R&D, policy makers for the final demonstration of the core 27 Grant Agreement number: EDIDP-MUGS-2019-002-iMUGS ANNEX 1 technologies. The PC with the support of the MST will implement these actions with contributions from partners (transfer of information on achievements & results, specific actions by partners themselves…). This task can be combined with task for security management. Subtask 0.4.2 Dissemination of the project results: MILREM, all partners (M6-M30) This task is devoted to disclosing and disseminating (in a controlled manner) the iMUGS results to relevant stakeholders and it will follow the indications of the Dissemination Plan. The disclosure of the results is addressed to different audiences. Each new result will be disseminated by the partner(s) who have generated the result(s), when it is not protected or exploited. The PC with the support of the MST will ensure the compliance, regarding IPR & Data, with the dissemination rules from the Consortium Agreement and EU law regarding protection and access to classified information. The research organisations in the consortium can publish articles about scientific and technical achievements of the project in peer-reviewed journals, via presentations at NATO Industrial Advisory Group, EDA fora and other relevant international conferences and workshops. Task 0.5 Data and IPR Management: MILREM, all partners (M1-M30) Subtask 0.5.1 Data management: MILREM (M1-M30) The PC with the support of the MST will prepare with the help of SP leaders the Data Management Plan (DMP) specifying the type of data to be collected throughout the project, the legal base, the codification-anonymization procedures, and the data safety and security measures. Subtask 0.5.2 IPR Management: MILREM, all partners (M1-M30) Throughout the project, the PC with the support of the MST will support partners to identify protectable results and provide them with advice for protection of the results. The PC with the support of the MST will ensure the coordination of the consortium and internal communication on IPR issues. The Consortium Agreement will be the reference point for all IPR processes. Task 0.6 Ethics Management: MILREM (M1-M30) At the beginning of the project, an ethics code of conduct can be prepared by the PC with the support of the MST in which ethical challenges and good practices will be identified. During each reporting period, the PC with the support of the MST will perform ethics checks to verify that adequate measures as noted above have been implemented at the mid-term and final milestones, identify ethical gaps and recommend mitigation actions. The ethics checks conclusions can be included in the Periodic Report (for Period 1) and in D0.4 at the end of the project. An ethics risk assessment of the issue of minimizing collateral damage can be conducted and potential risk mitigation measures that might support further development and technology are identified. The Periodic Report for Period 1 and D0.4 can include a check of the measures (such as potential technical options, approaches to the use of military equipment) suggested within the project to fulfil the gaps in regulations. The Ethics Check will be conducted by person(s) having prior expertise in military ethics and law of armed conflicts. Deliverables D0.1 (M1) iMUGS Project Plan D0.2 (M13) iMUGS Progress Report 1 D0.3 (M25) iMUGS Progress Report 2 D0.4 (M30) iMUGS Final Report D0.5 (M2-28) iMUGS Progress Report In addition, SP leaders will deliver monthly internal reports to the PC. The PC will coordinate security management, risk management, system’s engineering management documentation and produce relevant internal documents. 28 Grant Agreement number: EDIDP-MUGS-2019-002-iMUGS ANNEX 1 4.3. List of deliverables No iMUGS Deliverable Work Short name Type Reporting conditions Dissem Delivery package of lead ination date number participant [in months] D0.1 Project Plan 1 Milrem R Full Release of deliverable to EC CO M1 D1.1 Development and Test Plan 1 Milrem R Full Release of deliverable to EC CO M3 D4.1 Test Report 1 4 Milrem R Full Release of deliverable to EC CO M5 Detailed Design Definition: System’s Integration 2 Milrem Summary Report of deliverable sent to EC D2.1 R CO M7 (Initial) D3.1 Demonstration 1 Ready System Prototype 3 Milrem R Summary Report of deliverable sent to EC CO M8 D3.2 Integration Report 1 3 Milrem R Full Release of deliverable to EC CO M8 D4.2 Demonstration 1 Report (EE) 4 Milrem R Full Release of deliverable to EC CO M8 D4.3 Test Report 2 4 Milrem R Full Release of deliverable to EC CO M10 D3.3 Demonstration 2 Ready System Prototype 3 Milrem R Summary Report of deliverable sent to EC CO M11 D3.4 Integration Report 2 3 Milrem R Full Release of deliverable to EC CO M11 D4.4 Demonstration 2 Report (LV) 4 Milrem R Full Release of deliverable to EC CO M11 D0.2 Progress Report 1 1 Milrem R Full Release of deliverable to EC CO M13 D4.5 Test Report 3 4 Milrem R Full Release of deliverable to EC CO M13 D3.5 Demonstration 3 Ready System Prototype 3 Milrem R Summary Report of deliverable sent to EC CO M14 D3.6 Integration Report 3 3 Milrem R Full Release of deliverable to EC CO M14 D4.6 Demonstration 3 Report (BE) 4 Milrem R Full Release of deliverable to EC CO M14 Detailed Design Definition: System’s Integration 2 Milrem Summary Report of deliverable sent to EC D2.2 R CO M15 (Second) D4.7 Test Report 4 4 Milrem R Full Release of deliverable to EC CO M17 D3.7 Demonstration 4 Ready System Prototype 3 Milrem R Summary Report of deliverable sent to EC CO M18 D3.8 Integration Report 4 3 Milrem R Full Release of deliverable to EC CO M18 29 Grant Agreement number: EDIDP-MUGS-2019-002-iMUGS ANNEX 1 No iMUGS Deliverable Work Short name Type Reporting conditions Dissem Delivery package of lead ination date number participant [in months] D4.8 Demonstration 4 Report (FI) 4 Milrem R Full Release of deliverable to EC CO M18 D4.9 Test Report 5 4 Milrem R Full Release of deliverable to EC CO M21 D3.9 Demonstration 5 Ready System Prototype 3 Milrem R Summary Report of deliverable sent to EC CO M22 D3.10 Integration Report 5 3 Milrem R Full Release of deliverable to EC CO M22 D4.10 Demonstration 5 Report (FR) 4 Milrem R Full Release of deliverable to EC CO M22 D4.11 Test Report 6 4 Milrem R Full Release of deliverable to EC CO M23 D2.3 Detailed Design Definition: System’s Integration (Final) 2 Milrem R Summary Report of deliverable sent to EC CO M24 D3.11 Demonstration 6 Ready System Prototype 3 Milrem R Summary Report of deliverable sent to EC CO M24 D3.12 Integration Report 6 3 Milrem R Full Release of deliverable to EC CO M24 D4.12 Demonstration 6 Report (DE) 4 Milrem R Full Release of deliverable to EC CO M24 D0.3 Progress Report 2 1 Milrem R Full Release of deliverable to EC CO M25 D1.3 Manned-Unmanned Teaming Study Report 1 Milrem R Full Release of deliverable to EC CO M30 D1.2 Study Report 1 Milrem R Full Release of deliverable to EC CO M30 D0.4 Final Report 1 Milrem R Full Release of deliverable to EC CO M30 1 Milrem Full Release of deliverable to EC M2, M4, M6, M8, M10, Continuous reporting (updated project work plan, risk D0.5 R CO M16, M18, and issue report) M20, M22, M28 30 Grant Agreement number: EDIDP-MUGS-2019-002-iMUGS ANNEX 1 4.4. List of milestones No iMUGS Milestone WP Due date Means of verification MS1 System’s Requirements Review 1 M3 SRR report approved MS2 Critical Design Review 2 M6 CDR report approved MS3 Demonstration 1 3-4 M8 Functionality approved and verified; Demonstration 1 Report MS4 Demonstration 2 3-4 M11 Functionality approved and verified; Demonstration 2 Report MS5 Demonstration 3 3-4 M14 Functionality approved and verified; Demonstration 3 Report MS6 Demonstration 4 3-4 M18 Functionality approved and verified; Demonstration 4 Report MS7 Demonstration 5 3-4 M22 Functionality approved and verified; Demonstration 5 Report MS8 Demonstration 6 3-4 M24 Functionality approved and verified; Demonstration 6 Report MS9 Engagement Event 4 M29 Final review; Event Minutes approved 31 Grant Agreement number: EDIDP-MUGS-2019-002-iMUGS ANNEX 1 4.5. Critical risks for implementation Description of risk Proposed risk-mitigation measures Technologies performances Some developed components are not The integration process will be progressive and step by sufficiently performing. step. As soon as an intermediary version of a WP: 1-5. Level of likelihood: Low component is ready, it will be tested in the distributed bench model and/or physical platform. Test driven development is foreseen for hardware and software which inherently lowers the risk of hardware performance and software bugs etc. The issues will therefore be solved gradually and not discovered at the end. In addition, early and clear definition of technologies, interfaces and conventions will help to reduce this risk. Also, emulation of not yet available components by mock-up or simulation can be used. The experimental demonstration could be repeated once the advanced components become available. Unforeseen technical problems that may The situation will be assessed by the Steering not be resolved with the assigned committee of the project, in collaboration with the resources. involved WP/SP leaders to decide about adequate re- WP: 2-5. Level of likelihood: Low planning actions that ensure the overall project result. System inability Non-availability or underestimation of key Regular reviews to ensure availability of the key human resources at key points of the resources. PC and WP leaders will monitor project. continuously the progress, the resource consumption WP: 1-5. Level of likelihood: Low and reallocate work between partners and WPs according to the joint responsibility clause. Difficulties and delays in integration of Careful definition of technical requirements and iMUGS components. especially of module interfaces. Long lead items, e.g. WP: 1-5. Level of likelihood: Low base vehicle component, are specified in the procurement plan (included in the Management Plan). Test driven development approach for hardware and software. Consider user’s interaction and procedures. Active involvement of the project coordinator and early reporting when a risk is recognizable. Due to system complexity, the integration Usage of Model Based systems engineering: Model and reduces overall system performance. continuously measure component and system WP: 2-5. Level of likelihood: Low/Medium performance throughout design, development and integration activities. Concurrent view of system budgets (bandwidth, mass and derived performance indicators) will always be available and can be used for simulating overall system performance. The use of appropriate tools (Model Based Systems Engineering (MBSE) software) will assess potential shortcoming before the actual integration/demonstration of the system. Inability to perform a demonstration. Early planning to ensure availability of facilities. The WP: 5. Level of likelihood: Low consortium will take necessary actions in a timely manner (detailed demonstration preparation plans, pre- demo acceptance reviews, dry-runs, contingency planning, time buffers), well before the actual dates to ensure proper delivery. In the case of a force majeure, 32 Grant Agreement number: EDIDP-MUGS-2019-002-iMUGS ANNEX 1 the use of appropriate tools, e.g. existing simulation environment, can be used for the provision of a synthetic scenario build. Operational value of the demonstrated Clear criteria defined for demonstrability. Close system not evident to audience during/after coordination of the demonstration contents and demonstrations. scenario with Steering Board and consultations with WP: 5. Level of likelihood: Low/Medium PMS. Partner underperforms or leaves the In case of a partner’s departure, pending workload will consortium. be re-distributed among partners based on their WP: 1-5. Level of likelihood: Low/Medium competences. In addition, the Consortium Agreement will foresee such situations and will describe measures to be taken to prevent non-compliance to project activities. Low quality of project results. The internal acceptance reviewing process for all WP: 1-5. Level of likelihood: Low project deliverables and reports, plus the contribution of the Advisory Board, will ensure high quality project results. A Quality Assurance plan will ensure a sound review procedure. Delays in the tasks’ completion due to lack The project work plan has been carefully drafted, and of resources, inability of partners or the partners have extensive experience in participating disharmony in the collaboration. in similar projects. The coordinator and the project WP: 1-5. Level of likelihood: Low/Medium management team will adopt a proactive approach by identifying all critical paths in the project and by performing the necessary rescheduling and crashing. Detailed schedule will be presented at project Kick- Off. Missing communication and preparations Incorporation of the representative of the participating between the participating MoD’s can member states as early as possible. Establishing a endanger the generation of a common central point of contact for the participating MoDs and understanding within the proposed planning with enough spare time. schedule. WP: 1-5. Level of likelihood: Low/Medium System Integration delays or increased Interfaces are specified and developed according to costs resulting from legacy or incoherent widely accepted standards (STANAG, etc). interfaces from subsystems or components. Performance is predicted by system level data WP: 1-5. Level of likelihood: Low/Medium budgeting and modelling and verified at the bench model and after physical assembly. Users acceptance User requirements do not capture user We assume a latent cooperation (engagement of end- intentions. users to the capture process: consultations, requirement WP: 1-2. Level of likelihood: Low verification etc). The developed solution is too expensive to The modular iMUGS system will provide different be affordable by end-users. levels of complexity, so a range of solutions (including WP: 1-5. Level of likelihood: Low different individual components) with varying costs will be available as an end product. Proposed solutions are not aligned with the Societal concerns are taken into account at an early European core values. stage by SP 2. Study prepared. WP: 2. Level of likelihood: Low Legal, Regulatory Limited access to NATO standards could Use national representatives to monitor the sensitive jeopardize interoperability between our standards. Dedicate a person from each partner with solution and the external environment. enough security clearance to act as a Proof of Concept WP: 2-5. Level of likelihood: Low (PoC)with national MoD for compliancy monitoring 33 Grant Agreement number: EDIDP-MUGS-2019-002-iMUGS ANNEX 1 w.r.t sensitive standards. iMUGS solution is not compliant with Early in-depth analyses of legal issues in SP2. EU-level national and EU legislation. developments on AI ethics are monitored and assessed. WP: 2. Level of likelihood: Low Conflicts between upcoming regulations Watch on the technologies and regulations which and our SoS configuration (from the safety impact the architecture definitions, including ground perspective). vehicles’ military and civil regulations. Liaise with WP: 1-5. Level of likelihood: Low/Medium regulatory authorities and apply for permission in due time both for demonstrations and in case of new regulative restrictions. Wide gap between the components’ Expose regularly the risk (list of gaps, and procedure requirements provided by the nations and for agreement based on driving parameters for the the one provided by the consortium. technology) to the MoDs so they can react WP: 1-2. Level of likelihood: Low/Medium appropriately to minimize the risk occurrence. National export authorities do not approve Apply for export licences in due time, prepare export of equipment for a demonstration to authorities with background information and involve in another EU country. project progress at project Kick-Off Meeting (KOM). WP: 1, 5. Level of likelihood: Low Co-financing through procurements Preparing procurement documentation and timely unknown until a too long period. delays on procurement assessment. WP: 1. Level of likelihood: Low/Medium Missing export licenses can delay the Requests for export licenses will be completed in transport and the belonging follow-on advance, implementing time buffer considering the tasks. follow-on tasks. Following the KOM, a review of the WP: 1, 5. Level of likelihood: Low/Medium needs will be realised through the consortium. Dates, deadlines and timelines will be centralized for follow up. 4.6. Summary of staff effort WP1 WP2 WP3 WP4 Beneficiary Studies Design Protot. Testing Total 1.1 Milrem AS 70 241 81 120 512 1.2 SAFRAN Electronics & Defense SAS 11 193 0 28 231 1.3 GT Cyber Technologies OÜ 43 142 31 31 247 1.4 Bittium Wireless Oy 16 266 13 33 329 1.5 Insta DefSec Oy 106 0 2 14 122 1.6 GMV Aerospace and Defence SAU 13 85 46 23 167 1.7 Krauss-Maffei Wegmann GmbH & Co KG 223 4 21 13 261 1.8 Diehl Defence GmbH & Co KG 8 46 2 17 74 1.9 Nexter Systems SA 26 168 7 27 227 1.10 Latvijas Mobilais Telefons SIA 27 0 14 0 41 1.11 (Un)Manned NV 15 132 51 33 232 1.12 Ecole Royale Militaire – Koninkljike Militaire School 12 41 0 15 67 1.13 dotOcean NV 17 50 0 29 96 Planned person months TOTAL 589 1368 268 383 2608 34 Grant Agreement number: EDIDP-MUGS-2019-002-iMUGS ANNEX 1 Part B 5. Project presentation The objective of iMUGS (integrated Modular Unmanned Ground System) is to develop and deploy (through demonstrations) a European technology based ground and aerial vehicle system, and the related infrastructure with the aim of advancing the capabilities of the participating European industries & armed forces. The iMUGS system is modular, cyber secure and capable for manned-unmanned teaming. iMUGS provides core autonomous functions and swarming capabilities. Figure 1: High-level System Diagram of the iMUGS Architecture iMUGS aims to develop a modular, standardized and open system architecture for unmanned ground and aerial platforms; the subsystems described above will be integrated in a modular way in this architecture. This architecture will enable the development of systems composed of different manned and unmanned ground and aerial platforms with high autonomy capabilities, swarming ability and sensors, payloads and intelligent functionalities and assets, all connected through a secured and resilient architecture to a communication network and to a Command and Control (C2), interoperable with external Computerized Command, Control, Communications Intelligence (C4I) systems and joint Intelligence, Surveillance, Reconnaissance (ISR) databases. For the purpose of demonstrating the project at the end, the prototype of the system and the demonstrations of it will be based on one specific Unmanned Ground Vehicle (UGV) (Themis from MILREM) and a specific list of payloads that are described in the implementation part. The project consists in the studies, design, prototyping and testing of the fundamental features of unmanned ground systems: autonomous functions, cyber security, communications, networking, swarming, command and control, interoperability, manned-unmanned teaming and of their integration based on a modular, standardized and open system architecture. These works will pave the way for building a robust, innovative and credible Unmanned Ground Systems (UGS) competency in EU and represent a significant leap over what exists today. The corresponding outcomes of this 30 months project shall provide a very strong basis for the realization of ambitious future UGS (iMUGS will not develop a new platform but will focus on creating added value for an existing one). This unprecedented cross-border cooperation in EU, supported by several Member States and backed by end-users in an advisory capacity, shall advance considerably the ability of the European Industry in this sector including SMEs to deliver systems which meet demanding armed forces priority requirements, and its competitiveness for creating new market opportunities. 35 Grant Agreement number: EDIDP-MUGS-2019-002-iMUGS ANNEX 1 THE GEOPOLITICAL AND SOCIETAL CONTEXTS CALLING FOR IMUGS The rapidly occurring changes in the geopolitical and societal contexts are characterised by:  Reduced acceptance of loss of human life leads to expectations that defence is arranged with the least possible risk to personnel;  Centre of gravity in future defence will be population-related with operations concentrated in and around cities, natural resources, lines of communication, and energy/power;  Operational environment, globalization and international crises require expedited readiness to conduct operations outside of the national boundaries. These changes indicate that integrated, semi-autonomous robotics systems will play a critical role in the future complex operational environments. NEW TECHNOLOGIES ENABLING OPERATIONAL SUPERIORITY ARE AVAILABLE OR DEVELOPABLE To support manned operations, autonomous systems will enable novel capabilities required to counter new threats, based on technology development. Current capabilities of the unmanned systems are limited to the human-in-the-loop, remote-control use of single aerial or ground assets separately by dedicated operators. In order to face the changed role and challenges, several technologies and systems enable an ambitious development:  Accurate, up-to-date common operational picture and adequate information management;  Secured communications to improve the resilience of the systems;  Data fusion to manage the amount of raw data and invert it to actionable intelligence;  Artificial Intelligence (AI) to provide assistance for human controlled decision making;  Electronic warfare and cyber activities to resist to new threats;  Resilient solution to cater denied access to position, navigation and timing;  Rapidly deployable unmanned platforms requiring limited assistance to perform;  Autonomous functions for assets’ mobility and planning;  A modular and secure way to integrate the different scalable capabilities;  Operational modes for manned and un-manned assets cooperation;  Safety features for mobility and payload operation. THE SCOPE OF IMUGS SPANS FROM AUTONOMY TO A PLATFORM-AGNOSTIC MODULAR ARCHITECTURE The project will develop a modular, standardized and open system architecture for unmanned ground and aerial platforms, all connected through a secured and resilient communication network and to a secured command and control capability to safely operate multiple aerial and ground assets by a single operator. This scalable architecture will allow to address multiple types of operational missions with multiple types of payloads, sensors and ground/aerial platforms. Resilient system ensures data integrity, secure communications, cyber and electronic warfare resistance. System has semi-autonomous and autonomous features for operator’s assistance, route and mission planning, requiring limited man- in-the-loop involvement. AI capabilities include unmanned assets working as a group with a single objective. Development includes operational modes for unmanned assets and hybrid operations with manned assets. Added capability for autonomous mobility of the platform and mission planning with human- in-the-loop functionalities include follow-me vehicle/pedestrian, way point navigation, autonomous surveillance and patrolling through intelligent agents supporting the control with task orientation. Autonomous capabilities are furthermore secured with obstacle and human avoidance. The autonomy framework developed will be platform-agnostic, enabling integration to unmanned ground platforms and adaptation to current manned vehicles. Task orientation includes swarming capabilities where heterogenous assets have capability to work as a group with a common objective. System will furthermore be capable of expedited deployment and interoperable with existing command and control and manned operations. 36 Grant Agreement number: EDIDP-MUGS-2019-002-iMUGS ANNEX 1 iMUGS can be remotely controlled in Line Of Sight (LOS) or using Beyond Visual Line Of Sight (BVLOS) communication means on the operating area. Its high processing power and the capability to interact at all layers of the communication spectrum at the tactical edge results in enhancement of friendly forces' capabilities to react faster than the adversary can anticipate, using the advantage from highly capable information systems, cyber domain and artificial intelligence. iMUGS can threaten adversary’s capabilities, cohesion, understanding and offensive behaviour due to cumulative and timed effects because it operates faster in tasks that require human involvement, interaction and decisions. iMUGS (collective) capability can be easily augmented by rapidly configurable specific payloads: ISR capabilities, teaming with Unmanned Aerial Vehicles (UAV), acoustic aggressive fire detection, ballistic protection, medical evacuation (MEDEVAC) equipment, and Electronic Warfare (EW) assets (Signals Intelligence, close-in jamming etc). The project is structured along the features expected as its key outcomes; it will be implemented by a consortium bringing together the best of class in a balanced manner Modular approach allows organizing the development to functional subprojects corresponding to the key elements (sub systems); each subproject includes activities for project management, studies, design, prototyping and testing (see Work breakdown Structure). 1. Systems Integration, led by MILREM, with the support of EMA (EE); 2. Autonomous functions led by SAFRAN (Fr), with the contributions of NEXTER (FR), DIEHL (DE) and MILREM; 3. Cyber security led by GTCT (EE); 4. Communication equipment and network led by Bittium (FI), with the support of LMT (LV); 5. Swarming led by ERM-KMS (Belgium), with the contributions of Insta (FI) and dotOcean (BE).; 6. Command and Control and Interoperability led by (Un)Manned (BE), with GMV (Spain) achieving interoperability; 7. Manned-Unmanned Teaming led by KMW, with the support of NEXTER Participants and their complementarity for the project are further described in the Section 6.1.4.3. Participating project members for the PESCO for Integrated Unmanned Ground System project (UGS) are Germany, France, Spain, Belgium, Finland, Latvia and Estonia. A Letter of Intent of these seven MS is provided as an Appendix of the application (Ref to file “iMUGS Section 3.4 Letter of Intent”). In the event of an action awarded with EDIDP grant, Member States will appoint a project manager. Coordinated by MILREM, the iMUGS Consortium has the capabilities to develop the scalable system for integrating the various unmanned assets and hence provide the solutions to various challenges. Across the Consortium, the added-value is brought both by high-tech SMEs, MidCaps and big companies: indeed, 40% of the development work shares are performed by small and medium size enterprises (SMEs) and 20% by medium capitalized companies (Midcaps), and the coordination between partners and achieving of the results and resources are backed with 40% participation of large capitalized companies representing core knowhow in their fields; SAFRAN, NEXTER, DIEHL, and KMW. Workshares have been balanced with the participating Figure 2: Key partners of the iMUGS project Member States in view. 37 Grant Agreement number: EDIDP-MUGS-2019-002-iMUGS ANNEX 1 THE IMPACTS OF THE PROJECT WILL RISE A NEW DAWN FOR AERO-TERRESTRIAL OPERATIONS iMUGS will contribute significantly to the development of credible operational solutions to armed forces in the medium term, based on leading edge competencies established in the EU, while engaging in a constructive dialog with its end-users. The project will consequently provide a very significant breakthrough potential both in technological and operational terms. It will contribute to placing the European Union at the forefront of the Defence sector and enhance the competitiveness of the European Defence Technological and Industrial Base (EDTIB) due to innovation and cost efficiency. By agreeing on common requirements and harmonized capabilities, the project will facilitate capacity building among partners. iMUGS will also contribute to the industrial autonomy of Europe in a moving geopolitical context. European armed forces will have access to world-class European equipment and systems, securing operational supremacy. A major innovation area will be on mobility autonomy, coupled with cybersecurity and EW resistant secure multi-technology communication solution, preparing for ability of such systems to operate within adverse and unprepared areas, in fully autonomous mode of operation, including in GNSS denied areas. The iMUGS Autonomy Framework is designed in a generic way, based on existing standards and fully adaptable with various type of UGVs for a large range of applications. Also, Autonomy functions can be turned in driver assistance for manned platforms by providing either proximal area awareness or to help the driver in a fine manoeuvre over a short-term horizon. They can also be used to develop an infrastructure protection and inspection system by extending the robotic coordination to infrastructure sensors. Planning and scheduling, but also mobility planning can be extended to include both human and infrastructure sensor activities. iMUGS will allow to rapidly gather, process and disseminate large amounts of information to decision-makers (ISR). Artificial Intelligence evaluates reliability and credibility of the gathered data and provide evidence-based conclusions, situational understanding and recommendations for further collection or exploitation. iMUGS’ modular approach will allow the development and rapid deployment of additional functionalities and payloads over time. The Control Station (CS) allows a single individual to control multiple semi-autonomous systems using the same software suite and controller, therefore, maximizing the use of assets, sensors, payloads, data/information sharing and decision-making. iMUGS will contribute to increasing efficiency across the life cycle thanks to modular design, interchangeability and ease of maintenance. More generally, the project paves the way towards manned-unmanned collaboration in the context of next generation ground capabilities and will open new perspectives of exploitation of UGS and related technologies in operation. IMUGS IS WELL ALIGNED WITH THE EU PRIORITIES A. CAPABILITY DEVELOPMENT PLAN European strategy and co-operation in developing autonomous land systems is mandatory for EU troops to effectively engage, protect, deploy, sustain and command in the future battlefield. The 2018 Capability Development Plan (CDP) by the European Defence Agency (EDA) confirms this by prioritizing developing unmanned ground combat capabilities and systems with evolving levels of autonomy. iMUGS will focus on key functionalities which are critical for ensuring European Strategic Autonomy in order to meet defence capabilities agreed by the Member States in the context of the CDP. The project is consistent with several major priorities defined in the 2018 CDP, namely:  Development of unmanned ground capabilities;  Addressing cyber defence challenges in the air, space, maritime and land domain;  Enhancing Intelligence, Surveillance and Reconnaissance (ISR) capabilities;  Developing systems with evolving levels of autonomy and developing Artificial Intelligence. b. Permanent Structured Cooperation The Integrated Unmanned Ground System (UGS) Project was officially adopted on the updated list of projects for the Permanent Structured Cooperation (PESCO) in November 2018. The project respects the several binding commitments undertaken by participating Member States. The project will help the participating Member States to: 38 Grant Agreement number: EDIDP-MUGS-2019-002-iMUGS ANNEX 1  Increase joint and “collaborative” strategic defence capability projects (commitment 3);  Ensure the availability of the capabilities for achieving the level of ambition in Europe (6);  Procure with identified EU added value (8);  Draw up harmonised requirements agreed by participating Member States (9);  Overcome capability shortcomings identified under the CDP and Coordinated Annual Review on Defence (CARD), increase EU strategic autonomy and strengthen the EDTIB (15);  Take part in at least one project under the PESCO (17);  Confirm that the acquisition strategy will have a positive impact on the EDTIB (20). Results expected for the project are coherent with the European Union capability development plan objectives. Project has been initiated in the PESCO venue by the participating Member States. Estonia, Finland, Latvia, France, Belgium, Germany and Spain have jointly agreed the common requirements for the development and agreed to co-finance and procure the results. Majority of the work is performed by state-of-the-art companies from these countries. Confirmation for signed Letter of Intent by the Ministries of Defence is added to the application as proof of support by the participating Member States (Ref to file “iMUGS Section 3.4 Letter of Intent”). 6. Focus on award criteria 6.1. CONTRIBUTION TO EXCELLENCE 6.1.1. OBJECTIVES AND RELATION TO THE CALL FOR PROPOSALS Relation to the call for proposals iMUGS fully complies with the call EDIDP-MUGS-2019, as shown in the table below. Table 1: relation to the call for proposals Scope [call text] Include a system capable of manned-unmanned and unmanned-unmanned teaming with other robotic unmanned aerial and ground platforms as well as traditional manned vehicles to provide combat support and combat service support to ground forces; [iMUGS’ answer] iMUGS will develop scenarios and a system capable of manned-unmanned and unmanned-unmanned teaming with other robotic unmanned aerial and ground platforms as well as traditional manned vehicles to provide combat support and combat service support to ground forces, as described in iMUGS operational and technical objectives [Ref to OO1]. [call text] Increase situational awareness and force protection of ground units, their combat effectiveness, endurance, mobility and autonomy, and enable faster deployment; [iMUGS’ answer] iMUGS will increase situational awareness of ground units by providing access to observational data (e.g. automated observation) [ref to OO2]. A large set of embedded sensors for distanced observation will provide a better overview of the field of operation, improving overall effectiveness [Ref to OO5, OO6]. In addition, the integrated communication system will allow efficient information exchange with other systems deployed by the troops [Ref to OO4]. iMUGS will improve the endurance of ground units by exposing robots instead of soldiers (through teleoperation and autonomous capabilities) [Ref to OO2]. iMUGS will increase troops’ mobility by enabling fast deployment [Ref to OO1]. [call text] Have the ability to be deployed in support of dismounted troops in all types of geographic and operational environments (including denied environments) with evolving levels of autonomy and robustness for transport and supply delivery, force protection, interdiction, ISTAR (Intelligence, Surveillance, Target Acquisition and Reconnaissance), communication relay, military engineering support, medical evacuation or CBRN protection; [iMUGS’ answer] iMUGS will increase effectiveness of dismounted soldiers through the use of 39 Grant Agreement number: EDIDP-MUGS-2019-002-iMUGS ANNEX 1 unmanned systems and autonomous mission planning tools [Ref to OO2, OO5]. The iMUGS solution will be demonstrated in deployment in a wide range of operational scenarios and concepts [Ref to OO1]. iMUGS solution will support dismounted troops with its flexible architecture that allows a wide range of available and future payloads in its support functions, and it will continue its support role in all types of geographic and operational environments with its robust, resilient architecture and simplify integration of future payload capabilities depending on the evolving battlespace and support needs of the troops [Ref to OO1; OO2; OO3; OO6]. Robust vehicle architecture and communications system will allow continued operations in denied environments [Ref to OO4], manned-unmanned teaming and operations [Ref to TO7]. The autonomy design of iMUGS is evolutive and provides soldier and driver assistance in all types of operation conditions [Ref to OO2]. [call text] Lower workload for UGS operator(s) through maximum use of artificial intelligence and assisted functions in order to assure better awareness of the tactical situation for UGS operator(s); [iMUGS’ answer] The usage of autonomous [Ref to OO2] and swarming [Ref to OO5] functionalities will reduce the workload and significantly reduce reaction time, through automatic planning algorithms, for the operator of UGS [Ref to OO5] Also the possibilities for following the tactical situation will be improved with the C2 of this project [Ref to OO6]. [call text] Include modular design and interoperability of the UGS, in order to ensure transferability of the relevant technology to other platforms (including existing manned vehicles) and simplify payload integration during the follow-up development projects. [iMUGS’ answer] iMUGS will include development of a modular framework for autonomous systems, as well as subsystems that can be deployed independently, enabling transfer of technologies to other platforms than the one used within the project [Ref to OO2; TO1; TO2] [call text] Proposals can also include the integration of an increased number of unmanned systems (swarming) to be remotely operated by human beings. [iMUGS’ answer] iMUGS will develop and integrate swarming capabilities, i.e. heterogeneous agents having capabilities to work as a group with multiple mission objectives. [Ref to OO5] Targeted activities [call text] Cover at least the design of a multipurpose unmanned ground system, not excluding upstream and downstream activities, such as feasibility study or prototyping and testing in an operational environment. [iMUGS’ answer] iMUGS project is concentrating effort on design (56%) but also covering upstream and downstream activities (feasibility study (13%), prototyping (11%) and testing (15%)) [Ref to Section 7.1.4] for a multipurpose unmanned ground system as well as aerial system [Ref to Section 7.1.4.1]. Demonstrations are included in the testing programme (6 based in different European countries and calendar date to address various environments) in a realistic setting [Ref to Section 7.1.4.1]. Main high-level requirements [call text] Designed for operations encompassing the entire spectrum of conflicts from permissive to denied environments, by day, night and in adverse weather conditions; [iMUGS’ answer] iMUGS will integrate a wide range of mission capabilities, both autonomous and remotely operated, in permissive, semi-permissive and denied environments [Ref to OO2]. Autonomous functions developed in iMUGS will allow operation in various conditions: urban and off road, day and night, Global Navigation Satellite System (GNSS) denied, communication unavailable, adverse weather etc. The communications infrastructure will allow resilient connectivity in most operational scenarios. [Ref to OO1; OO2; OO4] [call text] Provide, when necessary, in addition to functioning as part of mechanized troops, advanced mobility and a reduced footprint allowing systems to support dismounted troops in different environments, where traditional manned vehicles are not able to operate; [iMUGS’ answer] Military operational scenarios [Ref to OO1] will describe the possibilities for the usage of iMUGS in different conditions and environments. A subset of these scenarios will be tested during the demonstrations of this project. Scenarios which cannot be considered during this project will be listed in the Manned-unmanned teaming (MUM-T) study [Ref to OO1] for a follow-on 40 Grant Agreement number: EDIDP-MUGS-2019-002-iMUGS ANNEX 1 project. [call text] Support all types of missions of infantry units without compromising their stealth and endurance; [iMUGS’ answer] Through novel tactical Command and Control, Intelligence, Surveillance and Reconnaissance (C2ISR) software, iMUGS will allow approach march, provide support for dismounted troops and include controlled/low emissions’ profile [Ref to OO6]. Moreover, iMUGS will reduce soldier stealth exposure and increase soldier endurance by providing autonomous functions that will perform missions without direct intervention of soldiers in the field [Ref to OO2]. Due to the existing design, the platform has low visible, electromagnetic and acoustic signature (able to operate in silent mode, fully electric) [Ref to TO1]. [call text] According to the UGS weight class, have design elements for protection which address the appropriate threats; [iMUGS’ answer] iMUGS will develop resilience and graceful degradation against cyber, electromagnetic and physical exploitation [Ref to OO3]. The physical reliability of iMUGS is achieved by ruggedization and ballistic protection as a payload [Ref to TO1]. [call text] Be equipped with cyber secure and Electronic Warfare (EW) resilient C2; [iMUGS’ answer] iMUGS has cyber secure & EW resilient C2 both on the platform and on C4I level. iMUGS provides autonomous detection of compromise or a cyber attack with appropriate mitigation recommendations [Ref to TO3]. As part of the C2-entity, the communication solution provides integrated EW functionality such as detection of jamming, end-to-end security, alternative communication channels [Ref to TO4]. [call text] Have a modular, open, scalable and cyber-secure architecture for different manned and unmanned capabilities; [iMUGS’ answer] iMUGS solution has an open and scalable architecture based on industry and military standards and allows capability extension with flexible payload interface and open software architecture. Both UGV and C2 Control System (CS) support a wide range of manned and unmanned capabilities and allow future capability extension with modular software and flexible communications subsystem to serve evolving future needs. [Ref to OO2; OO3; OO6; TO2; TO6] [call text] Provide a modular architecture for future upgrades and implementation of different autonomous functions; [iMUGS’ answer] iMUGS will develop a modular, safe and scalable architecture for autonomy [to OO2] addressing several designs and implementation of autonomous functionalities as described in the previous point. The architecture is designed in a way, which makes it easy to implement updates and upgrades throughout the life cycle of the system [Ref to TO2]. [call text] Be capable of manoeuvring autonomously to pre-planned battle positions and have the ability to carry at least a squad sized unit equipment; [iMUGS’ answer] The autonomous functions will be able to follow a mission plan including pre- planned battle positions to perform various autonomous missions as way point navigation, surveillance, patrolling, follow me [Ref to OO2, OO5]. iMUGS autonomous UGV will enable iMUGS to carry at least a squad sized unit equipment. [call text] Have autonomous functions for unmanned ground systems' LOS (Line Of Sight) and BLOS (Beyond Line Of Sight) missions; [iMUGS’ answer] iMUGS will include an autonomous and safe ground system with “human in the loop” from teleoperation to driving assistance in unknown environment and from driving assistance to mixed interactions and to full autonomy in pre-mapped environment [Ref to OO2]. Its communication solution provides the required connectivity supporting all operational scenarios comprising both local and remote applications including LOS and BVLOS use cases, stand-alone and fully networked system architecture and swarming [Ref to OO4]. [call text] Be based on a ground vehicle on which a variety of payloads can be mounted to support various mission functionalities: transport, fire-support, ISR, EW and cyber, etc. The sensors and communication systems of the ground vehicle shall have the capability to be integrated into broader networks; [iMUGS’ answer] iMUGS is based on a modular framework that will enable integration of different 41 Grant Agreement number: EDIDP-MUGS-2019-002-iMUGS ANNEX 1 types of payloads. The use of an all-over-IP approach within communication subsystem of iMUGS will enable a smooth integration in various types of networks and into broader networks [OO3, TO4]. [call text] Ensure that autonomy related capabilities, that can cause collateral damage, are restricted to human-in-the-loop or human-on-the-loop common control in order to minimize collateral damage risks ensure operations under rules of engagements. [iMUGS’ answer] Safety is a key subject of iMUGS design and will be addressed as part of the modular framework for both human-in-the-loop (such as follow me) and human on the loop (supervising a remote task) through dedicated safety & security activities [Ref to OO2, TO2]. Expected impact [call text] Enhanced interoperability between armed forces of Member States [iMUGS’ answer] iMUGS will use existing standards [Ref to TO1] and define new open interfaces where required, use IP based communication technology [Ref to OO4] and a modular and open system architecture to enhance interoperability on payload as well as vehicle-to-vehicle level [Ref to TO4]. The interoperability will also be enforced by a common understanding of military operational scenario [Ref to OO1]. [call text] Increased situational awareness and force protection of ground units, their combat effectiveness, endurance, mobility and autonomy to enable faster deployment, and to enhance the interoperability and affordability of ground forces; [iMUGS’ answer] iMUGS will increase situation awareness of ground units by providing, within our system, autonomous missions such as automated observation as well as a large set of embedded sensors for distanced observation [Ref to OO6]. The integrated communication solution allows efficient automated information exchange with other systems deployed by the troops [Ref to TO4]. iMUGS will improve the endurance of ground units by exposing robots instead of soldiers (through teleoperation and autonomous capabilities [Ref to OO2]). iMUGS will increase effectiveness of ground soldiers through augmenting sensors to shooter abilities [Ref to OO6]. iMUGS CS will support relevant C2 and ISR interoperability standards [Ref to TO6]. The design will allow for a wider industrial base and the modularity will allow the customer to opt for more affordable options among the selection of payloads [Ref to TO1]. [call text] Faster decision-making and significantly increased resilience and protection of soldiers in any environment; [iMUGS’ answer] By providing autonomous functionalities to the soldier, iMUGS will allow faster decision-making (through surveillance missions and autonomy sensors, soldiers will get better situation awareness to take faster decision, particularly in difficult environment as night or certain weather conditions) and also increase protection of soldiers (by sending iMUGS unmanned system for reconnaissance and securisation before sending soldiers in a zone) [Ref to OO2; OO6] Decision making functionalities are integrated in the autonomy framework, such as planning, scheduling, resource allocation, diagnosis, perception. The system will propose options to the soldiers, facilitating human decision making. [call text] Contribution to rebuild a credible deterrent in terms of land combat capability, by introducing in the shortest time the right number of advanced logistic and combat vehicles in general as well as CSPS and introducing the unique capabilities of UGS to operate in high risk scenarios [iMUGS’ answer] Fast deployability and transportation to hostile environments will enable the creation of deterrent UGS at the tactical level, reinforcing reactivity with better force protection [Ref to OO6]. [call text] Reduction, through commonality and mass production, of the acquisition and life-cycle costs for each Member State [iMUGS’ answer] The modular architecture of iMUGS allows multiple potential suppliers to propose production to increase acquisition efficiency and potential localisation objectives. The use of industry standards and commonality of the C2 station over a wide range of unmanned systems (ground or air) will simplify life cycle costs by increasing production volume of components, combining central control, and simplifying future unmanned system integration through commonality. The presence of large-scale ground system manufacturers in the iMUGS consortium will allow guiding of mass production and commonality objectives and reuse of existing capital investments and cost control 42 Grant Agreement number: EDIDP-MUGS-2019-002-iMUGS ANNEX 1 constraints throughout the project lifecycle. [Ref to OO6; TO1; TO2; TO7] The main European defence industries in the ground vehicle domain are working together in this project to propose a common solution, enabling mass production and the reduction of life cycle costs. [Ref to TO1]. [call text] Contribution to the strategic autonomy of the European Union. [iMUGS’ answer] iMUGS will help to establish and improve the industrial capabilities within the European Union for all aspects of unmanned ground systems. This starts with the design of unmanned ground systems, ideas of the ways how to use these systems, building a prototype and testing it in the end [Ref to OO1-OO6]. Objectives of iMUGS From the previous requirements that are covered by iMUGS, the project has identified the following operational and technical objectives. iMUGS will reach this overall objective through several SMART (Specific, Measurable, Achievable, Realistic, Timebound) operational and technical objectives. The operational objectives are related to the way the end-user operates with the System. The technical objectives reflect the innovative aspects of the project. IMUGS Operational Objectives (OO) OO1: Develop, analyze and define military operational scenarios and concepts for deploying iMUGS and engaging with iMUGS with a focus on man-unmanned teaming. The analysis covers teaming with other unmanned systems, soldiers and manned systems and with combinations of these. This will be done, based on workshops with the participating member states from the EU, with the help of virtual and constructive simulation and with tests and demonstrations. The tests and demonstrations will use systems and developments from this project. The project will provide an analysis on the ethical use of autonomous UGVs and on the compliance with applicable legislation.  KPI.O1.1: Military operational scenarios and concepts. Target: Definitions written and reviewed. Measure: Demonstrations and study/report  KPI.O1.2: Deployment of unmanned systems. Target: Prototypes built. Measure: Demonstrations and reports. OO2: Develop and integrate an autonomous and safe ground system with “human in the loop” (for both mobility and mission autonomy) from teleoperation to driving assistance in unknown environment and from driving assistance to mixed interactions and to full autonomy in pre-mapped environment. The autonomous capabilities as well as the ground vehicle capabilities will be developed considering the following environments: urban and off-road, day and night, GNSS denied, normal and degraded communication, and various environmental conditions (winter and summer). It will perform safe operations, including fail-safe behaviours, helping fratricide prevention through increased ISR capabilities.  KPI.O2.1: Number of successful autonomous missions in environments relevant to the project Member States (pMS) climatic conditions. Target: 80%. Measure: Simulation, Demonstrations and reports.  KPI.O2.2: Detection of humans. Target: >90% Measure: Simulation and reports. OO3: Develop a modular cyber defence system delivering resilience against cyber, electromagnetic and physical exploitation attacks of concern.  KPI.O3.1: Response to cyber-attacks. Target: Detection of 3 different types of cyber-attacks; isolation of affected components; mission success in presence of cyber-attacks. Measure: Demonstration showing that a compromised component is detected and addressed by the Cyber Defence System, resulting in mission success. OO4: Develop a communication solution that provides the required connectivity supporting all operational scenarios comprising both local and remote applications including LOS and BLOS use cases, stand-alone and fully networked system architecture and swarming. The solution is interoperable 43 Grant Agreement number: EDIDP-MUGS-2019-002-iMUGS ANNEX 1 with other communication systems deployed by the troops allowing efficient information transfer and supports both manned and unmanned operations.  KPI.O4.1: Connectivity. Target: The communication solution provides the required connectivity supporting all operational scenarios comprising both local and remote applications including LOS and BLOS use cases, stand-alone and fully networked system architecture and swarming. Measure: Demonstrations and field tests.  KPI.O4.2: Interoperability. Target: Communication system provides integrated services for manned and unmanned operation. The same system can be used for all ground communications required by the combat unit. Measure: Demonstration and Field tests OO5: Develop and integrate swarming capabilities (heterogeneous agents having capabilities to work as a group with multiple mission objectives) aiming to operate multiple vehicles by a single operator.  KPI.O5.1: Number of agents in the loop (real-time) in a fully structured environment. Target: 3 platforms and 10 smaller vehicles. Measure: Demonstration.  KPI.O5.2: Generate solutions for multi-agent scenarios, that are optimized against a common set of objectives. Target: Near to real-time proposal of possible solutions for the agents to C2. Measure: Demonstration of control of multiple platforms (10 to 15) through a swarming interface; report. OO6: Provide situation awareness information to the soldier through Command and Control (C2), thanks to different sensors and payloads (as ISR) and advanced intelligent perception algorithms.  KPI.O6.1: Integration of ISR sensor payload software on the C2 platform. Target: Control of at least one ISR payload from iMUGS C2 platform. Measure: Demonstration and reports.  KPI.O6.2: Presentation of threats detected by iMUGS sensors on the C2. Target: Dissemination of threats: at least 3 levels of threat identification flags. Measure: Demonstration and reports. iMUGS Technical Objectives (TO) TO1 – SP Integration: Develop an open, modular, interoperable architecture for UGV systems supporting existing standards.  KPI.T1.1: Open, modular, interoperable, standards-based system architecture inherently encompassing operational safety and cyber security properties and optimized towards foreseen mass production of the Systems (upgradeability, sensor agnostic architecture) resulting in reduction of life cycle costs and increased physical reliability. Target: Standards based interfaces between subsystems and standards-based architecture specification (STANAGs, NAFv4, NATO General Vehicle Architecture) Measure: Design specification and interfaces specifications are based on existing relevant standards, production scalability, safety and cyber security targets.  KPI.T1.2: Exposure of system capabilities to users for enabling operational assessment and concept definitions. Target: Operator centric functionality demonstrated to end-users in relevant environment. Measure: Demonstration activities performed; feedback received. Final report. TO2 – SP Autonomy: Develop a modular and cyber secure computer (backbone) for autonomous safe architecture scoping existing standards.  KPI.T2.1: Safe and secured autonomy solution integrated (UGV integration and sensors integration). Target: Common autonomy services are available. End-to-end security provided. Measure: According to test plans: Integration tests. Validation tests.  KPI.T2.2: Autonomy algorithms from 4 partners integrated in the autonomy backbone. Target: Containers in place within the backbone. Measure: According to test plans: Integration tests. Validation tests. TO3 – SP Cyber: Design a Cyber Defence System capable of detecting and responding to cyber-attacks. 44 Grant Agreement number: EDIDP-MUGS-2019-002-iMUGS ANNEX 1  KPI.T3.1: Design of a Cyber Defence System capable of autonomously detecting a compromise or an attack against onboard components, such as cyber-attacks coming from other entities in the same communication network, components compromised in the supply chain, and attempts to load malicious code onto the system through physical exploitation. Target: Design fulfils the requirements. Measure: Cyber Defence Review (CDR) report.  KPI.T3.2: Prototyping of a cyber-attack response controller capable of issuing an appropriate mitigating recommendation. Target: Successful integration into the iMUGS platform. Measure: Demonstration showing that an appropriate recommendation is generated. TO4 – SP Communications: Develop a secure and scalable multiple channel network communications capable of deploying both commercial and tactical mesh network technologies, with support to swarming.  KPI.T4.1: Secure network services solution integrated. Target: Secure network services for mobile Virtual Private Newtork (VPN) and Mobile Device Management (MDM) are available. End-to-end security provided. Communications can be routed over multiple channels (e.g. commercial / tactical networks) seamlessly. Measure: According to test plans: Integration tests. Validation tests. Field tests and demonstrations.  KPI.T4.2: Integration of the selected communications means including commercial, vehicle- to-vehicle and tactical Internet Protocol (IP) mesh networks including relayed and multi-hop scenarios Target: Seamless and transparent communications can be provided over the selected communications means. Measure: According to test plans: Integration tests. Validation tests. Field tests and demonstrations.  KPI.T4.3: Integration of selected EW capabilities. Target: Detection of jamming and localization of the jammer are available. Resistance to defined jamming (applies to only tactical mesh / Vehicle-to-Vehicle (V2V) communications). Measure: According to test plans: Integration tests. Validation tests. Field tests and demonstrations. TO5 – SP Swarming: Develop architectures, methods and algorithms to optimize a multi-agent system against multiple objectives.  KPI.T5.1: Capability to solve multi-objective problems and perform multi-objective missions Target: Performing multi-objective missions (up to 5) Measure: Simulation  KPI.T5.2: Setting up simulations for development, testing and the demonstration of the targeted capabilities, as well as field testing global swarming. Target: According to test plans: validation tests and demonstrations Measure: demonstration TO6 – SP Command, Control & Interoperability: Ensure interoperability and standardisation of interfaces with existing Command and Control (C2) as well as C4I and Battlefield Management System (BMS) and databases.  KPI.T6.1: Communication system interface compatibility. Target: All relevant subsystems can interface to the communication system and transfer IP-data transparently over the communication system. Measure: Integration tests. Tests according to the validation plan. Field tests and demonstrations.  KPI.T6.2: Development of a Control and Data Model specific to UAV and UGV systems. Target: Development of a reconfigurable land and air vehicle control and user C2, interface definition and prototyping. Measure: Demonstration and reports.  KPI.T6.3: Interoperability with existing C4ISR systems. Target: Implementation of two (2) interoperability protocols in iMUGS C2. Measure: Demonstration and reports. TO7 – SP MUM-T: Simulation & supporting infrastructure for manned-unmanned teaming  KPI.T7.1: Integration of unmanned systems into existing virtual and constructive simulation. Target: Generic unmanned systems can be used for the evaluation of military operation scenarios. Measure: Tool for workshops (military operational scenarios)  KPI.T7.2: Integration of transportation means and C2 equipment for UGV to a manned vehicle (Boxer). Target: Unmanned systems will be deployed and controlled with the help of manned systems (Boxer). Measure: Demonstration. 45 Grant Agreement number: EDIDP-MUGS-2019-002-iMUGS ANNEX 1 6.1.2. CONTRIBUTION TO EXCELLENCE 6.1.2.1. Key iMUGS features iMUGS will develop 6 features, corresponding each to one subproject (SP): C2, Communications, Autonomy, Swarming, Cybersecurity, MUM-T. System architecture will ensure the technical and operational coherency of the outcomes of the project. For each of these features, the iMUGS consortium will start from a documented state-of-the-art, and go significantly beyond during the implementation of the project. Open, modular, technology agnostic architecture (SP1 System’s Integration) State-of-the-art: Until now, UGVs have been largely stand alone, bespoke, designed and built for single mission, introducing a various set of solutions with proprietary interfaces and dreadful “logistics, training and operational challenges”. There is a permanent increasing need for networked information technology in and between UGVs, which enables better Operational Capabilities and faster, more efficient and precise effects during missions. This requires a common/standardised approach so that devices constituting an unmanned ground system can exchange information with each other and can be integrated more easily, ie an approach aligned to manned platforms as identified in the EDA LAVOSAR I&II studies and thereafter the development of NATO STANAG 4754 – requiring a modular, interoperable and open architecture approach and enabling lowering development and life-cycle costs. (Unmanned Ground systems roadmap, Unmanned Systems Integrated roadmap) Beyond the state-of-the-art: The capability development roadmaps envision a fully network centric, multi mission reconfigurable approach with the stepwise introduction of a wide range of customer defined payloads and system components throughout the life cycle of a vehicle. The architecture proposed for iMUGS will enable, through following the implementation of respective standards (STANAG, NATO Generic Vehicle Architecture (NGVA), etc), open, modular architecture (interface descriptions and modularity specification) the widest selection of customer selected system capabilities and payloads from a large industrial base and will accommodate new sensors and components as these become available from several suppliers. The architecture will also inherently include safety features and include ad hoc a dedicated aspect on cyber security and defence (especially EW considerations). The open modular architecture is developed end-to-end, encasing safety critical and non-safety critical components from tactical C2, real-time control of vehicle, fleet and teaming control, multiple communications networks to autonomous functions, platform and cyber defence system. The openness and modularity are applied in each component of the architecture through standards-based interface definitions and interoperability requirements. Representation of the architecture and verification of the implementation is provided by the iMUGS domain models (and the whole system model) – through Model Based Systems Engineering methods using NATO Architecture framework v4 and Concept Development and Experimentation (CD&E) principles. Extensive end-user engagement is planned during the requirements engineering through consultation process for input to Mission Definition Review (MDR), System Requirement Review (SRR) and CDR. The project activities will be conducted in coherence with NATO IST Panel Activity „Interoperability for Semi-Autonomous Unmanned Ground Vehicles“, activities funded Under „PADR-US-03-2019: Interoperability standards for military unmanned Systems“ and other relevant calls for proposals and other relevant coordinating activities. 46 Grant Agreement number: EDIDP-MUGS-2019-002-iMUGS ANNEX 1 Autonomous functions (SP2) State-of-the-art: Various types of autonomous systems have been developed in aeronautics and space domains, involving various forms of automated reasoning. Autonomous architectures were defined by automatic planning, scheduling and diagnosis, while execution was managed by a smart executive. The 123 Remote Agent Experiment (RAX) architecture is one of the first examples with those components. In the land domain, various Defense Advanced Research Projects Agency (DARPA) Challenges (2004 4 to 2007) addressed autonomous mobility, with teams opposed in environments from desert to urban context. The Boss architecture, demonstrated by Carnegie Mellon University (CMU), combines perception, planning and behavioural executive functions in a modular and scalable software environment. It won the last challenge in the more difficult urban context. Software/system objectives were to allow incremental development, to minimize impact of changes and to support alternate 5 6 algorithms . Modern implementations of such architectures extend the different functionalities: complex environment, uncertainty and more complex missions. Unmanned capabilities for military missions have been successfully developed in Europe during the recent years. These capabilities are 789 successfully demonstrated from 2006 at European Land Robotic Trials (ELROB) . In Europe, robotized platforms projects rely on proprietary hardware and software architectures and are poorly interconnected with other UGVs. They operate in a closed environment which make them protected from cyber-attacks. Beyond the state-of-the art: iMUGS aims at improving autonomous functions in Europe by developing a fully tested Autonomy Framework (AF). From the hardware point of view, the Framework is composed of Autonomy computers (including Safety Integrity Level (SIL) and non SIL components) as well as a dedicated set of sensors necessary to perform autonomy missions. The iMUGS concept is based on a fully modular and open backbone located on the UGV platform and connected to its actuators and its proprioceptive sensors. The backbone includes the Hardware components as well as a Software Architecture allowing easy development and deployment of autonomy functions. The backbone is also interfaced to C2 through secured communication means to provide the operator with the robot and mission data and is connected to cybersecurity components to be able to react to detected Cyber Attacks or another artefact. The autonomy functions (based on different and redundant algorithms for resilience) will be hosted in the autonomy backbone through containers. This provides an easy modularity, avoids fault propagation from one container to the other (segregate) and offers a better system/resources monitoring. The backbone will be designed to be platform agnostic even if it will be demonstrated on the THEMIS platform. Within the AK development, 6 main autonomy missions will be addressed: Line of Sight 1 Remote Agent Experiment, http://rax.arc.nasa.gov, February 8-9, 2000 Pasadena, CA 2 Remote Agent Experiment, http://rax.arc.nasa.gov, February 8-9, 2000 Pasadena, CA 3 Brat and al. A Robust Compositional Architecture for Autonomous Systems IEEEAC paper #1499, Version 9, Updated Dec 16, (2005) 4 Sebastian Thrun & Al. Stanley: The Robot that Won the DARPA Grand Challenge, Journal of Field Robotics 23(9), 661– 692 (2006) 5 Philip Polack, Florent Altché, Brigitte d'Andréa-Novel, Arnaud de la Fortelle. A Real-time Safe Planning and Control Architecture for Autonomous Driving Adapting to Slippery Roads, jan 2019 6 Sagar Behere, Martin Törngren (2016), Information and software Technology, Information and Software Technology 73 (2013) 7 ELROB – The European Land Robot Trial, https://www.elrob.org/ 8 Philip Polack, Florent Altché, Brigitte d'Andréa-Novel, Arnaud de la Fortelle. A Real-time Safe Planning and Control Architecture for Autonomous Driving Adapting to Slippery Roads, jan 2019 9 C Guettier, B Bradai, F Hochart, P Resende, J Yelloz, G Alexandr, Standardization of Generic Architecture for Autonomous Driving: A Reality Check, Energy Consumption and Autonomous Driving / Lecture Notes in Mobility, 57- 68, sep 2015 47 Grant Agreement number: EDIDP-MUGS-2019-002-iMUGS ANNEX 1 Teleoperation, Beyond Line of Sight Teleoperation, Follow-me vehicle and pedestrian, Way point navigation, Patrolling & Reconnaissance and Surveillance. The decision layer will use a common subset of Hierarchical Task Networks (HTN) and Action Notation Modelling Language (ANML) to model and describe robotic actions at mission or manoeuvre levels. Based on these representations, several solving techniques will be used to compute on-line robot activities on a time horizon. These planning techniques will be coupled with low level control, such as model predictive control (MPC) or adaptive control. A combination of temporal task network at execution combined with automata representations will be considered for the project and scheduling strategies will have to be defined on-line. The situation awareness is critical for combat mission. Three different Simultaneous Localization and Mapping (SLAM) techniques will be envisaged for the project. Several hybridizations of outdoor SLAM will also be evaluated, including for example stereovision, inertial navigation and vision-based techniques. The SLAM technique can be complemented with a high-performance obstacle map, optimized on Graphical Processing Unit and delivering real-time performances when needed. A mission payload dedicated to observation will also provide additional useful tactical information in the command chain. Based on deep learning techniques, the processing stage will be able to provide target detection and Figure 3: Autonomous backbone architecture reconnaissance. Payload activity will be tasked on-line by the mission planning system. This is an efficient approach to deal with environment dynamics and to pinpoint relevant information according to mission objectives and context. A proximal 360° vision for autonomous mobility will also be provided to enable real-time obstacle map processing. The architectural framework for autonomy will also address safety, cyber-security and resilience in a transverse way, by providing either specific system components or generic containers (for instance, safety components will impact only execution control and trajectory management, while a set of specific guarantees –real time, atomicity, integrity- will be encapsulated by their containers). Cybersecurity (SP3) State-of-the-art: At present, the level of autonomy for vehicles on the market is limited, but the capability is rapidly growing. Current state-of-the-art vehicles offer little design considerations in the way of security to the information and control signals present throughout the vehicle. Most vehicle instrumentation and control designs make use of the Controller Area Network (CAN) bus standard. This system is a widely adopted standard but was never designed to secure the information shared on the 10 platform and lacks even some of the most basic security items such as encryption and authentication . 10 Sagong, S. U. (n.d.). ESCAR Europe 2018. In ESCAR Europe 2018. Retrieved from https://labs.ece.uw.edu/nsl/papers/Bushnell_escar2018_CameraReady.pdf 48 Grant Agreement number: EDIDP-MUGS-2019-002-iMUGS ANNEX 1 The current method of securing vehicles from cyber threats is based on adherence to non- mandatory guidelines, although many governments around the world have adopted a control-oriented 11 strategy, introducing legislation to address cyber risks . Several voluntary guidelines have been published from organizations such as Society of Automotive Engineers (SAE) and National Highway Traffic Safety Administration (NHTSA), and the US has recently introduced the Security and Privacy 12 in Your (SPY) Car Study Act of 201714 . This law mandates NHTSA to conduct a study to identify measures to implement standards for mitigating cyber security risk in vehicles. Specifically, these standards will require segregation of systems with differing security and criticality requirements and require the system to autonomously monitor, detect and prevent malicious code attempting to stop or take control of the vehicle15. In the EU, there have been measures to address the risk of cyber threats in general, but nothing with direct applicability to autonomous vehicles14. There has been much research to further the development of intrusion detection systems for vehicles, raising an alert in the event of a potential compromise or attack. Efforts have been directed toward securing the highly vulnerable CAN bus network through very economical and simple means. One design focuses on monitoring for abnormally high frequency of message transmission on the CAN 13 14 bus, indicating a potential attack . Other research attempts to apply a more generic method of behavioural modelling of autonomous vehicles. Although this technology has much more maturity as applied to conventional IT systems, current research strives to adopt this for autonomous vehicles. This model establishes an operational baseline by monitoring communication between subsystems and the resulting physical actions the vehicle takes. The system autonomously monitors for deviations from this baseline, 15 presenting anomalies to a human user to analyse for evidence of an attack . Beyond the state-of-the art: As autonomous functions advance, there is an exceedingly growing demand for computing performance and the number of subsystems required to accomplish this. The increase in computing resources directly correlates to a larger cyber-attack surface and therefore increased risk of cyber-attacks. Unlike the automotive sector, this military platform is exposed to a completely different plane of threats. As forces incorporate this asset into their battle plans, enemies will look for vulnerabilities to exploit or deny its capabilities; the large cyber-attack surface will require extra attention to safeguard from multiple attack vectors. The ability to secure and monitor for an attack will exceed the capabilities of a human operator, especially with consideration of autonomous operations outside the range of communication. Therefore, autonomous monitoring and detection is needed. Our solution draws from similar concepts that leading cyber threat detection research has proven but will address threats with a holistic model that includes cyber, electromagnetic, and physical attacks to the system, autonomously monitoring for evidence of a compromise or an attack from these vectors. In the event of detection, our system will provide an appropriate response for the platform to make without human interaction, mitigating an attack and ensuring resiliency for the platform to accomplish its assigned mission. 11 Taeihagh , A., & Si Min Lim, H. (2018). Governing autonomous vehicles: emerging responses for safety, liability, privacy, cybersecurity, and industry risks. Retrieved from https://papers.ssrn.com/sol3/papers.cfm?abstract_id=3211839 12 Security and Privacy in Your Car Study Act of 2017, H.R. 701, 115th Cong. (2017). 13 Moore, M. R., & Bridges, R. A. (2017). Modeling inter-signal arrival times for accurate detection of CAN bus signal injection attacks: a data-driven approach to in-vehicle intrusion detection. Retrieved from https://dl.acm.org/citation.cfm?id=3064816 14 Young, C., & Olufowobi, H. (2019). Automotive Intrusion Detection Based on Constant CAN Message Frequencies Across Vehicle Driving Modes. Retrieved from https://lib.dr.iastate.edu/ece_conf/67/ 15 Bezemskij, A., & Loukas, G. (2016). Behaviour-based anomaly detection of cyber-physical attacks on a robotic vehicle. Retrieved from https://ieeexplore.ieee.org/document/7828584 49 Grant Agreement number: EDIDP-MUGS-2019-002-iMUGS ANNEX 1 Communications (SP4) State-of-the-art: Current tactical C2 communication systems have been designed for leading tactical operations with voice and short messages, which requires low data rates. Although modern high data rate links are already been deployed, these solutions in general have been designed for manned operations supporting the current warfare, e.g. way the troops operate and organize themselves. In addition, each military branch often deploys their own solutions, which may not be interoperable with each other. The result of all this is that there are multiple parallel communication systems deployed, none of them in particular designed for supporting the deployment of UVs. 16 Current high-end solutions for remote control applications are typically based on proprietary technology optimized for the specific solution, up to deploying military satellite services to allow control of Unmanned Vehicles (UVs) in international operations. Although integrated and networked solutions including relayed solutions are becoming available, point-to-point system architecture is still typical for a remote-control link. In addition, video, control and telemetry data have traditionally deployed separate dedicated links. Alternatively, low-end consumer solutions may deploy WiFi-based and other similar technologies, inadequate for harsh environments such as the battlefield (interference, jamming…) and do not either support networking. Current state-of-the art mobile networks such as LTE and 5G provide capacity and connectivity and may play some role in unmanned communications but are dependent on the network infrastructure and will fail in the battlefield (jamming…). Deploying dedicated proprietary solutions for UVs is a straightforward way to implement the required UV data links. However, this increases the total complexity and cost of the communications throughout the entire logistics chain even further. In addition, in joint manned/unmanned operations the troops have to carry extra equipment in addition to their normal tactical C2 communication devices. Furthermore, current data link solutions for UVs are not usually interoperable and do not support information transfer with command systems deployed by ground forces, which means that in addition to less flexible applicability the current systems do not support building joint situational awareness due to incompatibility and lack of interfaces. Beyond the state-of-the art: iMUGS will develop and demonstrate a flexible and efficient communications concept, based on a fully networked solution combining all available resources (tactical and commercial networks, and networks with future expansion possibilities, like satellite communication) into a single entity allowing the unmanned system to be operated from the forward area to the support lines. Several features will be developed under this concept: A joint Tactical C2 and Communication network: The core of the proposed communication solution is based on modern tactical communications technologies including self-forming and self-healing tactical mesh network. The solution will form a single entity connecting both troops and UVs to each other and to the C2 system through a unique IP network providing the users the required data transfer and security services. The solution will support both manned and unmanned operations by adapting the parameters of the radio interface such as bandwidth and the waveform as required. This is based on the deployment of SDR technology. The use of the communication network by UGV and C2 Command Posts in a transparent way will make the UGV and the C2 systems network agnostic. This feature will facilitate the adoption of new communication network technologies by iMUGS components including the vehicle, the payloads and the C2 applications. In addition to information transfer, the communication solution shall provide selected EW/Electronic Support Measures functionality integrated to the same system to support combat operations and establishing joint situational awareness. One of the key ideas is to deploy the entire network as a sensor having the communications equipment providing information about the 16 DTC website: http://www.domotactical.com/solutions/?robotic-communications, Silvus Technologies website: https://silvustechnologies.com/applications/unmanned-systems/, Aero defence technologies: https://www.aerodefensetech.com/component/content/article/adt/features/articles/22651 50 Grant Agreement number: EDIDP-MUGS-2019-002-iMUGS ANNEX 1 radio environment and processing the information with distributed AI computing. In addition, the standard IP-interfaces allow connecting EW payloads to the system providing functionality such as spectrum monitoring and jamming. The integrated all-IP solution supports information exchange between various C2 and battle management systems that allows sharing, for example, joint situational awareness information. Vehicle-to-vehicle communication solution: Based on mesh-networking, the novel communication solution will support convoy-type of applications and future free formed large swarms. The concept consists of a tactical waveform design/implementation and an antenna solution combining a 360° coverage and connectivity of omnidirectional antennas to superior link performance of directional antennas. UGVs communication will be low power (LPD), resistant to jamming (AJ) and the signal will be difficult to be intercepted (LPI). Wide deployment of SDR: Secure Software Defined Radio technology will allow the proposed solution to be updated and further developed based on the requirements and evolving concepts of operation. This greatly enhances the overall life-cycle management and system maintenance. The deployment of SDR is also a key to wide interoperability and ability to flexibly support various applications with the same equipment. For example, the SDR communication equipment can be configured to carry out EW/ESM tasks and many other functionalities. Novel way of secure networking: The connections will be routed seamlessly via the best available channel including commercial mobile networks, satellite connections and tactical networks. In such a complex hybrid network the quality of service is enhanced using Artificial Intelligence/ Machine Learning-aided system level control. In addition, when opening up channels to the public telecom network, cyber threats must be properly addressed and eliminated. The system will ensure end-to-end security by deploying for example encryption, mobile VPN technology and mobile device management. The interoperability between systems supports full information transfer and joint operations, including wide-scope situational awareness and support to EW. Swarming (SP5) State-of-the-art: During the last two decades, extensive research has been executed in the field of 17 optimization strategies and search algorithms . Some of these algorithms have been demonstrated to bring value to multi-objective function solvers (MOFS), both on autonomy level as on the level of 18 vehicle collaboration or swarming . Most of the applications on swarm MOFS, today, run on simulators, and the first demonstrators (ex: DARPA, OceanAlpha-PLAN) are being deployed today. A common approach used in MOFS is to describe a physical model of the vehicle and parameterize the model, translate the environment to a data structure and to describe the optimization problem in terms 19 of constraints using a descriptive language (Constraint Programming) . Models and environments 20 resemble those in the gaming industry . In the industrial world, the Industrial Internet of Things (IIoT) 21 and digital twins, have become more generally deployed approaches . These digital twins can substitute the models used in the MOFS simulation environment, theoretically linking a physical asset to a swarm optimization algorithm. The large volumes of captured data must be reduced and rendered into data structures making the data available to search algorithms. Hence another essential discipline emerges, feature extraction and data structuring. Optimizations are currently executed on fleets of aerial and 17 Ebenhart R.C, Shi Y., Kenndy J., Swarm intelligence, 2001 18 F. Lucas, C. Guettier, P. Siarry, A.-M. Milcent and A. de la Fortelle Constrained Navigation with Mandatory Waypoints in Uncertain Environment Journal of Information Sciences and Computer Engineering, 2010 19 C. Guettier, B. Patin and J.-F. Tilman. Validation of Autonomous Concepts using the ATHENA Environment. In Proceedings of the International European Space Agency Workshop on On-Board Autonomy. Noordwijk, The Netherlands, October 2001 20 Luebke D. et al, Level of Detail for 3D graphics, 2002 21 F. Tao, H. Zhang, A. Liu and A. Y. C. Nee, "Digital Twin in Industry: State-of-the-Art," in IEEE Transactions on Industrial Informatics, vol. 15, no. 4, pp. 2405-2415, April 2019 51 Grant Agreement number: EDIDP-MUGS-2019-002-iMUGS ANNEX 1 seaborne vehicles, where a world can be described in binary logics, the challenge for ground vehicles is that they operate in complex environments that cannot be described as such. Beyond the state-of-the-art: iMUGS aims to bridge existing practical gaps between theory and implementation of scalable multi-agent collaboration and optimization which should ensure operations in mission-critical unstructured outdoor environments. In order to execute such complex missions, the challenging existing gaps relate to the timely and compact rendering and structuring of data needs to be solved. Two types of swarming optimizations are envisaged: local and global optimization. Local optimization relies upon local (edge) limited computational power and local information, where global optimization relies upon many data sources on many different levels (edge-fog-cloud) and virtually unlimited computational resources. Global swarming: iMUGS will provide a global swarming solution having access to many data sources. Except for data captured on the edge, most information and computational power are not hard real-time available. With respect to that constraint, the first challenge is to subdivide the problem statement into real-time until non-real-time requirements. Secondly, a hierarchic, type ‘level of detail’ or resolution world model approach, aims to subdivide the problem into parallel datasets that can be outsourced to computational power on each level of the architecture and solutions are progressively refined. Low resolution and hard-real-time problems are solved on the edge, near-real-time solutions using larger sections of available world information are solved on massively parallel computational power available in the fog, other non-real-time calculations are handled in the cloud. The local swarming: iMUGS will provide a local swarming solution. Local swarming approach is a swarming modality, that is active when all connections to C2 (command and control) or fog or cloud, are broken or very limited. In that case, the agents must be able to optimize their tasks based upon computational power and data sources available in their local network or stand-alone in the edge and a collaborative behaviour is aimed to emerge. Local swarming will thus optimize a local problem. Due to the low starting Technology Readiness Level (TRL) of local swarming and lack of a priori information of the equipment that local swarming is using, this swarming mode will only be developed and demonstrated on simulation level. The iMUGS swarming framework should also support an intelligent mixed interaction between the local and global swarming functionalities depending on the operational constraints and the complexity of the mission. Command and control / Control station (SP6) State-of-the-art: Remote control stations (CS) for UGVs exist today (Oshkosh, ST Kinetics) but they are typically non-standard, specific to the UGV manufacturer’s vehicle where design parameters driven by vehicle manufacturers and without regards for control of or interaction with other unmanned vehicles. In addition, no ground CS combines air and land unmanned operations: a CS to operate medium-altitude long-endurance (MALE) and tactical UAV’s beyond line of sight within European skies require airworthiness certifiable systems when the UAV exceeds 150 kg per European Union Aviation Safety Agency (EASA) regulations, whereas USA and other countries are more lenient and laxer with military use exceptions on such certification. Also, current CS solutions focus in the control of a single UGS in basic teleoperation modes, in many cases using proprietary interfaces and protocols. Today’s integrated operations require close coordination with the air and land segments and strong collaboration between them necessitate a joint view and control of the ground and airborne unmanned assets, which is not possible at the moment and thus require operator level coordination with increased work on human operators and reduced performance envelope. The experience of previous defence programs has shown that airworthiness certification is to be considered and embedded as soon as the design of the system, and has important impact on performances, costs, operational use and calendar. Beyond the state-of-the art: iMUGS aims to develop a modular heterogenous fleet UGS Control Station capable of commanding multiple UGS from a centralized C2 position, thus minimizing operator workload by combination of Control Station features with UGS autonomy and swarming capabilities. iMUGS will integrate air component to unmanned ground systems in design, and thus allow joint force operations and acquisition and provide long term design stability. Aerospace certification is an aspect that cannot be added to a product later on, it must be integrated and planned from the initial design 52 Grant Agreement number: EDIDP-MUGS-2019-002-iMUGS ANNEX 1 phases and high-level requirements should be traced throughout the project cycle from design to hardware and software to certify the final product. For this reason, the C2 station of iMUGS will be an integrated one, designed to allow future UAV airworthiness certification. iMUGS control station will meet the same strict aerospace safety critical design rules for airworthiness certification with the use of (Un)Manned’s Sol technology base, for eventual co-operation of UGS with UAS systems and control of UAS and UGS from the same control station. Furthermore, it will conform with relevant standards such as existing Standardization Agreement (STANAG) 4586 for UAV operations, derive a standard UGV operations concept based on it. The control station design will also comply with the upcoming STANAG 4817 for Multi Domain Control Station (MDCS) and NGVA compatible mobile vehicle control interfaces. At its release iMUGS C2 station will be at the forefront of the control stations for control of multiple unmanned systems: on the ground and in the air. iMUGS CS will take a modular approach to capabilities, allowing the development and rapid deployment of additional functionality and payloads over time in phases of MUGS project. A flexible control station architecture with different unmanned vehicle profiles will be created, that can be expanded later to any Unmanned System. Eventually all unmanned systems will be controllable from the same C2 station and integrated into battlefield tactical environment. Instead of the typical company vehicle specific implementations a common standard station will allow many European nations and companies to cooperate in system design, later European cooperation in operation and potentially asset sharing. iMUGS system architecture can be deployed over a variety of ground and air systems that are interlinked via same communication means. The Control Station allows a single individual to control multiple semi-autonomous systems using the same software suite and controller, therefore, maximizing the use of assets, sensors, payloads, data/information sharing and decision-making. Manned-Unmanned Teaming (SP7) State of the-art: Unmanned flight systems have already been in use for several years. Scenarios for using these systems exist, as well as the belonging infrastructure, logistics and training concepts. The whole development of unmanned ground systems, e.g. Concept of Operations (ConOps), military operational scenarios, virtual simulation of ground systems or studies about the ways to deploy them are at their premises. Today there are no common concepts on how to handle Manned-Unmanned Teaming (MUM-T) within the participating nations inside the European Union (EU). Beyond the state-of-the art: Within the iMUGS project, working groups with military representative from the participating countries will be organised to define and assess concepts of operation for MUM- T in connection to iMUGS. The workshops planned within MUM-T will help to build a European base for the future development of the topics connected to MUM-T. These topics are military operational scenarios to be considered for this project, the deployment of unmanned ground and aerial systems and possible future scenarios. The military operational scenarios will describe how iMUGS can be used and what the current restrictions are. A subset of these military operational scenarios will be shown during the demonstrations of this project and will help to update these scenarios already during the realisation of this project. The investigations about the deployment of unmanned systems will summarize the current possibilities and what will be necessary and helpful in the future. Examples for the deployment of unmanned systems will be presented during the demonstrations. The possible future scenarios will summarize the points of the discussions which cannot be considered for this project, a roadmap will explore possible middle-term developments. It will cover main interests for the time being and what might be helpful and necessary for the future. A second outcome will be that the possibilities of the constructive and virtual simulation in respect to iMUGS in different combinations will be evaluated. The constructive simulation will integrate an iMUGS and test possible military operational scenarios within the workshops mentioned above. These scenarios will consider different combinations of iMUGS with manned vehicles and with soldiers. As a side effect, the opportunities for the virtual simulation as a training equipment for iMUGS will also 53 Grant Agreement number: EDIDP-MUGS-2019-002-iMUGS ANNEX 1 be visible within this project. Deliver operator-centric and efficient design as well as production of the individual components and the whole System. 54 Grant Agreement number: EDIDP-MUGS-2019-002-iMUGS ANNEX 1 6.1.2.2. Overall concept of iMUGS As shown in enclosed figure, iMUGS aims to develop a modular, standardized and open system architecture for unmanned ground and aerial platforms; the subsystems described above will be integrated in a modular way in this architecture. This architecture will enable the development of systems composed of different manned and unmanned ground and aerial platforms with high autonomy capabilities, swarming ability and sensors, payloads and intelligent functionalities and assets, all connected through a secured and resilient architecture to a communication network and to a C2, interoperable with external C4I systems and joint ISR databases. For the purpose of demonstrating the project at the end, the prototype of the system and the demonstrations of it will be based on one specific UGV (MILREM THeMIS) and a specific list of payloads that are described in the implementation part. The iMUGS system architecture is depicted in figure below and described in detail in section 6.1.2.1 [Open, modular, technology agnostic architecture (SP1 System’s Integration)]. The architecture allows efficient deployment of unmanned ground and aerial vehicles to be operated in parallel with manned platforms in various combat situations and tasks supporting the operation. The iMUGS system is highly modular and interoperable with other land, - sea- and air-based systems (manned or not) to provide the users the flexibility of mission configuration, timely and safe availability of situational information and capabilities of system control. Hence, we are specifying the core architecture and allowing a wide variety of payloads to be configured in a cyber-secure manner with the system to achieve mission objectives. These payloads range from a simple specific sensor to a full-fledged integration with another type of asset to enable teaming and information analysis, -distribution etc. In the context of iMUGS we foresee the integration of payloads into the system to be flexible and cost efficient– so that new types or significantly improved missions/capability are available to the users of the technology. As today the state-of-the-art technology portfolio of iMUGS components contains items sourced or of which development relies on technology from outside of EU. The project clearly identifies the components and technologies with existing or potential non-dependence issues and proposes either alternative non-dependent EU sources/technologies or formulates a suggestion for achievement of (at- least) non-dependence to be utilized in an EU-wide measure such as the European Non-Dependence Process or similar. Figure: iMUGS overall architecture 55 Grant Agreement number: EDIDP-MUGS-2019-002-iMUGS ANNEX 1 6.1.2.3. Added value of the expected outcome iMUGS paves the way towards manned-unmanned collaboration in the context of next generation ground capabilities, it will open a new era of use of UGS and related technologies in the operations, particularly advanced autonomous functionalities, and in-between will provide the credible basis to progressively introduce it in operational capacities. iMUGS will contribute significantly to the development of credible operational solutions to armed forces in the medium term, based on leading edge competencies established in the EU, while engaging in a constructive dialog with its end-users. The project will consequently provide a very significant breakthrough potential both in technological and operational terms. iMUGS project will improve several key technologies up to TRL 7 as listed in 22 the following table . Table 2: iMUGS TRL progress End of the Project items/components Initial project SP1.Integration Fast deployment for unmanned aerial and ground systems TRL 4 TRL 7 Secured sensor and payload gateway TRL 3 TRL 7 SP2.Autonomy Fratricide avoidance and safety TRL 3 TRL 5 Autonomous functions for off-road operations and tasks:  Way point navigation TRL 4 TRL 7  Follow me for pedestrian and vehicle TRL 4 TRL 7  Obstacle avoidance TRL 4 TRL 6  Shuttle service TRL 4 TRL 7 Mission planning:  Path planning TRL 4 TRL 7  Multi horizon task solver TRL 3 TRL 6  Autonomous patrolling TRL 2 TRL 5  Autonomous surveillance TRL 2 TRL 5  Autonomous reconnaissance TRL 2 TRL 5 SP3.Cyber Cyber Defence System (CDS) Detection Subsystem TRL 2 TRL 6 CDS Response Controller TRL 0 TRL 7 SP4.Communication Integrated communications solution for voice and data, operators and TRL 4 TRL 6 equipment including vehicle to vehicle communications SP5.Swarming Local Swarming behaviour TRL 1 TRL 4 Global Swarming Behaviour TRL 2 TRL 5 SP6.C2 Secured and standardized approach for interoperability TRL 3 TRL 6 Certifiable Mission Control Station TRL 3 TRL 5 SP7.MUM-T Simulation of iMUGS TRL 1 TRL 5 Deployment of iMUGS TRL 2 TRL 6 22 Horizon 2020 technology readiness levels issued for the work programme 2014-2015 https://ec.europa.eu/research/participants/data/ref/h2020/wp/2014_2015/annexes/h2020-wp1415-annex-g-trl_en.pdf 56 Grant Agreement number: EDIDP-MUGS-2019-002-iMUGS ANNEX 1 The development of operational concepts (SP7) and the testing of the iMUGS in demonstrations (WP5), the project will provide input for the European Defence Forces’ operational assessment and concept definition. Milrem robotics THeMIS platform (https://milremrobotics.com/defence/) – a medium weigh class UGV - will be used for demonstrations and development on concepts for teaming with dismounted troops. THeMIS mobility platform is tracked hybrid mobility platform vehicle with sufficient payload capacity, pulling force and top speed. In addition, the iMUGS project will have a strong impact on future defence systems. 6.1.3. CONTRIBUTION TO INCREASING EFFICIENCY ACROSS THE LIFE CYCLE iMUGS will also contribute to efficiency with its use of modular and integrated design approach, in both vehicles, payloads and C2 software, which in turn will enable existing capital investments to be reused and to remain up to date with modular changes. Reuse of mass-produced base platforms with reconfigurable payloads in many roles will provide benefits of economies of scale in acquisition. In addition, continuous constrictive dialogue with the end-users will deliver operator-centric and efficient design as well as production of the individual components and the whole System. 6.1.4. QUALITY OF IMPLEMENTATION, ORGANISATION AND RESOURCES 6.1.4.1. Quality and effectiveness of the work plan – Work packages, deliverables and milestones Methodology i Figure: CD&E lifecycle iMUGS project methodology is based on an CD&E agile concept with demonstrations, lifecycle through the following items: a. Operational concepts: requirements and military scenarios are captured through high level simulation with the participation of end-users; b. Iterative V-cycle development covering system requirement increments as well as iterative design cycles (using Model Based system engineering); c. Experimentation through technical simulations and demonstrations. 57 Grant Agreement number: EDIDP-MUGS-2019-002-iMUGS ANNEX 1 It ensures the participation and contribution of end-users on an iterative way all along the project through the first phase (operational concepts: requirements and military scenarios capture involve end- users) and the last phase of the CD&E methodology (test and demonstrations: field tests will be performed together with end-users and results of end-users evaluations will be used to close the loop of the methodology back to operational concepts phase). a. Operational concepts through high level simulation The constructive simulation will use MASA SWORD, a (NATO) HLA certified tool, which is a complete wargame solution with automated forces for high-level training and analysis. For example, with the help of MASA SWORD armies prepare their operational engagements and use it also for direct support during operations. The virtual simulation of KMW is used for all kinds of training, starting with driving and shooting simulators up to high-end combat simulators. Armed forces around the world use these simulators to educate and train their soldiers and will be used within iMUGS to build operational scenarios with end-users. This will ensure the operational scenarios will be defined close to the needs and conditions of the later engagements. b. Iterative V-cycle development The project will be developed through an agile incremental development process with multiple deliveries – this implies a rapid system requirements model development from mission requirements and operational scenarios. Respective interfaces between subsystems/modules will be specified early in the project. Adherence to military NATO STANAGs will be pursued, NATO Architecture Framework v4 is used for architecture representation and communication. To achieve rapid integration cycles a geographically distributed bench model (connected through secured network) will be established. This will enable test driven development approach to be fully utilised as newly developed functionality will be integrated to the bench model for early verification and testing (running automated tests at the subsystem and system level). This will include the Figure: Iterative V-cycle with multiple deliverables 58 Grant Agreement number: EDIDP-MUGS-2019-002-iMUGS ANNEX 1 integration of simulation environments. Testing and verification will follow as the components are prototyped. Available hardware and software functionality will be integrated into the system and functionality verified (accepted) before commencing with demonstrations (formalized with pre- and post-demonstration reviews). This will make up a Continuous Delivery pipeline to feed the demonstration events with increasing verified functional capabilities. Within the development cycle, Model Based Systems Engineering and Task tracking software solutions will be used to track project work and make a model of the system available for all project partners. c. Experimentations through simulation and demonstrations Low level simulation (technical level for autonomous functions and swarming functions) iMUGS development is based on the use of simulation within the development of some functions like autonomy and swarming. Autonomy functions will be implemented first in simulated environment based on hardware in the loop simulator, in order to ensure proper integration but also to test autonomy algorithms before implementation (to increase efficiency of the implementation as well as to increase security during tests and demonstrations). Also swarming functions will be first implemented and tested through a simulator environment. Demonstrations & engagement To showcase the capabilities of the system, an operator-centric functionality demonstration approach is taken where we plan to have demonstrations (in different climatic and seasonal conditions, in several countries) based on the functionalities available at that point in time. 6 demonstrations are scheduled within the project, in line with the iterative methodology in place in the iMUGS project. Each demonstration will receive its own scenario, where the core functionality and payloads fitting into that scenario are demonstrated (on the field or hangar demonstrations) – operated by the end-user where applicable (for higher TRL functionality and possibly taking part to a military exercise for example). Five main scenarios would list as: autonomous Intelligence, Surveillance, Target Acquisition, & Reconnaissance (ISTAR) missions, force protection, logistics activities, Medical Evacuation (MEDEVAC) and Area patrolling. Demonstration locations are chosen to cover several climatic and seasonal conditions. Demonstrations are built upon an operator-centric functionality exposure giving an overview and first- hand experience on how operators and commanders are able to exploit the system capabilities – gradually extending the capability spectrum as functionality is being delivered by consortium members. Demonstration 1, Estonia, M6 Operator control scope: Line of Sight Missions planning: ISR, Forward Operating Base (FOB) logistics’ scenarios (Line of sight control)  Logistics’ mule at the base  Deployment with an Armoured Personnel Carrier (APC) and return to base – Maintenance + Cyber: logfile analysis Missions:  Tethered UAV ISR  Secure communications for unmanned and manned missions based on a tactical mesh network including radio relay / multi-hop scenarios  Providing power to troops.  Beacon based follow-me pedestrian and/or vehicle – simplistic approach march and preparation for Shuttle service Demonstration 2, Latvia, M11 Operator control scope: Line of Sight and Beyond Visual Line of Sight Missions planning: SIGINT, aggressive fire detection and alternative networks:  iMUGS systems integration with BMS (Viedsargs)  Troop and UGV use of tactical Long-Term Evolution (LTE) mobile communications networks 59 Grant Agreement number: EDIDP-MUGS-2019-002-iMUGS ANNEX 1  Performing Signal Intelligence (SIGINT) (communications and electronic intelligence) mission: SIGINT solution Skudra capabilities  Performing aggressive fire detection and source recognition with an ISR system (ISOA)  Performing Close-in jamming (approach march) Demonstration 3, Belgium, M14 Environment: Coastal Operator control scope: Beyond Visual Line of Sight Missions planning: Area patrol, ISR mission, ISR mission kit integration procedures:  Performing area patrol mission (inc. swarming – i.e. more than one UGV)  Performing BVLOS reconnaissance mission (silent mode). Demonstration 4, TBD, M18 Operator Control scope: Beyond Visual Line of Sight – standalone C2 Mission planning: Area exploration, MEDEVAC, Cyber hostile environment, EW  Detecting Cyber-attack detection  Standalone C2 control station: functionality demonstration (Single, multiple UGV control, Tethered UAV integration)  Performing MEDEVAC mission  Advanced tactical mesh communications with optimized network functionality and integrated EW functionality (e.g. detection and localization of jamming)  Performing Area exploration Demonstration 5, Germany, M22 Operator control scope: BVLOS – mobile C2 Mission planning: Force protection, ISR (feed to joint intelligence surveillance reconnaissance database) Servicing and mission configurations: Supply chain security design; compromised software injection, detection and reaction.  Deployment with APC  Performing force protection missions (ballistic protection, area exploration)  Follow me pedestrian and aggressive fire detection during an approach march  Collective resupply and MEDEVAC to/from front line  Performing an ISR mission with waypoint navigation and geo-localisation in with EW hostile environment elements (GNSS-denied, occasional jamming and occasional radio silence,).  Teaming with multirotor UAV (including reconditioning and storage)  C2: Multiple UGV, UAV display (health and usage full monitoring system, inc. cyber and autonomy flags), display of payload information/control Demonstration 6, Germany, M24 Full system and capability demonstration – end-to-end demonstrations: all missions re-run, mixed control scope (handover from Control Station to LOS control, etc, maintenance of a dynamic relay network, enhanced V2V functionality) Engagement Event, Belgium, M29 The engagement event is held at the end of the project to expose the outcomes of the development and is foreseen to be held close or integrated to a conference or other EU-level event in Brussels. The events would also serve as opportunity for discussions on future developments and relevant aspects (such as ethics and technology non-dependence) with stakeholders and policymakers. Invited parties include the European Commission, European Defence Agency, NATO Science and Technology Organisation, etc. 60 Grant Agreement number: EDIDP-MUGS-2019-002-iMUGS ANNEX 1 Overall structure of the project As iMUGS project is a significant project in terms of budget and in terms of participants, organisation is key to secure proper implementation of it. In order to ensure iMUGS quality of implementation, iMUGS will be structured into two axes:  Sub project axis (horizontal axes on following figure, ensuring coherence of the development of each subsystem of the project above the different activities)  Work package axis (vertical axis on figure ensuring coherence within each activity to report to EU). These two axes will form the organisation matrix of the project with main axis based on SP management. As described above, main management project axis of iMUGS is based on “Subprojects” (SP), which will constitute the global architecture of the project:  SP1 System integration will provide the overall system engineering and system architecture development, reference UGV platforms (MILREM THeMIS) and will integrate the developed technologies to a system demonstrator,  SP2 Autonomous functions will establish the framework (including sensors and software) and functionalities for navigational and mission autonomy,  SP3 Cybersecurity will deliver analysis, design and reference implementation of a Cyber secure system design, secure supply chain and Cyber Defence System on a UGV system,  SP4 Communications equipment and networks will provide an interoperable (tactical and commercial networks), EW resilient communications solution (hardware and software),  SP5 Swarming will deliver global and local swarming technologies for collaborative robotic behaviour and rapid rescheduling and re-tasking of agents.  SP6 Command, Control and Interoperability will develop a C2 control station airworthiness certifiable for expansion and has tactical component that interoperable with C4I and Joint Intelligence, Surveillance and Reconnaissance (JISR) systems.  SP7 Manned-Unmanned Teaming will cater for global operational scenarios for the system capability development. Figure: iMUGS Project workplan 61 Grant Agreement number: EDIDP-MUGS-2019-002-iMUGS ANNEX 1 Each of these SPs will be divided into different tasks per activities (management, studies, design, prototyping, testing) and these tasks report to the corresponding WP:  WP1 Studies  WP2 Design  WP3 Prototyping  WP4 Testing This leads to the following breakdown structure of the project (Figure): Figure: iMUGS Work breakdown structure 62 Grant Agreement number: EDIDP-MUGS-2019-002-iMUGS ANNEX 1 iMUGS Gantt Chart The Master Schedule is as follows. The detailed schedule at SP level is available and will be presented at project kick-off, synchronized to M1. The subtask durations are shown in the work package tables. Figure: iMUGS Gantt chart 63 Grant Agreement number: EDIDP-MUGS-2019-002-iMUGS ANNEX 1 6.1.4.2. Appropriateness of the management structure and procedures, including risk management Management structure and bodies Figure: iMUGS management structure The organisational structure and decision-making mechanisms are established taking into account the scale of the project (medium size consortium, highly collaborative and interrelated SPs and WPs). Organizational structures and decision-making mechanisms are defined in the Consortium Agreement between the beneficiaries. Project and Quality Management have been further developed and described in the respective plans as Attachments 2 and 6 to the Consortium Agreement. Similar roles and responsibilities of the management bodies are described below. Project Coordinator (PC) MILREM (Mr Markku RAUTIO) The project will be managed by a Project Coordinator from MILREM. The PC is the legal entity acting as the intermediary between the Parties and the Funding Authority, the European Commission (EC). The PC is responsible for:  Ensuring the punctual compliance by the partners with their obligations;  Ensuring that all SPs and WPs maintain the overall project vision with a common approach for technical decisions;  Collecting, reviewing and submitting reports and other deliverables (including financial statements and related certification) to the EC;  Preparing meetings (Executive Board, Steering Group), chairing the meetings and monitoring the implementation of the decisions taken;  Ensuring flows of project information and documents between the partners;  Administering the EC financial contribution in accordance with the Grant Agreement Management support team (MST) Project coordinator, administrative support, specific roles The MST provides support for the day-to-day project management activities. The MST personnel will be under the responsibility of the Project Coordinator and support him for the general management of the project and communication with EC. The MST will be in charge of the daily coordination of the project (organisation and minutes of meetings, conference calls…). It will support the coordinator for the risk management, the preparation of periodic and final reports, and the financial management. Besides, MST can comprise in particular the following roles (people in charge to be appointed):  The Project Security Officer will manage the practical aspects related to security, together with the security officers of the partners of the project.  The Data Manager will support the partners for questions related to the protection and collection of data. 64 Grant Agreement number: EDIDP-MUGS-2019-002-iMUGS ANNEX 1  The IPR Manager will be in charge of implementing the IPR policy set forth in the consortium agreement and the grant agreement, and bring support to the partners when it comes to IP  The Ethical and Legal Manager will be in charge of the Ethics Check to verify the implementation of the ethical issues as stated in WP1 description.  Communication Manager will plan, establish and update communication strategy and raise target groups awareness about project results. The Communication manager will be responsible for the implementation and follow-up of communication activities Project Architect MILREM The Project Architect will lead the definition of iMUGS system architecture and subsystems, draft the requirements and system models, coordinate multiple design alternatives together with SP leaders, coordinate trade-off analysis on system budgets, interface with subsystem and payload providers and participating member states project team. Sub Projects Leaders SP1: MILREM, SP2: SAFRAN, SP3: GTCT, SP4: Bittium, SP5: ERM-KMS, SP6: GMV, SP7: KMW SP leaders are responsible for production of SPs deliverables and their submission to the PC; they report on the progress of their SPs and present detailed and updated work plans to contribute to maintenance of the quality assurance plan. They contribute to management decisions within the EB (see below) scope and implement the decisions that impact their respective SPs. SP leaders exercise technical coordination of the project according to the directives of the PC, maintain alignment in time and content between the different tasks, and support the PC with risk assessment. SP leaders will organize specific meetings bringing together partners involved in their SP as often as necessary and at least every 6 months to follow SP progress or discuss any technical issue within their SP. These may be physical meetings or conference calls. SP leader will be responsible for the interrelations between the different tasks of the WPs. They will bring recommendations to the WP coordinators regarding the global management within the WP and work with the WP coordinators to develop the different reports to the EC. WP WP1: MILREM, WP2 KMW WP3: SAFRAN, WP4: NEXTER, WP5 DIEHL coordinators WP coordinators supports the coordination, coherence and good implementation of the project within their respective WP. WP coordinators supports technical coordination of the project according to the directives of the PC, support alignment in time and content between the different activities and support the PC with risk assessment. WP coordinators can organize specific meetings bringing together partners involved in their WP as often as necessary to follow WP progress or discuss any technical issue within their WP. These may be physical meetings or conference calls. Steering Group (SG) PC + 1 representative of all partners The SG is composed of the PC and one representative from each partner. The SG is responsible for the high-level decision making on all issues that can have an impact on the project. The SG takes any major decision affecting the execution of the project, such as a change in the consortium composition, a transfer of resources between partners or between WPs or SPs, or a change in the planning or in the technological choices. Matters within the SG scope of decisions are defined in the CA and include:  Major changes in work, particularly termination, creation, or reallocation of activities;  Amendments of the Consortium Agreement (CA);  Requests for an amendment of the Grant Agreement to the EC;  Actions to be taken in case of default of a project partner or of force majeure events;  Requests to the EC for admission of other partners to the iMUGS project;  Access Rights of the project partners. The SG is the highest level of authority in the project and will meet at the kick-off of the project, M12, M24 and M30, and upon any specific occasion requiring decisions at its level, according to CA. SP leaders and partners PC, SP leaders, WP coordinators, project architect Executive boards (EB) The EBs are composed of the PC, the SP leaders, the WP coordinators, the PA, respectively. 65 Grant Agreement number: EDIDP-MUGS-2019-002-iMUGS ANNEX 1 It acts in the supporting of the consortium, as supervisory for the execution of the project and as internal support by:  Actively managing deliverables in accordance with the schedule and requirements of the Grant Agreement;  Detecting potential issues and deviation from the work plan and identifying, proposing and implement corrective actions;  Deciding upon major changes in SPs if the need to do so arises;  Deciding on specific technical (re)orientations of the project whenever the need arises;  Ensuring the application of standard quality assurance practices and performing risk management;  Managing and controlling the data required and generated by the project;  Securing the appropriate dissemination and exploitation of Project results;  Supporting the PC in preparing meetings with the EC. The EBs will meet face-to-face at least once a year during the project duration. Besides, every 3 months conference calls will be organised to monitor the project progress, to assure the proper execution of the project and proactively identify and address potential problems that could impact key deliverables of the project. Ad hoc meetings of the EB are convened whenever specific issues arise. Every EB meeting will include in its agenda the list of relevant specific topics and conduct a proper review and programme activity status evaluation and take management decisions at the level that does not require approval by all partners. Each SP Leader reports to the PC on the progress of current activities of its SPs. Roles and task for the EB will be further defined at the beginning of the project. Advisory Board (AB) PC, representatives and high-level experts from the end-users, policy advisors, industrial stakeholders, SMEs The AB is composed of the PC and external participants of the project: representatives and high-level experts from the end-users, policy advisors (think tanks, academies, doctrine makers) and industrial stakeholders (including SMEs). The AB is in charge of reviewing the project progress, the operational/use cases choices as well as technical choices, and to provide recommendations. The AB will meet face to face once a year. PC will be in charge of organising the AB with the support of the MST. Although the AB members are not partners of the consortium, they can have access to selected project deliverables after signature of NDAs. It is envisaged that all SP’s can additionally have their own specific AB’s due to the different technological nature of the SP’s and their individual needs for such support. The principles for the AB’s including the composition of the external experts within will be agreed in the Consortium Agreement. Several stakeholders have already expressed their intent to support the project. Board of participating member states Participating project members for the PESCO for Integrated Unmanned Ground System project (UGS) are Germany, France, Spain, Belgium, Finland, Latvia and Estonia (see § 6.6). Bringing together representative of these 7 countries in a board will foster the control of the implementation of the project: fulfilment of the common requirements, insight on the procurement perspectives, development of operational scenarios. The board will be chaired by the project manager appointed by the Member States and meet once a year during the project. Management tools These management bodies will have the following tools at their disposal to insure a smooth and resilient implementation of the project. Consortium Agreement define the roles of each partner, the rules of collaboration among partners (roles, responsibilities and mutual obligations for the project life), IPR protection (see dedicated section), rules for budget re-allocation, etc. Project will ultimately be defined and run in compliance to the Grant and Consortium Agreements. These agreements with the contracting authorities identify and define the plans, processes and deliverables for the project. 66 Grant Agreement number: EDIDP-MUGS-2019-002-iMUGS ANNEX 1 Project Work Plan (Description of Work). This operational document narrowly relies on section 6.1 of this application document; it encompasses the concept, methodology and work organisation (in particular SPs and WPs). Project Quality Assurance Plan define quality assurance and management procedures, templates for the documents, internal review processes to ensure the quality of deliverables and of any other publication, complying with formal requirements established by the Consortium Agreement; A (secured) Documents Repository will be implemented to assist in the management of documents. Meetings will be planned and agreed at the Consortium level (see above EB and SG descriptions). Sub- Project Meetings will be organized by the SP Leaders, according to the needs of each SP. The meetings dates and locations will be selected in order to minimize the number of travels (synchronized meetings); the use of teleconferences will be maximised to limit the use of face-to-face meetings, for cost and environmental stakes. Decision process Occurrence of conflicts will be prevented by strong partner commitments, complementarity of contributions and interests, detailed work plan with accurate task allocation, and an effective internal communication process. As a general rule, all decisions will be taken by consensus at the management level (Tasks, SPs, EB) at which the need for decision arises. Ultimate decision level is the SG. Procedures will be defined in the Consortium Agreement. Project reporting The procedure for the preparation of formal Periodic and Final Reporting will be coordinated by the PC and will be explained to the partners to ensure that the procedure is clear for each partner and respected by them. The procedure is built on the collaboration and collection of the input from each partner orchestrated at different levels: SP leaders will coordinate the reporting for their SP, consolidate and complete the information they collect from partners and send the information per activity to the corresponding WP coordinator. The WP coordinator will send the report to the PC within the planned time schedule. Based on the inputs of the partners, the PC will consolidate and complete the report before submitting to the EC. Continuous monitoring and reporting will also be ensured through key milestones that have already been identified for the project implementation. They will be carefully monitored by the corresponding SP leaders and at project level by the PC. When the date of milestones review is achieved, the results verification will be conducted against set objectives and a short explanation will be issued regarding the milestone’s assessment. If a milestone is delayed or is not achieved, the impact on project and SPs will be assessed and a back-up plan will be proposed by the concerned SP leaders. Reporting will be defined in the Consortium Agreement to be in full compliancy to the Grant Agreement. Details for reporting will be agreed with the EC with the first report. Financial management The coordinator is responsible for the transfer of the EU funding to the partners. The EC’s rules on financial issues, taking into account the specificities of EDIDP, will be presented to the partners by the PC at the Kick-off Meeting. During reporting periods, the Project Coordinator will provide partners with the necessary information so that they could undertake their financial reporting in compliance with the EC rules. The person-month and budget consumption will be followed during each reporting in order to monitor its compliance with the planned amounts in the Grant Agreement. Selected approaches for decision making, management and reporting are according to the EU governance model and the EDIDP guidelines for organizing the project according to different activities performed during the project. Risk management iMUGS risk management will be viewed as a circular process in which risks are identified, analysed, managed and monitored. Risk Management reviews are agile and regular. System level reviews will take place every 6 months, monthly intervals are foreseen at SP level.  Risk identification. During the project implementation, the PC, with the support of the SP leaders, will review the risks at regular intervals to re-state current priorities as project priorities 67 Grant Agreement number: EDIDP-MUGS-2019-002-iMUGS ANNEX 1 may shift over time (deadlines, budget re-forecasts, and performance expectations) and unforeseen difficulties might arise. They will also identify further risks that can occur.  Risk analysis. iMUGS will use estimates of likelihood and impact against the key risks. iMUGS will try to quantify risks wherever possible by using a scoring system to ensure comparison of risks across the different project work-streams.  Risk management. Risk responses in iMUGS will fall under one of the types: a) Avoid the risk: This can be done by avoiding use of technologies where feasible alternatives exist; b) Mitigate the risk: If a risk cannot be avoided, management will try to reduce the risk by making it either less likely or less consequential. This will include the development of contingency plans for those risks which cannot be avoided, c) Accept or retain the risk: For the risks that can’t be 23 mitigated, controlled or avoided, NATO Architecture Framework v4 can be used to convey the system architecture to all stock and stakeholders to provide a uniform, standards based architectural view.  Risk monitoring. iMUGS will run a well-maintained risk register for monitoring risk- management performance. The register defines mitigating actions for each risk, citing who will do what and by when. Risks are reassessed after every 3- or 6-month period or at certain milestones or completion of certain tasks. A sprint cycle is used so that we reassess in sync with some regular management meetings. A risk burndown chart will be used to visualize the residual risk during the course of the project.  Risk Contingency Plans. In order to monitor and minimize iMUGS’ risks, the consortium will prepare a list of risks and propose contingency plans as early as possible. The provided risk table proposes a first analysis of the main risks and the proposed risk mitigation measures. 4 mains categories of risks: Technologies performance; System inability; Users’ acceptance; Legal, regulatory. As iMUGS will not be dependant from another project or program, it will thus not potentially be indirectly impacted by risks encountered in the frameworks of such projects. 6.1.4.3. Complementarity of the participants and consortium Table: iMUGS consortium complementarity table Un-Manned ERM-KMS DotOcean MILREM SAFRAN NEXTER Bittium DIEHL GTCT KMW GMV LMT Insta System’s Architecture X X X X X X X & Integration Autonomy X X X X Cyber X Communication X X Swarming X X X C2 &Interoperability X X MUM-T X X X Management X X X X X iMUGS is built on a close interaction between industries, research & technology organizations, academia and end-users and brings together 13 partners from 7 European countries, ensuring a large coverage and representation of the European Members States in the project. Each participant brings a specific expertise and added value to the consortium, ensuring a large complementarity of consortium partners and the interdisciplinary of the approach. 23 NATO Architecture Framework, Version 4, April 2019 https://www.nato.int/cps/en/natohq/topics_157575.htm? 68 Grant Agreement number: EDIDP-MUGS-2019-002-iMUGS ANNEX 1 1.1 MILREM is a leading developer of unmanned ground systems and experienced integrator of various payloads to unmanned systems. Inhouse capabilities include also autonomy development, particularly with state-of-the-art machine learning. MILREM has an experience as payload integrator and will provide its mid-size unmanned platform for iMUGS demonstrations. MILREM has an experience as manager and coordinator of different consortia performing the projects based on the financial resources made available within different programs. 1.2 SAFRAN has a wide experience in robotics and autonomous systems. Its expertise extends to all the necessary capabilities for developing various autonomous functionalities for unmanned systems as well as to safety and security aspects of ground and aerial systems. 1.3 GTCT has the experience and network for identifying expected future cyber threats, evaluating novel anomaly detection techniques, and in cyber defence system integration. 1.4 Bittium is well established tactical and secure communications technology and solution provider with long experience for software defined radio development, mobile cellular and satellite handsets and base station products. Bittium’s expertise and references comprise also special communication solutions from underground mines to industrial applications. Bittium will provide the multi-channel integrated communication solution suitable for both machine and operator use. 1.5 Insta has a specific experience for developing collaborative operating robots for local swarming environment. 1.6 GMV has the knowhow for securing the interoperation of the supervised unmanned assets with command and control and joint intelligence, surveillance and reconnaissance and also dismounted soldier systems. 1.7 KMW leads the European market for highly protected wheeled and tracked vehicles. More than 50 nations armed forces rely on tactical systems by KMW. KMW has wide-ranging system competence in civil and military simulation, as well as in command and information systems and remote-controlled weapon stations with reconnaissance and observation equipment. 1.8 DIEHL provides expertise for the system safety of the autonomy development. DIEHL has wide experience in the integration of robotic systems and autonomy development for them. 1.9 NEXTER has wide experience in the integration of robotic systems and autonomy development for them. More generally, NEXTER Systems has a wide expertise of defence land systems design and integration, notably around vehicles. 1.10 LMT has established a reputation as the most trusted mobile operator in Latvia. It has specific knowledge to utilize 4G/5G/LTE public networks for military use. 1.11 (Un)Manned is the only European company with experience in developing airworthiness certifiable MALE UAV ground control stations with state-of-the-art user interfaces and has unique know-how in flexible generic (air-land-marine) unmanned vehicle Ground Control Surveilliance (GCS) design. 1.12 ERM-KMS has wide experience in developing and experimenting robotic systems and their single and group behavioural capabilities. 1.13 dotOcean is the leading developer of autonomous and secure interconnected collaborative systems where many devices combine into one or multiple robots or sub-robots based on End-To-End Encryption (E2EE), IIoT and digital twin technologies in global scale. 6.1.4.4. Appropriateness of the allocation of tasks Table: iMUGS, Other direct cost (‘travel’, ‘equipment’, and ‘goods and services’) 1.1/MILREM Cost (€) Justification Travel 338482 Travel cost for the facilitating and participation to the project meetings, milestones, integration activities and testing/demonstrations. Abroad co- operation with other work packages partners and stakeholders. Equipment 599020 Platform HW purchases, simulation and data warehousing computers, Payloads and sensors for integration. EMC and safety testing services. Other goods 507124 Purchases of SW kits and licenses and support for data warehousing and and services diverse mission kit components and development and testing services. Total 1444986 69 Grant Agreement number: EDIDP-MUGS-2019-002-iMUGS ANNEX 1 1.12/ERM- Cost (€) Justification KMS Travel 87360 Travel cost for the participation to the project meetings, milestones, integration activities and testing/demonstrations. Abroad co-operation with other work packages partners. Equipment 88667 Swarming development infrastructure and tools, including Fog Graphics Processor Unit (GPU) server CUDA simulation and development, small mobile robot platforms and payload for testing and validation, mobile computing devices and work-stations for developments and simulation. Other goods - - and services Total 176027 6.2. CONTRIBUTION TO INNOVATION 6.2.1. CONTRIBUTION TO INNOVATION Seven Major Innovative concepts will emanate from iMUGS: Two types of innovations are expected as the outcomes of the project:  Incremental innovations (using existing technologies but in a new environment or usage)  Major or disruptive innovations (providing new technologies) These innovations echo the key objectives of the project as stated in §6.1.1., i.e. operational objectives (OO) and technical objectives (TO). 1. Autonomy backbone: modular, sensor & platform agnostic, able to host an important variety of algorithms coming from different providers for defence uses [ref to to2] Beyond prototyping, no existing robotic kit on the market can be used in a Defence context where safety and integrity levels expectations are high, especially when we target autonomous operation and/or fire support, i.e. weaponized robotics. None of the existing middleware either comply with IEC 61508 norm or allow SIL and non SIL hardware and software components to work together in a same framework. iMUGS project will develop an autonomy framework including a hardware SIL2 or SIL3 platform in order to support an appropriate safety level where necessary and a non SIL hardware with higher computational resources and memory for more complex autonomy functions. The IEC 61058 will be the starting point of iMUGS safety design. The quality plan for implementation will result in the development of SIL algorithms and backbone using Motor Industry Software Reliability Association (MISRA) coding rules and right tooling: static code analysis, unit testing, coverage tests. The certification of the complete iMUGS systems is not the aim of the project and some existing algorithms will not be rewritten to cover SIL execution or will run on non-SIL platform (typically GPU boards). The safety analysis will be enforced to support future developments, thus a major step forward to existing technologies. iMUGS publish subscribe middleware associated with a Data Model will facilitate algorithms integration and ensure the system modularity and scalability. The backbone design is based on a plugin approach, algorithms are included in containers which are hosted and executed by iMUGS backbone. The data Model enables an abstraction of the Sensors data and the platform data, for the autonomy functions. 2. Military operational scenarios taking into account the use of autonomous systems and manned-unmanned teaming [ref to oo2 and to7] At the moment there are a lot of discussions and ideas about what can be done with autonomous and unmanned ground systems in a military context. But there is no common understanding within the participating member states or in the EU about possible ways to deploy these systems, or to engage with such systems, or how military operational scenarios with these systems may look like. Furthermore, there are also reservations and constraints regarding the usage of autonomous and unmanned systems, which have to be considered. 70 Grant Agreement number: EDIDP-MUGS-2019-002-iMUGS ANNEX 1 iMUGS project will develop and define in a first step bases for military operational scenarios together with the representative of the participating member states, taking, where possible, national specifics, wishes or limits into account. Based on this, basic military operational scenarios will then be defined and evaluated with the help of high-end simulation and demonstrations. At the end of this project these scenarios will be the base for the further engagements of unmanned ground systems, alone or together with other manned or unmanned systems, or also with one or more soldiers. 3. Detection and resilience to cyberthreat [ref to oo3 and to3] While there is a lot of research into cyber-attack detection on vehicular platforms, there is currently no market product available to address this threat. Most of the research in this area are focusing on a one- dimensional attack vector or otherwise does not consider the widest scope of potential cyber threats. None of this research has considered the idea of implementing an automated response to detection of attacks. The iMUGS Cyber Defence System (CDS) strives to fill these gaps, acting as an intrusion detection platform capable of monitoring for evidence of a compromise or an attack from cyber, physical exploitation, and electromagnetic threat vectors. In the event of a potential attack, the system will provide an appropriate mitigating response to secure or contain the threat autonomously, ensuring resiliency of the platform while in a military operational environment. 4. A certifiable control station commanding several ugs and uas [ref to to6] iMUGS project aims to develop an UGS Control Station (CS) capable of commanding several UGS types and UAVs from a centralized C2 position, also with UGS autonomy and swarming capabilities, thus maximizing operational efficiency and coordination and minimizing operator workload. Future operations will combine UGS and UAS in support of forces and iMUGS CS innovative approach will enable this kind of joint operations. Taking into account the end-user recommendations, iMUGS CS will be designed to be ready for a future integration of certifiable MALE UAS to the CS, and thus ready by its architecture and design able to meet strict airworthiness certification requirements like DO-178C/ED-12C and able to operate in non-segregated European skies. iMUGS C2 station will be unique in that operational capability. Also, the CS is innovative in being reconfigurable to control any generic unmanned vehicle. A standard based open architecture and reconfigurable ‘vehicle profile’ based CS will allow integration of future unmanned systems (land-air-sea) through software updates only, to rapidly introduce into service new unmanned systems, reduce future acquisition and integration/logistics/support costs for military and allow flexible and innovative approaches for future UGV manufacturers. iMUGS will allow a reconfigurable human interface in both static and NGVA compatible vehicular installations. 5. Learning and planning for autonomous missions with difficult environments and swarming capabilities [ref to oo1, to5, oo5 and oo6] a. Planning and scheduling for autonomous missions within difficult environments Autonomous system architectures are challenging when integrating mobility and mission planning, especially because some mission data (terrain, objectives, available resources) are known offline and others are acquired on-line. Still, some uncertainty remains at execution time. The planning problem involves technical actions (measurements, communications, etc.) and operational actions to realize on some specific 24 terrain areas or along the navigation plan . Actions must be executed according to timing and resources constraints despite situation awareness and objectives updates. In modern autonomous architectures, planning and scheduling is performed on the fly, responding to an operator demand (mission update), terrain obstacles, or using free space discovery. To achieve high operational efficiency, planning and scheduling must be solved just in time when state-of-the-art solvers may involve heavy processing loads. iMUGS innovative approach is to guide the problem solving with machine learning techniques. iMUGS approach combines a Constraint Programming (CP) method with novel machine learning techniques. CP provides a powerful baseline to model and solve combinatorial and constraint satisfaction problems 24 The Ripsaw UGV, https://special-ops.org/11986/ripsaw-ugv/, retrieved 16th May 2019 71 Grant Agreement number: EDIDP-MUGS-2019-002-iMUGS ANNEX 1 25 26 (CSP). This approach has several applications for real-world autonomous system in space , aeronautics 27 and defence . Planning problems are dealing with graphs representing manoeuvres or off-road navigation. Graph convolutional neural networks (GCNNs), a recent variant for learning complex patterns in graph data, will be used to make decisions and to solve planning problems. Using feedback from the neural network, a model-based planner and scheduler can efficiently solve new problem instances. One novel advantage is to accelerate drastically the processing by guiding the search algorithm. Another advantage is to consider problem variables with uncertainties either due to temporal, resources or spatial considerations. Learning from terrain data can be performed offline, such that the knowledge acquired can be used on-line to accelerate the on-board planner. The planning and scheduling are considered at different levels of mission and mobility. On one side, it can deal with coordination and swarming constraints. On the other side, it can deal with short term navigability constraints such as terrain obstacles. iMUGS will provide an adaptive problem scale control to address high level mission goals as well as short terms mission contingencies. b. Local and global swarming experimentation Swarm intelligence is a ground-breaking concept unseen on the battlefield. Demonstrations and applications have been mainly confined to simulation or tightly controlled conditions in the case of physical platforms28 29, especially for ground vehicles. The main challenge today is to create robust and useful controllers for swarms of real robots that need to be safety critical in realistic conditions. iMUGS project aims to work on local and global swarming for practical purposes. Local swarming will be realized using suitable parametrized robot controllers, just as with traditional autonomous systems. Global swarming will be realised using a new approach of exploiting an interacting group of autonomous robots. The first challenge of swarming is to subdivide the problem statement into real-time until non-real- time requirements. Secondly, a hierarchic, type ‘level of detail’ or resolution world model approach, aims to subdivide the problem into parallel datasets that can be outsourced to computational power on each level of the architecture and solutions are progressively refined. Low resolution and hard-real-time problems are solved on the edge, near-real-time solutions using larger sections of available world information are solved on massively parallel computational power available in the fog, other non-real-time calculations are handled in the cloud. The outputs of these development will be used to provide new requirements for supporting solutions and human provided solution fitness. Although the project focuses on ground-based systems, the work and results will provide important insight regarding autonomous air and sea vehicles as well. 6. Network agnostic concept: transparent access to c2 and ugv through communication network [ref to oo4 and to4] Currently, UGS have dedicated communication links devoted to the teleoperation from a Control Station. These communication links are not integrated with other networks, which increases the number of communication equipment and systems required. In addition, information exchange between different systems is not typically supported, which is a major limitation in modern warfare. iMUGS project aims to combine various tactical and commercial communication technologies into a single entity allowing the users (vehicles & troops) to connect easily and transparently to the services through a unique IP network. The same single solution shall support both manned and unmanned operations with ground and aerial vehicles e.g. UAVs, which makes maintenance & support operations easier and enable seamless information exchange between different applications. The use of the communication network in a transparent way will make the UGV and the C2 systems network 25 Roldán Gómez, Juan Jesús (2018). Adaptive and Immersive Interfaces to Improve Situational Awareness in Multi-Robot Missions. Doctoral Thesis, E.T.S.I. Industriales (UPM). https://doi.org/10.20868/UPM.thesis.52353 & George Leu, Jiangjun Tang (2019). Survivable Networks via UAV Swarms Guided by Decentralized Real-Time Evolutionary Computation 26 The MQ-9 Reaper UAV, www.airforce-technology.com/projects/predator-uav/, retrieved 16/05/19 9 27 The Dragon Runner UGV, https://qinetiq-na.com/products/unmanned-systems/dragon-runner/, retrieved 16/05/19 28 L. Bayindir, A review of swarm robotics tasks, Neurocomputing 172, 292-321 (2016) 29 “Gremlins are coming: DARPA enters Phase III of its UAV programme”, by Talal Husseini (July 2018) https://www.army-technology.com/features/gremlins-darpa-uav-programme/, retrieved 16th May 2019 72 Grant Agreement number: EDIDP-MUGS-2019-002-iMUGS ANNEX 1 agnostic. This feature will facilitate the adoption of new communication network technologies by iMUGS components including the vehicle, the payloads and the C2 and end-users. iMUGS Communication Network will be developed with a focus on interoperability and standards, minimizing barriers related with regulation, allowing EU member states or any customer worldwide to integrate directly the solution into their defence systems. The network agnostic concept would enable the application of cutting-edge communication technologies from the civil domain to the military domain in a future. 7. Novel tactical c2isr software to make imugs interoperable with c4isr systems [ref to to6] Current UGV Control Stations are standalone systems not integrated with Tactical C2 Systems nor Joint ISR networks. This limits Tactical Commander from exploiting the full capabilities of UGS in military operations. STANAG 4559 CSD has so far been applied to integrated Medium-Altitude Long- Endurance (MALE) and High-Altitude Long-Endurance (HALE) UAS GCS in JISR networks, it will be quite innovative to apply it to UGS. The iMUGS project aims to develop a Tactical C2ISR software that will be used by the tactical commander for conducting the mission assigned to the dismounted soldiers and UGS and at the same time being interoperable with C2 systems of lateral and higher echelons. The Tactical C2ISR system will provide the commander a complete integrated view of the battlefield including dismounted soldiers and UGS fleet. Within iMUGS project, the focus on the Tactical C2ISR is mainly in the conduct capability of the mission. iMUGS Tactical C2ISR could be extended to provide additional functionality for the planning phase of the mission. The Tactical C2ISR will make iMUGS fully interoperable with JISR networks through a STANAG 4559 Coalition Shared Database, enabling iMUGS C2 to be used by any NATO country. Patenting A patent application process will be introduced based on needs arising during the project. In the defence industry technology is typically classified information. For the same reason, defending a patent may be difficult. However, if there are commercial applications for the solutions developed, IPR protection measures will be applied. 6.2.2. POTENTIAL SPIN-OFFS OF THE TECHNOLOGIES Due to the very demanding requirements of iMUGS and -in particular- the interoperability requirements, the technologies developed within the project have a tangible potential for spin-offs, i.e. to be integrated into other defence systems/capabilities or even into mission critical civil systems. iMUGS Control Station technologies supporting UGS and ready to integrate UAS could be applied to any project where an unmanned system needs to be controlled, remotely or autonomously, with real time safety criticality requirements, in both civil and military applications. A derivative of iMUGS control station, may be used in defence operations or logistics systems using UAS and UGS. Furthermore, the trend in the defence sector for fleet management of unmanned systems (ref. STANAG 4817 currently in development) will be influenced by the iMUGS project (contribution to requirements and best practices), bringing Europe back at the forefront of unmanned systems technologies. On the civilian market, use of unmanned systems in public service for distribution and transportation services and municipal management can be controlled with an iMUGS combined control centre. iMUGS Communications network concept is network agonist and could be used for other defence and civil applications, C4I systems in general, security/safety-critical applications and more specific applications like for example unattended sensor networks. iMUGS Network technologies can also be applied for EU civil-military operations requesting a combination of communication means and/or enhanced security. In addition to network-based approach, the solution also supports local deployment, which allows providing the connectivity and services locally, for example, for rescue missions in rural areas. iMUGS Cyber Defence System (CDS) can be fully commercialised for any ground-based and maritime autonomous military system. 73 Grant Agreement number: EDIDP-MUGS-2019-002-iMUGS ANNEX 1 In addition, part of the technology could be easily adapted to the cyber defence of space systems and other autonomy applications in the civilian sector (e.g. automotive, mining, energy, etc.) Some of the data processing algorithms can be applied to cyber defence of conventional IT systems as well. iMUGS autonomy Framework is designed in a generic way, based on existing standards and fully adaptable with various type of UGVs for a large range of applications (military and civil applications: logistics, transportations or industrial civil applications as mining industry, construction sites...). Also, Autonomy functions can be turned into driving assistance functions for manned platforms (main battle tank, infantry fighting vehicles) by providing either proximal area awareness or by helping the driver in a fine manoeuvre over a short-term horizon. They can also be used to develop an infrastructure protection and inspection system by extending the robotic coordination to infrastructure sensors. Planning and scheduling, but also mobility planning can be extended to include both human and infrastructure sensor activities. iMUGS swarming functions could be used in other defence capabilities in the long run but also for civil applications (maritime, search and rescue, security, logistics for heavy charge, …). Robots swarming is an emerging domain that raises a large panel of activities as it is expending the capability of a unique robot. 6.2.3. CONTRIBUTION TO INCREASING EFFICIENCY ACROSS THE LIFE CYCLE iMUGS will contribute to a common ground for technology development among European Industry. Within iMUGS, new combinations of technologies and systems, and their utilisation doctrines will be implemented, tested and assessed. The concept (see §7.1.2.2) fosters by essence the efficiency across the lifecycle. The project will enable a variety of new ways of utilizing UGVs supporting future innovations. The Autonomy Framework will be based on existing standards be fully adaptable with various type of UGVs. Works on MUM-T will provide an outlook of future developments within a kind of roadmap indicating the main interests at the moment and what might be helpful and necessary for future innovations. The integrated and secure communications combining commercial technologies together with tactical communications solutions in the same network will ease future uses of the C2 system by enhancing scalability and flexibility. In addition, the communication solution can be deployed in multiple applications minimizing the need for multiple dedicated non-interoperable systems and equipment. Moreover, the UGS Command Post is fully interoperable with recognized standards for C2 systems and JISR networks to facilitates its integration It will greatly reduce the initial investment cost as well as the maintenance cost as there is no need for separate systems for each actual and future application. The deployment of SDR technology will allow continuous development and system level maintenance throughout the entire life cycle of the product to keep the system up to date with the evolving warfare and operations. The cyber defence system implements graceful degradation which allows the system to continue operations in a degraded state and prevents complete mission failure or disruption of operations. This will allow greater efficiency for the duration of system life for operations in the presence of attackers compromising portions of the system or even noncritical systems. 6.3. Contribution to the competitiveness and growth of defence undertakings in the Union 6.3.1. Contribution to the competitiveness and growth Before developing the contribution of the iMUGS’ outcomes to competitiveness and growth, it is worth displaying the consortium’s vision on the midterm roadmap. This roadmap is coherent with the targeted TRL landscape (§6.1.2.3) at the end of the project and the consortium, which masters all the dimensions of UGS systems, prefigures a future European added-value chain and industrial sector. The contribution of iMUGS to competitiveness of the EDTIB relies on 4 key outcomes of the project:  A standardized architecture  Enabling integration to unmanned ground platforms and adaptation to current manned vehicles  Standardized interfaces between systems and features  Scalability and modularity  Development and use of European based technologies 74 Grant Agreement number: EDIDP-MUGS-2019-002-iMUGS ANNEX 1 Figure: iMUGS and beyond roadmap In turn, these 4 outcomes will foster the admission of newcomers – particularly SMEs – into the defence ecosystem, thus enhancing competition and innovation throughout the entire value chain. This consortium mastering all the critical dimensions of UGS prefigures a future European added-value chain and industrial sector. Competitiveness and growth thanks to standardization (architecture, interfaces) Many international surveys show the contribution of standards to the competitiveness of undertakings and thus to their sustainability, turnover, job creation, etc. Among others, a survey by the ISO (Economic benefits of standards, 2014) highlighted three compelling findings which are totally relevant in the iMUGS context: 1. Streamlining internal operations: this first key benefit impacts more the cost competitiveness of the players concerned Figure: iMUGS component and providers 2. Innovating and scaling up operations: this key benefit will pave the way to fill the innovation and technology gap between the EDTIB and its US and Chinese counterparts 3. Creating and entering new markets: this key benefit will impact all the players of the value chain sketched above, i.e. many players of the EDTIB Competitiveness and growth thanks to scalability and modularity Scalability and modularity of defence systems will be leveraged by the solutions developed in the frame of iMUGS. The industrial adopters of these solutions will gain competitiveness on the international markets (tenders, Request for Information (RFI), Request for Proposals (RFP)…) for 2 reasons:  modularity and scalability are of high value to the end users, including national defence procurement authorities which anticipate streamlined procurement processes  this valuable feature is obtained without additional costs; in the contrary, the costs remain under control thanks to the standardisation mentioned above 6.3.2. Market opportunities 75 Grant Agreement number: EDIDP-MUGS-2019-002-iMUGS ANNEX 1 The robotic and UAV market in 2018 is 30 valued at $116 bn by HIS market and is expected to reach $210 bn in 2022 for a CAGR of 20%. The sub-market of UGV is valued $2.35bn in 2018 and will have a CAGR of 15% for the forecast period. 31 The International Federation of Robotics estimated the defence robot market value at $902 m in 2017 and will continue to become a well- established technology as more and more units are sold. Moreover, 1,300 UGVs have been installed worldwide in 2017 representing an increase of 33% Figure 4: UGV 10-year sales forecast (2017- compared to 2016. The possibilities of companies 26) by supplier (Source HIS market) from the EU, to become a part of the market outside the EU, depend strongly on international cooperation on an industrial and political level. As shown on the following figure, about 75% of the market share are not identified in terms of suppliers. The addressable markets that have currently been identified within the European Union are as follows: Netherlands, Norway, Germany, United Kingdom, France, Poland, Spain, Italy, Czech Republic, Finland, Sweden, Denmark, Greece. The total addressable market in these countries is a total of €722.2M. Figure 5: UGV 10-year total sale forecast by end-user country in USD m (Source HIS market 2017) Defence robots aim to enhance armies’ capabilities while protecting soldiers or replacing them on dangerous operations. Autonomous vehicles will slowly take over the battlefield and UGS will contribute to 32 military superiority by giving troops an advantage at the ground level. Autonomy of UGV is today still limited to simple functions. But UGS market opportunities will increase with new development alloying new and efficient uses (swarming, etc.) and a growing understanding of these systems. Based on this, also the market opportunities for the manned platforms for the control of the iMUGS and the vehicles and systems to engage together with iMUGS will increase. In Europe,  the French army is looking forward to use UGVs for the future battlefield with its Scorpion programme with a planned procurement of around 100 vehicles.  At short term (end of 2020) France will deploy Mule UGVs in external operations.  At long term (operational in 2035) Germany and France plan to have built Mobile Ground Control Station (MGCS) that will include manned and unmanned vehicles operated in teaming conditions.  In March 2019, Poland revealed its new Tank Destroyer Programme, where UGS´s can also take part in. 30 “Follow the leader: US Army unmanned ground vehicle programmes”, JANE’s by HIS market, https://www.janes.com/images/assets/925/87925/Follow_the_leader_US_Army_unmanned_ground_vehicle_programmes.pdf 31 Executive Summary World Robotics 2018 Service Robots (2019), https://ifr.org/downloads/press2018/Executive_Summary_WR_Service_Robots_2018.pdf 32 “Remote defence: ground systems: Paving the way for autonomy in land systems”, EDA, https://eda.europa.eu/webzine/issue16/cover-story/paving-the-way-for-autonomy-in-land-systems 76 Grant Agreement number: EDIDP-MUGS-2019-002-iMUGS ANNEX 1  The United Kingdom has also announced the Platoon Robotics programme planning to expand robotics to platoon sized units within their military.  The Netherlands also has a Robotics and Autonomous Systems (RAS) Unit within the 13th Light Brigade of the Royal Netherlands Army. The main emphasis of these programmes is on supply, logistics and Casualty Evacuation (CASEVAC) support operations that can be conducted via UGVs providing more safety for the human operator. The aforementioned armed forces are testing the vehicles alongside existing force structures and in addition developing doctrines involving robotics in swarm configurations and in solo operations. Outside the union,  the United States has the agenda to comprehensively integrate robotic systems into every branch of 33 its Armed Forces by 2025 .  The Russian Federation also has multiple Unmanned Ground Systems for military application, such 34 as the Uran-9, which has been deployed to combat operations in Syria .  High-level support and generous funding for robotics and unmanned systems R&D have created a myriad of research institutes within China’s defense industry and numerous universities, both civilian and military. Rapid deployments of increasingly capable systems present challenges to U.S. military forces operating in the Asia-Pacific region, particularly as U.S. defence planners implement 35 the Third Offset strategy. Inside and outside the EU, UGVs are now mainly used for trials and tests. Military engagements of UGVs, independently if these engagements are for training purposes or if these are real military engagements, the number will be not of significance in the next future. The producers of the most prominent UGVs for both the military and commercial market within the European Union fall in to small and mid-sized categories: MILREM THeMIS, DOK-ING MV-4, Shark Robotics Colossus. Foreign markets are also very proactive in the development of Unmanned Ground Systems, the most prominent of these are: Rheinmetall (Canada) Mission Master, Howe&Howe Thremite, HDT Hunter WOLF, Polaris MRZR X and the Lockheed Martin 36 Fire-Ox. In July 2019, ST Engineering presented an unmanned teaming (UGS) between an autonomous Next generation Armoured Fighting Vehicle (HGAFV), a Probot UGV and a UAV. The same year, 37 Rheinmetall Defence presented a demonstrator of its Mission Master UGV for surveillance, protection, etc. uses. ECA Group manufactures a Multi-missions UGV for Inspection, IEDD/EOD and CBRN and Leonardo sells its TRP-2 Combat a small, light, tracked UGV platform for use in tactical situations where the human presence is not advisable. MILREM has developed several UGVs as the THeMIS (Tracked Hybrid Modular Infantry System) a multi-mission UGV with the Estonian Ministry of Defence support or 38 the Titan Unmanned Ground Vehicle (UGV) in collaboration with QinetiQ North America. MILREM Robotics is also collaborating with ST Engineering since 2017 to increase the ability of the THeMIS to 39 operate under beyond-visual-line-of-sight (BVLOS) conditions . A live fire exercise was performed in 2019. 33 “ARMY POISED TO TRANSFORM GROUND ROBOTICS INDUSTRY”, DEFENSE NEWS BY JEN JUDSON , APRIL 2017, HTTPS://WWW.DEFENSENEWS.COM/SMR/UNMANNED-UNLEASHED/2017/04/12/ARMY- POISED-TO-TRANSFORM-GROUND-ROBOTICS-INDUSTRY/ 34 Russia confirms its armed robot tank was in Syria, c4isrnet, by Kelsey D. Atherton, May 2018,, https://www.c4isrnet.com/unmanned/2018/05/07/russia-confirms-its-armed-robot-tank-was-in-syria 35 „China’s Industrial and Military Robotics Development”, U.S-China economic & security review commission, 2016 https://www.uscc.gov/sites/default/files/Research/DGI_China's%20Industrial%20and%20Military%20Robotics%20Develop ment.pdf 36 “ST Engineering shows off unmanned teaming with NGAFV”, Shephard Media, July 2019 https://www.shephardmedia.com/news/uv-online/st-engineering-shows-unmanned-teaming- ngafv/?dm_i=4GWN,MFOK,2FZCP7,2MVCV,1 37 Rheinmetall-defence website, “Rheinmetall Mission Master – The ultimate Unmanned Ground Vehicle” https://www.rheinmetall-defence.com/en/rheinmetall_defence/systems_and_products/unbemannte_fahrzeuge/index.php 38 Army-technology website, Titan Unmanned Ground Vehicle (UGV) https://www.army-technology.com/projects/titan-unmanned-ground-vehicle-ugv/ 39 Army technology, „Milrem and ST Engineering demonstrate BVLOS armed combat UGV“, May 2019 https://www.army-technology.com/news/MILREM-armed-combat-ugv/ 77 Grant Agreement number: EDIDP-MUGS-2019-002-iMUGS ANNEX 1 6.3.3. Contribution to increasing efficiency across the life cycle The outcomes of iMUGS will support future military developments, collaborations and more effective cooperation between Member States armed forces on the battlefield. iMUGS Control Station could be potentially used with any UXS system with safety and certification requirements, as is expected for a broad spectrum of UXS Defence applications, and also for dual use systems. iMUGS Tactical C2ISR and Autonomy Framework could be potentially used by any EU MS. Tactical C2ISR use prevalent interoperability standards and could be integrated with the EU MS Computer Information systems (CIS). iMUGS Autonomy Framework could be potentially used as technological basis to any UGV within industry domain (demining, construction, logistic in severe environment). Proposed as technological bricks, it will facilitate future cooperation ground vehicle systems project by providing a modular solution enabling a variety of new ways of utilizing UGVs. In general, standard interfaces based (S-DDS) open architecture implementation will allow reconfigurability and adaptability in both UGV vehicles and command/control infrastructure. Modular approach in design and software architecture will allow use of large-scale production in vehicle and CS units for cost reduction and to serve many niche functions with change of payload of software, some future functions which may not be foreseen today. Modular approach will also serve national needs and local payloads and software to be integrated into a cost-effective base platform. Flexibility in use will allow base units to serve many functions through its economic service life. The deployment of SDR-technology will make it possible to continuously develop and maintain the system throughout the entire life cycle. Communications: The deployment of SDR-technology will make it possible to continuously develop and maintain the system throughout the entire lifecycle. In addition, the same equipment can be used for several applications - voice or data, manned or unmanned, vehicles, troops etc. This is a major advantage and it reduces the maintenance cost over the lifecycle of the system. A common integrated control station will allow future unmanned systems integration into an existing CS structure by only updating software. Standardisation will directly improve acquisition, introduction to service and maintenance costs, incl. military operator training costs but also simplify future unmanned systems designs. The effort spent in proprietary and non-interoperable CS developments can be spared or directed to innovative UGV vehicle functionalities in future systems. 6.4. Contribution to the industrial autonomy of the European defence industry and to the security and defence interests of the union 6.4.1. Contribution to the industrial autonomy of the European defence industry and defence interests of the union Today, for the development of unmanned systems, whether they are autonomous or man-cooperative, European defence industry depends on third countries, which creates vulnerabilities at the geopolitical level (ITAR regulations…) and tactical level (potential trapdoors in software or operating systems):  Autonomy. EU and China have a good advance in the frame of autonomy capabilities for vehicles (civil or military); most available computers and tools for such applications are US or China based. An EU-sourced Autonomy Framework and Autonomy capability know-how is crucial regarding the future battlefield. iMUGS autonomy framework will be fully based on SW items (algorithms, simulation tools, data warehouse, Middleware and autonomy common services) developed within EU. The goal to get a fully European based autonomy framework (including HW items) will be reached in a future step of the project through the implementation of Kalray processing capabilities.  Communications. The deployment of European SDR waveforms will support both interoperability and joint operations between the member states as well as reduces the dependence to non-EU sources.  Cyber security. Securing autonomous systems is a critical capability for defence but also civil applications. Most secure processing platforms available today are not from the EU. An EU-sourced secure hardware platform and OS for cyber defence would ensure that systems built in Europe are more resilient to cyber-attacks (non-EU system could include trapdoors).  Swarming. An internal capability and know-how for swarming is crucial regarding the future battlefield. With ever increasing and faster access to data impossible to grasp by humans, automated methods to optimally use and exploit available data real-time, to make rational and optimal decisions, will become a key technology to the European defence in general. 78 Grant Agreement number: EDIDP-MUGS-2019-002-iMUGS ANNEX 1  C2. The availability of interoperability standards for unmanned systems that can be used without restrictions by EU countries, is key for the development of European C2 and C4I solutions integrating unmanned systems in the operations. iMUGS will use existing and in development standards and foster the development of emerging standards for UGVs C2.  Availability of electronic components. Most hardware comes from outside EU. iMUGS will not make Europe fully non-dependent but will limit their number and impact on design criticality. A preliminary EU critical technologies analysis has been undertaken in order to maximize iMUGS impact. Stating European non-dependency means that all fundamental aspects are covered by EU solutions. In the scope of Ground systems, iMUGS has identified key technologies (table below), where solutions availability is limited or absent at EU level. This is precisely one of the features of iMUGS to address all these aspects as shown in the table below. Table 3: iMUGS critical mapping table Technological Addres- Avai- Research sed in Impact lability Domains iMUGS Subsystem level Artificial New AI solutions specific to ground vehicles Intelligence Swarming Advancement of local and global swarming technologies Cyber security Novel systematic approach to cyber threat analysis and development of novel Cyber Defence Systems Manned New operational scenarios for the use of autonomous Unmanned unmanned systems Teaming Communication Advancement of network-centric architecture and unified network solution Command and Development of control system for simultaneous control of a Control heterogenous fleet of multi domain UxS (land-air-sea). Including innovative and flexible human factors design. Development of an interoperable C2 system. System level Standardisation Advancement of UGV system of systems architecture Integration Rapid integration of heterogenous technologies for multi- mission capable system; enhanced system level validation Legend: Availability: Green = Sources in EU; Yellow = Non-satisfactory performances in EU; Red = No EU existing source. Technology assessment is fully (green) or partially (yellow) addressed for most critical technologies. 79 Grant Agreement number: EDIDP-MUGS-2019-002-iMUGS ANNEX 1 6.4.2. Contribution to the security and defence interests of the Union iMUGS corresponds to the Capability Development Plan through the following aspects: Information superiority. The extensive data collecting performed by iMUGS will contribute to achieve battlefield information superiority, being fully interoperable with ISR networks. In particular:  The C2 solution will provide a tactical CIS combining different technologies into a single entity allowing the users to connect transparently and easily to the services through a unique IP network. The solution will also include a routine to ensure a quick and safe communication. Uses of recognized standards for C2 systems and JISR networks will increase the solution interoperability and integration into the MS armies’ systems.  The communication solution will use a highly flexible hybrid solution for radio communications, mapped to armed forces’ ability to use Radio Spectrum (RS) for military activities.  Autonomy sensors and perception algorithms will extend situational combat zone awareness. Ground combat capabilities. The project will have a positive impact on capacity preparations, protection, deployment and sustainability.  iMUGS is focusing on future use of unmanned and autonomous systems to accomplish missions with the least possible risk to soldiers. The use of autonomous robots will limit friendly soldier exposure, increasing force protection, facilitate permanent observation and the deployment of various sensors without endangering soldiers and increasing their workload.  The project will also contribute to swarming and manned-unmanned teaming future developments to face potential technically advanced adversaries. Enhanced logistics and medical supporting capabilities. The innovative and resilient architecture resulting from the project will contribute to improved logistic capabilities such as resupply and medical evacuation, including UAVs and UGVs.  The development of autonomous mobility software and intuitive manned-unmanned teaming solutions will alleviate soldier workload and simplify operation control by using the platform for carrying unit equipment during long dismounted tactical movements.  The interoperable C2 solution will speed up deployment by moving the platform quickly and affordably to the battlefield by using the pre-existing logistics systems.  The autonomous functions will help in collecting soldiers for rescue missions without exposing other soldiers or by limiting the number of soldiers necessary for the rescue mission. same point for logistic capabilities. Enabling capabilities for cyber resilient operations. The innovative solution for securing the platform from cyber threats will ensure continued, reliable and safe operation of highly advanced UGVs.  The holistic approach to detect cyber, electromagnetic and physical exploitation threats considers all angles from which an attack can originate.  Providing the ability to autonomously respond to threats enhances resilience during military operations.  Use of risk assessments for the supply chain and for the design of the subsystems helps identify and mitigate risks. Cross-domain capabilities. The project addresses the real and existing need for EU to develop capability and know-how in the area of autonomous unmanned vehicles on the battlefield by merging defence and civil EU expertise. It builds cross-domain capabilities contributing to achieving EU’s ambition through:  Autonomous and automated guidance, navigation and control (GNC).  Decision-making techniques: Extensively applying artificial intelligence to UGV, developing efficient multi-robot control through swarm intelligence. During iMUGS project, future technology development will be anticipated and some solutions to support them will be proposed as vehicle to vehicle communication to support swarming and MUMT implementations. 80 Grant Agreement number: EDIDP-MUGS-2019-002-iMUGS ANNEX 1 The development of unmanned systems is a R&T priority worldwide, both in the civil and the military domains, and a large proportion of unmanned systems critical technologies are shared among both domains. The availability of EU core technologies for defence unmanned systems are key to the autonomy in defence of EU but can also have a multiplier effect with the applicability of them to the civil domain, enabling EU to be major player in the growing unmanned business. No national policy stands against the solutions developed within the project nor their use cases. The project outcome will indeed help European forces improve their situation awareness and their efficiency while reducing the risk of loss of human lives. 6.5. The proportion of the overall budget of the action to be allocated to SMEs More than 40% of the overall budget of the action is allocated to the SMEs established in the European Union. More than 60% of the budget of the action allocated to the SME’s is allocated to SMEs which are established in Member States other than those where the in the consortium which are not SMEs are established (Cross Border SMEs). Figure: Allocation of the budget to SMEs and participating project Member States 81 Grant Agreement number: EDIDP-MUGS-2019-002-iMUGS ANNEX 1 The added value of each SMEs involved in iMUGS consortium are provided in the following table: Table 4: iMUGS SMEs added value N° SME Industrial or technological added value 1.1 MILREM MILREM AS focuses on designing and producing remotely controlled unmanned ground vehicles utilizing hybrid power; combining combustion engine with military-logistically available fuels with electric propulsion. MILREM has an experience as payload integrator and will provide its mid-size unmanned platform for iMUGS demonstrations. MILREM also has the experience and knowhow to manage the system architecture and integration and the overall coordination of the iMUGS project with partners. 1.3 GTCT GTCT focuses on cyber range and security solutions. GTCT will deliver a comprehensive plan to secure the iMUGS system. The centrepiece of this is the development of the cyber defence system (CDS), which is a novel approach that seeks to actively detect and provide recommendations to respond to live cyber- attacks. 1.11 (Un)Manned (Un)Manned develops highly reliable software and systems for aerospace and defence sectors, for manned and unmanned platforms, with a particular expertise in certifiable avionics development. Its unique Sol technology automates airworthiness certification of safety critical embedded computer systems to DO-178C and DO-254 norms. In the iMUGS project, its technology will allow standardisation in the military sectors and strengthen European Defence industry with the most recent methods of safety critical system development. 1.13 dotOcean DotOcean is active in autonomous system design since 2012. DotOcean systems, as AES256-E2EE interfaced, hence safely controllable world-wide. Systems utilize digital twin technology, merging multi-system situational awareness and mapping information to provide solutions in complex problems on several complexity levels. Approach enables to operate fleets of autonomous vehicles and to develop and deploy algorithms for swarm and collaborative behaviour. 3.1 Rantelon Rantelon is a subcontractor to MILREM. Rantelon specializes in design and engineering of radio frequency electronic equipment. Rantelon will integrate and demonstrate Electronic Warfare (EW) payloads during the iMUGS project. 3.2 DA-Design DA-Design is a subcontractor to Bittium Wireless Ltd within the communications work share and focuses on microwave technologies and waveform implementation. The work shall contribute to vehicle-to-vehicle communication solution. Together with Bittium, DA-Design shall provide the project an innovative solution that not only improves the system functionality but creates a novel capability for V2V communications. 3.3 AVQ AVQ is an independent consulting company with a focus on functional safety and system safety of complex technical systems. Company is subcontractor to Diehl Defence for the system safety development for the autonomy work share. 3.5 Threod Threod Systems produces unmanned aircraft systems and sub-systems for intelligence collection and surveillance tasks. In the iMUGS project, Threod Systems Systems will provide the tethered UAV and will contribute into the development of the one hand-controller. 82 Grant Agreement number: EDIDP-MUGS-2019-002-iMUGS ANNEX 1 6.6. Contribution to the further integration of the European defence industry iMUGS project has strong support within the members of the Permanent Structured Cooperation in the European Union. Participating project members for the PESCO for Integrated Unmanned Ground System project (UGS) are Germany, France, Spain, Belgium, Finland, Latvia and Estonia. A Letter of Intent of these seven MS is provided as an Appendix of the application (Ref to file “iMUGS Section 3.4 Letter of Intent”).  These MS have made an agreement for the common requirements for the equipment and the functionalities to be developed during the iMUGS project.  These MS have agreed to co-finance the system prototyping based on national industry share for the EDIDP-MUGS-2019 action. This initial agreement includes commitment through joint procurement of the equipment. In the event of an action awarded with EDIDP grant, Member States will appoint a project manager. These seven co-financing and jointly procuring members represent more than 60% of the total contribution to European Defence Fund budget.  These MS will actively participate to the workshops for operational scenarios development and will furthermore participate to the testing (d) with in-kind contributions in a form of testing areas and facilities when feasible. Further decisions for procurement will be made during and after the qualification (e) and certification (f) activities of the tested and demonstrated functionalities. Figure: Wide interest and potential for further integration of European defence industry The PESCO UGS project has furthermore four observing participants adding to the European wide interest; The Netherlands, Czech Republic, Hungary and Poland, representing additional 10% of the total contribution to European Defence Fund budget. In 2017, 25 Member States established PESCO to jointly invest in shared capability projects and enhance operational readiness and contribution of their armed forces. Standards are key enablers of interoperability and further integration of the European defence industry. The architecture developed during the project has the potential to become a European standard. Member States cooperation with the Industry will in its turn support optimizing the available resources and improve their overall effectiveness, with a view to the most demanding missions and operations and contributing to the fulfilment of the Union level of ambition. 83 Koostatud:21.10.2025 16:44:45 Konto väljavõte Organisatsioon: KAITSEMINISTEERIUM E-konto number: 2800082844 EUR tulukonto KV10415,10230-10236 Kaitsevägi K600 Töökood Kuupäev Dokumendi Maksja/saaja Maksja/saaja konto Maksja/saaja nimi Viitenumber Summa Kande Kande Summa number regsitrikood kande valuuta valuuta konto valuutas kurss valuutas Panga arhiveerimiskood Eelarve Selgitus 20230213000289459119 13.02.2023 2390506450 DE59700202700655468722 EUROPEAN 5 292.50 EUR 1.0000000 5 292.50 COMMISSION RMI16976591 2370025781 24-JAN-2023/10883825 Periood 13.02.2023 - 13.02.2023 Perioodi algjääk: 3 119 128.18 Perioodi kreeditkäive: 0.00 Perioodi deebetkäive: 5 292.50 Perioodi lõppjääk: 3 124 420.68 Hetkeseisuga 21.10.2025 kell 16:44 Vabad vahendid: 5 712 965.90 Reserveeritud:: 0.00 Kinnitan: Kinnitan: asutuse juht juhataja raamatupidamise eest vastutav isik peaspetsialist pitsat pitsat