Grįžti į sąrašą

Virtualios elektrinės programinės įrangos diegimo paslaugos

Išanalizuota

AB „Miesto gijos“ (PV)

Rinkos konsultacijaCPV: 72212518 - Emuliacijos programinės įrangos kūrimo paslaugos
ID: 78135892026-05-12 10:12
Atidaryti CVP IS

Aprašymas

Perkamos virtualiosios elektrinės (VPP) programinės įrangos diegimo, konfigūravimo, integravimo, priežiūros ir palaikymo paslaugos. Ši sistema leis automatizuotai stebėti, prognozuoti, optimizuoti bei agreguoti paskirstytus energijos išteklius, teikti pasiūlymus elektros energijos rinkoms ir vykdyti perdavimo sistemos operatoriaus aktyvavimus. Tikslas – efektyviau dalyvauti balansavimo ir kitose elektros energijos rinkose, užtikrinant optimalų įrenginių darbą.

Kvalifikaciniai reikalavimai

  • 1Tiekėjo vidutinės metinės veiklos pajamos iš informacinių sistemų kūrimo, palaikymo ir/ar vystymo paslaugų per paskutinius 3 (tris) finansinius metus arba per laiką nuo tiekėjo įregistravimo dienos yra ne mažesnės kaip 200.000,00 Eur (be PVM).
  • 2Tiekėjas per paskutinius 3 (tris) metus arba per laiką nuo tiekėjo įregistravimo dienos (jeigu tiekėjas vykdė veiklą mažiau nei 3 (tris) metus) iki paraiškų pateikimo dienos turi būti suteikęs bent pagal vieną sutartį virtualios elektrinės programinės įrangos diegimo, nutolusių energijos išteklių agregavimo, ir/ar energijos gamybos ir/ar vartojimo optimizavimo, ir/ar energijos produktų rinkų integravimo, ir/ar PSO integravimo, įtraukiant fizinius objektus, procesus, santykius ir elgseną, t.y. verslo procesų analizės, projektavimo, sistemos kūrimo (ar modernizavimo) ir diegimo paslaugas, kurių vertė ne mažesnė kaip 200.000,00 Eur be PVM.
  • 3Projekto vadovas (bent 1): per paskutinius 3 (trejus) metus turi būti suteikęs bent vienos informacinės sistemos, kurios diegimo vertė yra ne mažesnė nei 200.000,00 Eur be PVM ir kuri jau yra įdiegta į eksploatacinę aplinką, kūrimo ir / arba modernizavimo projekto valdymo paslaugas pilnai nuo projekto pradžios iki pabaigos.
  • 4Informacinių technologijų architektas (bent 1): per paskutinius 3 (trejus) metus turi turėti ne trumpesnę nei 2 metų darbo patirtį informacinių sistemų architektūros projektavimo srityje.
  • 5Sistemų integravimo specialistas (bent 1): per pastaruosius 3 (trejus) metus turi turėti ne trumpesnę kaip 1 (vienų) metų patirtį informacinių sistemų integravimo srityje naudojant XML/XSD, REST API, WSDL arba lygiavertes technologijas žiniatinklio paslaugų programavimui ir konfigūravimui.
  • 6Sistemų integravimo specialistas (bent 1): per pastaruosius 3 (trejus) metus dalyvavęs ne mažiau kaip 1 (viename) įvykdytame (baigtame, t. y. įdiegtame į eksploatacinę aplinką), informacinės sistemos, kūrimo ir/arba modernizavimo projekte kaip sistemų integravimo specialistas, kurio funkcijos buvo bent vienos integracinės sąsajos analizė, projektavimas ir kūrimas.
  • 7Programuotojas (bent 1): per pastaruosius 3 (trejus) metus turi turėti ne trumpesnę kaip 2 (dviejų) metų patirtį informacinių sistemų programavimo srityje.
  • 8Informacinių sistemų kūrimo, palaikymo ir vystymo veikloje turi būti įgyvendintos organizacinės ir techninės saugumo valdymo priemonės, atitinkančios ISO27001 arba lygiaverčių standartų reikalavimus.
  • 9Tiekėjas laikosi kokybės vadybos sistemos ISO 9001:2015/LST EN ISO 9001:2015 standarto reikalavimų arba lygiavertės kokybės vadybos sistemos standartų reikalavimų.

Techniniai reikalavimai

VPP veikimas ir kontrolė

  • 1VPP turi palaikyti aktyvavimų valdymą ir įrenginių komandavimą taip, kad būtų galima laikytis mFRR aktyvinimo laiko reikalavimų (aktyvavimo pradžia ≤ 7 min, FAT ≤ 12,5 min, išjungimas ≤ 10 min).
  • 2VPP turi palaikyti mFRR aktyvavimo užduoties (setpoint) skiriamąją gebą ne mažesnę kaip 0,1 MW ir užtikrinti galimybę stebėti/vertinti pastoviosios būsenos paklaidą pagal PSO kriterijus (±10% arba 0,1 MW).
  • 3VPP turi sudaryti galimybę teikti balansavimo paslaugas atskirais įrenginiais.
  • 4VPP turi sudaryti galimybę teikti balansavimo paslaugas telkiant įrenginių galias.
  • 5Įrenginiai turi būti aktyvuojami per Modbus TCP/IEC-104.
  • 6VPP turi sudaryti galimybę į VPP gauti įrenginių būsenos duomenis.
  • 7VPP turi sudaryti galimybę suplanuoti kiekvieno įrenginio darbo režimus atsižvelgiant į kiekvieno įrenginio techninius apribojimus, technines galimybes, techninius parametrus tokius kaip galia, greitis, darbo trukmė – likęs rezervas. Kvalifikacijai reikalingi duomenys.
  • 8VPP turi sudaryti galimybę užduotis įrenginiams koreguoti rankiniu būdu.
  • 9VPP turi sudaryti galimybę užduotis įrenginiams koreguoti automatiniu būdu.
  • 10VPP turi palaikyti saugų veikimą ryšio ar išorinių sistemų sutrikimų atveju.
  • 11VPP turi užtikrinti pasiūlymų ir aktyvavimų atsekamumą.
  • 12Turi būti pademonstruota aktyvavimo eigos stebėsena realiu laiku (aktyvi galia, nuokrypiai, reakcijos laikas).
  • 13Turi būti pademonstruota naudotojų roles (administratorius, operatorius, skaitytojas) ir jų teisių skirtumus VPP sistemoje.
  • 14Turi būti pademonstruotas VPP būsenos ir įspėjimų valdymas (pvz. įrenginio iškritimas, ryšio sutrikimas, galios ribų viršijimas).

Ataskaitos ir žurnalavimas

  • 1VPP turi sudaryti galimybę formuoti ir eksportuoti aktyvavimo tipo ataskaitą.
  • 2Aktyvavimo tipo ataskaita turi būti formuojama automatiškai.
  • 3Turi būti galimybė nustatyti automatinį aktyvavimo tipo ataskaitos išsiuntimą el. paštu nurodytu adresu.
  • 4VPP turi sudaryti galimybę formuoti įrenginių aktyvavimo ataskaitą.
  • 5Įrenginių aktyvavimo ataskaita turi būti formuojama automatiškai.
  • 6Turi būti galimybė nustatyti automatinį įrenginių aktyvavimo ataskaitos išsiuntimą el. paštu nurodytu adresu.
  • 7VPP turi sudaryti galimybę formuoti savikainos ir faktinės aktyvavimo kainos palyginimo ataskaitą.
  • 8Savikainos ir faktinės aktyvavimo kainos palyginimo ataskaita turi būti formuojama automatiškai.
  • 9Turi būti galimybė nustatyti automatinį savikainos ir faktinės aktyvavimo kainos palyginimo ataskaitos išsiuntimą el. paštu nurodytu adresu.
  • 10VPP turi sudaryti galimybę formuoti pasiūlymų ataskaitą.
  • 11Pasiūlymų ataskaita turi būti formuojama automatiškai.
  • 12Turi būti galimybė nustatyti automatinį pasiūlymų ataskaitos išsiuntimą el. paštu nurodytu adresu.
  • 13Esant poreikiui VPP turi sudaryti galimybę integruoti su Užsakovo naudojama finansinės apskaitos sistema (FAS), siekiant perduoti VPP sugeneruotus finansinius duomenis (ataskaitas, suvestines) tolesniam apdorojimui.
  • 14Turi būti pademonstruotas aktyvavimo rezultatų fiksavimas ir atsekamumas (kas, kada, kokiu pagrindu buvo aktyvuota).
  • 15Turi būti pademonstruoti įvykių žurnalai ir naudotojų veiksmų registravimas (prisijungimai, parametrų keitimai, aktyvavimai).
  • 16Turi būti pademonstruotas standartinių ataskaitų formavimas (aktyvavimai, pajėgumų panaudojimas, finansiniai pjūviai).

Integracija su rinkomis ir PSO

  • 1VPP produktas turi sudaryti galimybes Užsakovui dalyvauti PSO vykdomuose balansavimo paslaugų kvalifikavimo procesuose, įskaitant mFRR paslaugą, pagal galiojančius Baltijos šalių ir Litgrid AB reikalavimus.
  • 2VPP produkto funkcionalumas turi būti pritaikytas PSO kvalifikavimo metu taikomiems duomenų mainų, aktyvavimo, stebėsenos ir bandymų reikalavimams įgyvendinti.
  • 3VPP produktas turi palaikyti duomenų mainus, reikalingus PSO kvalifikavimo procesams, įskaitant mFRR balansavimo energijos pasiūlymų pateikimą per žiniatinklio paslaugą, naudojant XML pranešimus pagal ENTSO‑E CIM / IEC 62325 standartą.
  • 4PSO siunčiamų aktyvavimo nurodymų priėmimą ir apdorojimą.
  • 5Atsakomųjų pranešimų (ACK) ir pasiūlymų neprieinamumo statuso palaikymą pagal PSO nustatytą tvarką.
  • 6VPP turi sudaryti galimybę atlikti PSO numatytus duomenų mainų bandymus.
  • 7VPP produktas turi užtikrinti galimybę PSO kvalifikavimo metu teikti PSO realaus laiko duomenis apie rezervą teikiančius įrenginius ir (arba) jų grupes, įskaitant: suplanuotą aktyviąją galią, faktinę aktyviąją išėjimo galią, ribotos energijos rezervuarų atveju – SOC informaciją.
  • 8Jeigu realaus laiko duomenų teikimas laikinai neįmanomas, VPP turi sudaryti galimybę duomenis kaupti su laiko žymomis ir pateikti PSO sutartu periodiškumu.
  • 9VPP produktas turi palaikyti rezervų aktyvavimo ir įrenginių valdymo funkcijas taip, kad būtų galima įgyvendinti PSO parengties tvirtinimo bandymus, įskaitant: aktyvavimo užduočių priėmimą ir perdavimą įrenginiams; aktyviosios galios valdymą su reikiama skiriamąja geba; aktyvavimo eigos stebėseną ir duomenų fiksavimą bandymų metu.
  • 10VPP produktas turi leisti generuoti ir eksportuoti kvalifikavimo metu surinktus duomenis ir ataskaitas, reikalingas PSO atliekamai duomenų analizei, parengties tvirtinimo bandymų rezultatų pateikimui, aktyvavimo eigai, laikams ir energijos kiekiams pagrįsti.
  • 11VPP produktas turi palaikyti integraciją su perdavimo sistemos operatoriaus PSO informacinėmis sistemomis, reikalingą balansavimo paslaugų teikimui realaus eksploatavimo metu.
  • 12VPP turi palaikyti keitimąsi duomenimis su PSO sistemomis pagal PSO nustatytus reikalavimus, įskaitant: balansavimo energijos ir (ar) rezervo pajėgumo pasiūlymų (bidų) teikimą; PSO atsakymų (ACK) priėmimą; pateiktų pasiūlymų neprieinamumo pažymėjimą; aktyvavimo nurodymų priėmimą ir apdorojimą.
  • 13VPP turi sudaryti galimybę PSO realiuoju laiku teikti: suplanuotą aktyviąją galią; faktinę aktyviąją išėjimo galią; galimą mFRR balansavimo aukštyn ir (ar) žemyn kiekį; ribotos energijos rezervuarų atveju – SOC informaciją.
  • 14VPP turi vykdyti aktyvavimus: priimti PSO siunčiamas aktyvavimo užduotis; išskaidyti aktyvavimo signalus į atskirus rezervą teikiančius įrenginius ar jų grupes; valdyti aktyviosios galios užduotis su ne mažesne kaip 0,1 MW skiriamąja geba; užtikrinti aktyvavimo eigos stebėseną ir atsekamumą.
  • 15VPP integracija su PSO turi būti pakankama sklandžiam balansavimo paslaugų teikimui pagal galiojančius PSO reikalavimus.
  • 16Duomenų mainai su PSO apima integraciją su PSO vidinėmis paslaugų valdymo ir energijos balanso sistemomis (pvz., LMMS), pagal PSO nustatytas technines ir procedūrines taisykles.
  • 17VPP produktas turi būti suintegruotas su balansavimo elektros energija rinka.
  • 18VPP turi palaikyti pasiūlymų pateikimą, modifikavimą, atšaukimą, vykdymo ir sandorių ataskaitas, tiek valandinius, tiek 15 min. produktus.
  • 19VPP turi būti suderinama su PSO naudojamomis balansavimo paslaugų mainų platformomis (pvz., MARI ir PICASSO), tiek kiek tai reikalinga pasiūlymų teikimui, aktyvavimų gavimui ir ataskaitų apsikeitimui.
  • 20VPP produktas turi būti suintegruotas su rezervo pajėgumų rinka.
  • 21VPP produktas turi būti suintegruotas su Nord Pool elektros birža.
  • 22VPP produktas turi automatiškai apskaičiuoti balansavimo energijos pasiūlymus (aFRR / mFRR) ir parengti segmentuotus pasiūlymus pagal kainą ir apimtį.
  • 23VPP turi palaikyti mFRR balansavimo energijos pasiūlymų pateikimą PSO per žiniatinklio paslaugą, teikiant XML pranešimus pagal ENTSO‑E CIM/IEC 62325‑451‑7 “ReserveBidDocument”.
  • 24VPP turi palaikyti PSO atsakymų (ACK) priėmimą po pasiūlymo pateikimo ir suteikti galimybę identifikuoti semantines/duomenų klaidas.
  • 25VPP turi palaikyti pateikto mFRR pasiūlymo neprieinamumo pažymėjimą per žiniatinklio paslaugą.
  • 26VPP produktas turi palaikyti automatinį pasiūlymų teikimą ir galimybę rankiniu būdu patvirtinti ar pakoreguoti pasiūlymus prieš pateikiant PSO ar biržai.
  • 27Turi būti pademonstruotas balansavimo paslaugų pasiūlymų (bid) formavimas ir pateikimas, įskaitant kainos, apimties ir laiko parametrus.
  • 28Turi būti pademonstruotas aktyvavimo signalo priėmimas (simuliuotą arba testinį) ir jo išskaidymas į atskirus įrenginius.

Prognozavimas ir optimizavimas

  • 1VPP produktas turi palaikyti energijos gamybos/vartojimo prognozes su bent 15 min. rezoliucija (market-ready).
  • 2VPP turi teikti pasiūlymus ir juos aktyvuoti atsižvelgiant į kiekvieno įrenginio darbo specifiką ir turimą pajėgumą.
  • 3VPP turi sudaryti galimybę nustatyti pasiūlymo kainos skaičiavimą pagal užsakovo nustatytą kainos skaičiavimo metodiką.
  • 4VPP produktas turi integruoti kelis prognozių šaltinius ir leisti keisti prognozių tiekėją be programinio kodo perrašymo.
  • 5VPP produktas turi optimizuoti DER veikimą, atsižvelgiant į kainas, techninius apribojimus, prognozes ir rinkos signalus.
  • 6VPP produktas turi palaikyti skirtingus optimizavimo variklius / metodus ir galimybę keisti optimizatorių be produkto perrašymo.
  • 7VPP turi palaikyti prioretizavimo taisykles.

Naudotojo sąsajos reikalavimai

  • 1Sąsaja turi būti intuityvi ir lengvai suprantama, kad vartotojai galėtų greitai išmokti ja naudotis be didelių pastangų, realizuota remiantis geriausia naudojamumo (usability) praktika.
  • 2Sąsaja turi greitai reaguoti į vartotojo veiksmus, kad būtų užtikrintas sklandus ir efektyvus darbas.
  • 3Sąsaja turi veikti įvairiose platformose ir naršyklėse, kad vartotojai galėtų naudotis sistema nepriklausomai nuo jų naudojamos įrangos.
  • 4Sąsaja turi būti vizualiai patraukli ir profesionaliai atrodanti.
  • 5Sąsaja turi veikti be klaidų ir užtikrinti, kad vartotojai galėtų pasiekti reikiamą informaciją ir funkcijas bet kuriuo metu.
  • 6VPP vartotojo sąsaja turi remtis pelės ir klaviatūros įrenginių naudojimu. Turi būti numatyta ir pritaikyta lietimui skirta sąsaja.
  • 7Naudotojo sąsaja turi būti suprojektuota taip, kad mažintų naudotojo kognityvinę apkrovą: informacija pateikiama hierarchiškai, iškeliant esmines būsenas ir leidžiant detales peržiūrėti pagal poreikį.
  • 8Naudotojo sąsaja turi sudaryti galimybę naudotojui gauti kontekstines rekomendacijas.
  • 9Sistema turi naudotojui aiškiai ir nedviprasmiškai pateikti informaciją apie veiksmų būseną (pvz. vykdoma, įvykdyta, atmesta, klaida).
  • 10Turi būti pateikiami įspėjimai ir sistemos veikimo būsenos paaiškinimai, susiję su vykdomais veiksmais.
  • 11Naudotojo sąsaja turi palaikyti efektyvų darbą patyrusiems naudotojams (pvz. spartieji veiksmai, minimalus perteklinis patvirtinimų skaičius dažniems veiksmams).
  • 12VPP grafinė vartotojo sąsaja turi būti orientuota į naudotoją.
  • 13VPP dizainas turi būti sukurtas taikant geriausias UX ir UI praktikas, siekiant naudotojo sąsają padaryti kiek labiau įmanomą intuityvią ir suprantamą, vengiant perteklinių veiksmų.
  • 14VPP dizainas turi būti adaptyvus, kokybiškas ir vizualiai tvarkingas, išnaudojant visą VPP aplinkos plotą (pvz. išsidėstymas ir dizaino elementai prisitaiko prie lankytojo ekrano dydžio).

Diegimo ir palaikymo reikalavimai

  • 1VPP diegimui ir paleidimui gamybinėje aplinkoje skiriamas ne ilgesnis nei 6 (šeši) mėnesių terminas.
  • 2Diegėjas turi užtikrinti 1 metų garantinį ir 3 metų techninį aptarnavimą, pradedant nuo Galutinio VPP priėmimo-perdavimo akto pasirašymo dienos.
  • 3Diegėjas su Užsakovu suderintoje infrastruktūroje turi įdiegti ne mažiau kaip 2 VPP aplinkas: produkcinę ir funkcionalumų testavimo.
  • 4Diegėjas turi įdiegti priemones, užtikrinančias naujų sistemos versijų produkcinėje aplinkoje diegimą, užtikrinant jos veikimą diegimo metu.
  • 5Turi būti realizuoti sprendimai, kad migravimo arba atnaujinimo paketo diegimo metu programinis kodas, aplikacijos, duomenų bazių atnaujinimas reikiamose aplinkose būtų atliekamas be papildomų VPP naudotojo veiksmų.
  • 6Turi būti parengtos VPP administravimo instrukcijos, detali VPP diegimo ir eksploatavimo procedūra.
  • 7Turi būti parengtos VPP naudotojų instrukcijos, patalpintos pačioje VPP, naudotojams patogiu formatu skaityti ir naršyti.
  • 8VPP komponentai turi būti gamintojo rekomenduojamos naujausios, stabilios ir palaikomos versijos; VPP naudojami trečiųjų šalių komponentai turi būti siunčiami tik iš oficialių šaltinių.
  • 9Nenaudojamas VPP funkcionalumas turi būt išjungtas, nepalaikomi komponentai ir konfigūracijos, jeigu juose nustatyta pažeidžiamumų, privalo pakeisti analogiško funkcionalumo komponentais arba pašalinti.
  • 10Turi būti vykdomas konfigūracijos keitimas pagal pasikeitusius veiksnius (pvz., padidėjusią apkrovą, sumažėjusią duomenų saugyklos talpą), saugos priemonių veikimo stebėjimas, sisteminių įrašų ir incidentų analizavimas, užtikrinant stabilų VPP veikimą, saugumą ir našumą.

Bendrieji VPP sistemos reikalavimai

  • 1Turi būti pateiktas rinkoje egzistuojantis VPP produktas (stabili, palaikoma naujausia versija), kurio diegimas ir konfigūravimas atliekamas pagal techninės specifikacijos reikalavimus, be individualaus kūrimo nuo pradinės stadijos.
  • 2VPP programinė architektūra ir jos realizacija turi palaikyti pajėgumų plėtimą (Scaling) ir veikti daugiasluoksnės architektūros pagrindu.
  • 3Visi VPP komponentai turi būti technologiškai funkcionalūs ir prieinami 98 % laiko, 24 valandas per parą, 7 dienas per savaitę, 365 dienas per metus (nesant trečiųjų šalių sutrikimų).
  • 4Duomenų matomumas ir prieinamumas VPP naudotojams ir paslaugų gavėjams turi būti realizuotas ir užtikrintas pagal principą „Tiek kiek būtina ir kiek įmanoma mažiau“.
  • 5VPP komponentai ir vidinė bei išorinė komponentų integracija turi būti realizuota remiantis SOA (Service Oriented Architecture) principais.
  • 6VPP pagrindinių funkcinių komponentų sąsajos API turi būti pagrįstos atvirais standartais ir formatais.
  • 7Turi būti galimybė suprojektuoti VPP taip, kad būtų palaikomas neribotas VPP komponentų išplėtimas (scalability).

Įrenginių valdymas ir agregavimas

  • 1VPP turi stebėti įrenginių būsenas realiu laiku, tinkamu balansavimo produktams.
  • 2VPP produktas turi agreguoti Užsakovo valdomus paskirstytus energijos išteklius (DER) į vieną valdomą virtualų portfelį stebėjimui, prognozavimui, optimizavimui, pasiūlymų teikimui ir aktyvavimams energijos rinkose.
  • 3VPP turi sudaryti galimybę rankiniu būdu įtraukti naują įrenginį ir pakoreguoti konfigūraciją/parametrus naudojant produkto standartines konfigūravimo priemones.
  • 4VPP produktas turi palaikyti realaus laiko telemetriją (iki 1 s rezoliucijos) vienu metu iš ne mažiau kaip 100 fizinių įrenginių.
  • 5VPP produktas turi skaičiuoti maksimalų galimą įrenginio pajėgumą.
  • 6VPP turi automatiškai kompensuoti pajėgumus, kai įrenginys nepasiekiamas.
  • 7VPP turi leisti naudotojui konfigūruoti, kurie įrenginiai dalyvauja kompensacijoje.
  • 8VPP turi leisti konfigūruoti, kuriems balansavimo produktams (aFRR/mFRR/Capacity/FCR) konkretus įrenginys gali būti naudojamas.
  • 9Sistemoje turi būti pademonstruota, kaip į VPP įtraukiami bent 3 skirtingų tipų įrenginiai (pvz. kogeneracinė jėgainė, šilumos siurblys, elektrolizeris) ir kaip jiems priskiriami techniniai apribojimai (galia, greitis, SOC, darbo trukmė).
  • 10Turi būti pademonstruotas agreguotos galios skaičiavimas realiu laiku, atsižvelgiant į individualių įrenginių būsenas ir ribojimus.
  • 11Turi būti pademonstruota, kaip VPP automatiškai perskirsto apkrovą, kai vienas ar keli įrenginiai tampa neprieinami.
  • 12Turi būti pademonstruota, kaip operatorius gali rankiniu būdu įjungti / išjungti konkretų įrenginį arba jo dalyvavimą atskirose balansavimo paslaugose.

Programinės įrangos licencijavimas

  • 1Diegėjo pateikiama standartinė licencinė programinė įranga (angl. Commercial Off-The-Shelf Software), reikalinga VPP veikimui, turi būti pateikiama kartu su visomis reikiamomis licencijomis visam Sutarties galiojimo laikotarpiui.
  • 2Diegėjas turi pateikti programinę įrangą ir licencijas visoms numatomoms įdiegti VPP aplinkoms (pvz. testavimo, mokymų ar produkcinei aplinkai).
  • 3VPP apdorojamos informacijos/duomenų apimtys neturi būti ribojamos programinės įrangos ir vartotojų licencijomis.
  • 4VPP produkto licencinė programinė įranga turi turėti gamintojo palaikymą (atnaujinimų parsisiuntimą ir diegimą, naujų komponentų pateikimą).
  • 5Jeigu siūloma programinė įranga yra licencijuojama priklausomai nuo VPP naudojančių naudotojų (žmonių ar sistemų) kiekio, tarnybinių stočių parametrų ar pan., Diegėjas turi pateikti licencijas, kurios užtikrintų racionalų ir efektyvų VPP veikimą ir naudojimą 5 metų perspektyvoje ir ne mažiau kaip 15-ai būsimų VPP naudotojų.
  • 6Naudotojų licencijos „Pagr. naudotojas“ (angl. Full User), turi būti skirtos dirbti su visais, išskyrus administravimą, komponentais.
  • 7Naudotojų licencijos „Riboto naudotojo” (angl. Light/Limited User) turi būti skirtos matyti ir atlikti reikiamas funkcijas pagal naudotojo rolę apribotam modulių/funkcionalumų komplektams, duomenų peržiūrai.

Saugumo ir duomenų apsaugos reikalavimai

  • 1VPP turi būti diegiami Užsakovo valdomuose duomenų centruose.
  • 2Turi būti užtikrintas subjektų ir duomenų apie juos privatumas bei konfidencialumas.
  • 3Turi būti užtikrintas siunčiamos ir saugomos informacijos konfidencialumas.
  • 4Turi būti užtikrintas siunčiamos ir saugomos informacijos vientisumas.
  • 5Turi būti užtikrintas siunčiamos ir saugomos informacijos autentiškumas ir įrodomumas (Non-repudiation).
  • 6Duomenų sauga turi būti užtikrinama naudojant SSL sertifikatus, atskiriant duomenų bazes, kuriose saugomi asmens duomenys, duomenų šifravimą ir kitus metodus.
  • 7VPP turi užtikrinti automatinį naudotojų sesijos nutraukimą, kai prisijungęs naudotojas tam tikrą laiką yra neaktyvus, su įspėjamuoju pranešimu.
  • 8Visi VPP naudotojai ir paslaugų gavėjai turi būti identifikuoti.
  • 9VPP turi generuoti VPP klaidų žurnalą (error log) ir turėti galimybę generuoti klaidų ataskaitas.
  • 10VPP turės būti diegiama į skirtingas DMZ zonas, apsaugotas vidinėmis ir išorinėmis ugniasienėmis ir Užsakovo apsaugos sistemomis.
  • 11Turi būti užtikrintas saugus programinės ir sisteminės programinės įrangos pataisymų (patch) diegimas ir pažeidžiamumo (vulnerability) valdymas.
  • 12Saugi VPP sąranka turi užtikrinti portų uždarymą, nereikalingos programinės įrangos diegimo užkardymą, privaloma laikytis bent jau OWASP-10 reikalavimų (Top 10 Web Application Security Risks).
  • 13Prieš įdiegiant VPP į produkcinę aplinką, Diegėjas turi pateikti dokumentus, įrodančius, kad VPP neturi kritinių, aukšto ir vidutinio lygio kibernetinių pažeidžiamumų.
  • 14VPP turi užtikrinti, kad Užsakovo duomenys (data at rest), jų perdavimas (data in transit) ir jų atsarginės kopijos (data backups) yra šifruojami, parenkant naujausias NIST, EISA ar BSI organizacijų rekomendacijas atitinkančius šifravimo algoritmus.
  • 15VPP naudotojų paskyros gali būti valdomos per Užsakovo valdomą AD sistemą, užtikrinant vieno prisijungimo (SSO) principus ir autentikavimui naudojant bent vieną iš protokolų: Open ID Connect, SAML 2.0, WS-Fed.
  • 16Jeigu VPP nepalaiko Užsakovo naudotojų autentifikavimo per AD / Entra ID, turi būti užtikrintas dviejų veiksnių (2FA) autentifikavimas sistemos naudotojams ir administratoriams.
  • 17Jeigu VPP nepalaiko Užsakovo naudotojų paskyros autentifikavimosi protokolų, VPP privalo palaikyti šiuos slaptažodžio reikalavimus: ne mažiau kaip 8 simboliai, bent trys simbolių kategorijos (didžiosios raidės, mažosios raidės, skaitmenys, specialieji simboliai), slaptažodis negali sutapti su prisijungimo vardu, negali sudaryti 3 ar daugiau simbolių iš prisijungimo vardo, periodinis keitimas (ne rečiau kaip kas 90 d.), negalima naudoti ankstesniojo.
  • 18VPP naudotojų paskyroms priskiriamos privilegijos ir (arba) rolės bei kiti saugos parametrai gali būti valdomi per Užsakovo valdomą AD ir (arba) lokaliai VPP sistemoje.
  • 19VPP turi būti galimybė valdyti privilegijuotų, sisteminių vartotojų parametrus (User name, slaptažodis) naudojant PAM.
  • 20VPP įvykių žurnaluose turi būti registruojami ir saugomi visų VPP naudotojų atlikti veiksmai ir paskyrų bei privilegijų/rolių keitimo veiksmai, o VPP naudotojai neturi galimybių pakeisti arba ištrinti išsaugotų žurnalų įrašų.
  • 21Užsakovas turi būti nedelsiant informuojamas apie VPP informacijos ir kibernetinės saugos įvykius ir incidentus ar asmens duomenų saugumo pažeidimus.
  • 22Jeigu VPP yra nustatytas kritinis kibernetinio saugumo pažeidžiamumas (CVSS nuo 9,0 iki 10,0 balų), jis turi būti išspręstas per 5 kalendorines dienas.
  • 23Aukšto prioriteto pažeidžiamumas (CVSS nuo 7,0 iki 8,9 balų) turi būti išspręstas per 10 kalendorinių dienų.
  • 24Vidutinio prioriteto pažeidžiamumas (CVSS nuo 4,0 iki 6,9 balų) turi būti išspręstas per 30 kalendorinių dienų.
  • 25Žemo prioriteto pažeidžiamumas (CVSS nuo 0,1 iki 3,9 balų) turi būti išspręstas per 60 kalendorinių dienų.
  • 26Jeigu VPP turi zero-day pažeidžiamumą, turi būti galimybė visiškai izoliuoti VPP nuo pasiekiamumo iš išorinio tinklo.
  • 27Turi būti galimybė apriboti VPP administravimo modulio pasiekiamumą pagal Užsakovo pateiktus išorinius IP adresus.
  • 28VPP lygyje turi būti galimybė Užsakovui laikinai arba visiškai atjungti tarnybas (services), kurių naudojimas nėra būtinas ar reikalingas VPP veikimui užtikrinti.
  • 29VPP turi būti sukonfigūruota taip, kad leistų Užsakovui įgyvendinti BDAR numatytas duomenų subjektų teises (teisę būti informuotam, susipažinti, reikalauti ištaisyti, būti pamirštam, apriboti tvarkymą, nesutikti, teisę į duomenų perkeliamumą).
  • 30Visi Užsakovo Diegėjui perduoti duomenų subjektų prašymai neturi būti papildomai apmokestinami viso VPP naudojimo metu.
  • 31Diegėjas turi užtikrinti, kad Užsakovo duomenys nebus perduodami už Europos ekonominės erdvės ribų, nebent egzistuotų bent viena iš BDAR V skyriuje numatytų perdavimo išimčių.
  • 32Diegėjas privalo užtikrinti, kad visa VPP veikimui reikalinga aparatinė ir programinė įranga, įskaitant licencijas, programinį kodą, saugos (šifravimo) raktus ir kt., yra valdoma ir kontroliuojama, užtikrinant, kad VPP kūrimui, palaikymui ir vystymui būtų naudojama tik leistina ir licencijuota aparatinė ir programinė įranga.
  • 33VPP ir jos komponentai negali turėti nutrauktos gamybos komponentų (end-of-life product).
  • 34Jeigu VPP turi integraciją su Užsakovo ypatingos svarbos informacine infrastruktūra (YSII), diegiamai VPP yra taikomi LR Kibernetinio saugumo YSII techniniai reikalavimai.
  • 35Diegėjas privalo pateikti dokumentaciją, kurioje būtų nurodyta kaip Diegėjo VPP bus integruojama su Užsakovo pateiktomis sistemomis, detalizuojant naudojamą programinę ir techninę įrangą, IT/OT technologijas, protokolus ir sujungimo būdus.

Architektūros ir infrastruktūros reikalavimai

  • 1VPP infrastruktūros sprendimas neturėtų nepagrįstai riboti galimybių ateityje keisti ar plėsti virtualizacijos, talpinimo ar vykdymo technologijas.
  • 2VPP serveriai turi būti integruoti į esamą Užsakovo naudojamą virtualizacijos platformą (pvz., VMware ar lygiavertę), suderinamą su Užsakovo infrastruktūra.
  • 3Jeigu VPP sprendimo architektūra naudoja konteinerių technologijas, Diegėjas turi užtikrinti, kad jos būtų suderinamos su Užsakovo infrastruktūros, saugos ir eksploatavimo reikalavimais.
  • 4VPP nauji serveriai ir kita IT įranga kiekvienoje serverių spintoje neturi viršyti bendros 3 kW elektros maitinimo galios pagrindinio maitinimo PDU įrenginyje ir bendros 3 kW galios rezervuojančio maitinimo PDU įrenginyje.
  • 5VPP serveriai turi būti jungiami prie duomenų perdavimo tinklo įrenginių per šviesolaidines sąsajas.
  • 6VPP serveriai turi būti jungiami prie esamų duomenų perdavimo tinklo komutatorių. Esant VPP poreikiui duomenų perdavimo tinklo komutatoriai turi būti plečiami.
  • 7Šviesolaidinių Ethernet sąsajų sparta turi būti ne mažesnė kaip 10 Gb/s.
  • 8Serveriai turi naudoti esamą SAN sistemą išplečiant ją pagal VPP poreikį.
  • 9Vidiniai serverių diskai gali būti naudojami tik tiek kiek reikia virtualizacijos hipervizoriaus veikimui.
  • 10Serverių ryšiai su SAN gali būti vykdomi iSCSI arba NVMe-TCP protokolu.
  • 11Užsakovo klasterį sudarančio esamo serverio pagrindiniai techniniai parametrai: procesorių tipas – 3,6 GHz, 16 branduolių, x86 architektūros; procesorių – 2 vnt.; operatyvioji atmintis – DDR5-5600; operatyviosios atminties kiekis – 512 GB; hipervizoriaus diskas – 480 GB; SAN – iSCSI; tinklas – SFP28 Ethernet 10/25 GbE 4 vnt.; maitinimo šaltiniai – 2 vnt. po 1000 W; virtualizacijos platforma – VMware.

Dokumentai11

  • 2_priedas_Techninės_specifikacijos_projektas.docx
  • 3_priedas_Reikalavimai_tiekėjų_kvalifikacijai_preliminarūs.docx
  • 5_priedas_Paslaugu pirkimo pardavimo sutarties BD.docx
  • 5_priedas_Paslaugu pirkimo pardavimo sutarties SD.docx
  • 6_priedas_Pasiūlymo forma.docx
  • 9.1._priedas_Privalomų funkcinių reikalavimų atitikimas_projektas.xlsx
  • 1_priedas_Klausimu_atsakymu lentele (pildymui).docx
  • 2842_7813589.pdf
  • Kvietimas rinkos konsultacijai.docx
  • 9.2._priedas_Sistemos demonstravimo veiklos scenarijai_projektas.docx
  • 4_priedas_Ekonominio_naudingumo_vertinimo_ metodika_preliminari.docx
tendis.lt · Sukurta recodin.lt