Achiziție - Implementarea Platformei Integrate de Monitorizare

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?

... afișează tot conținutul

Platforma propusă trebuie să asigure conectivitatea nativă cu soluția existentă de telefonie (Server PBX) utilizată de autoritatea contractantă, pe baza protocolului standard SIP, fără a condiționa utilizarea unei anumite mărci sau a unui server telefonic proprietar.
În acest context, este obligatoriu ca platforma să poată gestiona apeluri de intrare și apeluri de ieșire, configurabile individual pentru fiecare utilizator/operator, permițând definirea drepturilor și scenariilor de comunicare specifice (apeluri directe, preluare apeluri, apeluri de urgență, broadcast etc.).
Pentru îndeplinirea acestei funcționalități, este permisă utilizarea unei componente terțe (third-party), cu condiția ca aceasta:
• să fie complet integrată în interfața de lucru a platformei, fără a necesita aplicații externe pentru operare;
• să funcționeze unificat cu restul modulelor din platformă, inclusiv corelarea cu fluxurile video și alertele;
• să permită integrarea cu centrala SIP existentă și să fie compatibilă cu protocoalele și configurările actuale ale rețelei VoIP.
Funcționalitatea trebuie să acopere și inițierea apelurilor către echipele din teren, într-un mod contextual, direct din interfața operatorului, inclusiv asocierea apelurilor cu evenimente sau locații video specifice (de exemplu: apăsarea unui buton de panică în aplicație inițiază apel automat către echipa de intervenție).

... afișează tot conținutul

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ă?

... afișează tot conținutul

Cerința privind cele minimum 125 de dispozitive ANPR cu procesare pe server (4K) se referă exclusiv la un mecanism de recunoaștere a numerelor de înmatriculare bazat pe procesare centralizată (server-based).
Nu este vorba despre camere cu LPR integrat (edge) – acestea sunt tratate separat, în alte cerințe. Aceste camere 4K necesită analiză LPR pe server, fie pentru că nu dispun de modul LPR integrat, fie pentru că acel modul este insuficient pentru nivelul de acuratețe și complexitate analitică solicitat în proiect (ex. procesare pe liste, corelare cu alerte, prelucrare avansată).
Soluția presupune preluarea fluxurilor video de la aceste camere de înaltă rezoluție și procesarea acestora de un modul software LPR dedicat, instalat pe server.

... afișează tot conținutul

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.

... afișează tot conținutul

Cerințele privind capacitățile minime solicitate – respectiv 125 dispozitive ANPR, 100 fluxuri de analiză video avansată, 20 dispozitive pentru recunoaștere facială, 20 utilizatori platformă, 15 utilizatori analiză video, 15 utilizatori gestionare incidente, 10 conexiuni API – reprezintă cerințe cumulative privind volumul funcțional, dar modul de licențiere nu este impus într-o formă unitară, ci este la alegerea ofertantului, în funcție de arhitectura și modelul de licențiere al soluției propuse.
Prin urmare, se acceptă ca anumite licențe să acopere mai multe funcționalități, dacă acest lucru este nativ în modelul de licențiere oferit. De exemplu:
• Dacă o licență de analiză video avansată include și funcționalitatea de recunoaștere facială, atunci nu este necesară o licență separată pentru facial recognition;
• Dacă licențele ANPR sunt parte dintr-un pachet de analiză video generală, ele pot fi luate în considerare ca acoperind cerințele respective.
Condiția esențială este ca oferta să includă licențe care acoperă complet și explicit volumul minim solicitat pentru fiecare funcționalitate, indiferent de modul în care acestea sunt licențiate sau combinate, cu condiția ca acestea nu impun careva limitări de utilizare, sau anumite licențe/funcționalități nu impun limitări funcționale.
Este important ca aceste corelații să fie prezentate clar în propunerea tehnică, pentru a evita interpretări subiective la etapa de evaluare.
Iar licențele trebuie să fie posibil de atribuit într-un mod dinamic pe dispozitive/fluxuri după decizia beneficiarului.

... afișează tot conținutul

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.

... afișează tot conținutul

Cerința nr. 283 se referă atât la exportul înregistrărilor video brute, cât și la exportul datelor asociate (metadate), generate sau corelate în cadrul platformei. Prin urmare, în afară de înregistrările video, este avută în vedere și capacitatea de a exporta spre exemplu următoarele tipuri de date:
• metadate extrase automat din fluxurile video (ex. număr de înmatriculare, marcă, culoare, direcție de deplasare);
• evenimente și alerte înregistrate în sistem, inclusiv cele generate de analize video sau reguli de securitate;
• jurnale de activitate și incidente, inclusiv date despre acțiunile operatorilor;
• statistici și rapoarte configurabile pe baza datelor colectate;
• fișiere de audit sau alte elemente administrative.
Scopul acestei funcționalități este de a permite utilizarea acestor informații în aplicații externe (ex: aplicații de analiză forensică, rapoarte instituționale, dosare de investigație) sau pentru integrare în alte platforme, prin formate standardizate.

... afișează tot conținutul

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?

... afișează tot conținutul

În lipsa unei referințe clare și directe în documentația de atribuire pentru „pct. 32, lit. b.”, precizăm că cerințele privind integrarea cu sisteme ALPR (Automatic License Plate Recognition) nu impun limitări privind tipologia dispozitivelor — fixe sau mobile.
Prin urmare, modulul ALPR al platformei trebuie să fie compatibil atât cu camere fixe, cât și cu sisteme mobile, în condițiile prevăzute de specificațiile tehnice din caietul de sarcini. Oferta trebuie să asigure flexibilitate funcțională și compatibilitate cu echipamentele existente sau planificate, indiferent dacă acestea sunt montate pe stâlpi, vehicule de patrulare, drone sau alte suporturi mobile.

... afișează tot conținutul

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?

... afișează tot conținutul

Întrebarea formulată nu conține o referință tehnică clară, însă putem confirma că soluția ofertată trebuie să corespundă cerințelor minime obligatorii prevăzute în documentația de atribuire, inclusiv cerințelor privind interoperabilitatea, conform specificațiilor tehnice și arhitecturii solicitate.
Totodată, în spiritul unei bune practici tehnologice, se acceptă ca soluția propusă să utilizeze o arhitectură deschisă, scalabilă și modulară, care să permită integrarea viitoare de noi componente, module și tehnologii, fără a afecta integritatea sau funcționalitatea de bază a platformei.
Important de menționat este că soluția trebuie să fie de un grad industrial, așa cum este definit în documentația de atribuire.

... afișează tot conținutul

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?

... afișează tot conținutul

Cerințele menționate la pct. 13 vizează funcționalități de auditare și jurnalizare completă a activităților din platformă, în conformitate cu principiile de securitate cibernetică și trasabilitate operațională.
Platforma trebuie să dispună de un mecanism centralizat de audit și jurnalizare, care să permită:
• înregistrarea tuturor acțiunilor relevante ale utilizatorilor, administratorilor și ale componentelor sistemului (acces, modificări, alarme, interacțiuni etc.);
• stocarea securizată și protejată împotriva modificării a acestor jurnale (log-uri);
• accesul controlat și filtrat la datele de audit, conform drepturilor și rolurilor definite;
• exportul jurnalelor în formate standard (ex: syslog, JSON, CSV) pentru integrare cu soluții terțe (SIEM, SOC etc.);
• respectarea cerințelor din standarde internaționale precum ISO/IEC 27001 și/sau OWASP Logging Guidelines.
• Expunerea interfețelor API pentru integrarea cu sisteme terțe de analiza si jurnalizare.
Se acceptă și se încurajează ca platforma să fie deschisă și interoperabilă, permițând integrarea cu soluții terțe de monitorizare și analiză de securitate (ex. Splunk, ELK, Graylog), cu condiția ca toate cerințele funcționale de audit și jurnalizare să fie pe deplin acoperite.

... afișează tot conținutul

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.

... afișează tot conținutul

1. Referitor la subpunctul a – Modul de gestionare a evenimentelor de trafic rutier, bazat pe recunoașterea numerelor de înmatriculare (ANPR):
Prin „gestionarea evenimentelor de trafic rutier” în contextul platformei bazate pe ANPR se înțelege capacitatea acesteia de a detecta, înregistra, clasifica, corela și acționa automat asupra unor situații predefinite. Scenariile relevante includ, dar nu se limitează la:
• Detectarea și înregistrarea accesului vehiculelor din liste negre (ex. vehicule furate, fără drept de acces);
• Identificarea vehiculelor care depășesc limitele temporale sau zonele geografice permise (geofencing, overstay);
• Corelarea vehiculului cu o anumită încălcare sau incident raportat (ex. asociere automată cu incident de blocare rutieră);
• Gestionarea accesului în zone restricționate prin alerte automate, declanșare bariere, notificări;
• Raportare automată și jurnalizare a incidentelor rutiere identificate pe baza plăcuțelor.
Prin „gestionare” se înțelege atât monitorizarea pasivă cu alertare, cât și intervenția automată sau asistată (notificare dispecer, acțiune fizică – ex. deschidere/închidere barieră, asociere incident). Totodată gestionarea se refera la toate cerințele funcționale, minime obligatorii pentru acest modul.
Scenariile considerate relevante pentru gestionare în contextul traficului rutier ar fi ca exemplu, dar nu se limitează la:
• Detectarea vehiculelor de interes (ex. listă neagră, furate, suspendate),
• Acces neautorizat într-o zonă controlată,
• Identificarea vehiculelor fără plăcuțe vizibile sau parțiale,
• Verificări de conformitate periodică (revizie tehnică/asigurare),
• Monitorizarea traficului pe baza tipului de vehicul (camion, autobuz, taxi etc.),
• Identificarea vehiculelor care încalcă limitele de viteză

2. Referitor la subpunctul d – Modul de analiză inteligentă a fluxurilor video:
Integrarea unui modul de analiză inteligentă a fluxurilor video într-o platformă unificată de monitorizare și control răspunde unei nevoi reale și stringente a autorităților care gestionează siguranța publică și rutieră: aceea de a identifica rapid și automat situațiile cu potențial de risc, fără a depinde exclusiv de intervenția operatorilor umani. Astfel, cerința privind existența acestui modul nu este una arbitrară, ci reflectă o abordare proactivă și modernă în gestionarea siguranței, în linie cu tendințele internaționale și bunele practici în domeniul securității inteligente.
Pe lângă scenariile deja menționate (obiecte abandonate, persoane suspecte, congestionări etc.), platforma trebuie să acopere un set extins de comportamente anormale, relevante pentru contextul operativ. Lista minimă recomandată, care trebuie acoperită, include:
• Trecere în sens interzis / sens opus;
• Staționare neregulamentară prelungită în zone critice;
• Deplasare pietonală în zone nepermise (ex. carosabil);
• Escaladarea sau forțarea unui perimetru;
• Formarea de grupuri în zone de interes - Aglomerații neobișnuite;
• Congestii de persoane sau vehicule
• Alergare, agitație excesivă sau comportament agresiv identificabil video;
• Trafic invers în zone pietonale sau parcări.
• Persoane căzute sau întinse la sol
Platforma trebuie să permită definirea scenariilor pe reguli personalizabile, dar minimul acceptat trebuie să acopere lista de mai sus pentru a asigura comparabilitatea între ofertanți și respectarea cerințelor minime.

... afișează tot conținutul

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.

... afișează tot conținutul

Cerința privind includerea nativă a tuturor modulelor funcționale dezvoltate și menținute de același producător este una opțională și nu constituie o condiție de descalificare

... afișează tot conținutul

Î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.

... afișează tot conținutul

Formularea prezentă în cerința nr. 19 trebuie înțeleasă în contextul general al cerințelor funcționale definite în caietul de sarcini, care trebuie citit și interpretat în ansamblu, nu izolat.
Obligația platformei de a permite integrarea cu sisteme terțe vizează interoperabilitatea tehnologică necesară pentru funcționarea coerentă a soluției în cadrul unui ecosistem instituțional existent sau viitor, și nu implică integrarea nedeterminată cu orice sistem arbitrar.
Prin urmare, această cerință se referă exclusiv la capacitatea tehnică de deschidere și interoperabilitate, în măsura în care este solicitată prin cerințele funcționale specifice (ex: integrare cu sisteme VoIP, ALPR, sisteme de control acces, GIS, dispecerat, etc.). Nu se solicită demonstrarea unei integrări concrete cu sisteme nemenționate expres.
Orice interpretare care extrapolează această cerință în afara limitelor stabilite de documentația tehnică este nefondată și nu reflectă conținutul procedurii de atribuire.

... afișează tot conținutul

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ă.

... afișează tot conținutul

Cerința nr. 30, în special subpunctul a), face referire explicită la integrarea cu infrastructura VoIP existentă prin utilizarea de protocoale deschise și standardizate, în special SIP (Session Initiation Protocol).
Prin urmare, soluția propusă trebuie să asigure compatibilitate deplină cu un server SIP standard, indiferent de producătorul acestuia, fără a impune soluții închise, proprietare sau integrare condiționată de elemente externe.
Responsabilitatea ofertantului se limitează la demonstrarea suportului nativ al platformei pentru protocoalele SIP și interoperabilitatea funcțională cu un server VoIP existent, în condițiile definite de standardele internaționale (RFC 3261 și următoarele).
Administrarea, licențierea și operarea efectivă a serverului SIP existent nu fac obiectul acestei proceduri de achiziție, iar solicitarea privind denumirea sau modelul serverului nu este relevantă în condițiile în care se specifică clar că protocolul trebuie să fie standard și deschis.
Cerința vizează abilitatea platformei de a se conecta și comunica în mod compatibil cu infrastructura existentă, nu de a livra sau administra acea infrastructură. Orice soluție care respectă specificațiile SIP standard este considerată conformă.

... afișează tot conținutul

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ă.

... afișează tot conținutul

Termenul „nativ” nu este utilizat în sens vag sau interpretabil, ci are o semnificație clară: funcționalitate inclusă direct în platformă, dezvoltată și menținută de același producător, testată și stabilă, fără integrare externă sau dezvoltări personalizate.
Nu se acceptă substituirea acestor funcționalități cu plugin-uri, SDK-uri terțe sau soluții custom. Integrările cu sisteme externe sunt tratate separat și nu înlocuiesc cerințele native.
Toate cerințele sunt minime și obligatorii, iar documentația trebuie interpretată în ansamblu. Soluțiile experimentale sau dezvoltările la comandă nu sunt conforme.
Această este perfect justificată si de reducerea riscurilor de interoperabilitate da și predictibilitate în costuri și efort de integrare;

... afișează tot conținutul

Cat este de critică și importantă interoperabilitate prin standarde deschise solicitate - utilizand protocoale precum WMS (Web Map Service), WFS (Web Feature Service) si REST API, pentru schimb de date cu alte sisteme GIS?

... afișează tot conținutul

Implementarea acestor standarde deschise sunt necesare pentru îndeplinirea cerințelor privind vizualizarea și corelarea evenimentelor în timp real pe hărți, cu atît mai mult este o cerință opțională și nu limitează ofertanții.

... afișează tot conținutul

Stimați reprezentanți ai autorității contractante,
Analizând documentația de atribuire și grila de punctaj, observăm o lipsă de transparență și previziune în ceea ce privește costurile reale post-implementare ale platformei solicitate prin această achiziție.
Mai exact, deși sunt detaliate cu rigurozitate multiple cerințe tehnice funcționale și scenarii de utilizare, nu este clarificat în niciun punct care sunt așteptările privind:
• Costurile viitoare de dezvoltare a platformei (pentru noi funcționalități sau adaptări);
• Costurile licențelor suplimentare pentru extinderea funcționalităților;
• Costurile de suport și mentenanță pentru perioada care depășește termenul minim obligatoriu (3 sau 5 ani);
• Costul total estimat de proprietate (TCO) pentru o perioadă predictibilă de utilizare a soluției – de exemplu, 10 ani.
Considerăm că evaluarea doar a costului inițial de achiziție fără a lua în considerare costurile reale și recurente de operare, mentenanță și extindere poate duce la selecția unei soluții aparent mai ieftine, dar care în realitate implică costuri mult mai mari pentru instituția publică pe termen mediu și lung.
Mai mult, remarcăm că diferența de punctaj pentru oferirea unui suport pe 5 ani (față de minimul de 3 ani) este de doar 45 de puncte dintr-un total de aproximativ 860, ceea ce, în opinia noastră, nu reflectă importanța critică a fiabilității, continuității și costurilor de suport pentru o platformă de o asemenea anvergură și complexitate operațională.
Prin urmare, solicităm respectuos:
1. Introducerea unui criteriu distinct de evaluare privind TCO (Total Cost of Ownership) – pe o perioadă de minimum 10 ani, sau, în lipsa acestuia, obligativitatea declarării costurilor anuale de suport pentru fiecare an suplimentar față de perioada minimă asigurată;
2. Alocarea unui punctaj suplimentar, de minimum 100 de puncte, pentru ofertanții care propun un cost anual de întreținere și suport mai mic decât competiția, reflectând astfel impactul bugetar pe termen lung asupra instituției publice și facilitând o alegere cu adevărat sustenabilă.
Considerăm că introducerea acestui criteriu este nu doar logică, ci esențială pentru asigurarea transparenței, eficienței economice și a responsabilității financiare în procesul de achiziție publică.

... afișează tot conținutul

Ofertarea unor ervicii de suport tehnic, mentenanță și garanție de producător pentru soluția livrată pe o perioadă de minim 5 ani este una opțională și nu limitează ofertanții.

... afișează tot conținutul

Stimați reprezentanți ai autorității contractante,
În ceea ce privește cerința nr. 293, care prevede ca „platforma trebuie să includă un motor de reguli capabil să analizeze și să coreleze automat mii de evenimente pe secundă, clasificându-le în incidente prioritizate”, vă rugăm respectuos să oferiți clarificări esențiale privind următoarele aspecte:
1. Ce se consideră evenimente în acest context? Sunt ele exclusiv generate de sistemele VMS (video analytics, ANPR etc.), sau includ și surse externe (sisteme terțe, senzori, alarme etc.)?
2. Care este definiția exactă a unui „incident prioritizat”? Pe baza cărui set de reguli sau clasificări se face această prioritizare?
3. Se dorește o funcționalitate similară unui sistem de corelare de tip SIEM, SOAR sau Business Rules Engine? Acest tip de funcționalitate este extrem de avansat, depășind sfera unei platforme VMS clasice.
Dorim să subliniem că majoritatea soluțiilor VMS din industrie nu includ în componenta sa un motor de reguli de acest nivel de complexitate, ci se integrează, atunci când este cazul, cu sisteme externe de corelare, orchestrare sau analiză avansată menit anume acestor funcționalități extra.
În acest sens, vă rugăm să reanalizați caracterul obligatoriu al cerinței, întrucât:
• Soluțiile standard din piață oferă funcționalități avansate de detecție și alertare, însă nu sunt concepute ca motoare de corelare în masă a evenimentelor raportat la „analiza a mii de evenimente pe secunda”;
• Cerința poate restrânge nejustificat concurența, favorizând anumite soluții, care presupun costuri majore și arhitecturi extinse, nejustificate dacă nu sunt clar precizate obiectivele concrete urmărite prin această corelare masivă.
Cerem ca această cerință să fie reanalizată și eventual transformată într-o cerință opțională, cu punctaj suplimentar acordat pentru ofertanții care dispun de un astfel de modul, integrat sau extern, astfel încât să fie menținută competiția deschisă și echilibrată între soluțiile din piață. În caz contrar rugăm să numiți minim 2-3 soluții din domeniu care dispun de acest functional specializat, care va demonstra contrariul că această solicitare nu limiteaza dreptul la participare tuturor participantilor?

... afișează tot conținutul

Cerința nr. 293 este formulată în contextul modulului de gestionare a situațiilor de interes, definit clar în documentație ca fiind unul dintre modulele de bază ale platformei („c. modul de gestionare a situațiilor de interes, destinat organizării și corelării evenimentelor relevante pentru siguranța rutieră și publică”).
Prin urmare, nu se acceptă eliminarea sau transformarea acestei cerințe într-una opțională. Platforma ofertată trebuie să includă nativ un motor de reguli performant, capabil să proceseze în timp real un volum mare de evenimente și să coreleze automat datele din surse multiple – video, ANPR, alerte, senzori, integrări externe – pentru a genera incidente structurate, prioritizate și acționabile.
Cerința reflectă nevoia autorității contractante de a implementa o soluție matură, scalabilă și dovedită, care să poată răspunde sarcinilor reale din teren, în special în contexte operaționale complexe și cu risc ridicat.
Platforma propusă trebuie să respecte toate cerințele minime obligatorii, iar ofertele care nu includ un astfel de modul nu pot fi considerate conforme.

... afișează tot conținutul

„Platforma trebuie să asigure actualizarea automată și manuală a listei de interes, cu posibilitatea de a adăuga sau elimina vehicule pe baza informațiilor furnizate de autorități” – vă rugăm să clarificați:
În ce format și prin ce mijloace vor fi furnizate listele de interes de către autoritățile competente?

... afișează tot conținutul

Listele de interes vor fi furnizate prin intermediul unui API, pus la dispoziție de autoritățile competente. Platforma trebuie să asigure integrarea cu acest API, precum și posibilitatea de gestionare manuală a listelor, conform cerinței.

... afișează tot conținutul

În legătură cu cerința 180 – vă rugăm să clarificați:
Ce anume se are în vedere prin „vizualizarea traseului”?
Este suficientă afișarea cronologică a locațiilor înregistrate?

... afișează tot conținutul

Prin „vizualizarea traseului” se înțelege reprezentarea grafică în timp real a deplasării pe hartă, pentru acele dispozitive care transmit metadate de localizare.
Afișarea cronologică simplă nu este suficientă – platforma trebuie să permită trasarea dinamică și interactivă a traseului parcurs.

... afișează tot conținutul

Referitor la cerința 182 – vă rugăm să specificați:
1. Care este sistemul de gestionare a contravențiilor utilizat în prezent de către autoritatea contractantă?
2. Ce tip de interfață sau protocoale de integrare sunt disponibile

... afișează tot conținutul

Cerința este formulată clar: integrarea se va realiza prin intermediul unor interfețe API deschise, puse la dispoziție de autoritatea contractantă.
Numele sistemului existent nu este relevant, întrucât interoperabilitatea se va asigura prin standarde de integrare, nu prin compatibilitate specifică de produs.

... afișează tot conținutul

Referitor la cerința 189 – vă rugăm să ne oferiți următoarele detalii:
1. Care sunt sistemele concrete de gestionare a incidentelor cu care se preconizează sincronizarea platformei?
2. Ce metodă sau protocoale de sincronizare sunt utilizate sau se doresc

... afișează tot conținutul

Vă rugăm să examinați cerințele în ansamblu, nu izolat. Funcționalitatea de gestionare a incidentelor trebuie să fie parte integrantă a soluției ofertate, nu dependentă de sincronizarea cu un sistem extern.
Integrarea cu alte sisteme, acolo unde este necesară, se va realiza prin interfețe API, conform specificațiilor tehnice generale din documentația de atribuire.

... afișează tot conținutul

Referitor la cerința nr. 205 privind reacția automată a camerelor PTZ în funcție de evenimente detectate de alte sisteme, vă rugăm să specificați:
1. Care sunt tipurile de evenimente acceptate sau prevăzute ca declanșatori pentru acțiunea PTZ?
2. Cum trebuie să reacționeze camera – este vorba despre trimiterea la un preset, activarea urmăririi automate (auto-tracking), sau alt comportament?

... afișează tot conținutul

Cerința este clară, minimă și obligatorie. Platforma trebuie să permită declanșarea automată a acțiunilor PTZ (ex. preset, auto-tracking)

... afișează tot conținutul