Sistem automatizat al controlului de frontieră (Automated Border Control, ABC, e-Gate)
suma planificată 30,000,000.00 MDL
| Valoare | CPV | Titlu achiziției | Cantitate | Livrare |
|---|---|---|---|---|
| 30,000,000.00 MDL | 35100000-5 | Echipament | 10 Bucata |
01.09.2025 - 30.12.2025 bd. Dacia, 80/3 |
Conform răspunsului dvs. la întrebarea 23, valabilitatea contractului nu poate fi extinsă până în 2026. Totuși, documentația de licitație prevede un termen de livrare de 120 zile lucrătoare de la semnarea contractului, ceea ce înseamnă că, la data prezentă a depunerii ofertei, termenul de livrare este cel puțin februarie 2026, fiind încă în cadrul celor 120 de zile lucrătoare.
Vă rugăm să explicați această abordare.
Termenul de livrare este de 120 de zile calendaristice asa este prevazut in caietul de sarcini si DS
Conform răspunsului dvs. la întrebarea 26, instalația pilot funcțională va rămâne în operare.
Aceasta înseamnă că numărul total de eGate-uri de livrat este 11, luând în calcul și eGate-ul pilot?
Numărul total de eGate-uri de livrat este de 10, inclusiv instalația pilot, care va fi integrată ca parte din sistemul final după validarea testelor
Bună ziua. Vă rugăm să publicați caietul de sarcini.
Buna ziua, caietul de sarcini a fost încărcat.
The tender documentation provides for delivery under DDP terms. Considering that this requires the supplier to handle all local customs and tax formalities, which may pose difficulties for non-resident economic operators, we kindly ask you to confirm whether it would be possible to amend the delivery terms to DAP.
Buna ziua,
Ne menținem poziția și solicităm condiții de livrare DDP, deoarece conform cerințelor expuse în pct.10 din tabelul pct 20 din Anunțul de participare, furnizorul trebuie să facă dovadă că deține specialiști (ingineri certificați) locali care vor asigura mentenanța și dacă este cazul și reparația utilajului (suplimentar a de vedea și termenii de reacție solicitați).
Stimată autoritate contractantă,
Având în vedere cerința privind demonstrarea experienței relevante pe teritoriul Republicii Moldova, vă rugăm respectuos să ne confirmați următorul aspect:
Poate fi acceptată experiența producătorului echipamentelor (ex. cititoare documente, soluții pentru prelucrarea datelor biometrice etc.), în cazul în care acesta participă în calitate de asociat într-un consorțiu cu o companie din Republica Moldova?
Menționăm că producătorul deține experiență demonstrabilă în livrarea și integrarea unor soluții similare în alte jurisdicții și va avea un rol activ în livrarea și punerea în funcțiune a echipamentelor în cadrul proiectului.
Vă mulțumim anticipat pentru clarificare.
Buna dimineața, da, se va accepta.
În cadrul anunțului de participare, la punctul 22, este menționată aplicarea licitației electronice. Totuși, având în vedere că procedura se desfășoară pe platforma SIA RSAP (MTender), iar aceasta nu prevede aplicarea licitației electronice în cadrul procedurilor respective, vă rugăm să ne confirmați dacă mențiunea referitoare la licitația electronică este corectă sau dacă a fost inclusă din eroare?
Buna ziua,
procedura în cauză se va desfășură fără aplicarea licitației electronice, în Anunțul de participare s-a inclus din greșeală (Anunțul de participare va fi modificat în cel mai scurt timp).
Documentul „anunț de participare abc en”, punctul 16 menționează:
„16. Termeni și condiții de livrare: livrarea se va face conform Incoterm DDP, la adresa autorității contractante, Republica Moldova, mun. Chișinău, Bulevardul Dacia 80/3, în termen de până la 120 zile lucrătoare de la semnarea contractului.”
Vă rugăm să confirmați dacă cele 120 de zile se referă la data sosirii transportului celor 10 porți ABC la Aeroportul Chișinău?
Buna ziua, termenul de până la 120 de zile lucrătoare, se referă la perioada maximă admisă pentru livrarea și instalarea completă a celor 10 porți ABC la adresa autorității contractante. Astfel, livrarea echipamentelor la Aeroportul Internațional Chișinău, precum și instalarea și punerea lor în funcțiune, trebuie să fie finalizate integral în acest termen.
Documentul „anunț de participare abc en”, punctul 8 menționează:
„Cantitate: 10”.
Puteți confirma dacă aceste 10 porți ABC vor fi împărțite între zona de sosiri și cea de plecări?
Aveți în plan împărțirea celor 10 porți ABC între posturile de control de frontieră?
Este necesar ca una dintre porțile ABC să aibă o lățime mai mare (pentru trecerea pasagerilor în scaune cu rotile)? Sau acești pasageri vor fi direcționați către punctele de control manual?
Vă rugăm să furnizați planurile de amplasare pentru analiză din partea furnizorului.
Numărul total de porți prevăzut este 10. Distribuția acestora între zona de sosiri și cea de plecări, precum și repartizarea între posturile de control, va fi determinată la etapa de proiectare, împreună cu ofertantul selectat, în funcție de fluxurile operaționale. Caietul de sarcini nu specifică obligativitatea unei porți cu lățime mărită pentru scaune cu rotile, dar sistemul trebuie să fie „user-friendly” și accesibil, fiind recomandată adaptarea pentru toate categoriile de pasageri, conform bunelor practici europene. Planurile finale de amplasare vor fi elaborate după semnarea contractului, în colaborare cu ofertantul și în baza infrastructurii existente
Documentul „anunț de participare abc en”, punctul 20, criteriul 14 menționează:
„Garanție de minim 3 ani, inclusiv asigurarea echipamentului livrat cu piese de schimb și componente pentru o perioadă de minim 5 ani de funcționare.”
Puteți confirma motivul pentru care garanția este de 3 ani, iar livrarea pieselor de schimb este pe 5 ani?
Aceasta înseamnă că în anii 4 și 5 de operare nu mai este inclusă garanția și se asigură doar livrarea pieselor de schimb? Dacă se confirmă, am dori să recomandăm alinierea celor două perioade la 3 ani sau 5 ani pentru a menține tot suportul tehnic necesar pe această durată și nu doar furnizarea pieselor.
Conform caietului de sarcini, perioada minimă de garanție este de 3 ani, iar disponibilitatea pieselor de schimb și componente esențiale trebuie asigurată pentru cel puțin 5 ani de la punerea în funcțiune. După expirarea garanției, suportul tehnic și întreținerea vor putea fi realizate contra cost, pe baza acestor piese de schimb. Extinderea perioadei de garanție poate fi negociată suplimentar în cadrul contractului de mentenanță
Documentul „caiet de sarcini – descrierea funcționalităților de bază a sacf en”, punctul 1.7 menționează:
„Bariera de ieșire trebuie să aibă o înălțime suficientă pentru a împiedica pasagerul care trebuie să treacă prin controlul de frontieră clasic (la ghișeu) să o poată ocoli sau sără.”
Puteți confirma dacă există o înălțime minimă solicitată sau dacă aceasta este la discreția furnizorului, având în vedere alte implementări similare în Europa, conform cerințelor Agenției Frontex privind „Ghidurile de bune practici tehnice pentru sistemele ABC”? Conform ghidului tehnic Frontex, nu este specificată o înălțime minimă pentru ușa de ieșire.
Înălțimea minimă a barierei de ieșire nu este indicată numeric în caietul de sarcini, dar se solicită ca aceasta să fie suficientă pentru a preveni ocolirea sau săritul facil al sistemului, conform bunelor practici europene și recomandărilor Frontex. Ofertantul va propune soluția optimă ținând cont de aceste cerințe
Documentul „caiet de sarcini – descrierea funcționalităților de bază a sacf en”, punctul 1.12 menționează:
„b) accesul la interfața de administrare și la stațiile de monitorizare va fi protejat prin autentificare multifactor (MFA) și politici de control al accesului bazate pe roluri (RBAC);”
Vă rugăm să confirmați dacă soluția trebuie să se conecteze cu un director existent de utilizatori al clientului (ex. LDAP), gestionat de către client, pentru a autentifica utilizatorul și parola?
Dacă da, puteți confirma dacă directorul de utilizatori al clientului suportă autentificarea multifactor (și care este al doilea factor)?
Dacă nu, se așteaptă ca furnizorul să propună o soluție care include un sistem propriu de gestionare a utilizatorilor cu MFA integrat, corect?
Caietul de sarcini prevede ca accesul la interfața de administrare și stațiile de monitorizare să fie protejat prin autentificare multifactor (MFA) și RBAC. Detaliile privind integrarea cu un director existent (ex. LDAP/AD) sau implementarea unui sistem propriu cu MFA integrat vor fi stabilite împreună cu Beneficiarul la faza de proiectare, în funcție de infrastructura disponibilă.
Documentul „caiet de sarcini – descrierea funcționalităților de bază a sacf en”, punctul 1.12 menționează:
„d) furnizorul va asigura ca toate componentele software să respecte principiile secure-by-design și vor fi supuse testelor de penetrare și auditului de securitate;”
Puteți furniza detalii suplimentare cu privire la procesul de testare de penetrare și audit de securitate (de exemplu: care entități sunt implicate, ce termene trebuie respectate, dacă acestea vor fi efectuate într-un mediu închis sau în mediul de producție)?
Testarea de penetrare și auditul de securitate pentru toate componentele software și hardware vor fi asigurate de furnizor, conform principiilor „secure-by-design”. Modalitatea concretă (entități implicate, termene, mediu de testare/producție) va fi agreată de comun acord cu Beneficiarul la etapa de implementare; testarea este recomandată inițial în mediu controlat
Documentul „caiet de sarcini – descrierea funcționalităților de bază a sacf en”, punctul 2.1 menționează:
„2.1. Procesul de tranziție ABS (pași, acțiuni/procese, informații, comunicare API, mesaje informative etc.) va fi elaborat împreună de Beneficiar și Ofertant, dar în același timp Ofertantul va descrie cel puțin 2 procese diferite (procese de tranziție utilizate în alte proiecte implementate, bune practici);”
Puteți confirma care este volumul de muncă de dezvoltare așteptat din partea furnizorului atunci când se menționează că „va fi elaborat împreună de Beneficiar și Ofertant”?
Considerați că furnizorul trebuie să dezvolte servicii web pentru a permite integrarea și schimbul de date cu sistemul IGPF, sau este necesar doar să personalizăm datele (ex. fluxul de date, formatul, mesajele de intrare, codurile de ieșire și interpretarea rezultatelor)?
Puteți furniza informații suplimentare despre sistemul IGPF, cum ar fi documentația de control a interfeței (sau cel puțin o parte din aceasta)?
Procesul de tranziție ABS (pași, acțiuni, mesaje API, etc.) va fi elaborat de comun acord între Beneficiar și Ofertant. Ofertantul va descrie minimum două procese diferite, bazate pe bune practici. Este necesară dezvoltarea serviciilor web (SOAP) pentru integrare și schimb de date cu IGPF; personalizarea fluxului și formatului de date va fi realizată în colaborare cu Beneficiarul. Documentația privind interfața IGPF va fi pusă la dispoziția ofertantului după semnarea contractului.
Documentul „caiet de sarcini – descrierea funcționalităților de bază a sacf en”, punctul 2.5.1.3 menționează:
„2.2. Comunicarea între sistemul ABC și serverul de date și aplicații al IGPF trebuie să se facă prin servicii web SOAP;”
Puteți confirma motivul pentru care sunt solicitate exclusiv servicii web SOAP și dacă pot fi luate în considerare și servicii REST API?
Caietul de sarcini solicită explicit utilizarea serviciilor web de tip SOAP pentru comunicarea între sistemul ABC și serverul de date IGPF, pentru compatibilitate cu infrastructura existentă. Nu sunt acceptate alte tehnologii (ex. REST API) la această etapă
Documentul „caiet de sarcini – descrierea funcționalităților de bază a sacf en”, punctul 2.2 menționează:
„Sistemul trebuie să fie echipat cu o ‘oglindă digitală’ pentru a asista pasagerul în timpul captării imaginii. Pasagerul va primi, de asemenea, instrucțiunile necesare pe un monitor/ecran, inclusiv instrucțiuni grafice. Toate informațiile furnizate vor fi conforme cu practici prietenoase pentru utilizator.”
Pe baza experienței noastre și a numeroaselor implementări cu acest tip de soluție, în unele instalări recente s-a decis împreună cu clientul final să se utilizeze o Interfață Grafică Simplificată (de ex. simboluri pentru a scoate pălăria și ochelarii, indicații pentru a privi către cameră pentru captură frontală), în locul unei oglinzi digitale, pentru a facilita înțelegerea de către pasager.
Puteți confirma dacă o astfel de propunere este considerată conformă cu cerința? (Suntem disponibili să furnizăm detalii suplimentare despre GUI din alte instalări, dacă este necesar.)
Sistemul trebuie să fie echipat cu o „oglindă digitală” pentru asistarea pasagerului, precum și cu instrucțiuni grafice pe monitor. Utilizarea unei interfețe grafice intuitive suplimentare este posibilă, dar nu substituie cerința obligatorie de prezență a oglinzii digitale, conform caietului de sarcini
Documentul „caiet de sarcini – descrierea funcționalităților de bază a sacf en”, punctul 2.5.1.4 menționează:
„2.5.1.4. Algoritmul de captare a feței trebuie să analizeze continuu fluxul video de la cameră pentru a detecta fața pasagerului. De îndată ce fața pasagerului este detectată la distanța corectă față de cameră, sistemul trebuie să ruleze un algoritm de evaluare a calității (proces computerizat) pentru a verifica dacă imaginea facială îndeplinește criteriile minime conform ISO 39794-5 și ISO/IEC 19794-5:2011 – Imagine facială (distanța ochilor, blur, focus, poziție, expresie).”
Puteți confirma motivul pentru care cerința menționează standardul „ISO 39794-5”?
Conform înțelegerii și experienței noastre pe piață, ISO 39794-5 este utilizat pentru captarea facială a cetățenilor în scopul personalizării documentelor de călătorie (ex. crearea/reînnoirea pașapoartelor electronice), în timp ce ISO/IEC 19794-5:2011 (menționat și în Ghidurile Tehnice Frontex) este utilizat pentru funcționarea porților ABC și pentru procesul de potrivire biometrică între capturile faciale live și imaginea facială din documentul de călătorie.
Caietul de sarcini solicită respectarea atât a standardului ISO 39794-5, cât și ISO/IEC 19794-5:2011 pentru imaginea facială. Astfel, sistemul trebuie să fie compatibil cu ambele standarde
Documentul „caiet de sarcini – descrierea funcționalităților de bază a sacf en”, punctul 2.6 menționează:
„2.6. Sistemul trebuie să aibă un buton/comutator de urgență care permite pasagerului să solicite asistență din partea inspectorului. Butonul de urgență va declanșa o alarmă (audibilă și vizuală), dar nu va elibera automat barierele. Inspectorul va putea deschide bariera de intrare utilizând un ‘buton de urgență’, care nu va fi accesibil pasagerului în a doua etapă a controlului;”
Cerința menționează: „Inspectorul va putea deschide bariera de intrare utilizând un buton de urgență” – conform instalărilor noastre standard în Europa (în conformitate cu ghidurile Frontex), dar și la nivel global, ofițerul de frontieră are control complet asupra porții printr-o aplicație software (rulând pe stația de lucru a ofițerului), prin care poate deschide ușa de intrare a porții pe care o supraveghează, fără dificultate și fără necesitatea unor butoane fizice (acțiunea fiind înregistrată în sistem).
Puteți confirma dacă o astfel de soluție poate fi propusă și este considerată conformă cu cerințele?
Sistemul trebuie să prevadă atât posibilitatea controlului barierei din aplicația software (stația de monitorizare), cât și existența unui buton/comutator fizic de urgență accesibil doar inspectorului, conform cerințelor din caietul de sarcini
Documentul „caiet de sarcini – descrierea funcționalităților de bază a sacf en”, punctul 3.1.4 menționează:
„Capacitatea de a integra senzori radar în partea inferioară pentru scanarea zonelor de ușă.”
Puteți confirma de ce cerința menționează în mod specific senzori radar?
Pe baza celor mai recente instalări ale noastre, recomandăm utilizarea senzorilor infraroșii pentru că sunt mai rapizi și oferă o precizie mai mare. Puteți confirma dacă propunerea acestei tehnologii este de asemenea considerată conformă cu cerințele?
Caietul de sarcini solicită în mod explicit integrarea senzorilor radar în partea inferioară pentru scanarea zonelor de ușă. Alte tehnologii (ex. senzori IR) pot fi propuse suplimentar, dar nu substituie această cerință minimă.
Documentul „caiet de sarcini – descrierea funcționalităților de bază a sacf en”, punctul 4.5 menționează:
„Pentru a asigura o operare eficientă a sistemului ABC în cadrul ecosistemului aeroportuar, Furnizorul va detalia în propunerea tehnică următoarele:
a) Cum se va realiza integrarea cu sistemele existente, inclusiv: DCS (Departure Control System); AODB (Airport Operational Database); FIDS (Flight Information Display System); RMS (Resource Management System).”
Puteți confirma contextul fiecărei dintre aceste integrări și motivul pentru care aceste 4 tipuri de integrări sunt considerate parte a procesării și operării pasagerilor prin sistemul ABC? De asemenea, prețul trebuie să includă aceste integrări?
Dacă este aplicabil, vă rugăm să furnizați detalii suplimentare pentru fiecare dintre cele 4 tipuri de integrare (ex. ce date se schimbă, cu ce companii aeriene, formatul datelor, așteptările privind datele de intrare și ieșire pentru fiecare), astfel încât să putem analiza și construi o descriere a propunerii tehnice.
Rețineți că, din câte înțelegem, această cerință nu este inclusă în ghidul de bune practici Frontex și este în afara ecosistemului controlului de frontieră.
Integrarea cu DCS, AODB, FIDS, RMS este solicitată pentru operarea eficientă în cadrul ecosistemului aeroportuar. Ofertantul va detalia în propunerea tehnică modalitatea de integrare, tipurile de date, protocoalele și va include aceste integrări în prețul ofertei. Detaliile se vor stabili la etapa de proiectare, în colaborare cu Beneficiarul.
Documentul „caiet de sarcini – descrierea funcționalităților de bază a sacf en”, punctul 4.5 lit. b) menționează:
„Arhitectura logică propusă a integrării, inclusiv schimbul de date (format, frecvență, protocoale) și mecanismele de rezervă în caz de indisponibilitate a sistemelor externe;”
În ceea ce privește mecanismele de rezervă (fallback), vă rugăm să rețineți că trebuie oferite mai multe detalii pentru fiecare dintre aceste integrări (a se vedea întrebarea 13), astfel încât să putem propune și implementa un mecanism adecvat (care poate include stocarea locală a datelor).
Trebuie considerat că sistemul de porți poate continua procesarea pasagerilor chiar și dacă pierde conexiunea cu infrastructura IT a IGPF?
Rețineți că aceasta poate afecta, de exemplu, verificările de securitate în fundal ale pasagerilor înainte de a intra sau ieși din zona de control de frontieră.
Ofertantul trebuie să detalieze în propunerea tehnică mecanismele de rezervă (fallback) pentru fiecare tip de integrare. Sistemul ABC trebuie să poată continua procesarea locală în caz de indisponibilitate a sistemelor externe, cu sincronizare ulterioară a datelor după restabilirea conexiunii, conform politicilor interne și cerințelor de securitate.