Achiziție - Implementarea Platformei Integrate de Monitorizare (repetat)

Referitor la cerința nr. 275, privind determinarea vitezei de deplasare a vehiculelor în timp real cu o marjă de eroare de cel mult 10%, vă rugăm să specificați dacă se are în vedere utilizarea de camere video (cu funcționalitate radar integrată si certificare metrologică) sau radare specializate?
Menționăm că, în lipsa unor dispozitive hardware specializate, estimarea software a vitezei poate avea o marjă de eroare flotanta si instabila și ar putea servi drept proba juridical de constatare a unei incalcari.
Pentru a asigura un tratament egal al ofertanților, vă rugăm să precizați dacă această cerință poate fi retrasa, întrucât sunt lezate drepturile unor tratamente echitabile si participare ne-restrictiva.

... afișează tot conținutul

Cerința nr. 275 vizează determinarea vitezei vehiculelor în scopuri de analiză și investigare, nu pentru constatarea juridică a contravențiilor. În acest sens, nu se solicită obligativitatea certificării metrologice.
Se solicită asigurarea unui mecanism tehnic care nu implică utilizarea unor senzori fizici de măsurare și care permite o estimare orientativă a vitezei cu marja de eroare menționată (≤10%), în scopuri analitice.
Această abordare nu restricționează participarea ofertanților și permite adaptarea la arhitecturi hibride sau modulare.

... afișează tot conținutul

Referitor la cerința nr. 271, privind suportul pentru formatele de compresie video H.264, H.265, MPEG-4, MPEG-2 și MJPEG, vă rugăm să reevaluați necesitatea includerii formatului MPEG-2, întrucât acest standard este considerat tehnologic depășit și ineficient din punct de vedere al compresiei și stocării.
Adnotam faptul, că începând cu data de 3 ianuarie 2024, toate brevetele aferente MPEG-2 au expirat la nivel mondial, ceea ce face ca standardul să nu mai fie susținut activ de majoritatea producătorilor de soluții moderne de supraveghere video.
În acest context, pentru a evita impunerea unor cerințe anacronice care pot restrânge inutil participarea unor soluții moderne, vă rugăm să reconsiderați eliminarea MPEG-2 din lista de formate obligatorii.

... afișează tot conținutul

Cerința privind suportul pentru formatele H.264, H.265, MPEG-4, MPEG-2 și MJPEG a fost formulată pentru a asigura compatibilitatea retroactivă cu dispozitive video existente sau cu înregistrări istorice provenite din infrastructura deja implementată în anumite locații.
Totodată, autoritatea contractantă confirmă că utilizarea activă a formatului MPEG-2 nu este obligatorie pentru funcționarea curentă, ci doar pentru scopuri de interoperabilitate sau import de conținut anterior.

... afișează tot conținutul

Referitor la cerința nr. 234, privind integrarea cu Registrul de Stat al Populației (RSP) și Registrul Informațiilor Criminalistice și Criminologice (R1CC), vă rugăm să clarificați dacă platformei VMS i se solicită doar capabilitatea de a primi și utiliza informațiile transmise printr-un API furnizat de autoritatea competentă.
Menționăm că aceste sisteme sunt gestionate de instituții publice și accesul la ele este strict reglementat. Astfel, orice sincronizare automată, inclusiv extragerea imaginilor persoanelor căutate, presupune existența unui mecanism de interoperabilitate pus la dispoziție de către autorități, și nu poate fi responsabilitatea directă a VMS-ului.
În acest sens, vă rugăm să specificați:
• dacă există un API documentat pentru accesul la aceste date pus la dispozitie dupa incheierea unui contract;
• dacă sincronizarea periodică se va face printr-un serviciu extern care livrează datele către VMS;
• și dacă această cerință poate fi reformulată astfel încât platforma să suporte integrarea, în cazul în care autoritatea furnizează accesul și formatele de date necesare, dar nu invers.

... afișează tot conținutul

Cerința nr. 234 vizează funcționalitățile platformei, nu a modului VMS, care este parte componenta a acesteia, prin urmare platforma trebuie sa fie capabila si sa implementeze se referă la capacitatea tehnică a platformei de a permite integrarea cu registrele menționate, nu la responsabilitatea directă a ofertantului de a implementa integrarea în lipsa unui mecanism oficial de interoperabilitate. Aspectele de reglementare țin exclusiv de responsabilitatea Autorității Contractante. Ofertantul trebuie sa asigure ca oferta este pe deplin conforma cerințelor si corespunde nevoilor si așteptărilor autorității contractante.
Prin urmare, cerința se menține, dar interpretarea sa trebuie înțeleasă ca neimpunând obligația realizării efective a integrării în lipsa accesului legal, ci doar disponibilitatea tehnică a platformei pentru a asigura interoperabilitatea in modul definit in cerințele tehnice

... afișează tot conținutul

Referitor la cerința nr. 133, conform căreia platforma trebuie să suporte dezvoltarea și implementarea de algoritmi personalizați pentru analiza datelor, vă rugăm să specificați în mod clar:
1. Ce tip de algoritmi se au în vedere?
2. Ce nivel de acces este vizat?
3. Vă rugăm să furnizați exemple concrete de cazuri de utilizare pe care autoritatea le are în vedere pentru a putea evalua relevanța și fezabilitatea tehnică a cerinței în raport cu funcționalitatea unui VMS.

... afișează tot conținutul

Cerința nr. 133 vizează funcționalitățile platformei, nu a modului VMS, care este parte componenta a acesteia, prin urmare platforma trebuie sa fie capabila si sa implementeze o arhitectura deschisa care să permită dezvoltarea și integrarea de algoritmi personalizați(inclusiv alte subsisteme) pentru analiza datelor operaționale sau video în cadrul platformei, fără a limita utilizarea la funcționalitățile predefinite ale producătorului.
Clarificări:
a. Prin „algoritmi personalizați” se înțelege posibilitatea de a dezvolta sau integra module proprii (ex. scripturi, modele AI/ML, reguli analitice) pentru prelucrarea datelor, recunoașterea de tipare comportamentale, clasificarea obiectelor sau alte analize relevante pentru securitate.
b. Nivelul de acces vizat presupune acces la API-uri, SDK sau interfețe de extensie (plug-in framework) care permit adăugarea acestor componente, fără a necesita modificări ale codului sursă al platformei.
Exemple de cazuri de utilizare vizate:
• dezvoltarea unui algoritm care să detecteze comportamente anormale într-un anumit spațiu (ex: traversare în afara trecerii de pietoni în zone aglomerate);
• implementarea unui filtru AI pentru recunoașterea anumitor obiecte (ex: arme albe, saci voluminoși abandonați);
• aplicarea unor algoritmi specifici pentru detectarea anumitor vehicule (ex: transport agabaritic, vehicule școlare, etc.).
Cerința nu impune livrarea unor algoritmi concreți, ci doar deschiderea arhitecturii platformei pentru astfel de integrări viitoare, în funcție de necesitățile beneficiarului. Această flexibilitate este esențială pentru adaptarea sistemului în timp și nu presupune favorizarea unui anumit furnizor.

... afișează tot conținutul

Referitor la cerința nr. 125, vă rugăm să specificați dacă prin „detectarea și prevenirea tentativelor de acces neautorizat” se face referire la:
• a) accesul fizic în perimetre securizate (prin integrare cu sisteme de control acces),
• b) accesul neautorizat la platforma software (securitate IT), sau
• c) ambele.
Totodată, vă rugăm să precizați dacă se acceptă implementarea funcționalității de prevenție și blocare automată prin integrare cu sisteme externe (control acces, firewall etc.), întrucât platformele VMS nu blochează direct accesul, ci pot emite comenzi automate către subsisteme care gestionează fizic sau logic accesul.

... afișează tot conținutul

Cerința nr. 125 se referă atât la prevenirea accesului logic la platforma software, deci vizează Acces logic/software – detectarea și prevenirea tentativelor de acces neautorizat în platforma informatică (ex: autentificări eșuate repetate, acces din locații nesigure, tentative de escaladare a privilegiilor etc.), conform cerințelor de securitate IT și audit menționate în alte puncte ale caietului de sarcini

... afișează tot conținutul

Vă rugăm să specificați dacă cerința privind utilizarea de chei de criptare generate aleatoriu, cu rotație periodică, se referă la:
• criptarea transmisiilor video între camere și platformă (ex: RTSP over TLS),
• criptarea metadatelor și a fișierelor în timpul stocării,
• sau la criptarea comunicațiilor de rețea între componente (servere, clienți).

... afișează tot conținutul

Cerința nr. 115, referitoare la utilizarea de chei de criptare generate aleatoriu, cu rotație periodică, se aplică în mod extins tuturor nivelurilor de comunicație și stocare în cadrul platformei, astfel:
a. Criptarea transmisiilor video între camere și platformă – Da, acolo unde este posibil (în funcție de capabilitățile camerelor), transmisia video trebuie să fie protejată (ex. prin RTSP over TLS sau protocoale similare securizate), pentru a preveni interceptarea datelor video în rețea.
b. Criptarea metadatelor și a fișierelor în timpul stocării – Da, cerința include și criptarea la nivel de storage (atât pentru datele video, cât și pentru metadate, fișiere jurnal, baze de date interne etc.), utilizând algoritmi și chei moderne de criptare, gestionate conform unei politici interne de rotație.
c. Criptarea comunicațiilor de rețea între componente (servere, clienți) – Da, platforma trebuie să asigure canale securizate între componentele sale interne (servere, stații de lucru, interfețe de administrare), prin protocoale precum TLS, VPN, SSH sau echivalente.
Despre rotația cheilor: Cerința de rotație periodică a cheilor implică:
 generare aleatorie a noilor chei criptografice,
 actualizarea acestora fără afectarea serviciilor critice,
 gestionare centralizată și auditabilă a cheilor (ex. printr-un modul de tip KMS – Key Management System).
Cerința are un caracter general de securizare a întregului ecosistem, iar implementarea poate fi realizată atât nativ în platformă, cât și prin integrare cu soluții specializate de criptare și gestionare a cheilor.

... afișează tot conținutul

Referitor la managementul centralizat al cheilor de criptare, vă rugăm să precizați dacă este acceptabil ca această funcționalitate să fie realizată prin integrarea platformei VMS cu un sistem de tip KMS (Key Management System) furnizat de beneficiar sau terți? Consideram ca este o cerinta care limiteaza particparea echitabila la concurs prin impunerea conditiilor irealizabile de catre alti furnizori, or rugam enumerarea solutiilor care pot indeplini cerinta data.

... afișează tot conținutul

Cerința nr. 116 vizează funcționalitățile platformei, nu a modului VMS, care este parte componenta a acesteia, prin urmare platforma trebuie sa fie capabila sa gestioneze cheile intr-un mod centralizat, sau prin integrarea cu solutii specializate care asiugra acest lucru.
Clarificare: Scopul cerinței este asigurarea unui nivel ridicat de securitate în gestionarea cheilor criptografice, astfel încât procesul de criptare/decriptare să fie controlat centralizat și în siguranță. Această cerință nu impune utilizarea unei soluții închise sau proprietare, ci permite soluții compatibile, interoperabile, deschise.

... afișează tot conținutul

Vă rugăm să specificați ce tipuri de activități sunt considerate „tentative de acces neautorizat sau abuz” în contextul activității administratorilor și utilizatorilor privilegiați.
Totodată, vă rugăm să confirmați dacă este acceptabilă implementarea auditului prin loguri detaliate (audit trail)

... afișează tot conținutul

În contextul cerinței nr. 104, prin „tentative de acces neautorizat sau abuz” se înțeleg orice acțiuni realizate de administratori sau utilizatori privilegiați care încalcă politicile de acces, securitate sau confidențialitate stabilite de autoritatea contractantă, inclusiv, dar fără a se limita la:
Exemple de activități considerate tentativă de acces neautorizat sau abuz:
a. accesarea nejustificată a unor date sau fluxuri video clasificate sau cu acces restricționat;
b. modificarea neautorizată a configurațiilor critice ale platformei;
c. ștergerea intenționată sau accidentală a înregistrărilor fără autorizare;
d. escaladarea neautorizată a propriilor drepturi de acces;
e. vizualizarea sau exportarea datelor în afara cazurilor de utilizare aprobate;â
f. încercări repetate de conectare cu credențiale greșite (posibil atac de tip brute force).

Măsuri tehnice acceptate: Da, este acceptabilă și recomandată implementarea auditului prin loguri detaliate (audit trail), care să includă:
a. identificarea utilizatorului (ID, IP, sesiune);
b. acțiunea efectuată (login, acces fișiere, modificări, export, ștergere);
c. timestamp complet (dată și oră exactă);
d. rezultatul acțiunii (reuşită/eșec);
e. alte atribute (resurse accesate, nivel de autorizare etc.).

Alte cerințe implicite. Platforma trebuie să permită:
 monitorizarea și detectarea în timp real a acțiunilor suspecte;
 generarea de alerte automate în cazul activităților deviante;
 posibilitatea exportului și analizării logurilor pentru audit extern sau intern;
 protejarea și arhivarea logurilor pentru o perioadă minimă conform politicii de retenție a autorității contractante.
Cerința permite implementarea funcționalității prin mecanisme standardizate de audit trail, ceea ce corespunde cu bunele practici internaționale în domeniul securității IT și al sistemelor critice.

... afișează tot conținutul

Vă rugăm să specificați:
• Care tip/model anume de sisteme de semaforizare sau control acces sunt avute în vedere pentru integrare cu platforma mobilă?
• Ce echipamente specifice sau protocoale sunt utilizate sau așteptate (ex: Modbus, OPC, ONVIF, alte API-uri)?
• Ce se înțelege prin „suprascrierea programelor de blocare” – este vorba despre o funcție disponibilă în sistemele integrate (de exemplu, control acces fizic) sau despre o comandă directă din platforma mobilă către echipamentele respective?

... afișează tot conținutul

În legătură cu cerința nr. 98, clarificările sunt următoarele:
Tip/model de sisteme de semaforizare sau control acces avute în vedere pentru integrare. Nu se impune un anumit producător sau model anume. Platforma mobilă trebuie să fie permită controlul inclusiv asistemelor de semaforizare și control acces integrate

Nu este impusă o restricție de echipamente specifice sau protocoale.

„Suprascrierea programelor de blocare” – interpretare: Această formulare face referire la posibilitatea platformei de a transmite comenzi către sistemele de control acces sau semaforizare integrate pentru a modifica comportamentul acestora, în situații de interes (incident, urgență, escortă, intervenție etc.).

... afișează tot conținutul

Vă rugăm să specificați ce tipuri de rapoarte se așteaptă să fie accesibile prin aplicația mobilă, pentru a putea confirma conformitatea funcțională.

... afișează tot conținutul

Referitor la cerința nr. 91 privind disponibilitatea rapoartelor prin aplicația mobilă, se are în vedere ca aplicația să permită accesul securizat la cel puțin o serie de rapoarte orientate în principal la operarea tactică și intervenție rapidă, nu neapărat și rapoarte ce țin de analiză avansată.
Tipuri de rapoarte așteptate în aplicația mobilă:
1. Rapoarte de incident:
 Detalii despre evenimente detectate (tip incident, locație, ora, acțiuni declanșate automat sau manual).
 Statusul investigației sau măsurilor luate.
2. Rapoarte de trafic și mobilitate:
 Statistici privind fluxul rutier, viteze medii, volume de trafic pe zone/intervale.
 Identificarea congestiilor sau a zonelor cu risc crescut.
3. Alerte generate automat:
 Liste cu alerte în curs sau recente (vehicule de interes, comportamente anormale etc.).
 Posibilitatea de a filtra după tip, locație sau prioritate.
4. Rapoarte video sumarizate (snapshot-uri, metadate):
 Acces rapid la imagini asociate incidentelor, fără a necesita streaming continuu.
 Evenimente corelate cu zonele de monitorizare (camere, senzori etc.).
5. Rapoarte tehnice de stare a sistemului (opțional):Informații privind funcționalitatea echipamentelor (doar pentru roluri administrative).

Observații suplimentare
 Nu se impune afișarea completă a tuturor rapoartelor detaliate din platforma centrală.
 Interfața mobilă trebuie să fie optimizată pentru utilizare rapidă, cu informații rezumative și acționabile.
 Accesul trebuie să fie filtrat pe bază de rol și permisiuni, astfel încât doar utilizatorii autorizați să vizualizeze anumite tipuri de rapoarte.

Cerința nu vizează volumul complet al rapoartelor generate de sistem, ci o selecție de rapoarte relevante pentru intervenție, decizie și mobilitate operativă, în format compatibil cu afișarea pe dispozitive mobile. Platforma trebuie să permită configurarea flexibilă a acestor vizualizări, conform nevoilor autorității contractante.

... afișează tot conținutul

Vă rugăm să detaliați ce înseamnă, în contextul acestei cerințe, „distribuirea sarcinilor de procesare și stocare între site-uri diferite”.

... afișează tot conținutul

Cerința nr. 75, care face referire la „distribuirea sarcinilor de procesare și stocare între site-uri diferite”, vizează capacitatea platformei de a funcționa într-o arhitectură distribuită, în care resursele de procesare (ex: analiză video, interpretare de date) și stocare (ex: înregistrări video, metadate) pot fi împărțite și gestionate în mod descentralizat între mai multe locații fizice (site-uri).
În mod concret, această cerință presupune:
1. Procesare distribuită (load balancing): Platforma trebuie să permită distribuirea sarcinilor de analiză video sau detectare de evenimente către servere situate în diferite locații, pentru optimizarea resurselor și reducerea latențelor
2. Stocare distribuită: Înregistrările video și metadatele pot fi salvate în centre de date separate, în funcție de regiune, prioritate sau redundanță.
3. Failover între site-uri: Platforma trebuie să suporte toleranța la erori, adică dacă un site devine indisponibil, altul poate prelua automat procesarea/stocarea pentru a menține funcționalitatea sistemului.
4. Sistem unificat de management: Chiar dacă există mai multe site-uri distribuite geografic, acestea trebuie administrate centralizat dintr-o interfață comună, fără a afecta coerența operațională.

... afișează tot conținutul

Vă rugăm să clarificați în ce constă „configurarea dinamică a resurselor”.

... afișează tot conținutul

Cerința nr. 89, referitoare la „configurarea dinamică a resurselor”, presupune ca platforma să fie capabilă să adapteze în mod flexibil și automat alocarea resurselor de sistem – cum ar fi capacitatea de procesare, memoria, lățimea de bandă, spațiul de stocare sau sarcinile între servere – în funcție de nevoile curente și de modificările contextuale din teren.

... afișează tot conținutul

Vă rugăm să specificați ce tipuri de date se au în vedere în contextul „migrarea datelor din alte sisteme VMS sau de control acces către noul sistem”?

... afișează tot conținutul

Cerința privind „migrarea datelor din alte sisteme VMS sau de control acces către noul sistem” are în vedere asigurarea continuității operaționale și istoricului datelor relevante, în contextul unei tranziții către o platformă unificată modernă.
Platforma trebuie să asigure mecanisme de import pentru:
• Dispozitive video și configurații VMS (camere, fluxuri, zone, reguli)
• Date de control acces (utilizatori, carduri, grupuri, planuri de acces)
• Arhive video (în unele cazuri – prin integrare cu sisteme compatibile)

... afișează tot conținutul

Cu referire la cerința nr. 57, vă rugăm să clarificați dacă se consideră conformă o soluție în care analiza predictivă și raportarea se realizează prin integrarea cu un motor extern de analiză, utilizând SDK-ul proprietar al platformei VMS propuse, oferind astfel acces complet la datele relevante (fluxuri video, metadate, evenimente, alarme etc.), generarea rapoartelor fiind realizată într-un modul distinct, integrat în cadrul infrastructurii.

... afișează tot conținutul

Cerința nr. 57 vizează funcționalitățile platformei, nu a modului VMS, care este parte componenta a acesteia, prin urmare platforma trebuie sa fie capabila sa ofere acest funcțional nativ, sau prin integrare cu alte subsisteme, care asigura acest lucru intr-un mod fiabil integrat in platforma.
Cerința nu impune utilizarea unui motor intern propriu pentru analiza predictivă, ci acceptă modularitatea și integrarea cu soluții terțe, atâta timp cât acestea sunt pe deplin compatibile, nu afectează coerența arhitecturii generale a sistemului și oferă beneficiarul control asupra procesului de analiză și raportare. Acest lucru este în conformitate cu abordarea deschisă și modulară prevăzută în caietul de sarcini.

... afișează tot conținutul

Cu referire la cerința nr. 50, vă rugăm să detaliați:
a) Ce tipuri de amenințări sunt avute în vedere în contextul acestei cerințe;
b) Ce se înțelege prin „proceduri de răspuns predefinite” – sunt necesare fluxuri de lucru automatizate, manuale sau hibride, și ce exemple de astfel de proceduri sunt relevante pentru proiect?
c) Care sunt criteriile pentru clasificarea unui incident ca fiind major în contextul acestui sistem?

... afișează tot conținutul

1. Tipuri de amenințări avute în vedere: În contextul cerinței nr. 50, tipurile de amenințări vizate includ, dar nu se limitează la:
 Amenințări de securitate fizică: acces neautorizat în perimetre protejate, vandalism, sabotaj, obiecte abandonate;
 Amenințări cibernetice: tentative de acces neautorizat la platformă, interceptarea datelor transmise, atacuri DDoS sau compromiterea componentelor software;
 Amenințări operaționale: defecțiuni ale infrastructurii, pierderi de comunicații, indisponibilitatea componentelor esențiale;
 Amenințări în spațiul public: comportamente deviante, evenimente de panică, violență sau altercații monitorizate de platformă.
2. Proceduri de răspuns predefinite: Prin „proceduri de răspuns predefinite” se înțelege stabilirea unor scenarii automatizate, manuale sau hibride care să fie declanșate în funcție de tipul de incident detectat.
3. Criteriile de clasificarea unui incident ca ”major” sau altă clasificare, aplicate de către autoritățile responsabile nu sunt relevante din perspectiva cerințelor caietului de sarcini. Platforma trebuie să permită definirea și personalizarea criteriilor de clasificare a incidentelor, inclusiv stabilirea nivelurilor de severitate precum „Major”, „Mediu”, „Minor” sau altele, în funcție de politicile operaționale. Clasificările pot fi utilizate pentru declanșarea automată a acțiunilor, prioritizarea intervențiilor și filtrarea în rapoarte.

Cerința urmărește asigurarea unui sistem robust de detectare, clasificare și reacție contextuală la evenimente, cu suport pentru definirea unor proceduri clare și eficiente de răspuns, adaptabile la riscurile specifice identificate de autoritatea contractantă.

... afișează tot conținutul

Cu referire la cerința nr. 52 privind partajarea rapidă a informațiilor și a înregistrărilor video cu alte agenții sau autorități relevante, vă rugăm să specificați:
a) În ce format(e) trebuie să fie exportate/partajate aceste informații
b) Dacă există o platformă anume
c) Ce nivel de detalii trebuie inclus in materialele transmise

... afișează tot conținutul

Cerința privind partajarea rapidă a informațiilor și înregistrărilor video cu alte agenții sau autorități relevante urmărește să asigure cooperarea interinstituțională eficientă, în special în contextul investigării incidentelor și asigurării ordinii publice.
1. Format(e) de export/partajare. Platforma trebuie să permită exportul datelor video și informațiilor asociate în formate standard, deschise, care să asigure:
 Compatibilitate generală: MP4, AVI sau alte formate video comune;
 Integritate și autenticitate: suport pentru semnătură digitală, hash criptografic sau metadate încorporate;
 Documentație auxiliară: generarea automată a fișelor de incident sau rapoartelor de eveniment, în format PDF, DOCX sau XML, după caz.
2. Platformă anume: Nu este impusă o platformă specifică pentru partajare. Se solicită ca sistemul să aibă funcționalități de export și partajare configurabile, capabile să:
 Transmită datele printr-o interfață securizată, dacă există o platformă de colaborare interinstituțională stabilită ulterior de beneficiar;
 Permită descărcarea controlată a datelor, pe baza unor drepturi de acces;
 Suporte integrare ulterioară prin API cu sisteme externe, în cazul implementării unei platforme guvernamentale pentru schimb de informații (ex. interoperabilitate prin MConnect sau sistem MAI de colaborare).
3. Nivel de detalii în materialele transmise. Informațiile partajate trebuie să includă:
 Segmentul video relevant, însoțit de timestamp și detalii despre sursa camerei (ID, locație, oră);
 Metadate asociate: identificatori de vehicul (număr de înmatriculare), descrierea obiectului, locație GPS, comportamente detectate etc.;
 Contextul evenimentului: tipul incidentului, scenariul declanșator, rezumat narativ al secvenței (dacă e disponibil);
 Loguri de sistem: cine a exportat materialul, când, și prin ce mecanism.
Platforma trebuie să faciliteze exportul rapid, securizat și complet documentat al înregistrărilor video și metadatelor asociate, fără impunerea unui format sau platforme închise, respectând cerințele de interoperabilitate și trasabilitate stabilite de autoritatea contractantă.

... afișează tot conținutul

Cu privire la cerința nr. 44 privind generarea de rapoarte personalizabile care să includă grafice, diagrame și statistici privind activitatea din trafic și starea sistemului, vă rugăm să specificați:
Ce nivel minim de detaliu trebuie să fie disponibil în platformă

... afișează tot conținutul

Cerința privind generarea de rapoarte personalizabile vizează oferirea unor instrumente vizuale și analitice care să sprijine autoritatea contractantă în monitorizarea activității din trafic, evaluarea performanței sistemului și luarea deciziilor operative sau strategice. Nivelul minim de detaliu care trebuie să fie disponibil în platformă include:
1. Indicatori privind activitatea din trafic:
 Număr de vehicule detectate (zilnic/lunar/anual);
 Distribuție pe categorii (autoturisme, camioane, motociclete etc.);
 Tendințe de trafic pe zone și intervale orare;
 Număr și tip de încălcări rutiere detectate (viteză, semafor, oprire neregulamentară etc.);
 Hărți de căldură privind densitatea traficului.
2. Statistici privind starea echipamentelor și a platformei:
 Starea de funcționare a camerelor (activ/inactiv/eroare);
 Disponibilitatea rețelei și a componentelor server (uptime, alerte, notificări);
 Loguri de evenimente tehnice și operaționale;
 Alarme și incidente generate, distribuite pe severitate și tip.
3. Funcționalități vizuale și de personalizare:
 Posibilitatea de a genera grafice și diagrame (ex: grafice de tip bară, linie, radial, histograme);
 Selectarea intervalului de timp (zilnic, săptămânal, lunar, personalizat);
 Filtrare pe locație, tip de incident, cameră sau senzor;
 Export în formate standard: PDF, Excel, CSV, PNG.
Platforma trebuie să permită generarea de rapoarte detaliate și configurabile, care să includă indicatori operaționali și tehnici esențiali pentru evaluarea performanței sistemului și a traficului rutier, cu posibilitatea de vizualizare grafică și export în formate multiple. Acest nivel de detaliu este necesar pentru a sprijini atât activitatea curentă a structurilor de ordine publică, cât și deciziile de optimizare a infrastructurii și intervenției.

... afișează tot conținutul

Cu referire la cerința nr. 32 privind suportul nativ pentru integrarea cu soluții terțe de reprezentare geografică (GIS MAP), vă rugăm să specificați:
a) În cazul în care o platformă propusă acoperă majoritatea specificațiilor solicitate (ex. 9 din 10 puncte enumerate), dar nu poate asigura unul dintre ele, se va acorda punctaj proporțional în cadrul evaluării tehnice (din totalul celor 10 puncte alocate)?
b) Se consideră acceptabilă implementarea parțială a funcționalităților enumerate dacă există posibilitatea integrării ulterioare a punctului lipsă în perioada de implementare sau întreținere extinsă?

... afișează tot conținutul

Cerința nr. 32 prevede ca platforma să ofere suport nativ pentru integrarea cu soluții terțe GIS (sisteme de hărți digitale), pentru a permite o reprezentare geografică avansată a datelor colectate și a evenimentelor monitorizate.
1. Referitor la punctajul proporțional în evaluarea tehnică:
 Evaluarea tehnică se realizează în baza criteriilor specificate expres în documentația de atribuire, conform metodologiei de punctare stabilite.

 Dacă în documentul de evaluare NU este prevăzut explicit un sistem de punctaj proporțional pentru cerințele tehnice parțial îndeplinite, atunci această abordare nu se aplică automat.
 În lipsa unei prevederi explicite, cerințele declarate obligatorii (inclusiv cele de tip „suport nativ”) trebuie îndeplinite integral pentru a fi considerate conforme.
2. Referitor la acceptabilitatea implementării parțiale cu completare ulterioară: Pentru a asigura tratament egal și nediscriminatoriu, platforma propusă trebuie să asigure din start suportul nativ pentru funcționalitățile esențiale menționate în cerință.
Implementarea parțială, cu completări ulterioare în perioada de implementare sau întreținere extinsă, poate fi acceptată doar dacă este prevăzută explicit această posibilitate în caietul de sarcini sau în documentația de achiziție.
În caz contrar, o astfel de abordare ar putea favoriza anumite soluții care nu îndeplinesc inițial cerința integrală, ceea ce ar contraveni principiului transparenței și concurenței loiale.
În absența unei prevederi exprese în caietul de sarcini privind acordarea unui punctaj proporțional sau acceptarea implementării ulterioare a funcționalităților lipsă, cerința nr. 32 trebuie considerată a fi obligatorie și complet aplicabilă în momentul ofertei.
Recomandarea este ca ofertanții să prezinte o soluție care acoperă toate punctele menționate în cerință pentru a evita riscul de neconformitate.

... afișează tot conținutul

Cu referire la cerința nr. 26 privind gestionarea traficului rutier și infrastructură inteligentă, vă rugăm să specificați:
a) Ce tip de echipamente, semafoare, bariere sau senzori sunt deja în exploatare în infrastructura clientului și care sunt protocoalele utilizate?
b) Se acceptă realizarea integrării și configurării acestor funcționalități în cadrul perioadei de implementare și testare prevăzute (primele 2 luni), în cazul în care soluția de bază permite integrarea cu sisteme de trafic pe bază de protocoale deschise și standardizate?

... afișează tot conținutul

Cu mențiunea că cerința este una opțională expunem că:
Întrebările formulate reflectă o interpretare eronată a cerinței din documentația de atribuire. Menționăm că cerința nr. 26 nu se referă la posibilitatea de a realiza integrarea în viitor, ci solicită în mod explicit ca platforma ofertată să includă nativ integrări deja realizate, aplicabile și funcționale, fără a necesita dezvoltări ulterioare, module adiționale sau personalizări care ar genera costuri și riscuri suplimentare.
Prin urmare, nu este relevant în acest context ce tipuri de echipamente sunt deja în exploatare la nivelul infrastructurii beneficiarului, și nici nu este solicitată realizarea ulterioară a integrărilor în perioada de implementare, chiar dacă soluția teoretic permite astfel de extensii.
Această cerință are ca scop asigurarea caracterului matur și dovedit al soluției propuse, eliminând riscurile de nefuncționare, întârzieri sau creșteri de costuri în faze ulterioare.

... afișează tot conținutul

Având în vedere faptul că mai multe cerințe tehnice (ex: 238, 239, 240, 241, 245, 266) corespund integral cu specificațiile Irisity IRIS+ (https://docs.irisity.com/iris-plus-documentation/iristm-architecture-and-engineering), vă rugăm să confirmați dacă:
1. Aceste cerințe reflectă o funcționalitate esențială si este obligatorie, fără de care nu pot fi atinse obiectivele proiectului, sau
2. Pot fi considerate cerințe opționale, pentru care pot fi acordat un punctaj tehnic suplimentare în cazul în care sunt îndeplinite integral, iar soluțiile alternative care oferă funcționalități echivalente sunt acceptate.
Această clarificare este importantă pentru a permite participarea unei game mai largi de operatori economici și pentru a asigura respectarea principiului concurenței loiale.

... afișează tot conținutul

Autoritatea contractantă precizează că cerințele menționate sunt opționale, fapt indicat explicit în documentația de atribuire. Vă rugăm să consultați cu atenție structura cerințelor și grila de evaluare tehnică.
Îndeplinirea acestora nu este obligatorie și nu condiționează eligibilitatea ofertei.

... afișează tot conținutul