Grįžti į sąrašą

KONSULTACINIŲ PASLAUGŲ NAUJOS KARTOS BEPILOČIŲ ORLAIVIŲ INFORMACINĖS SISTEMOS PRODUKTO SPECIFIKACIJOMS IR VYSTYMUI PIRKIMO TECHNINĖ SPECIFIKACIJA (PROJEKTAS)

Išanalizuota

Akcinė bendrovė „Oro navigacija“ (PV)

Rinkos konsultacijaCPV: 72223000 - Informacijos technologijos reikalavimų peržiūros paslaugos
ID: 72614882026-04-03 14:28
Atidaryti CVP IS

Aprašymas

Perkamos konsultacinės paslaugos, skirtos naujos kartos bepiločių orlaivių informacinės sistemos produkto specifikacijoms ir vystymui. Paslaugos apima sistemos funkcionalumo architektūros išgryninimą, kaštų ir naudos analizės atlikimą skirtingiems įgyvendinimo scenarijams bei produkto vystymo kelrodžio parengimą. Kuriama sistema turi įgyvendinti vieno langelio principą BO operatoriams ir institucijoms, ypatingą dėmesį skiriant kooperatyvių ir nekooperatyvių BO atpažinimui bei oro erdvės pažeidimų valdymui.

Kvalifikaciniai reikalavimai

  • 1Tiekėjas turi turėti dokumentuotą patirtį ne mažiau kaip 2 (dviejų) sudėtingų skaitmeninių platformų ar valdymo sistemų kūrimo ar konsultacinių projektų per paskutinius 5 metus. Projektai gali būti iš oro erdvės valdymo (UTM / U-Space / ATM), mobilumo, transporto, logistikos, energetikos, telekomunikacijų ar kitų reguliuojamų sektorių, kuriuose keliami aukšti reikalavimai realaus laiko duomenų apdorojimui, saugumui ir reguliacinei atitikčiai. Projektų aprašymai ir referencijos pateikiamos pasiūlyme.
  • 2Tiekėjas turi turėti patirtį rengiant IT sistemų kaštų ir naudos analizes (CBA) ir TCO vertinimus, įskaitant pirkti / pritaikyti / vystyti scenarijų palyginimą. Pasiūlyme pateikiamas bent vienas analogiško darbo pavyzdys.
  • 3Tiekėjo komandoje turi dalyvauti ekspertas, išmanantis ES U-Space reglamentų paketą (2021/664, 2021/665, 2021/666) arba gebantis pagrįsti analogiškų reguliuojamų sektorių sprendimų taikymą UTM kontekstui. Ekspertinės žinios apie MSDF, aviacijos stebėjimo duomenų šaltinius (ADS-B, Remote ID, radaras) ir kooperatyvių / nekooperatyvių BO atpažinimo sistemas laikomos privalumu.
  • 4Tiekėjas privalo skirti projekto vadovą, atsakingą už Paslaugų teikimo organizavimą, kokybės užtikrinimą ir komunikaciją su Pirkėju. Projekto vadovo kandidatūra turi būti pateikta ir suderinta su Pirkėju ne vėliau kaip per 5 darbo dienas nuo Sutarties įsigaliojimo.
  • 5Tiekėjo komandoje turi dalyvauti: (a) bent vienas ekspertas, turintis patirties integruojant sudėtingas reguliuojamas sistemas; patirtis aviacijoje ir bepiločių orlaivių eismo valdymo sistemose yra privalumas (b) bent vienas IT / sistemų architektūros ekspertas, turintis patirties kuriant ar projektuojant sudėtingas realaus laiko duomenų platformas arba kritinių paslaugų sistemas – patirtis gali būti įgyta mobilumo, transporto, logistikos, energetikos, telekomunikacijų ar kitose panašiose srityse; patirtis tiesiogiai aviacijos sektoriuje yra privalumas; (c) bent vienas ekspertas, išmanantis stebėjimo sistemų duomenų srautus ir (arba) daiktų interneto (IoT) / mišrių duomenų šaltinių integravimą; patirtis konkrečiai su BO atpažinimo technologijomis laikoma privalumu, tačiau nėra privaloma sąlyga; (d) bent vienas finansų ar verslo analizės ekspertas, turintis patirties rengiant IT sistemų kaštų ir naudos analizes (CBA) bei visų nuosavybės išlaidų (Total Cost of Ownership) vertinimus.

Techniniai reikalavimai

Pateikiami dokumentai

  • 1Savaitinės pažangos ataskaitos (el. paštu, laisva forma, ne ilgesnės kaip 1 puslapis);
  • 2Kiekvienos workshop sesijos protokolas – per 3 darbo dienas po sesijos;
  • 3Reikalavimų rinkinys (D-01) – struktūrizuotas dokumentas, suderintas su Pirkėju – PDF ir DOCX formato, iki 6 savaitės;
  • 4Kaštų ir naudos analizės ataskaita (D-02) su scenarijų palyginimu, jautrumo analize ir rekomendacija – PDF ir DOCX formato, iki 11 savaitės;
  • 5Sistemos architektūros aprašas – ADD (D-03), įskaitant BO klasifikavimo, pažeidimų aptikimo ir vieno langelio modulių architektūrą, suderintas su CBA rekomendacija – iki 14 savaitės;
  • 6Funkcijų žemėlapis (Feature Map) ir integracinės architektūros schema (D-04, D-05) – iki 14 savaitės;
  • 7Produkto vystymo kelrodis (Product Roadmap) ir rizikų registras (D-06) – iki 17 savaitės;
  • 8Galutinė pristatymo prezentacija (D-07) – PowerPoint ir PDF formatu, iki 17 savaitės.

Garantiniai įsipareigojimai

  • 1Suteiktoms Paslaugoms ir parengtiems Rezultatams turi būti suteikta 12 (dvylikos) mėnesių garantija.
  • 2Garantijos terminas skaičiuojamas nuo galutinio Paslaugų perdavimo–priėmimo akto pasirašymo dienos.
  • 3Garantijos laikotarpiu Tiekėjas privalo savo jėgomis ir lėšomis ištaisyti Pirkėjo nustatytus esminius Rezultatų trūkumus, netikslumus ar neatitikimus šios specifikacijos reikalavimams per 10 (dešimt) darbo dienų nuo Pirkėjo pranešimo apie trūkumus išsiuntimo dienos, išskyrus tuos atvejus, kai trūkumai atsirado dėl Pirkėjo kaltės ar patvirtintų reikalavimų pasikeitimo.

Paslaugų grupės ir apimtys

  • 1Reikalavimų rinkimo ir validavimo paslaugos – funkcinių ir nefunkcinių sistemos reikalavimų nustatymas, sisteminimas ir suderinimas su Pirkėju.
  • 2Kaštų ir naudos analizės paslaugos (pirkti / pritaikyti / vystyti) – struktūrizuotas UTM sistemos įgyvendinimo scenarijų ekonominis ir strateginis vertinimas, paremtas patvirtintais reikalavimais;
  • 3Sistemos architektūros projektavimo paslaugos – UTM sistemos funkcionalumo architektūros, komponentų ir integracijų aprašo parengimas, įskaitant BO atpažinimo, klasifikavimo ir oro erdvės pažeidimų modulių architektūrą;
  • 4Produkto vystymo kelrodžio paslaugos – prioritetų ir etapų plano parengimas, paremto kaštų ir naudos analizės išvadomis.
  • 5Reikalavimų rinkimo ir validavimo paslaugos – ne mažiau kaip 4 konsultacinės sesijos ir suderintas reikalavimų rinkinys (iki 6 sav. nuo Sutarties įsigaliojimo);
  • 6Kaštų ir naudos analizės paslaugos – 1 analizės ataskaita su scenarijų palyginimu ir rekomendacija (iki 11 sav. nuo Sutarties įsigaliojimo);
  • 7Sistemos architektūros projektavimo paslaugos – 1 architektūros aprašo dokumentas (ADD) ir integracinės architektūros schema (iki 14 sav. nuo Sutarties įsigaliojimo);
  • 8Produkto vystymo kelrodžio paslaugos – produkto kelrodis (Product Roadmap), rizikų registras ir galutinė pristatymo prezentacija (iki 17 sav. nuo Sutarties įsigaliojimo).

Bendrieji paslaugų reikalavimai

  • 1Šio pirkimo tikslas – įsigyti konsultacines paslaugas, kurių metu bus: (a) išgryninta sistemos funkcionalumo architektūra su aukšto lygio produkto specifikacija; (b) atlikta struktūrizuota kaštų ir naudos analizė (pirkti / pritaikyti / vystyti) naujos kartos UTM / U-Space sistemos įgyvendinimo scenarijams; (c) parengtas produkto vystymo kelrodis (Product Roadmap).
  • 2Parengti Rezultatai sudarys pagrindą Pirkėjo strateginiam sprendimui dėl sistemos įgyvendinimo modelio ir tolesniam techninės specifikacijos rengimui (programinės įrangos kūrimas nėra šio pirkimo apimtis).
  • 3Kuriama sistema turi įgyvendinti vieno langelio principą – suteikti BO operatoriams, institucijoms/ūkio subjektams, ir kitiems suinteresuotiems subjektams vieną bendrą skaitmeninę prieigos vietą visiems su BO operacijomis susijusiems procesams.
  • 4Sistema turi būti lanksti naujiems duomenų srautams ir technologijoms: architektūra turi numatyti galimybę integruoti naujus stebėjimo šaltinius/atpažinimo sistemas, įvairius duomenų srautus, ir išorines paslaugas be esminių sistemos pertvarkymų.
  • 5Ypatingas dėmesys skiriamas kooperatyvių ir nekooperatyvių BO atpažinimui bei oro erdvės pažeidimų automatiniam nustatymui ir valdymui.
  • 6Paslaugos turi atitikti ES reglamentų 2019/947 (UAS), 2021/664, 2021/665 ir 2021/666 (U-Space) reikalavimus.
  • 7Tiekėjas turi būti susipažinęs su EASA AMC/GM gairėmis, ICAO Doc 10019 (UTM) ir EUROCAE WG-105 dokumentais; kiekvienas pasiūlytas architektūrinis sprendimas turi būti pagrįstas reguliacinės aplinkos ar geriausios praktikos nuoroda, tačiau Tiekėjas gali remtis ir analogiškų sektorių (mobilumo, transporto, energetikos ir kt.) patirtimi, pagrįsdamas jos tinkamumą UTM kontekste.
  • 8ASTM F3411 (Remote ID) išmanymas laikomas privalumu.
  • 9Visi tarpiniai ir galutiniai Rezultatai teikiami lietuvių ir (arba) anglų kalba. Pristatymai Pirkėjo vadovybei vyksta lietuvių kalba.
  • 10Tiekėjas teikia pažangos ataskaitas el. paštu kas dvi savaites, ir dalyvauja dvišalėse pažangos peržiūrose ne rečiau kaip kas mėnesį.
  • 11Paslaugų teikimo terminas – 17 (septyniolika) savaičių nuo Sutarties įsigaliojimo dienos.
  • 12Tiekėjas, ne vėliau kaip per 5 (penkias) darbo dienas nuo Sutarties įsigaliojimo, privalo parengti ir pateikti Pirkėjui suderinti detalų Paslaugų teikimo grafiką su visų Rezultatų pateikimo datomis. Šalių pasirašytas grafikas tampa neatskiriama Sutarties dalimi.
  • 13Šalys rašytiniu susitarimu gali keisti Paslaugų teikimo grafiką, nekeičiant galutinio Paslaugų suteikimo termino, išskyrus atvejus, kai termino keitimą lemia Pirkėjo vėlavimas pateikti reikalingą informaciją, pastabas ar patvirtinimą.
  • 14Paslaugos gali būti teikiamos nuotoliniu būdu ir / arba Pirkėjo buveinėje, adresu: Balio Karvelio g. 25, LT-02184 Vilnius. Sesijų vieta derinama šalių susitarimu.
  • 15Konsultacinės sesijos organizuojamos Pirkėjo patalpose arba, šalims susitarus, nuotoliniu vaizdo konferencijos būdu.
  • 16Galutinio Rezultatų pristatymo sesija vyksta Pirkėjo patalpose, Vilniuje.

Kaštų ir naudos analizės paslaugos

  • 1Tiekėjas atlieka struktūrizuotą kaštų ir naudos analizę (CBA), grindžiamą 6.3 punkte patvirtintu reikalavimų rinkiniu.
  • 2Analizėje lyginami ne mažiau kaip trys įgyvendinimo scenarijai: (a) Pirkti – komercinio galutinio sprendimo (angl. COTS) įsigijimas ir pritaikymas; (b) Pritaikyti – esamo atviro kodo ar licencijuoto sprendimo adaptavimas prie Pirkėjo poreikių; (c) Vystyti – individualios sistemos kūrimas nuo nulio naudojant atviro kodo komponentus. Galimi kombinuoti scenarijai (pvz., branduolį pirkti, plėtinius vystyti).
  • 3Kiekvienas scenarijus turi būti įvertintas pagal šiuos kriterijus: (a) bendros nuosavybės kaštai (TCO) per 5 ir 10 metų laikotarpį, apimantys pradinius diegimo kaštus, licencijų ir priežiūros mokesčius, integracijų ir pritaikymo kaštus, žmogiškųjų išteklių poreikį bei infrastruktūros kaštus;
  • 4Kiekvienas scenarijus turi būti įvertintas pagal šiuos kriterijus: (b) atitikimas patvirtintiems funkcionaliems reikalavimams (funkcionalumo atotrūkio analizė, angl. gap analysis), ypač vieno langelio principo įgyvendinimo, kooperatyvių / nekooperatyvių BO atpažinimo, oro erdvės pažeidimų valdymo ir MSDF atvirosios architektūros atžvilgiu;
  • 5Kiekvienas scenarijus turi būti įvertintas pagal šiuos kriterijus: (c) atitikimas ES U-Space reguliacinių reikalavimų paketui (2021/664, 2021/665, 2021/666) ir EASA AMC/GM gairėms;
  • 6Kiekvienas scenarijus turi būti įvertintas pagal šiuos kriterijus: (d) strateginė nepriklausomybė ir rizikos: pardavėjo priklausomybė (vendor lock-in), duomenų suverenumas, sistemos pritaikymo lankstumas ateičiai;
  • 7Kiekvienas scenarijus turi būti įvertintas pagal šiuos kriterijus: (e) diegimo trukmė ir operacinis pasirengimas;
  • 8Kiekvienas scenarijus turi būti įvertintas pagal šiuos kriterijus: (f) techninė rizika ir sudėtingumas.
  • 9Analizės metodologija turi būti skaidri ir dokumentuota: Tiekėjas nurodo naudotus vertinimo metodus, prielaidas, duomenų šaltinius ir jautrumo analizę (angl. sensitivity analysis) pagrindinių kaštų parametrų atžvilgiu.
  • 10Rinkos apžvalga: Tiekėjas identifikuoja rinkoje egzistuojančius COTS ir pritaikomus UTM / U-Space sprendimus, kurie atitinka ar iš dalies atitinka patvirtintus Pirkėjo reikalavimus, ir įvertina jų brandos lygį, ES rinkos paplitimą ir pritaikymo galimybes Pirkėjo kontekstui.
  • 11Kaštų ir naudos analizės ataskaita turi baigtis aiškia, pagrįsta rekomendacija dėl optimalaus įgyvendinimo scenarijaus (arba scenarijų derinio), kurią Pirkėjas galėtų naudoti strateginiam sprendimui priimti.
  • 12Rekomendacija turi aiškiai nurodyti siūlomą modelį kiekvienam pagrindiniam sistemos komponentui (pvz., branduolinis variklis, geozonų modulis, BO atpažinimo integracija, naudotojų sąsajos).
  • 13Ataskaita pateikiama Pirkėjui tvirtinti. Pirkėjas pateikia pastabas per 5 darbo dienas, Tiekėjas jas įvertina ir pateikia galutinę ataskaitą per 5 darbo dienas.

Produkto vystymo kelrodžio paslaugos

  • 1Tiekėjas parengia produkto vystymo kelrodį (Product Roadmap), kuris turi būti tiesiogiai paremtas 7.5 punkte patvirtintos kaštų ir naudos analizės rekomendacija.
  • 2Kelrodis turi apibrėžti: sistemos kūrimo / diegimo etapus ir jų seką; kiekvieno etapo pagrindinį funkcionalumą ir laukiamus rezultatus; etapų laiko rėmus ir priklausomybes; išteklių poreikio (žmogiškieji, finansiniai, techniniai) preliminarų įvertinimą kiekvienam etapui; kriterijus perėjimui į kitą etapą.
  • 3Kelrodis turi numatyti šią etapų logiką (konkrečios terminai nustatomi atsižvelgiant į kaštų ir naudos analizės išvadas): 1 etapas – pagrindinio UTM funkcionalumo diegimas: vieno langelio prieiga, geozonų valdymas, skrydžių deklaravimas ir leidimų sistema; 2 etapas – stebėjimo ir saugumo modulių diegimas: kooperatyvių / nekooperatyvių BO klasifikavimas, oro erdvės pažeidimų aptikimas ir valdymas, MSDF branduolio diegimas; 3 etapas – plėtra ir integracija: papildomų stebėjimo šaltinių integravimas, išorinių API jungtys, sistemos masteliavimas ir optimizavimas.
  • 4Kelrodis turi aiškiai atspindėti, kurie komponentai kiekviename etape: perkamas / licencijuojamas iš išorės; pritaikomas iš esamo sprendimo; vystomas individualiai. Šis skirstymas turi tiesiogiai sekti iš 7.5 punkte patvirtintos kaštų ir naudos analizės rekomendacijos.
  • 5Tiekėjas parengia funkcijų žemėlapį (Feature Map), kuriame visi sistemos moduliai ir funkcijos išdėstyti prioritetų tvarka, susieti su kelrodžio etapais ir nurodant: modulio / funkcijos pavadinimą, trumpą aprašymą, prioritetą (privaloma / aukštas / vidutinis), įgyvendinimo modelį (pirkti / pritaikyti / vystyti) ir priklausomybes.
  • 6Tiekėjas identifikuoja pagrindines rizikas ir pateikia rizikų registrą su rekomenduojamais rizikų mažinimo veiksmais; pasirinkto įgyvendinimo scenarijaus specifines rizikas (pvz., vendor lock-in pirkimo atveju, kompetencijų stoka vystymo atveju).
  • 7Tiekėjas pristato visus galutinius Rezultatus Pirkėjo vadovybei ir nustatytoms suinteresuotoms šalims baigiamajame pristatyme.

Reikalavimų rinkimo ir validavimo paslaugos

  • 1Tiekėjas organizuoja ne mažiau kaip 4 (keturias) reikalavimų konsultacines sesijas su Pirkėjo paskirtais atstovais.
  • 2Sesijų data ir darbotvarkė derinamos su Pirkėju ne vėliau kaip 5 darbo dienos iki kiekvienos sesijos.
  • 3Sesijų metu turi būti aptartos šios funkcinės sritys: Registracija ir identifikacija. BO operatorių ir orlaivių registracijos mechanizmai, nuotolinio identifikavimo (Remote ID) reikalavimai, tapatybės tikrinimas ir vieningos prieigos modelis operatoriams bei institucijoms (vieno langelio principas).
  • 4Sesijų metu turi būti aptartos šios funkcinės sritys: Skrydžių planavimas ir leidimų sistema. Individualių BO operatorių bei valstybinių ir institucinių BO skrydžių planų teikimo, automatinio vertinimo, patvirtinimo ar atmetimo darbo eigos; 4D trajektorijų valdymas ir konfliktų aptikimas planavimo etape.
  • 5Sesijų metu turi būti aptartos šios funkcinės sritys: Oro erdvės valdymas ir geozonų sistema. Nuolatinių, laikinųjų, sąlyginių ir ir kitų zonų kūrimo, redagavimo, publikavimo ir galiojimo valdymo mechanizmai.
  • 6Sesijų metu turi būti aptartos šios funkcinės sritys: Kooperatyvių ir nekooperatyvių BO atpažinimas, stebėsena ir incidentų valdymas. Realiu laiku vykdomas orlaivių identifikavimas pagal turimus atpažinimo šaltinius ir jų priskyrimas kooperatyvios arba nekooperatyvios kategorijoms; daugiašaltinė duomenų sintezės integravimas (MSDF) į vieningą situacinį vaizdą; visų aktyvių BO trajektorijų stebėsena ir istorinių skrydžių duomenų kaupimas; statistinių ataskaitų generavimas (skrydžių intensyvumas, pažeidimai, operatorių aktyvumas, zonų apkrautumas) bei duomenų vizualizacija ir eksporto funkcionalumas; geozonų ir skrydžių planų atitikties kontrolė realiu laiku; grėsmės lygio vertinimas ir automatinis daugiapakopis alertavimas (operatoriui, institucijai, oro eismo paslaugų tarnybai); incidentų registravimas, reagavimo procedūrų palaikymas ir koordinavimas su gelbėjimo bei saugumo tarnybomis.
  • 7Sesijų metu turi būti aptartos šios funkcinės sritys: Meteorologinė informacija. Realaus laiko orų duomenų teikimas operatoriams ir sistemai; vėjo, matomumo, turbulencijos perspėjimai; integravimas su meteorologijos tarnybų šaltiniais.
  • 8Sesijų metu turi būti aptartos šios funkcinės sritys: API architektūra, MSDF ir išorinių sistemų integracija. Standartizuotų atvirų sąsajų (REST/MQTT) projektavimas duomenų mainams su institucijomis, oro eismo valdymo sistemomis, meteorologijos tarnybomis ir kitais išoriniais šaltiniais; atvirosios integracijos architektūra naujiems duomenų šaltiniams prijungti.
  • 9Sesijų metu turi būti aptartos šios funkcinės sritys: Naudotojų aplinkos. Institucinis portalas (skirtas kompetentingoms institucijoms: stebėsenai, zonų valdymui, ataskaitoms ir incidentų valdymui) ir BO operatorių aplikacija (skirta skrydžių planavimui, deklaravimui, leidimų gavimui ir realaus laiko statuso sekimui); funkcinis aplinkų atskyrimas ir naudojimo sąsajų reikalavimai.
  • 10Sesijų metu turi būti aptartos šios funkcinės sritys: Autentifikacija, 2FA ir kibernetinis saugumas. Naudotojų tapatybės nustatymo mechanizmai, dviejų faktorių autentifikacija, vaidmenimis grįstas prieigos valdymas (RBAC), duomenų perdavimo šifravimas, saugumo auditų galimybė ir atitiktis taikomiems kibernetinio saugumo reikalavimams (NIS2 ir kt.).
  • 11Galutinis suderintas reikalavimų rinkinys pateikiamas Pirkėjui patvirtinti.
  • 12Pirkėjas pateikia pastabas per 5 darbo dienas, Tiekėjas jas įvertina ir pateikia atnaujintą versiją per 5 darbo dienas.

Sistemos architektūros projektavimo paslaugos

  • 1Tiekėjas parengia UTM sistemos aukšto lygmens architektūros aprašo dokumentą (ADD), kuris turi atliepti visas 6.2 punkte apibrėžtas funkcines sritis ir būti suderintas su galutiniu patvirtintu reikalavimų rinkiniu (6.4 punktas).
  • 2Architektūros sprendimai turi atspindėti 7.5 punkte patvirtintą kaštų ir naudos analizės rekomendaciją (t. y. pasirinktą pirkti / pritaikyti / vystyti modelį kiekvienam komponentui).
  • 3Integracinės architektūros schema turi aprašyti visas išorines sąsajas: API jungtis su trečiųjų šalių aplikacijomis; BO atpažinimo sistemų sąsajas; eIDAS integravimą; standartines sąsajas su kitomis sistemomis.
  • 4API architektūra aukštu lygiu turi apimti: RESTful arba gRPC principų pasirinkimo pagrindimą; OAuth 2.0 / OpenID Connect autentifikavimo schemą; pagrindinių API blokų sąrašą (geozonų, skrydžių autorizacijos, telemetrijos, atpažinimo duomenų, pažeidimų, notifikacijų, administravimo API); webhook / event-driven architektūros elementus realaus laiko įvykiams.

Dokumentai3

  • Kvietimas į rinkos konsultaciją.docx
  • 1641_7261488.pdf
  • 1. Techninė specifikacija.docx
tendis.lt · Sukurta recodin.lt