Implementarea Platformei Integrate de Monitorizare

24 apr 2025, 10:01

Integrarea soluțiilor de comunicații – VoIP, pct. 30

Cum este necesar sa se asigure interoperabilitatea platformei cu infrastructura VoIP deja existentă, în special cu soluții bazate pe SIP? Integrarea necesită componente sau licențieri proprietare sau este permisă folosirea unor soluții terțe fără restricții? De asemenea, este necesarea corelarea în timp real a apelurilor VoIP cu imaginile video provenite din sistemele VMS și cu alertele sau datele operaționale, astfel încât operatorii să poată reacționa eficient în situații critice? Platforma trebuie sa permite inițierea comunicațiilor directe cu echipele din teren în acest context?

24 apr 2025, 10:02

Gestionarea datelor colectate de camerele ANPR, pct. 3.2

Pentru cele „minimum 125 de dispozitive ANPR cu procesare pe server (4K)” – este necesar un server LPR suplimentar sau este vorba despre integrarea cu camere care au deja funcționalitate LPR integrată?

24 apr 2025, 12:36

Întrebare de clarificare

Vă rugăm să confirmați dacă cerințele privind capacitățile minime solicitate (125 dispozitive ANPR, 100 dispozitive analiză video avansată, 20 dispozitive recunoaștere facială, 20 utilizatori platformă, 15 utilizatori analiză video, 15 utilizatori gestionare incidente, 10 conexiuni API) reprezintă cerințe cumulative și distincte pentru fiecare funcționalitate în parte, sau este acceptabil ca anumite licențe să acopere simultan mai multe funcționalități (ex: o licență de analiză video avansată să includă de asemenea și recunoaștere facială, sau alt exemplu licențele pentru camerele ANPR să fie parte din cele 100 fluxuri de analiză video). Vă rugăm să specificați clar dacă aceste funcționalități trebuie licențiate separat sau pot fi acoperite complementar în cadrul aceluiași tip de licență, pentru a evita interpretări subiective la etapa de evaluare.

24 apr 2025, 13:00

Clarificare referitor la cerința nr. 283

Referitor la cerința nr. 283 privind „opțiuni de export al datelor și înregistrărilor video” — vă rugăm să specificați ce tipuri de date, în afara înregistrărilor video, sunt avute în vedere pentru export? Precizarea este necesară pentru a înțelege corect cerințele funcționale și pentru a asigura conformitatea completă a soluției oferite.

24 apr 2025, 13:20

Integrarea cu sisteme de camere ALPR, pct. 32, lietra b.

Modulul ALPR trebuie să poată identifica doar plăcuțele de îmatriculare a unui sistem fix sau mobil? Sau este suficient unul din ele sau ambele?

24 apr 2025, 13:21

Interconectare si colaborare eficienta intre entitatile responsabil 2.4.

Ce tine de crearea unui ecosystem / platforme deschise intre insistutii, se accepă ca soluția ofertată să vină cu arhitecturi deschise inclusiv către terțe părți si scalabile, care sa permită adaugarea de noi module si tehnologii pe masura ce evolueaza tehnologiile?

24 apr 2025, 13:23

Audit și Jurnalizare pct. 13

Există cerințe funcționale și de conformitate pentru auditarea și jurnalizarea centralizată într-o platformă deschisă (asa cum este solicitată), care trebuie să integreze soluții terțe și să respecte standardele de securitate? Dacă da, ați putea oferi mai multe detalii legat de aceste cerințe?

24 apr 2025, 14:43

Întrebare de clarificare – cerința nr. 4

1. În legătură cu subpunctul a – modul de gestionare a evenimentelor de trafic rutier, bazat pe recunoașterea numerelor de înmatriculare (ANPR): – Vă rugăm să specificați ce tipuri de scenarii de evenimente rutiere sunt considerate relevante pentru „gestionare”. – Ce anume se înțelege prin termenul „gestionare” în acest context? 2. În legătură cu subpunctul d – modul de analiză inteligentă a fluxurilor video: – Pe lângă comportamentele menționate (obiecte abandonate, congestii, etc.), vă rugăm să indicați ce alte scenarii specifice se consideră „comportamente anormale” și trebuie acoperite de platformă? Lista ar trebui sa fie limitata la anumite cazuri predefinite si clare pentru toti ofertantii.

24 apr 2025, 14:44

Întrebare de clarificare – cerința nr. 5

Cerința privind obligativitatea ca toate modulele funcționale/subsisteme enumerate să fie incluse nativ, dezvoltate și menținute de același producător, fără integrare de soluții externe, plugin-uri sau dezvoltări personalizate, pare să favorizeze un anumit furnizor care deține în mod unic toate aceste componente. – Vă rugăm să reanalizați oportunitatea acestei cerințe și să luați în considerare eliminarea ei, pentru a nu restrânge în mod nejustificat concurența. – În cazul în care cerința rămâne neschimbată, vă rugăm să indicați cel puțin două exemple de producători care îndeplinesc în totalitate această specificație, având toate modulele dezvoltate intern, fără utilizarea altor mărci sau integratori.

24 apr 2025, 14:44

Întrebare de clarificare – cerința nr. 19

Înțelegem că platforma trebuie să dispună de o arhitectură deschisă, capabilă să permită integrarea cu sisteme terțe. Cu toate acestea, solicitarea pare a fi formulată într-un mod extrem de general și potențial nelimitat. – Vă rugăm să precizați explicit care sunt sistemele terțe concrete (tipuri sau mărci) cu care se solicită integrarea, în special în ceea ce privește categoria „alte sisteme/sub-sisteme de securitate și/sau management al fluxurilor operaționale”, având în vedere că formularea actuală poate duce la interpretări multiple. – Solicităm această clarificare întrucât cerința este marcată ca obligatorie, iar lipsa unei integrări generale (cu un sistem care nu este menționat explicit) nu ar trebui să conducă la excluderea automată a unui ofertant.

24 apr 2025, 17:46

Întrebare de clarificare – cerința nr. 30:

Referitor la cerința privind integrarea nativă cu soluții de comunicații securizate (VoIP), în special subpunctul a) privind integrarea cu infrastructura VoIP existentă utilizând protocoale deschise precum SIP: – Rugăm respectuos să confirmați dacă responsabilitatea ofertantului se limitează la asigurarea compatibilității platformei propuse cu un server SIP standard (prin suportul protocolului SIP), iar toate funcționalitățile, licențele și administrarea propriu-zisă a infrastructurii VoIP (SIP Server) nu vor constitui obiect al acestei proceduri de achiziție. – Totodată, vă rugăm să indicați ce tip/model/producător de SIP Server deține autoritatea contractantă, astfel încât să putem confirma expres capacitatea reală de integrare a platformei noastre cu infrastructura existentă. Această clarificare este necesară pentru a evita interpretări eronate și pentru a asigura o ofertare conformă, echitabilă și transparentă.

24 apr 2025, 17:56

Solicitare de clarificare

Dorim să atragem atenția asupra utilizării recurente a termenului „nativ” în multiple cerințe tehnice din caietul de sarcini, inclusiv, dar fără a se limita la următoarele puncte: 2, 5, 7, 22, 28, 30, 32, 60, 70, 72, 102, 152, 185, 212, 213. Formularea cerințelor ca „funcționalitate nativă” lasă loc de interpretare și, în opinia noastră, nu reflectă modul real și obiectiv în care sunt dezvoltate, extinse și perfecționate platformele software moderne, în special cele de tip VMS și de analiză video inteligentă. Subliniem că nicio platformă de acest tip nu este creată ca un tot unitar complet „din cutie”, cu toate funcționalitățile dorite de un anumit beneficiar dintr-un anumit domeniu (în acest caz: STI MAI și monitorizarea traficului rutier). În mod normal, astfel de platforme sunt construite modular, tocmai pentru a permite configurarea, integrarea și adaptarea acestora la infrastructura existentă a clientului (ex: camere, rețea, scenarii operaționale, standarde de securitate, etc.). Nu întâmplător, în documentația de atribuire este prevăzută o perioadă de 2 luni pentru dezvoltare și integrare și încă 1 lună pentru testare – ceea ce denotă clar că platforma se va configura și personaliza în funcție de cerințele specifice ale autorității contractante. Prin urmare, solicităm: • Excluderea termenului „nativ” din toate cerințele menționate, întrucât este o formulare care nu poate fi demonstrată tehnic sau juridic într-un mod echitabil și obiectiv pentru toți ofertanții; • Sau, în caz contrar, să fie clar definit ce înțelege autoritatea contractantă prin „funcționalitate nativă”, pentru fiecare caz în parte – în mod specific, măsurabil, demonstrabil. Considerăm că păstrarea acestei cerințe în forma actuală ar putea conduce la favorizarea nedreaptă a unui anumit furnizor, ceea ce contravine principiilor fundamentale ale achizițiilor publice: tratament egal, transparență și concurență loială.