Ministero dell’Interno
Dipartimento della Pubblica Sicurezza
Sigla: asb
OGGETTO: Contratto in forma pubblica amministrativa, a seguito di procedura di gara d’appalto esperita ai sensi dell’articolo 55 del D. Lgs.vo 50 del 18 aprile 2016, realizzata mediante ricorso al “Sistema Dinamico di Acquisizione della Pubblica Amministrazione”, avente ad oggetto la “fornitura di telecamere di videosorveglianza, di "lettura targhe" e di componenti "hardware e software"
per l'aggiornamento tecnologico della "Sala Apparati" della Questura di Roma, con connessi servizi di progettazione, installazione, presa in carico, supporto e formazione, bonifica e smaltimento, nonché assistenza evolutiva ed help desk per un arco temporale di 12 (dodici) mesi”, nell'ambito del Progetto 80.5.1, denominato "Potenziamento del sistema di videosorveglianza e realizzazione di un sistema per analisi intelligente e la metadatazione dei flussi video integrati per la Citta' di Roma Capitale", a valere sul "Fondo Sicurezza Interna 2014-2020-ISF1-POLICE-OS5-ON1". Lotto 1
REPUBBLICA ITALIANA
L’anno 2021 addì __ del mese di _____ - in Roma, nella sede del Ministero dell’Interno, avanti a me Dottor Ufficiale Rogante del Dipartimento della Pubblica Sicurezza, come da Decreto Ministeriale in data _ ______ ___, registrato all’Ufficio Centrale del Bilancio visto - sono presenti:
1) La dr.ssa Clara VACCARO, agente in nome e per conto del Ministero dell’Interno - Dipartimento della Pubblica Sicurezza, nella sua qualità di Direttore Centrale dei Servizi Tecnico-Logistici e della Gestione Patrimoniale, la quale dichiara che l'Amministrazione rappresentata è iscritta alla partita fiscale n. 80202230589;
2) Il Sig. __________, nato a _____il __ _____ ____ – nella sua qualità di dirigente e procuratore della Società/RTI ______ con sede legale in ______, via ________, n. __, il quale dichiara che la Società “____________”, rappresentata, è iscritta nel Registro delle Imprese di ________, al n.
____________, Codice fiscale e Partita I.V.A. n. ___________, con attività esercitata dal __/__/____ “___________________________________________” come risulta anche dal certificato rilasciato dalla Camera di Commercio, Industria, Artigianato, Agricoltura di _____________.
I predetti, della cui identità personale io, Ufficiale Rogante, sono certo, con il mio consenso rinunciano alla presenza di testi.
PRESO ATTO
della gravissima emergenza sanitaria da “COVID-19”, come riconosciuta e disciplinata ufficialmente e progressivamente con i seguenti provvedimenti governativi:
• D.L. 17/03/20, n. 18, convertito nella Legge 24 aprile 2020, n. 27;
• D.L. 25/03/2020 n. 19, convertito nella Legge 22 maggio 2020, n. 35;
• D.L. 16/05/2020 n. 33, convertito nella Legge 14 luglio 2020 n. 74
• D.L. 19/05/2020, n. 34, convertito nella Legge 17 luglio 2020, n. 77;
• D.L. 30/05/2020, n. 83, convertito nella Legge 25 settembre 2020, n. 124,
• D.L. 07/10/2020, n. 125;
• D.P.C.M. 13/10/2020;
• D.P.C.M. 18/10/2020;
• D.P.C.M. 24/10/2020;
• D.P.C.M. 03/11/2020;
• D.P.C.M. 03/12/2020;
delle persistenti raccomandazioni intese a limitare i contatti diretti tra le persone, al fine di prevenire il rischio di una sempre maggiore recrudescenza dell’epidemia;
della specifica disposizione, dettata dalla lettera o), comma 9, del D.P.C.M. 03/11/2020, secondo cui: “nell’ambito delle pubbliche Amministrazioni le riunioni si svolgono in modalità a distanza”.
PREMESSO CHE:
a) l’Amministrazione, con determina a contrarre nr. 27705 dell’1/4/2021, ha manifestato l’intendimento di avviare una procedura ad evidenza pubblica, ai sensi dell’articolo 55 del D. Lgs.vo n. 50 del 18 aprile 2016 e ss.mm.ii., realizzata mediante il ricorso al “Sistema Dinamico di Acquisizione della Pubblica Amministrazione”, per la fornitura di telecamere di videosorveglianza, di “letture targhe” e di componenti “hardware e software” per l’aggiornamento tecnologico della “Sala Apparati” della Questura di Roma con connessi servizi di progettazione, installazione, presa in carico, supporto e formazione bonifica e
smaltimento, nonché assistenza evolutiva ed help desk per un arco temporale di 12 (dodici) mesi, nell'ambito del Progetto 80.5.1, denominato "Potenziamento del sistema di videosorveglianza e realizzazione di un sistema per analisi intelligente e la metadatazione dei flussi video integrati per la Città di Roma Capitale", a valere sul "Fondo Sicurezza Interna 2014-2020-ISF1-POLICE-OS5-ON1";
b) l’Ufficio Tecnico e Analisi di Mercato ha all’uopo predisposto un articolato capitolato tecnico, suddiviso in 2 (due) lotti, ed ha fissato in complessivi € 2.872.645,00, IVA esclusa, l’importo da porre a base d’asta di una procedura di gara aperta da svolgere con ricorso al
“Sistema Dinamico di Acquisizione della Pubblica Amministrazione (SDAPA)”, di cui all’articolo 55 del D.Lgs.vo n.50 del 18 aprile 2016 e ss.mm.ii., da aggiudicare con il criterio dell’’“offerta economicamente più vantaggiosa”, in ossequio al disposto normativo di cui all’articolo 95, comma 2, del menzionato decreto legislativo, di cui il LOTTO 1 avente un valore complessivo di € 1.082.645,00, IVA esclusa;
c) l’Amministrazione ha proceduto, mediante apposita lettera d’invito del / /2021, trasmessa in modalità telematica, ad invitare le Società già ammesse al “Sistema Dinamico di Acquisizione” per le “categorie merceologiche” oggetto della procedura e per le “classi di ammissione” determinate dalla Stazione appaltante;
d) sono pervenute nr. ___offerte e l'Amministrazione, preso atto della proposta di aggiudicazione formulata dalla Commissione Ministeriale nella seduta del __/__/____, è venuta nella determinazione di aggiudicare la fornitura di che trattasi alla Società/RTI
“________”, al prezzo di_________________, cui sono da aggiungere Euro _______,__
per I.V.A. al 22%, per un valore massimo complessivo di Euro __________,__;
e) il/la Società/RTI viene indicato per brevità “Impresa” ed il Ministero dell'Interno - Dipartimento della Pubblica Sicurezza - viene indicato con la parola "Amministrazione";
Tanto premesso si conviene e si stipula quanto segue:
Articolo 1
(Oggetto del contratto, descrizione della fornitura e importo contrattuale)
Il presente atto ha come oggetto la fornitura di telecamere di videosorveglianza, di "lettura targhe" e di componenti "hardware e software" per l'aggiornamento tecnologico della "Sala Apparati" della Questura di Roma, con connessi servizi di progettazione, installazione, presa in carico, supporto e
formazione, bonifica e smaltimento, nonché assistenza evolutiva ed help desk per un arco temporale di 12 (dodici) mesi, nell'ambito del Progetto 80.5.1, denominato "Potenziamento del sistema di videosorveglianza e realizzazione di un sistema per analisi intelligente e la metadatazione dei flussi video integrati per la Città di Roma Capitale", a valere sul "Fondo Sicurezza Interna 2014-2020-ISF1- POLICE-OS5-ON1".
Le caratteristiche tecniche della fornitura dovranno essere in tutto conformi al presente contratto, nonché al capitolato tecnico ed all’offerta tecnico-economica dell’Impresa in data __/__/____, documenti che, benché non allegati e custoditi agli atti dell’Amministrazione, costituiscono anch’essi parte integrante del presente contratto.
Fornitura:
L’oggetto della fornitura è rappresentato dal complesso degli apparati, dei servizi e delle attività come di seguito descritti, tenendo conto che, al fine di una migliore comprensione dell'oggetto dell'appalto, sono state distinte tre aree d'intervento:
Gruppo A: costituito dai “siti di campo” attestati alla Sala Apparati della Questura di Roma, che sono già in esercizio e NON sono oggetto di aggiornamento tecnologico;
Gruppo B: costituito dai “siti di campo” di nuova realizzazione che saranno attestati alla Sala Apparati della Questura di Roma;
Gruppo C: costituito dai “siti di campo” attestati alla Sala Apparati della Questura di Roma, che sono già in esercizio e sono oggetto di aggiornamento tecnologico.
Su tali “siti” infatti attualmente sono installate le 5 telecamere analogiche fisse che dovranno essere sostituite con altrettante telecamere digitali fisse di nuova fornitura.
➢ Fornitura di nr.59 telecamere per videosorveglianza di “tipo PTZ”, da installarsi sui siti afferenti al Gruppo B;
➢ Fornitura di nr. 5 (cinque) telecamere per videosorveglianza di “tipo fisso”, da installarsi sui siti afferenti al Gruppo C;
➢ Fornitura di nr. 11 (undici) telecamere di “lettura targhe (ANPR)”, da installarsi presso i siti del Gruppo B;
➢ Fornitura di componenti hardware e software per l’aggiornamento tecnologico della Sala Apparati che, in particolare, prevede:
a) fornitura di un software VMS “(Milestone Xprotect”), comprensivo dei seguenti pacchetti software, nonché dell’implementazione di due “macchine virtuali” con specifiche funzionalità:
per la gestione dei flussi video delle telecamere di proprietà dell’Amministrazione;
- nr. 1 “XPCOBT - XProtect Corporate Base License”;
- nr. “144 XPCODL - XProtect Corporate Device License”, per altrettante telecamere.
per la gestione dei flussi video di altri sistemi
- nr. 1 “XPETBL - XProtect Expert Base License”;
- nr. 100 “XPETDL - XProtect Expert Device License”;
- nr. 100 “XPCOMIDL -XProtect Corporate Milestone Interconnect Camera License”;
per la funzionalità di “macchine virtuali”:
- “Milestone XProtectManagement Server/Event Server/Log Server”, ovvero la componente Milestone deputata alla gestione degli utenti, delle anagrafiche, dei log ecc…;
- “Milestone ONVIF Bridge”, ovvero la componente deputata a mettere a disposizione di altri sistemi i flussi video gestiti, in modalità conformi allo “standard ONVIF”.
b) fornitura di un software di “lettura targhe” (server virtuale “Prassel ViMS”);
c) fornitura di un’infrastruttura iperconvergente che deve essere del tutto rispondente alle caratteristiche di cui al Paragrafo 8, Sottoparagrafi 8.3.1 e 8.3.2, del capitolato tecnico, Lotto 1, parte II;
d) fornitura delle licenze di Sistema Operativo (“Windows Server 2016”);
e) fornitura di un software di “backup” delle “macchine virtuali”, per il quale sono richieste le relative licenze per almeno n. 20 (venti) “Virtual Machine”, le cui caratteristiche principali sono elencate nel Paragrafo 8, Sottoparagrafo 8.5, del capitolato tecnico, Lotto 1, parte II;
f) fornitura di un sistema di “storage”;
g) fornitura di componenti di rete;
h) fornitura di un “rack” atto ad ospitare le “componenti hardware” fornite;
i) fornitura di postazioni di controllo per le Sale Operative.
➢ Erogazione di servizi professionali per:
a) implementazione dell’aggiornamento tecnologico della Sala Apparati e presa in carico delle telecamere dei siti del Gruppo A;
b) installazione e presa in carico delle nuove telecamere per i siti del Gruppo B e del Gruppo C;
c) supporto per presa in carico dei sensori dell’Impianto sulla piattaforma di monitoraggio “IBM Tivoli” dell’Amministrazione;
d) progettazione;
e) bonifica e smaltimento dell’esistente;
➢ Servizio di formazione per un numero di 4 (quattro) giornate;
- Servizio di assistenza tecnica evolutiva, per la durata di 12 (dodici) mesi, con avvio differenziato per le varie tipologie di “siti” e di componenti dell’Impianto ma con scadenza unitaria, nonchè con costituzione del relativo "Magazzino delle parti di scorta", che dovrà contenere almeno le componenti di cui alla Tabella n. 3 del Paragrafo 10, Sottoparagrafo 10.2.2.1, del Capitolato Tecnico, Parte II^, - LOTTO 1;
-Erogazione di un servizio di “Help Desk”;
-Erogazione di un servizio di supporto tecnico per n. 5 giornate.
Il dettaglio della fornitura è contenuto nel capitolato tecnico pubblicato e reso disponibile, unitamente al bando di gara ed ai documenti complementari, sui siti istituzionali.
Luoghi di esecuzione
I luoghi di esecuzione del presente appalto specifico sono quelli compendiati nell’”Allegato 1” al Capitolato tecnico di gara Parte II^ - LOTTO 1, recante l’elenco di tutti i siti e degli apparati che costituiscono l’impianto e che sono oggetto, in particolare, del servizio di manutenzione evolutiva.
L’ammontare complessivo del contratto è di €__________, cui sono da aggiungere € ________ , per IVA al 22%, per un valore complessivo non superabile di € __________.
Etichette
In relazione agli obblighi di informazione e pubblicità relativi al beneficio del finanziamento, l’Impresa/RTI/Consorzio aggiudicataria/o si impegna a rispettare le previsioni di cui al Regolamento delegato (UE) nr. 1049/2014 del 30/7/2014 e relativo Allegato, che definisce le caratteristiche tecniche delle misure di informazione e pubblicità destinate al pubblico ed ai beneficiari ai sensi del Regolamento (UE) nr. 514/2014, in conformità al “fac simile” di cui all’allegato 11 del capitolato d’oneri.
Opzioni
1. L’Amministrazione, entro la scadenza contrattuale, si riserva la facoltà di operare modifiche, nonché varianti, del contratto di appalto in corso di validità derivante dalla presente procedura, previa autorizzazione del Responsabile Unico del Procedimento, ai sensi all’articolo 106, comma 1, lettere b), c), d) ed e), del D.Lgs.vo 50/2016 e ss.mm.ii., purché il valore della
modifica, nonché variante, sia al di sotto di entrambi i valori di cui al comma 2, lettere a) e b), del sopramenzionato articolo;
2. L’Amministrazione, entro la scadenza contrattuale, si riserva la facoltà di implementare la fornitura fino alla concorrenza massima di un quinto dell’importo contrattuale entro l’importo massimo complessivo stimato di € ________, IVA esclusa, che l’esecutore è tenuto ad eseguire, previa sottoscrizione di un atto di sottomissione, agli stessi patti, prezzi e condizioni del contratto originario senza diritto ad alcuna indennità ad eccezione del corrispettivo relativo alle nuove prestazioni, in ossequio all’articolo 106, comma 12, del D.Lgs.vo 50/2016 e ss.mm.ii.;
3. L’Amministrazione, entro la scadenza contrattuale, si riserva la facoltà di esercitare la previsione di cui al disposto normativo dell’articolo 63, comma 5, del D.Lgs. n. 50/2016 e ss.mm.ii., per una durata massima pari ad un’ulteriore annualità.
4. L’Amministrazione, entro la scadenza contrattuale, si riserva, altresì, la facoltà di disporre la proroga del servizio, ai sensi dell’art. 106, comma 11, del D.Lgs.vo n.50/2016 e ss.mm.ii., nella misura strettamente necessaria ed alle medesime o più favorevoli condizioni contrattuali, nelle more dello svolgimento e conclusione delle ordinarie procedure di scelta di un nuovo contraente.
Qualora l’Amministrazione voglia avvalersi delle opzioni di cui sopra è tenuta a darne comunicazione per iscritto alla controparte, prima della scadenza del contratto, mediante lettera raccomandata AR o mediante altra forma idonea a garantire data certa.
Il prezzo offerto è formulato in base a calcoli di propria convenienza, tutto incluso e nulla escluso.
Esso pertanto è fisso ed invariabile per tutta la durata del contratto.
Articolo 2
(Norme regolatrici del contratto) Per il presente contratto vengono osservate le seguenti norme:
a) la Legge per l’Amministrazione del Patrimonio e per la Contabilità Generale dello Stato (Regio Decreto 18 novembre 1923, n. 2440, e successive modificazioni);
b) il Regolamento per l’Amministrazione del Patrimonio e per la Contabilità Generale dello Stato (Regio Decreto 23 maggio 1924, n. 827, e successive modificazioni);
c) le Condizioni Generali d’Oneri per gli acquisti e le lavorazioni dei materiali di vestiario, equipaggiamento, servizi generali e casermaggio per la Polizia di Stato, approvate con Decreto
del Ministro dell'Interno n. 999.9687.AG.ll del 28 marzo 1953, registrato alla Corte dei Conti il 29 maggio 1953, per quanto applicabili;
d) il Decreto del Presidente della Repubblica 7 agosto 1992, n. 417, recante il Regolamento di amministrazione e di contabilità dell'Amministrazione della pubblica sicurezza;
e) il D.P.C.M 06/08/1997 n. 452, recante l’approvazione del capitolato di cui all'articolo 12, comma 1, del Decreto Legislativo 12 febbraio 1993, n. 39, relativo alla locazione e all'acquisto di apparecchiature informatiche, nonché alla licenza d’uso dei programmi;
f) il Decreto Legislativo n.50 del 18/04/2016, come integrato e corretto dal D. Lgs.vo
19/04/2017, nr. 56, entrato in vigore in data 20/05/2017, dalla Legge 14/06/2019, nr. 55, di conversione, con modificazioni, del Decreto Legge 18/04/2019, nr. 32, nonché dal decreto legge 16/7/2020, nr. 76, come convertito, con modificazioni, dalla Legge 11/9/2020, nr.
120;
g) il Decreto Legge 95/2012, convertito con Legge n. 135/2012;
h) la Legge 24 dicembre 2007, n. 244, in materia di fatturazione elettronica;
i) l’articolo 34 della Legge 31 dicembre 2009, n. 196, come da ultimo modificato dal Decreto Legislativo 16 marzo 2018, n. 29;
j) l’articolo 1 della Legge 28/12/2018, n. 208 (Legge di Stabilità 2016);
k) il Regolamento UE 2016/679, come recepito dal Decreto Legislativo 10/08/2018, nr. 101;
l) i Regolamenti nr. 513/2014, nr. 514/2014 e nr. 515/2014, tutti in data 16/4/2014, del Parlamento Europeo e del Consiglio, nonché nr. 800/2014 in data 24/7/2014, nr. 1042/2014, nr. 1048/2014 e nr. 1049/2014 della Commissione in data 25/7/2014 e 30/7/2014;
m) le disposizioni previste dal Codice civile e dalle Leggi speciali, per quanto non espressamente regolato dalle leggi e dai regolamenti di cui ai precedenti punti (a), (b), (c), (d), (e), f), g), h), i), j), k) ed l), in quanto compatibili con la Legge ed il Regolamento di contabilità generale dello Stato.
L’Impresa contraente dichiara di conoscere e di accettare, in ogni loro parte, tutte le normative di cui ai predetti punti a), b), c), d), e), f), g), h), i), j), k), l) ed m), che si intendono qui integralmente trascritte senza, peraltro, che siano allegate al contratto, ai sensi dell'articolo 99 del Regolamento per l’Amministrazione del Patrimonio e per la Contabilità Generale dello Stato.
Articolo 3
(Direttore dell’Esecuzione del Contratto e Responsabile di Progetto)
Ai sensi dell’art. 101, comma 1, del D.Lgs.vo n. 50/2016 e ss.mm.ii., l’Amministrazione, entro il termine di 10 (dieci) giorni solari dalla data di esecutività del presente contratto, provvederà a nominare un “Direttore dell’Esecuzione” del contratto, con compiti di coordinamento, direzione e controllo tecnico contabile dell’esecuzione del presente contratto in ossequio al disposto normativo di cui all’articolo 111, comma 2, del menzionato decreto legislativo, nonché del Decreto nr. 49 in data 7/3/2018 del Ministero delle Infrastrutture e Trasporti, e di tale nomina verrà data comunicazione all’Impresa.
Il Direttore dell’Esecuzione Contrattuale, congiuntamente con il Responsabile Unico del Procedimento, dovrà assicurare altresì la regolare esecuzione del contratto da parte dell’Impresa, verificando che le attività e le prestazioni contrattuali siano eseguite in conformità dei documenti contrattuali.
Entro la medesima data, l’Impresa dovrà nominare un “Responsabile Generale di Progetto (Project Manager)” con funzioni di unica interfaccia tecnico contabile con l’Amministrazione e di tale nomina dovrà essere data comunicazione all’Amministrazione.
Il suddetto “Responsabile di Progetto” sarà incaricato di curare il coordinamento tecnico delle attività in fase di messa in esercizio, nonché di svolgere la funzione di unico referente nei confronti dell’Amministrazione.
In particolare, al “Responsabile Generale di Progetto” faranno capo gli adempimenti di seguito indicati:
➢ programmazione, organizzazione, coordinamento e monitoraggio del progetto;
➢ interfacciamento con il Direttore dell’Esecuzione del Contratto;
➢ raccolta e controllo delle informazioni per la gestione della reportistica e delle penali;
➢ gestione del processo di fatturazione;
➢ gestione delle richieste, delle segnalazioni e delle problematiche sollevate dall’Amministrazione in merito all’erogazione dei servizi e delle forniture.
Il “Responsabile Generale del Progetto” dovrà anticipare e porre rimedio a tutte le criticità che dovessero emergere sia nella fase di realizzazione del progetto sia in quella successiva di erogazione dei servizi di assistenza, provvedendo alla tempestiva segnalazione all’Amministrazione di eventuali problematiche per le quali è richiesto l’intervento dell’Amministrazione stessa.
Il “Responsabile Generale del Progetto” dovrà garantire all’Amministrazione una costante ed efficace informazione sull’andamento del presente contratto.
In particolare, nella fase iniziale, fino al completamento delle attività di cui ai Paragrafi 7, 8, e 9 del capitolato tecnico di gara Parte II^ - Lotto 1, si terranno riunioni di monitoraggio delle attività con cadenza almeno quindicinale.
In tali riunioni, il “Responsabile Generale di Progetto” dovrà presentare il documento di “Stato Avanzamento Lavori (SAL)”, aggiornato di riunione in riunione.
Per quanto concerne invece i servizi di assistenza, il “Responsabile Generale del Progetto” dovrà fornire al Direttore dell’esecuzione contrattuale una “Relazione sull’andamento dei servizi di assistenza” con cadenza semestrale.
Tale relazione dovrà contenere la reportistica dei guasti e l’analisi dei “livelli di servizio” di assistenza erogati.
In particolare, il cennato documento dovrà riportare:
➢ “report” sul servizio di assistenza evolutiva preventiva dei “siti”, di cui al Paragrafo 10.2 del capitolato tecnico PARTE II - Lotto 1, in cui siano evidenziate eventuali criticità rilevate presso i vari “siti” durante l’effettuazione delle visite periodiche semestrali;
➢ “report” sugli interventi di assistenza correttiva, finalizzato alla valutazione dei “livelli di servizio” su base semestrale. In particolare, in tale “report” saranno indicati per tutti gli interventi i seguenti dati:
• identificativo della richiesta di intervento;
• identificativo del sito oggetto della segnalazione;
• data e ora della segnalazione dell’Amministrazione;
• nominativo del personale dell’Amministrazione che ha aperto la segnalazione di intervento;
• descrizione sintetica del guasto;
• data e ora del ripristino del servizio;
• indicazione del livello di servizio erogato;
• eventuali motivi ostativi alla risoluzione del guasto;
• apparati eventualmente dismessi (nr seriale);
• apparati sostitutivi (nr. seriale).
➢ stato aggiornato delle consistenze del “Magazzino delle Parti di Scorta”.
L’Impresa dovrà fornire i riferimenti (numero di telefono, numero di fax, indirizzo e-mail) del
“Responsabile Generale di Progetto”.
Il mancato rispetto dei termini indicati al presente Paragrafo comporterà l’applicazione di specifiche penalità previste al successivo articolo 12.
Articolo 4 (Validità contrattuale) VALIDITA’ CONTRATTUALE
La validità del presente atto negoziale decorrerà dalla data di ricevimento da parte dell’Impresa della comunicazione, da effettuare tramite PEC da parte dell’Amministrazione, successivamente all’esito positivo dei controlli effettuati dai competenti Uffici dell’Autorità Responsabile del “Fondo Sicurezza Interna 2014-2020”, nonché all’avvenuta approvazione del contratto e della sua registrazione, a norma delle vigenti disposizioni di legge, da parte degli Organi deputati al controllo di legittimità, fatta salva la formalizzazione della comunicazione di “esecuzione d’urgenza” di cui all’articolo 32, comma 8, del D.Lgs.vo n.50/2016 e ss.mm.ii., sostanziandosi in una progettualità garantita per complessivi 12 (dodici) mesi decorrenti dalla data della dell’approvazione del certificato di positiva verifica di conformità funzionale per la Sala Apparati ed i “siti” del Gruppo A (FASE 2).
Articolo 4.bis
(Riunione di avvio lavori – Progetto tecnico – Approvvigionamento fornitura (Telecamere per siti di campo, componenti Hw e Sw per gestione flussi multimediali Questura di Roma, pacchetti assistenza, magazzino parti di scorta) – Approntamento alla verifica inventariale -
FASE 1) 4.bis.1 - “Riunione di avvio lavori”
L’Amministrazione, entro il termine di 10 (dieci) giorni solari decorrenti dalla data di ricevimento della comunicazione, da effettuare tramite PEC da parte dell’Amministrazione, dell’esito positivo dei controlli dell’Autorità Responsabile del “Fondo Sicurezza Interna 2014/2020” e dell’avvenuta approvazione del contratto e della sua registrazione, di cui al precedente articolo 4, fatta salva la formalizzazione della comunicazione di “esecuzione d’urgenza” di cui all’articolo 32, comma 8, del D.Lgs.vo n.50/2016 e ss.mm.ii., nonché successivamente all’avvenuta nomina del Direttore dell’esecuzione del contratto, di cui al precedente articolo 3, provvederà, per il tramite dello stesso, ad organizzare un primo incontro (c.d. “Riunione di avvio lavori”) con il “Responsabile Generale di Progetto”, al fine di pianificare le attività successive dando così contestualmente “avvio ai lavori”.
Il mancato rispetto dei termini indicati al presente Paragrafo per cause imputabili all’Impresa comporterà l’applicazione di specifiche penalità previste al successivo articolo 12.
4.bis.2 – Progetto tecnico
L’Impresa, entro il successivo termine di 30 (trenta) giorni solari dall'avvenuta “Riunione di avvio lavori”, di cui al precedente Paragrafo 4.bis.1, dovrà presentare al Direttore dell'esecuzione del contratto un documento denominato “Progetto Tecnico”, che dovrà possedere i seguenti contenuti minimali:
- descrizione delle telecamere di tipo “PTZ” e dei relativi accessori forniti;
- descrizione delle telecamere “fisse” e dei relativi accessori forniti;
- descrizione delle telecamere di “lettura targhe” e dei relativi accessori forniti;
- descrizione dettagliata della soluzione per l’aggiornamento tecnologico del sistema di gestione dei flussi multimediali della Questura di Roma che dovrà contenere:
o descrizione dell’infrastruttura “iperconvergente” fornita, esplicitando le caratteristiche della stessa e dei nodi che la compongono;
o descrizione del sistema di "storage" fornito;
o descrizione delle “componenti di rete” fornite;
o architettura fisica che sarà realizzata con l’indicazione di tutti i collegamenti di rete, riportandosi in particolare gli schemi di installazione nel "rack" ed evidenziando tutti i cablaggi sia di rete che elettrici;
o architettura logica che sarà realizzata;
o descrizione delle macchine virtuali implementate;
o descrizione delle configurazioni che saranno realizzate sulle componenti di rete: "full proxy", "switch top-of-rack" e "switch" di distribuzione;
o descrizione dettagliata delle attività che saranno eseguite per addivenire all’aggiornamento tecnologico ed in particolare delle procedure di migrazione dalla situazione attuale a quella "to-be";
- Scheda riepilogativa di tutte le componenti "hardware" e "software" fornite con indicazione, per ogni componente, di:
o codice prodotto e numero seriale (per le telecamere deve essere indicato anche il sito di installazione);
o codice prodotto e numero di contratto del pacchetto di assistenza del fornitore, laddove richiesto.
- diagramma di "Gantt" parametrico, delle attività da eseguire per garantire la messa in opera del progetto con le tempistiche relative.
Tale “Progetto tecnico” sarà sottoposto a valutazione e approvazione da parte dall’Amministrazione per mezzo del Direttore dell’esecuzione del contratto, entro il termine di 10 (dieci) giorni lavorativi dalla presentazione dello stesso.
Nel caso in cui la valutazione del “Progetto tecnico” risultasse negativa o insufficiente, questo dovrà essere nuovamente presentato per la valutazione entro e non oltre il termine di 10 (dieci) giorni solari decorrenti dalla data di comunicazione del rigetto.
Trascorsi tali 10 (dieci) giorni, qualora il suddetto “Progetto tecnico” non sia ancora disponibile o la successiva verifica di conformità risulti ancora negativa, l’Amministrazione potrà rifiutare la fornitura riservandosi la facoltà di risolvere il contratto per mancato adempimento e di procedere in danno, con conseguente incameramento dell’intero deposito cauzionale e fatta salva ogni altra azione risarcitoria.
L’esito di tale verifica sarà comunicato all’Impresa tramite PEC da parte dell’Amministrazione.
Durante la vigenza contrattuale, l’Impresa ha l’onere di rivisitare il “Progetto Tecnico”, riportandovi le eventuali modifiche che potrebbero essersi rese necessarie in fase realizzativa.
Il mancato rispetto dei termini indicati al presente Paragrafo comporterà l’applicazione di specifiche penalità previste al successivo articolo 12.
4.bis.3 – Approvvigionamento apparati “hardware e software”
L’Impresa, entro il termine di 60 (sessanta) giorni solari dall'avvenuta “Riunione di avvio lavori”, di cui al precedente Paragrafo 4.bis.1, dovrà provvedere all'approvvigionamento della fornitura oggetto del presente atto, secondo le seguenti modalità e relative tipologie, pena l’applicazione delle penalità di cui al successivo articolo 12.
4.bis.3.1 FORNITURA DI NR. 59 (CINQUANTANOVE) TELECAMERE PER L’AGGIORNAMENTO TECNOLOGICO E L’INCREMENTO DEI “SITI DI CAMPO”.
(APPARATI GRUPPO A)
1. Fornitura di nr. 59 (cinquantanove) telecamere per videosorveglianza di tipo “PTZ”
Le telecamere di videosorveglianza di “tipo PTZ”, oggetto di fornitura in opera, dovranno rispettare i requisiti di seguito riportati:
1. telecamera "IP" nativa, di tipo "speedome PTZ";
2. telecamera a colori di tipo "DAY/NIGHT" con rimozione filtro "IR automatica" (ICR);
3. sensore di ripresa "CMOS" a colori progressive "scan" da almeno 1/3”;
4. risoluzione di almeno "2 Mpxl";
5. sensibilità del complesso di ripresa di almeno 0,2 "Lux" in modalità colore (day);
6. "Wide Dynamic Range" di almeno "120dB", realizzato mediante la cattura di più immagini con un diverso livello di esposizione;
7. bilanciamento automatico del livello di bianco;
8. ottica motorizzata con:
(a) focale minima compresa tra 4 e 5 mm;
(b) zoom ottico di almeno 30x;
(c) autofocus;
(d) autoiris o "P-IRIS";
(e) apertura minima pari a F=1.6 o inferiore;
9. zoom digitale almeno 12x;
10. tempo di otturazione minino di “1/10000 s” (sono migliorativi valori inferiori);
11. illuminatori "IR" integrati con range di copertura di almeno 150 m;
12. formati di compressione video supportati: “H.264, H.265 e M-JPEG”;
13. “frame” rate fino a “30 fps” alla massima risoluzione;
14. interfaccia di rete ethernet "RJ45";
15. protocolli di networking: "IPv4/IPv6","HTTP","HTTPS", "TCP/IP", "UDP", "SNMP",
"RTSP", "RTP", "NTP", "DHCP", "DNS FTP", "802.1x";
16. compliance allo "Standard Onvif" Profilo "S" e Profilo "G";
17. possibilità di trasmettere almeno due “stream video” configurabili indipendentemente di cui almeno uno alla massima risoluzione;
18. funzionalità di video "motion detection";
19. almeno n° 16 Posizioni angolari preselezionabili (“preset”) e possibilità di configurare “tour (ronde)”;
20. almeno nr. 1 ingresso e almeno nr. 1 uscita d'allarme a bordo camera, precisandosi che, nel caso in cui la telecamera proposta preveda l’impiego di un separato “modulo relè I/O di rete”, che inoltra gli allarmi su rete ethernet, sono a carico dell’Impresa tutti gli interventi necessari ad adeguare il singolo “sito di campo” e a far sì che esso sia perfettamente
funzionante (ad esempio fornitura di "switch" aggiuntivi, sostituzione "box" di contenimento apparati laddove le dimensioni fossero insufficienti, ecc.).
21. almeno nr. 8 zone di esclusione (Privacy Mask);
22. indice di protezione dagli agenti atmosferici almeno pari a “IP66”;
23. alimentazione "PoE/12 VDC/24 VAC/48VDC" con alimentatore o adattatore "PoE"
incluso nella fornitura, laddove necessario ad integrare la telecamera nel “sito di campo”;
24. temperatura di funzionamento compresa almeno nel seguente intervallo: -20 °C, 50°C;
25. livello di umidità operativo ≤90%;
26. dimensioni massime: altezza (H) 35cm, larghezza (L)22cm.
La fornitura delle telecamere è da ritenersi comprensiva di:
- staffe e supporti necessari per l’installazione delle stesse a palo o a muro;
- cavi di alimentazione, cavi per connessioni I/O necessari a riportare gli allarmi in ingresso e/o uscita.
Tutte le telecamere dovranno essere dotate di scheda di memoria "SD da 256 GB" con una velocità di scrittura non inferiore a "30MB/s", "Class 3"(U3). In assenza di collegamento con la Sala Apparati Provinciale, i flussi video dovranno essere memorizzati in locale sulla memoria "SDXC"; all’atto del ripristino del collegamento i dati dovranno essere trasmessi alla "server farm" per la loro memorizzazione sullo “storage” dedicato.
Le telecamere fornite dovranno essere coperte da garanzia del produttore di almeno 2 anni ed in fase esecutiva l'Impresa dovrà fornire all’Amministrazione la documentazione comprovante il possesso di tale requisito (es. fattura di vendita).
2. Fornitura di nr. 5 (cinque) telecamere per videosorveglianza di tipo “fisso”
Le telecamere di videosorveglianza di “tipo fisso”, oggetto di fornitura in opera, dovranno rispettare i requisiti di seguito riportati:
1. telecamera "IP" nativa;
2. telecamera a colori di tipo "DAY/NIGHT" con rimozione filtro "IR" automatica (ICR);
3. sensore di ripresa "CMOS" a colori progressive "scan" da almeno 1/3”;
4. risoluzione di almeno 5 "Mpxl";
5. sensibilità del complesso di ripresa di almeno 0,2 "Lux" in modalità colore (day);
6. "Wide Dynamic Range" di almeno 120dB, realizzato mediante la cattura di più immagini con un diverso livello di esposizione;
7. bilanciamento automatico del livello di bianco;
8. ottica varifocale motorizzata con:
(a) focale minima compresa tra 2,7 e 3,8 mm;
(b) rapporto di zoom ottico di almeno 2,5x;
(c) "autoiris" o "P-Iris";
(d) apertura minima pari a F=1.5 o inferiore;
9. tempo di otturazione minino di “1/10000” s (sono migliorativi valori inferiori);
10. illuminatori "IR" integrati con range di copertura di almeno 30 m;
11. angolo di campo orizzontale massimo pari almeno a 90°;
12. formati di compressione video supportati: "H.264" e "M-JPEG";
13. “frame” rate almeno fino a “20 fps” alla massima risoluzione;
14. interfaccia di rete "ethernet RJ45";
15. protocolli di "networking": "IPv4/IPv6", "HTTP", "HTTPS", "TCP/IP", "UDP",
"SNMP", "RTSP", "RTP", "NTP", "DHCP", "DNS FTP", "802.1x";
16. “compliance” allo “Standard Onvif Profilo S e Profilo G”;
17. possibilità di trasmettere almeno due “stream video” configurabili indipendentemente di cui almeno uno alla massima risoluzione;
18. funzionalità di video "motion detection";
19. almeno nr. 1 ingresso e almeno nr. 1 uscita d'allarme a bordo camera, precisandosi che, nel caso in cui la telecamera proposta preveda l’impiego di un separato modulo “relè I/O di rete”, che inoltra gli allarmi su rete ethernet, sono a carico dell’Impresa tutti gli interventi necessari ad adeguare il singolo “sito di campo” e a far sì che esso sia perfettamente funzionante (ad esempio fornitura di switch aggiuntivi, sostituzione box di contenimento apparati laddove le dimensioni fossero insufficienti, ecc.).
20. indice di protezione dagli agenti atmosferici almeno pari a “IP67”;
21. alimentazione "PoE/12 VDC/24 VAC/48VDC" con alimentatore o adattatore "PoE"
incluso nella fornitura, laddove necessario ad integrare la telecamera nel sito di campo;
22. temperatura di funzionamento compresa almeno nel seguente intervallo: -20 °C, 50°C;
23. livello di umidità operativo ≤90%.
lunghezza massima del dispositivo: 400 mm (parasole incluso).
La fornitura delle telecamere è da ritenersi comprensiva di:
- staffe e supporti necessari per l’installazione delle stesse a palo o a muro, in funzione del sito;
- parasole;
- cavi di alimentazione, cavi per connessioni I/O necessari a riportare gli allarmi in ingresso e/o uscita.
Tutte le telecamere dovranno essere dotate di scheda di memoria "SDXC da 256 GB" con una velocità di scrittura non inferiore a "30MB/s", "Class 3(U3)". In assenza di collegamento con la Sala Apparati Provinciale, i flussi video dovranno essere memorizzati in locale sulla memoria "SDXC" ed all’atto del ripristino del collegamento i dati dovranno essere trasmessi alla "server farm" per la loro memorizzazione sullo “storage” dedicato.
Le telecamere fornite dovranno essere coperte da garanzia del produttore di almeno 2 anni ed in fase esecutiva, l'Impresa dovrà fornire all’Amministrazione la documentazione comprovante il possesso di tale requisito (es. fattura di vendita).
3. Fornitura di nr. 11 (undici) telecamere di “lettura targhe”
Le telecamere di “lettura targhe”, oggetto di fornitura in opera, dovranno rispettare i requisiti di seguito descritti.
L’Impresa dovrà fornire una tipologia di telecamera con “funzionalità ANPR”, in cui tutte le logiche (OCR compresa) siano eseguite a bordo dell’apparato senza ausilio di componenti elaborazione esterne. L’apparato dovrà essere dotato di un sensore per il rilevamento delle targhe e di un sensore di contesto.
Il “lettore” fornito per ogni transito dovrà fornire:
- stringa di dati alfanumerica della targa rilevata;
- immagine “OCR in B/N” dalla quale deve essere possibile rilevare con esattezza la targa del veicolo;
- immagine “JPEG” a colori del contesto, relativo stesso istante temporale dell’immagine in
“B/N”;
- “CROP IMAGE”, cioè porzione dell’immagine in “B/N” contenente la targa catturata dal sensore di lettura delle targhe.
Il “lettore” fornito dovrà rispettare le seguenti caratteristiche tecniche minimali:
- modalità di funzionamento di “tipo free-run” (riconoscimento della targa dei mezzi transitanti senza l’ausilio di trigger esterni);
- doppia telecamera:
o una telecamera per la “lettura targhe (OCR”), avente risoluzione minima di “5 Megapixel”, sensore “CMOS di tipo global shutter” da almeno 1/2", “frame rate”
di almeno 60 fps;
o una telecamera di contesto a colori con risoluzione minima “2 Mpxl”.
- illuminatori “IR a led integrati”;
- esecuzione dell’algoritmo “OCR a bordo camera”;
- larghezza supportata della carreggiata inquadrata di almeno 4m;
- distanza massima di riconoscimento delle targhe di almeno 25 m;
- riconoscimento delle targhe dell’Unione Europea, dei principali Paesi extra comunitari, targhe speciali (esempio, Forze di Polizia, ecc.), riconoscimento di “pannelli Kemler” di segnalazione merci pericolose (Direttiva europea 2008/68/CE) relativa al trasporto del carico e della pericolosità dello stesso;
- percentuale di rilevazione fotografica dei veicoli in transito: almeno pari a 99%;
- percentuale di riconoscimento delle targhe sul totale riconoscibile ad occhio umano:
almeno pari a 95%;
- massima velocità del veicolo da rilevare di almeno 250 km/h;
- capacità di rilevazione del colore e di classificazione degli autoveicoli;
- almeno una “interfaccia Ethernet 10/100”;
- protocolli supportati: “TCP/IP, FTP, HTTP, SNMP”;
- “streaming video” su “protocollo RTSP/RTP” e compressione “H264 o superiore”;
- storage interno di almeno “128 GB” (tale requisito può essere soddisfatto anche mediante la fornitura di schede SD transfer rate di almeno 30 MB/s, se supportate);
- gestione di “black-list e white-list”;
- range operativo di temperatura da -30° a 55°;
- grado di protezione “IP66”;
- n° 1 ingresso d'allarme a bordo lettore;
- n° 1 uscita d’allarme a bordo lettore;
- alimentazione “PoE o 12 VDC o 24 VAC” (con alimentatore incluso).
La fornitura delle telecamere è da ritenersi comprensiva di:
- staffe e supporti necessari per l’installazione delle stesse a palo o a muro, in funzione del sito;
- apparati e cavi di alimentazione;
- eventuali cavi per “connessioni I/O” necessari a riportare gli allarmi in ingresso e/o uscita.
In assenza di collegamento con la Sala Apparati, i dati rilevati dovranno essere memorizzati in locale sull’apparato ed all’atto del ripristino del collegamento i dati dovranno essere trasmessi alla “server farm” per la loro memorizzazione sullo “storage” dedicato.
Le telecamere di “lettura targhe” fornite dovranno essere coperte da garanzia del produttore di almeno 2 anni ed, in fase esecutiva, l’Impresa dovrà fornire all’Amministrazione la documentazione comprovante il possesso di tale requisito (es. fattura di vendita).
4.bis.3.2 FORNITURA DI COMPONENTI HARWARE E SOFTWARE PER L’AGGIORNAMENTO TECNOLOGICO DEL SISTEMA DI GESTIONE DEI FLUSSI MULTIMEDIALI DELLA QUESTURA DI ROMA (APPARATI GRUPPO B).
1. Software “VMS” per catalogo multimediale
Al fine di addivenire all’implementazione di un catalogo multimediale, nel quale dovranno confluire tutti i flussi multimediali di interesse per le attività di Polizia, quali ad esempio: immagini delle telecamere dell’Impianto di videosorveglianza cittadina di proprietà dell’Amministrazione, immagini generate da sistemi di videosorveglianza di altri enti ( stazioni, Amministrazioni comunali, aeroporti, ecc…), immagini generate da altri “sistemi” dell’Amministrazione (videosorveglianza in mobilità, sistema Mercurio, Elivideo, ecc.), l’Impresa dovrà provvedere alla fornitura in opera del software
“VMS” “Milestone Xprotect”.
Il “software” dovrà essere installato dall’Impresa sull’infrastruttura “iperconvergente”, di cui al successivo punto 3.
Inoltre, per la gestione e la registrazione dei flussi video generati dalle telecamere di proprietà dell’Amministrazione, l’Impresa dovrà fornire i seguenti pacchetti “software”:
- nr. 1 “XPCOBT - XProtect Corporate Base License”;
- nr. 144 “XPCODL - XProtect Corporate Device License”, per altrettante telecamere L’Impresa dovrà implementare sull’infrastruttura “iperconvergente”, di cui al successivo punto 3, i
“recording serverMilestone XProtect Corporate”, necessari a ricevere e registrare i flussi video delle 144 telecamere. Ciascun “recording server” dovrà essere dimensionato riservando ad ogni telecamera un “throughput” di almeno “6Mbps”. Per ogni telecamera dell’Impianto, il sistema “VMS” dovrà essere configurato per registrare un flusso avente almeno le seguenti caratteristiche: codifica H.264 a media compressione, frame rate di 25 fps e risoluzione 1920x1080.
Le immagini ricevute dalle telecamere dei siti di campo devono essere memorizzate sullo spazio disco dell’infrastruttura “iperconvergente”, di cui al successivo punto 3, prevedendo, alla saturazione di tale spazio, lo spostamento dei flussi video più vecchi sul “sistema di storage” esterno al successivo punto 3.
Ulteriori indicazioni sulla modalità di configurazione del "VMS" e delle relative “macchine virtuali”
saranno fornite in fase esecutiva.
Al fine di implementare una soluzione completa per la gestione dei flussi video dovranno essere implementate “due macchine virtuali”, aventi le seguenti funzionalità:
- “Milestone XProtectManagement Server/Event Server/Log Server”, ovvero la componente “Milestone” deputata alla gestione degli utenti, delle anagrafiche, dei log ecc…
- “Milestone ONVIF Bridge”, ovvero la componente deputata a mettere a disposizione di altri sistemi i flussi video gestiti, in modalità conformi allo standard “ONVIF”.
2. "Software" di lettura targhe
Al fine di poter gestire i flussi di transiti di automezzi rilevati dalle telecamere di “lettura targhe” e poter interfacciare il sistema “SCNTT” della Polizia di Stato, l’Impresa garantisce la fornitura in opera di un server virtuale “Prassel ViMS” da installarsi sull’infrastruttura “iperconvergente”, di cui al successivo punto 3 .
A tal fine, l’Impresa dovrà fornire tutte le licenze “Prassel ViMS” necessarie a poter gestire tramite detto applicativo i nr. 11 (undici) lettori targhe in fornitura.
3. Infrastruttura server "iperconvergente"
L’Impresa dovrà provvedere alla fornitura in opera di un’infrastruttura server “iperconvergente”
avente le caratteristiche descritte nei seguenti punti 3.1 e 3.2.
Per garantire che la tecnologia fornita all’Amministrazione sia tra le migliori presenti sul mercato, la soluzione “iperconvergente” proposta deve essere ricompresa tra quelle prodotte dai “player”
classificati come “leader” nell’ultimo quadrante magico di “Gartner” o nell’ultimo report di “Forrester Wave”.
3.1 Caratteristiche dell’infrastruttura "iperconvergente"
Di seguito, vengono riportate le caratteristiche comuni a tutta l’infrastruttura:
- La soluzione proposta deve supportare ed essere certificata almeno per i seguenti software di virtualizzazione: "VMware ESXi" e "Microsoft Hyper-V";
- La soluzione proposta deve "supportare ed" essere certificata per ospitare "VM" con i seguenti
“Sistemi Operativi”:
➢ "Microsoft Windows Server" 2012, 2016 e successive;
➢ "Red Hat Linux 6.x, 7.x" e successive;
- La soluzione proposta deve essere dichiarata in “General Availability (GA)” alla data di presentazione dell’offerta. Non sono accettate soluzioni in “release beta” o con funzionalità non ancora rilasciate al pubblico o in “roadmap”;
- La soluzione deve essere completa degli apparati di connettività con le caratteristiche descritte nel successivo punto 7;
- Deve essere garantito l’aggiornamento gratuito del “software” dell’infrastruttura nel periodo di garanzia;
- Tutto il “software” per la gestione e la virtualizzazione delle risorse ”hardware” deve essere fornito in “bundle” con i sistemi, con supporto in garanzia di 36 mesi;
- L’infrastruttura deve avere almeno nr.4 (quattro) “nodi” con le caratteristiche descritte nel successivo punto 3.2.;
- L’infrastruttura deve essere resiliente alla perdita di un “nodo”, ovvero a fronte della perdita di un
“nodo” relativamente alla capacità dell’infrastruttura di continuare a funzionare, in caso di indisponibilità, deve essere garantita la ridondanza all’interno del “cluster” sui nodi restanti (N-1);
- Deve essere possibile, in caso di indisponibilità di un “nodo”, il ripristino delle funzionalità dell’infrastruttura “iperconvergente” senza intervento dell’operatore;
- In caso di “failure” di uno dei “nodi”, le “VM” presenti devono essere immediatamente disponibili sugli altri “nodi” senza alcuna interruzione o ripartenza del servizio;
- Deve essere possibile gestire e creare un numero illimitato di “VM”; in tal contesto ci si riferisce a possibili limitazioni della licenza di virtualizzazione e non alla limitazione fisica dell’infrastruttura e precisamente, la “console” di gestione delle “VM” deve essere in grado di creare e gestire un numero illimitato di “VM”;
- Devono essere presenti funzionalità di “snapshot” delle “VM” con modalità “crash-consistent” (ad esempio mediante integrazioni “VSS” su piattaforma “Microsoft”);
- Deve essere possibile la creazione di gruppi di consistenza, ovvero raggruppamenti logici di “VM”
da proteggere mediante “snapshot simultanei”;
- L’infrastruttura deve essere resiliente alla rottura di un disco ed i dati presenti sul disco rotto debbono essere automaticamente ricostruiti e senza intervento dell’operatore;
- Deve essere presente un meccanismo di controllo della congruità dei dati al fine di evitare perdita e/o corruzione dei dati stessi presenti all’interno del “file system”;
- Per la gestione dei dati è necessaria la presenza di una componente automatica di “multipathing”
per le “VM” al fine di garantire l’accesso ai dati in caso di “failure” o indisponibilità di elementi della soluzione;
- La protezione dei dati, basata su doppia copia del dato, deve essere sempre su “nodi” diversi;
- Deve essere possibile l’accesso trasparente a tutto il “file system” anche in caso di indisponibilità di un nodo o di altri elementi dell’infrastruttura;
- I “metadati” usati dal “sistema” devono essere ridondati per tollerare indisponibilità dei componenti dell’infrastruttura come ad esempio dischi o nodi senza perdita di dati;
- Eventuali guasti sui dischi debbono essere immediatamente presi in carico dal “sistema” per il ripristino della protezione;
- Il guasto di un qualsiasi disco non deve impattare la disponibilità dei dati, tantomeno rendere non validi porzioni di dato che erano presenti sul disco guasto;
- Deve essere possibile l’aggiornamento a caldo di “major” e “minor” “release” di tutto il “software”
della soluzione proposta dal fornitore (“software” per la gestione del “HCI”, “software” per la virtualizzazione dell’ “hardware”) attraverso una o più interfacce “web based”;
- Deve essere presente un meccanismo di “call-home” al fine di garantire la manutenzione proattiva e ridurre i tempi di risoluzione di eventuali problemi;
- Il totale dello spazio disco netto della soluzione deve essere almeno di “60 TB” senza l’attivazione di funzionalità quali compressione e/o deduplica ed anche considerando il “fault” di un singolo
“nodo”.
3.2 Caratteristiche dei nodi dell’infrastruttura "iperconvergente"
Di seguito, si riportano le caratteristiche tecniche dei “nodi” costituenti l’infrastruttura
“iperconvergente”.
- Ogni nodo deve essere di tipo “Rack Mount”;
- Il nodo deve avere 2 “CPU” con tecnologia del processore che garantisca “performance”
pubblicate in termini di “SPECrate2017_int_base” pari ad almeno 160;
- Il nodo deve avere 2 “CPU” con una frequenza di almeno 2.70 GHz e un numero di “core”
pari o superiore a 12 (24 core totali);
- Il nodo deve avere 384 “GB RAM DDR4” con moduli almeno da 2900 MHz;
- Il nodo deve avere 4 “SSD” ciascuno con capacità di almeno 1,9 “TBraw”;
- Il nodo deve avere 20 “HDDa” 10.000 “rpm” ciascuno con capacità di almeno 2,0
“TBraw”;
- Il nodo deve avere 4 “NIC Dual Port Port 10GbE SFP+” (per un totale di 8 “ GbE”
comprensive di “transceive”r fibra);
- Il nodo deve avere 1 Scheda Video “Nvidia M10” o superiore;
- Il nodo deve avere una porta di “management Ethernet out-of-the-band” per l’accesso alla
“remotevirtualconsole” anche a macchina spenta;
- Il nodo deve essere basato su “Hardware x86” standard;
- Gli alimentatori e le ventole del nodo devono essere ridondati.
4. Licenze di sistema operativo
L’Impresa dovrà provvedere alla fornitura in opera di tutte le licenze di Sistema Operativo “Windows Server 2016” necessarie per tutti i “server virtuali” che dovranno essere implementati per l’aggiornamento tecnologico del sistema di videosorveglianza della Questura.
5. Licenze di "software" di "backup" delle macchine virtuali
L’Impresa dovrà provvedere alla fornitura in opera di una soluzione “software” che consenta di proteggere le “macchine virtuali” ospitate sull’infrastruttura “iperconvergente”, di cui al precedente punto 3, effettuando il “backup” a caldo delle stesse all’interno del sistema di “storage”, di cui al successivo punto 6, con approvvigionamento di licenze per un “software” di “backup” per almeno nr.
20 “Virtual Machine”.
Di seguito, vengono riportate le caratteristiche principali del “software” richiesto:
- Modalità di “backup erestoreagentless”: la soluzione dev’essere in grado di effettuare tutte le operazioni necessarie alla creazione di copie di ”backup” ed al ripristino dei dati delle
“macchine virtuali” di produzione senza utilizzare alcun agente “software” persistente all’interno dei sistemi protetti.
- Funzionalità di “backup” e “restore” per condivisioni di rete (“NAS Share”): il prodotto deve poter effettuare “backup” e ripristino, su “repository” a disco, di file/cartelle da condivisioni di rete (“NAS Share”) di tipo “SMB/CIFS” ed “NFS”. Il funzionamento non deve prevedere l’utilizzo del protocollo “NDMP” e il prodotto deve offrire la possibilità di configurare, da un’unica politica di “backup”, una seconda copia dei dati verso un’altra destinazione. Dev’essere, inoltre, possibile specificare, sempre da un’unica politica di
“backup”, modalità e tempistiche di conservazione diverse per “retention” di tipo “short- term” e “long-term”. Il “backup” di “NAS Share” deve poter utilizzare “object storage” come
“repository” di “backup”, almeno per la “long-term” “retention”.
- Ripristino “istantaneo” con conversione in “macchina virtuale”: la soluzione deve poter pubblicare come “macchine virtuali” in modalità pseudo-istantanea (nell’ordine di alcuni minuti), uno o più “backup” di sistemi fisici o virtuali. Il prodotto deve eseguire in automatico la conversione del formato e la pubblicazione della “VM” nell’ambiente virtuale di destinazione, consentendo all’utente di personalizzare i parametri (ad es. la rete virtuale /
“switch” virtuale a cui collegare le “VM” pubblicate).
- Ripristino “istantaneo” granulare “agentless” a livello file/cartelle: la soluzione deve assicurare la possibilità, a fronte di un unico “backup” a livello immagine eseguito senza l’uso di agenti “software” persistenti all’interno delle “macchine virtuali”, di esplorare il “file system” in modalità pseudo-istantanea (nell’ordine di alcuni minuti) per recuperare “file” e/o cartelle, sia sul sistema originale che su destinazioni diverse.
- Ripristino “istantaneo” granulare “agentless” di singoli oggetti applicativi: la soluzione deve assicurare la possibilità di ripristinare in modalità pseudo-istantanea (nell’ordine di alcuni minuti) singoli oggetti applicativi (“database” / tabelle “SQL”, utenti “Active Directory”, messaggi e contatti “Exchange”, contenuti “Sharepoint”, database “Oracle”, etc.) da un unico
“backup” effettuato a livello immagine (“snapshot hypervisor”), senza l’uso di agenti persistenti né di strumenti “software” specialistici di terze parti.
- Gestione integrata ed unificata del “backup” di “macchine virtuali”, “fisiche” e “share NAS”: la soluzione deve poter integrare, in un’unica interfaccia di gestione, la possibilità di configurare ed eseguire le attività di “data protection” relative alle “macchine virtuali”, a quelle
“fisiche” (sia server che “clien”t, sia “Window”s che “Linux”) ed alle “share NAS”
(“SMB/CIFS/NFS”).
- Ripristino “delegato” per “VM”, “file”/cartelle, elementi applicativi: la soluzione deve consentire la definizione di ruoli, basati su utenti/gruppi locali o integrati in “Active Directory”, per eseguire il ripristino in autonomia di intere “VM”, “file”/cartelle e/o elementi applicativi (“Microsoft Exchange”, “SQL Server”, “Oracle”) tramite portale “web”. A ciascun utente o gruppo si può assegnare un perimetro (“scope”) di ripristino in termini di:
o “Macchine virtuali” o “contenitori” logici / fisici (cartelle,” host”, “cluster”, “data store”, “tag”…);
o Tipi di file (estensioni);
o File/cartelle: possibilità di ripristino esclusivamente nella posizione originale (non in locale o su altra destinazione);
o Elementi applicativi: possibilità di impedire il ripristino su posizione originale (per evitare sovrascritture involontarie).
• Integrazione nativa con “File System” di ultima generazione: il prodotto deve poter utilizzare, come destinazione di “backup” (“media”/“repository”), “file system” di tipo
“ReFS” (“Microsoft Windows”) e “XFS” (“Linux”) sfruttando nativamente le ottimizzazioni offerte da tali “file system” in termini di risparmio spazio disco e prestazioni (“Block cloning”
per “ReFS”, “RefLink” per “XFS”)
- Compressione e deduplicazione dei dati: la soluzione deve fornire tecnologie di compressione e deduplicazione dei dati, per ridurre lo spazio utilizzato su disco dai “backup”
e per ottimizzare il traffico di rete durante il trasferimento dati su collegamenti anche geografici o comunque ad alta latenza/basse prestazioni. La deduplicazione dev’essere eseguita a livello di blocco, in modalità “inline” (così come la compressione), ovvero direttamente durante le operazioni di “backup”/replica e non successivamente in un secondo tempo.
- Ripristino in ambiente virtuale con conversione del formato / ripristino “P2V” o
“V2V”: la piattaforma “software” deve offrire la possibilità di ripristinare come “macchine (o dischi) virtuali”, per almeno due “hypervisor”, qualsiasi “backup” di “macchine virtuali o fisiche” effettuato in precedenza.
- Raggruppamento e gestione intelligente degli spazi di archiviazione: la soluzione deve offrire la possibilità di gestire in modo unificato diversi spazi di archiviazione su disco per i
“backup” (“repository”), creando dei pool in logica “scale-out” all’interno dei quali si possano aggiungere/rimuovere dinamicamente “spazi storage” senza dover riconfigurare i processi e le politiche di “backup”. Dev’essere possibile creare un numero a piacere di spazi logici, contenenti un numero a piacere di spazi disco, in base alle esigenze.
- Architettura scalabile e distribuita: la soluzione deve prevedere la possibilità di utilizzare un qualsiasi numero di “sistemi aggiuntivi (macchine virtuali o fisiche”) ai fini delle operazioni di
“backup” e/o di “replica” dei “sistemi protetti”. Tali sistemi aggiuntivi devono essere gestiti
centralmente dalla console di amministrazione del prodotto, da dove dev’essere anche possibile definire/eliminare sistemi aggiuntivi (installando/rimuovendo componenti software in automatico).
- Monitoraggio e reportistica integrati nella soluzione: il “software” dovrà offrire nativamente funzionalità di monitoraggio, reportistica e “capacity planning”, riguardanti l’infrastruttura di “backup”, lo stato di protezione dei sistemi, “audit” delle attività di ripristino, con evidenza e segnalazione in tempo reale di eventuali allarmi o anomalie.
6. Sistema di "storage"
I flussi video generati delle telecamere dell’Impianto di videosorveglianza cittadina devono essere memorizzati all’interno della memoria dell’infrastruttura “iperconvergente”, fino al raggiungimento della capacità di quest’ultima, prevedendo lo spostamento automatico dei “file” più vecchi su uno
“storage” esterno che dovrà essere fornito in opera dall’Impresa.
Il “sistema di storage” dovrà essere collegato in fibra ottica agli “switch ToR”, di cui al successivo punto 7, 7.1, e dovrà poter esporre lo spazio disco tramite i protocolli richiesti in tabella alla velocità di almeno 10 “Gbit/s”.
Pertanto, l’Impresa dovrà garantire un’architettura di tipo “Scale-out distributed file system”, basata su nodi paritetici aggregati virtualmente, che includono potenza elaborativa, capacità disco e connettività
Tutte le caratteristiche richieste devono essere ottenute attraverso l’utilizzo di un singolo “sistema fisico”.
Di seguito, i requisiti minimi che devono essere soddisfatti dal sistema di “storage” fornito:
CARATTERISTICHE
MINIME VALORERICHIESTO
Classe di storage Enterprise Scale-Out Storage Montaggio Rack
Il sottosistema deve essere offerto completo degli accessori necessari al montaggio dell’intero sistema su armadi rack 19”.
Forniti con doppia alimentazione erogata da PDU a 16/32A.
Ridondanza
componenti hardware
Controller di gestione, controller di connettività, alimentazione, sistema di raffreddamento
Tipologia interfacce
richieste Ethernet 1/10 Gbit/s Numero
nodi/controller di gestione
Almeno 4 nodi/controller attivi
CARATTERISTICHE
MINIME VALORERICHIESTO
Numero interfacce richieste
Almeno 2 Porte 10GbE SFP+ (dotate di transceiver) per ciascun controller di gestione
Protocolli storage
supportati NFS, CIFS/SMB v1/v2/v3, HTTP e FTP
Continuità di servizio, affidabilità
Il sistema deve prevedere la completa ridondanza dei componenti vitali in modo da garantire l’accesso ai dati e la loro integrità anche in caso di guasto di un elemento. Lo storage deve disporre di soluzioni di mantenimento della cache e della non-volatile area storage in modo da garantire l’integrità dei dati in caso di interruzione dell’alimentazione elettrica.
Servizio di caching e/o accelerazione accesso ai dati
Deve essere disponibile la possibilità di utilizzare la funzionalità di caching e/o di accelerazione dell'accesso ai dati tramite cache dedicata su banchi di memoria o dischi SSD o altra tecnologia ad alta velocità di accesso.
Cache Il sistema dispone di almeno 64 GB di cache per controller
Sicurezza Il sistema deve poter supportare all’occorrenza dispositivi che nativamente consentano la crittografia dei dati a livello di firmware Espandibilità minima
dello spazio disco RAW
Il sistema deve consentire tramite un unico pannello di gestione di controllare il sistema e tutte le espansioni che si rendessero necessarie in futuro
Tipo di dischi supportati:
Il sistema deve supportare le seguenti tipologie: SSD, SAS, NL-SAS o in alternativa SATA
Resistenza alla rottura dei dischi
Il sistema deve adottare una tecnologia tale da garantire l'operatività del sistema, la correttezza dei dati archiviati e la loro sicurezza anche in caso di rottura di 2 dischi per ciascun raid-group.
o in alternativa meccanismi di erasure coding che consentano di supportare almeno il fault contemporaneo di 2 dischi all’interno del sistema o di un intero controller.
Inoltre il sistema deve adottare tecniche e/o tecnologie che consentano il ripristino del sistema e dei dati anche in caso di malfunzionamenti dei/del backplane.
RAID
Il sistema deve realizzare il livello RAID attraverso dispositivo hardware e deve supportare almeno 4 dei seguenti 0, 1, 3, 5, 6, 10, e 50 , o in alternativa il sistema deve offrire la protezione del dato tramite meccanismi di erasure coding, che consentano di sopportare almeno il fault contemporaneo di 2 dischi o di un intero controller.
Capacità Storage
minima richiesta 110 TB
CARATTERISTICHE
MINIME VALORERICHIESTO
(calcolato in
configurazione RAID 6 o erasure-coding) Configurazione dischi offerti
>= 10% SSD
Il restante tra SAS ed NLSAS o SATA 7. Componenti di rete
L’Impresa dovrà provvedere alla fornitura di opera delle seguenti componenti di “networking” ai fini dell’inserimento del nuovo catalogo multimediale all’interno della rete della Questura di Roma.
7.1 Full Proxy
L’Impresa dovrà provvedere alla fornitura in opera di una “appliance” denominata “Full Proxy”, il cui obiettivo principale è disaccoppiare la rete interna (“trusted”) del catalogo multimediale dalle reti esterne (non-“trusted”), dalle quali vengono ricevuti flussi multimediali generati sia dalle telecamere di videosorveglianza e di lettura targhe installate dell’Amministrazione, sia dai sistemi di videosorveglianza di altri enti.
Tale “appliance”, con particolare riferimento ai protocolli “RTSP” e “http/HTTPS”, dovrà supportare nativamentele seguenti funzionalità:
1) “parsing” del protocollo “RTSP”;
2) capacità di differenziare la comunicazione lato “client” da quella lato “server”, applicando profili di ottimizzazione differenti e consentendo di migliorare le prestazioni nei flussi di traffico;
3) capacità di ottimizzazione del traffico “RTSP Over SSL” mediante accelerazione
“hardware” dedicata e profili di sicurezza dedicati;
4) capacità di terminazione “SSL” lato “client”, lato “server”, e “dual mode”;
5) funzionalità nativa “Proxy RTSP” basata su moduli nativi specifici con gestione di configurazioni aggiuntive e di ottimizzazioni e sicurezza;
6) il modulo “RTSP proxy” deve far sì che il dispositivo operi come “Full Proxy”, vale a dire mantenere le comunicazioni in modo trasparente od applicando politiche di “SourceNAT
“ personalizzate per mascherare gli “IP” dei” client” verso reti non “trusted”;
7) il modulo “RTSP proxy” deve consentire delle customizzazioni nei flussi di traffico fra cui:
o definire come protezione di sicurezza l’ampiezza massima degli “Header” e del
“buffer” dati;
o abilitare o negare il “redirect” verso un differente indirizzo di destinazione per traffico “Unicast” e “Multicast”;
o controllare gli “Header RTSP” e la comunicazione dei flussi tramite apposite funzioni o comandi del modulo.
8) Per il modulo “RSTP proxy” sono richiesti i seguenti requisiti minimi di configurabilità:
a) settaggi specifici tramite “interfaccia grafica”;
b) “idleTimeout RTSP” per la gestione delle sessioni sospese;
c) “Maximum Header Size” per la gestione in sicurezza degli “header” di comunicazione “RTSP”;
d) “Maximum Queued Data” per il controllo della bontà dello “streaming” basato sul
“timing buffer”;
e) “Session Reconnect” ovvero capacità autonome di gestire e controllare le sessioni disconnesse ed operare la riconnessione o “resuming”, garantendo la persistenza verso i “server” (evitando “redirect”);
f) possibilità di configurare i parametri di “real http Persistence”.
9) Funzionalità attiva “proxy”:
a) determinare “source address” dal campo “transportheader”,
b) creare dinamicamente “listner RTP/RTCP” usando l’indirizzo determinato dal campo “transportheader”;
c) riscrivere il campo “transportheader source” con l’indirizzo del “virtual server” e inviarlo a destinazione;
d) “Tunneling” per “Real Networks” di “RTSP” su “http”, attraverso la porta “RTSP”
(554).
L’”appliance” dovrà avere almeno le seguenti caratteristiche:
- Richieste per secondo “(RPS) OSI L7 = 1 M”;
- Connessioni per secondo “(CPS) OSI L4 =500K”;
- Richieste per secondo “(RPS) OSI L4 http = 6M”;
- L4 “Max concurrent connections = 40M”;
- L4 “Throughput = 60 Gbps”;
- L7 “Throughput = 35 Gbps”;
- “SSL Bulk Encryption throughput = 15 Gbps”;
