Beknopte beschrijving horend bij vooraankondiging Algemene offerteaanvraag voor aanneming van werken: Aankoopcentrale vast ANPR netwerk Dit document heeft tot doel de kandidaten te informeren over de aard en de inhoud van de opdracht. De beknopte beschrijving maakt geen onderdeel uit van de opdrachtdocumenten van de aankoopcentrale. Voor het indienen van een offerte voor de later te publiceren algemene offerteaanvraag kan geenszins beroep worden gedaan op de modaliteiten die zijn opgenomen in deze beknopte beschrijving.
Pagina 1 van 64
INHOUDSTAFEL I. ADMINISTRATIEVE EN CONTRACTUELE VOORSCHRIFTEN ............................ 5 1.
ALGEMEENHEDEN ..................................................................................................... 5
1.1 1.2 1.3
Voorwerp van de opdracht........................................................................................................................ 5 Omvang van de opdracht .......................................................................................................................... 6 Bijzondere uitvoeringsmodaliteiten.......................................................................................................... 7 1.3.1 Modelgoedkeuring................................................................................................................. 7 1.3.2 Inkoppeling van data van reeds operationele ANPRs............................................................ 8
2.
BESCHRIJVING VAN DE OPDRACHT .................................................................... 8
2.1
Beschrijving ................................................................................................................................................ 8 2.1.1 Basissysteem.......................................................................................................................... 9 2.1.2 Uitbreiding........................................................................................................................... 10 2.1.3 Algemene technische bepalingen Front-Installation............................................................ 11 2.1.3.1 Kenmerken van de materialen ............................................................................................. 11 2.1.3.2 Kenmerken van de uitvoering.............................................................................................. 12 2.1.4 Front-Installation Standard .................................................................................................. 13 2.1.4.1 Beschrijving......................................................................................................................... 13 2.1.4.2 Kenmerken van de materialen ............................................................................................. 14 2.1.4.2.A ANPR captatie systeem ....................................................................................................... 14 2.1.4.2.B Lokale verwerkingseenheid (LPU)...................................................................................... 17 2.1.4.2.C Communicatiemodule naar Back-Office ............................................................................. 18 2.1.4.2.D Kast...................................................................................................................................... 20 2.1.4.2.E Paal ...................................................................................................................................... 23 2.1.4.2.F Bewakingscamera ................................................................................................................ 24 2.1.4.3 Kenmerken van de uitvoering.............................................................................................. 25 2.1.4.3.A ANPR captatie systeem ....................................................................................................... 25 2.1.4.3.B Lokale verwerkingseenheid (LPU)...................................................................................... 26 2.1.4.3.C Communicatiemodule naar Back-Office ............................................................................. 26 2.1.4.3.D Kast...................................................................................................................................... 28 2.1.4.3.E Paal ...................................................................................................................................... 29 2.1.4.3.F Bewakingscamera ................................................................................................................ 30 2.1.5 Controles.............................................................................................................................. 30 2.1.5.1 Dataprotocol ........................................................................................................................ 30 2.1.5.2 Communicatie Back-Office ................................................................................................. 30 2.1.5.3 Kast...................................................................................................................................... 31 2.1.5.4 Meetresultaten ..................................................................................................................... 31 Front-Installation Additions.................................................................................................................... 31 2.2.1 Detectie van vrachtwagenverkeer ........................................................................................ 31 2.2.1.1 Beschrijving......................................................................................................................... 31 2.2.1.2 Kenmerken van de materialen ............................................................................................. 31 2.2.2 Trajectcontrole – Hardware ................................................................................................. 32 2.2.2.1 Beschrijving......................................................................................................................... 32 2.2.2.2 Kenmerken van de materialen ............................................................................................. 32 2.2.2.3 Kenmerken van de uitvoering.............................................................................................. 32 2.2.3 HD bewakingscamera.......................................................................................................... 32 2.2.3.1 Kenmerken van de materialen ............................................................................................. 32 2.2.3.2 Kenmerken van de uitvoering.............................................................................................. 34 Back-Office ............................................................................................................................................... 34 2.3.1 Back-Office Standard .......................................................................................................... 34 2.3.1.1 Beschrijving......................................................................................................................... 34 2.3.1.2 Kenmerken van de materialen ............................................................................................. 35 2.3.1.2.A Dataserver............................................................................................................................ 35 2.3.1.2.B Basis Applicatieserver ......................................................................................................... 35 2.3.1.2.C Bewaking- en monitoringssoftware ..................................................................................... 35
2.2
2.3
Pagina 2 van 64
2.4
2.5
2.6
2.3.1.2.D Beheersoftware .................................................................................................................... 36 2.3.1.2.E Bewaking- en monitoringssoftware, en beheersoftware opdrachtnemer ............................. 38 2.3.1.2.F Kalendersturing ................................................................................................................... 39 2.3.1.2.G Gebruikers- en rechtenbeheer .............................................................................................. 39 2.3.1.2.H Push – Pull service PDA/Smartphone ................................................................................. 41 2.3.1.2.I Aanpassing nummerplaatregistratie..................................................................................... 42 2.3.1.2.J Gedeelde VAST ANPR netwerk ......................................................................................... 42 2.3.1.3 Kenmerken van de uitvoering.............................................................................................. 45 2.3.2 Back-Office Additions......................................................................................................... 47 2.3.2.1 Beschrijving......................................................................................................................... 47 2.3.2.1.A Verkeershandhaving ............................................................................................................ 48 2.3.2.1.B Verkeerskundemodules........................................................................................................ 48 2.3.2.1.C Offline data analyse modules............................................................................................... 48 2.3.2.1.D Listings ................................................................................................................................ 49 2.3.2.2 Kenmerken van de uitvoering.............................................................................................. 51 2.3.2.2.A Verkeershandhaving-Module Inhaalverbod (over een traject) ............................................ 51 2.3.2.2.B Verkeershandhaving-Module trajectcontrole....................................................................... 54 2.3.2.2.C Verkeershandhaving-Module sluikverkeer/Vrachtwagensluis ............................................ 57 2.3.2.2.D Verkeershandhaving-Module toegangscontrole .................................................................. 59 2.3.2.2.E Verkeerskunde-Module Versleuteling gegevens ................................................................. 62 2.3.2.2.F Verkeerskunde-Module reistijden........................................................................................ 63 2.3.2.2.G Verkeerskunde-Module tellingen ........................................................................................ 65 2.3.2.2.H Verkeerskunde-Module herkomst/bestemming ................................................................... 66 2.3.2.2.I Verkeerskunde-Module GIS (STANDAARD).................................................................... 68 2.3.2.2.J Offline data analyse-Module Queries (STANDAARD) ...................................................... 69 2.3.2.2.K Offline Data analyse-Module kleuranalyse ......................................................................... 71 2.3.2.2.L Offline Data analyse-Module DIV bevraging (STANDAARD) ......................................... 72 2.3.2.2.M Offline data analyse-Module politionele beeldvorming ...................................................... 72 2.3.2.2.N Offline Data analyse-Module nazicht Camerabewaking ..................................................... 73 2.3.2.2.O Offline data analyse-Module GIS (STANDAARD) ............................................................ 74 2.3.2.2.P Listing module-White List................................................................................................... 75 2.3.2.2.Q Listing module-Black List (STANDAARD) ....................................................................... 76 2.3.2.2.R Listing module-Patronen ..................................................................................................... 77 Bijkomende ontwikkelingen .................................................................................................................... 79 2.4.1 Verwerking PV’s via gewestelijk verwerkingscentrum, 3de partij....................................... 79 2.4.1.1 Beschrijving......................................................................................................................... 79 2.4.1.2 Kenmerken van de uitvoering.............................................................................................. 79 2.4.2 Beheer van verschillende Back-Offices vanuit een centraal systeem .................................. 79 2.4.2.1 Beschrijving......................................................................................................................... 79 2.4.2.2 Kenmerken van de uitvoering.............................................................................................. 80 2.4.3 Ontwikkeling procotol van een extra type ANPR camera ................................................... 80 2.4.3.1 Beschrijving......................................................................................................................... 80 2.4.4 Ontwikkeling protocol externe list van 3de partijen ............................................................. 81 2.4.4.1 Beschrijving......................................................................................................................... 81 2.4.5 Ontwikkeling van extra software......................................................................................... 81 2.4.5.1 Beschrijving......................................................................................................................... 81 2.4.5.2 Kenmerken van de uitvoering.............................................................................................. 81 Datacommunicatie.................................................................................................................................... 82 2.5.1 Koppeling Front-installation – Back-Office en Back-Office naar Back-Office .................. 82 2.5.2 Datastructuur versleutelde gegevens ................................................................................... 82 2.5.2.1 Kenmerken van de uitvoering.............................................................................................. 82 2.5.2.1.A Datastructuur Vlaams Verkeerscentrum .............................................................................. 82 Full omnium onderhoud na waarborgperiode....................................................................................... 86 2.6.1 Beschrijving......................................................................................................................... 86 2.6.1.1 Kenmerken van de materialen ............................................................................................. 87 2.6.1.1.A Incident management........................................................................................................... 87 2.6.1.1.B Problem management .......................................................................................................... 87 2.6.1.1.C Change management............................................................................................................ 87 2.6.1.2 Kenmerken van de uitvoering.............................................................................................. 88 2.6.1.2.A Incident management........................................................................................................... 88
Pagina 3 van 64
2.6.1.2.B 2.6.1.2.C
Pagina 4 van 64
Problem management .......................................................................................................... 90 Change management............................................................................................................ 92
I. ADMINISTRATIEVE EN CONTRACTUELE VOORSCHRIFTEN 1.
ALGEMEENHEDEN
1.1 Voorwerp van de opdracht De aankoopcentrale heeft als voorwerp de levering, plaatsing en het onderhouden van vaste automatische nummer plaat herkenningscamera’s, inclusief de beheers- en gebruikssoftware. De aanbestedende overheid beoogt met dit contract een gelijkvormigheid in vaste ANPR netwerken ten voordele van de bestellende overheden en de weggebruiker. Het onderliggend wegennet wordt éénvormig uitgerust met ANPR camera’s, CCTV camera’s, lussen,… Als objectief stelt de aanbestedende overheid op dat zij met deze aankoopcentrale een standaard instelt betreft vaste ANPR netwerken én dat zij voor overheden het aanspreekpunt wordt betreffende deze materie. De opbouw van een vast ANPR netwerk wordt opgedeeld in twee delen, het basissysteem en de uitbreidingen. Het basissysteem is de minimale hardware en software die bij het bestellen van een nieuwe installatie zullen geplaatst worden. De uitbreidingen zijn modules die aan het basissysteem worden toegevoegd om extra functionaliteit te creëren. De gehele opbouw van soft- en hardware wordt opgedeeld in twee verschillende delen, die op hun beurt opgedeeld worden in twee delen. Alle soft- en hardware die buiten staat wordt omvat onder de noemer Front-Installation. Alle soft- en hardware die binnen staat onder Back-Office. Deze twee delen zijn opgebouwd in een deel basissysteem (Standaard) en uitbreidingen (Additions). - Het basissysteem wordt onderverdeeld in twee delen, waar de data verzameld wordt en, waar de beschikbare data verwerkt wordt: o
Front-Installation Standard;
o
Back-Office Standard; De Back-Office Standard kan in de basisvorm data ontvangen, data verwerken, bewaren, data beschikbaar stellen voor de uitbreidingsmodules, gebruikers beheren en rechten toekennen, en bevat de basis van een bewaking en monitoringsysteem. Standaard zal een gebruikerszone één Back-Office Standard bezitten waar verschillende Front-Installation Standard gegevens naar verzenden. Beide basissystemen kunnen afzonderlijk besteld worden.
- Uitbreiding Gelijkaardig als onder het basissysteem kunnen de uitbreidingen onderverdeeld worden in twee hoofdcategorieën met telkens hun subcategorie: o
Front-Installation Additions;
o
Back-Office Additions.
Pagina 5 van 64
1.2 Omvang van de opdracht De omvang van de opdracht bestaat uit de volgende deelopdrachten die de bestellende overheden kunnen plaatsen: - De deelopdracht “Leveringen en werken” Het onderhoud tijdens de waarborgperiode maakt deel uit van deze deelopdracht en wordt niet afzonderlijk vergoed. Dit onderhoud vangt aan op de datum van de voorlopige oplevering van de betrokken bestelopdracht en eindigt op datum van de definitieve oplevering. Het onderhoud tijdens de waarborgperiode geschiedt overeenkomstig de voorschriften van de deelopdracht “Full omnium onderhoud na waarborgperiode”. - De deelopdracht “Full Omnium onderhoud na waarborgperiode” Deze opdracht vangt aan op de datum van de definitieve oplevering van iedere bestelopdracht. Ter bevestiging ervan wordt een afzonderlijke bestelbrief afgeleverd door de bestellende overheid.
1.3 Bijzondere uitvoeringsmodaliteiten 1.3.1
Modelgoedkeuring
Het hebben van een Belgische modelgoedkeuring conform KB 25.10.2010 voor de in dit contract beoogde trajectcontroletoepassing is een selectiecriterium. Deze modelgoedkeuring dient te worden toegevoegd aan de inschrijving of uiterlijk uitgereikt te zijn op datum van gunning. Gelet op het KB van 25.10.2010 kunnen enkel toestellen die beschikken over een modelgoedkeuring, uitgereikt door FOD Economie, K.M.O., Middenstand & Energie, gebruikt worden om onbemand snelheidsovertredingen vast te stellen. Deze modelgoedkeuring dient samen met de detectie en/of snelheidsbepalingsoftware behaald te worden. Bij elke wijziging van de apparatuur, waardoor de certificatie komt te vervallen, moet deze certificatie opnieuw worden uitgevoerd. De kosten voor het verkrijgen van een Belgische modelgoedkeuring zijn een last van de aanneming. De eventuele kosten voor het up-to-date houden van de modelgoedkeuring zodat de geïnstalleerde systemen ten allen tijde gebruikt kunnen blijven worden, zijn een last van de aanneming. Het behalen van een nieuwe modelgoedkeuring in gevolge een foutieve of onvolledige uitvoering van de geïnstalleerde installatie door de opdrachtnemer, is ten laste van de opdrachtnemer. Alle kosten voor certificatie zijn inbegrepen in de posten van de desbetreffende apparatuur en worden niet afzonderlijk vergoed. De software van het systeem voor gegevensverwerking wordt modulair opgebouwd met aparte versienummers en benaming voor elk deel software, zodanig dat de delen van de software die instaan voor de detectie en/of bepaling van de snelheid van de voertuigen en het effectief vastleggen van een overtreding, onafhankelijk zijn van de overige stukken software in deze opdracht. De opbouw moet de aanbestedende overheid en de opdrachtnemer toelaten aanpassingen aan te brengen aan alle andere modules, die zullen worden gevraagd in deze opdracht, zonder dat dit aanpassingen vereist van de detectie en/of snelheidsbepalingsoftware en dus geen invloed heeft op reeds behaalde certificaten en modelgoedkeuring.
1.3.2
Inkoppeling van data van reeds operationele ANPRs
Zowel in het basissysteem als bij de mogelijke uitbreidingen moet het mogelijk zijn data afkomsting van reeds eerder geïmplementeerde ANPR netwerken te kunnen koppelen en te verwerken.
Pagina 6 van 64
2.
BESCHRIJVING VAN DE OPDRACHT
2.1 Beschrijving Het concept van de ANPR bewaking wordt opgedeeld in twee delen, het basissysteem en de uitbreidingen. Het basissysteem is de minimale hardware en software die bij het bestellen van een nieuwe installatie zullen geplaatst worden. De uitbreidingen zijn modules die aan het basissysteem worden toegevoegd om extra functionaliteit te creëren. Twee voorbeelden van zo een uitbreiding kunnen zijn: - extra sensoren voor het bepalen van vrachtwagenverkeer; - de softwaremodule voor het uitvoeren van nummerplaatopzoekingen. De opdracht omvat onder andere de nodige prestaties voor: -
het bedrijfsklaar leveren van een nummerplaat herkenningssysteem en de nodige kabels om deze aan te sluiten;
-
het opstellen van een nummerplaat herkenningssysteem op het straatmeubilair en het uitvoeren van het kabelwerk;
-
indien nodig, het opstellen van een extra steun voor ophanging van het nummerplaat herkenningssysteem;
-
het leveren, opstellen en bedrijfsklaar aansluiten van een paalkast, inclusief het nodige kabelwerk;
-
het leveren, opstellen en bedrijfsklaar maken van een lokale controller voor het beheren van de data;
-
het opzetten van een communicatiepad tussen de buitenapparatuur en binnenapparatuur inclusief communicatiemodule en bekabeling;
-
het leveren, ontwikkelen en installeren van de nodige soft- en hardware voor beheren van sites, het opvragen en verwerking van de gegevens, het beheer van het systeem,…;
-
het leveren, opstellen en bedrijfsklaar aansluiten van uitbreidingen;
-
het ontwikkelen van extra software voor de specifieke verwerking van de beschikbare gegevens.
De gehele opbouw van soft- en hardware wordt opgedeeld in twee verschillende delen, die op hun beurt opgedeeld worden in twee delen. Alle soft- en hardware die buiten staat wordt omvat onder de noemer Front-Installation. Alle soft- en hardware die binnen staat onder Back-Office. Deze twee delen zijn opgebouwd in een deel basissysteem (standaard) en uitbreidingen (Additions). Bij de bestelling van een Back Office zijn er vijf (uitbreiding) modules inbegrepen: de module Queries, Black List, DIV bevraging en de ontwikkeling van de GIS interfaces. Voor deze modules zijn dan ook geen afzonderlijke posten voorzien.
2.1.1
Basissysteem
Het basissysteem wordt onderverdeeld in twee delen, waar de data verzameld wordt en, waar de beschikbare data verwerkt wordt. - Front-Installation Standard, met als onderdelen -
ANPR captatie systeem;
-
lokale verwerkingseenheid (LPU – Local Processing Unit);
-
communicatiemodule naar Back-Office;
-
kast;
-
bewakingscamera.
Pagina 7 van 64
- Back-Office Standard, met als onderdelen -
dataserver;
-
basis applicatieserver.
De Back-Office Standard kan in de basisvorm data ontvangen, data verwerken, data bewaren, data beschikbaar stellen voor uitbreidingsmodules, gebruikers beheren en rechten toekennen, en bevat een bewaking en monitoringsysteem waarbij de bewaking van de Front-Installation en de Back-Office volledig is uitgewerkt. Standaard zal een gebruikerszone één Back-Office Standard bezitten waar verschillende FrontInstallation Standards gegevens naar verzenden. Beide basissystemen kunnen afzonderlijk besteld worden.
2.1.2
Uitbreiding
Gelijkaardig als onder het basissysteem kunnen de uitbreidingen onderverdeeld worden in twee hoofdcategorieën met telkens hun subcategorie. - Front-Installation Additions met als onderdelen: - detectie van vrachtwagenverkeer; - uitrusting trajectcontrole; - HD bewakingscamera/ - Back-Office Additions: -
verkeershandhaving
-
- module inhaalverbod (over een traject); - module trajectcontrole; - module sluikverkeer/vrachtwagensluis; - module toegangscontrole. verkeerskundig
-
- module versleutelde gegevens; - module reistijden; - module tellingen/bezetting; - module herkomst/bestemming; - module GIS verkeerskundig. offline data-analyse
-
- module queries; - module kleuranalyse; - module DIV bevraging; - module politionele beeldvorming; - module nazicht camerabewaking; - module GIS horende bij offline data-analyse. listing
- module white list; - module black list; - module patronen. Enkele Back-Office Additions kunnen gerealiseerd worden met een basisopstelling Front-Installation Standard, andere Back-Office Additions hebben een uitbreiding nodig om te kunnen werken. Voor de verschillende modules is er telkens een post voorzien voor de aankoop van de module per
Pagina 8 van 64
Back-Office afzonderlijk. De ontwikkeling van de modules gebeurt in overleg met de aanbestedende overheid en bestellende overheden. De kosten voor de opdrachtnemer voor de ontwikkeling van de modules worden niet afzonderlijk vergoed. Voor de modules “Black list”, “Queries”, “DIV bevraging” en de beide GIS interfaces zijn geen posten voorzien. Deze zijn standaard geïnstalleerd in iedere Back-Office. Voor de andere modules is er per module een post voorzien die per geleverde en geplaatste BackOffice afzonderlijk wordt geteld.
2.1.3
Algemene technische bepalingen Front-Installation
Een Front-Installation, hierna soms genoemd, een buiteninstallatie, dient minimaal aan onderstaande kenmerken te voldoen. 2.1.3.1 Kenmerken van de materialen Voor alle buiteninstallaties dienen minimaal volgende kenmerken in acht genomen worden: - alle buiten opgestelde systemen moeten weerstaan aan de trillingen opgewekt door het voorbij rijdende verkeer; - alle buiten opgestelde systemen moeten ongevoelig zijn aan roestvorming. Extra voorzorgen dienen genomen te worden om roestvorming ten allen tijde te voorkomen; - de constructeur moet de uiterste temperatuurgrenzen opgeven waartussen het gehele systeem kan werken. De verwarming en ventilatie moet zo aangepast zijn dat alle apparatuur binnen zijn temperatuursgrenzen kan werken; - de beschermingsgraad van de behuizing(en) en kabeldoorgangen is minimaal IP 67, vandalismewerend; - het systeem moet ongevoelig zijn voor de typische relatieve vochtigheid van de omgevingslucht in Vlaanderen en dit zowel in de statische voorwaarden van opberging als tijdens het gebruik; - het systeem moet in overeenstemming zijn met het Koninklijk Besluit van 28 februari 2007 met betrekking tot de elektromagnetische compatibiliteit; 2.1.3.2 Kenmerken van de uitvoering Voor alle buiteninstallaties dienen minimaal volgende kenmerken in acht genomen worden: - na een spanningsonderbreking of herstart van het systeem, plaatst het systeem zich automatisch in de laatst gekende werkende toestand inclusief het opzetten van een communicatiepad; - het monteren of demonteren, aansluiten en configureren van alle verschillende functionele onderdelen, al dan niet gecombineerd, kan op eenvoudig en efficiënte wijze gebeuren (modulair). Dit om het onderhoud en herstellingen gemakkelijker te laten verlopen. De nodige verbindingskabels en overige toebehoren maken integraal deel uit van de betreffende posten, tenzij specifiek vermeldt in de samenvattende opmetingsstaat; - bij het plaatsen van een camera (ANPR, bewakingscamera of andere) wordt standaard een picto “bewakingscamera” voorzien (KB 10 februari 2008), het leveren en plaatsen van dit picto maakt integraal deel uit van desbetreffende posten van levering en plaatsing van de camera. Er zijn posten voorzien voor de levering en plaatsing van een extra picto; - de installatie van de alle apparatuur gebeurt steeds door hiervoor opgeleid personeel; - de tijdsynchronisatie van de systemen dient te gebeuren volgens het Network Time Protocol (NTP);
Pagina 9 van 64
- bij de installatie van materiaal boven de rijbaan dient een minimale vrije hoogte van 6 meter aangehouden te worden. Het plaatsen van materiaal lager dan 6 meter gebeurt altijd in samenspraak met de bestellende overheid; - de bevestiging van de apparatuur aan bruggen of tunnelfrontons dient met de grootste omzichtigheid te gebeuren. Met gepaste meetapparatuur wordt de diepte van de bewapening vastgesteld. Het boren van gaten gebeurt vervolgens mits gebruik van een dieptestang en mits goedkeuring van de brugbeheerder. Bij het boren van gaten of het indraaien van bouten of vijzen in de betondekking mag de bewapening niet geraakt worden. Voor het plaatsen van apparatuur op een brug is een afzonderlijke post voorzien. Voor andere locaties is geen afzonderlijke post voorzien. - het vasthechten van apparatuur aan de horizontale balk van een seinbrug gebeurt met behulp van beugels, zonder het boren van gaten in de bestaande constructie, die bereikbaar zijn vanaf het loopvlak van de horizontale balk. De apparatuur kan aan weerszijden van de dwarsliggers gemonteerd worden. - het vasthechten van apparatuur aan bestaande openbare verlichting gebeurt met behulp van beugels, zonder het boren van gaten in de bestaande constructie.
2.1.4
Front-Installation Standard
2.1.4.1 Beschrijving De Front-Installation Standard is de basisopstelling geplaatst op beschikbaar straatmeubilair (verlichtingspaal, bestaande portiek, brug, tunnelfronton,…) of op een nieuwe geleverde steun. De opstelling Figuur 1 Overzicht mogelijke opstelling op een verlichtingspaal bestaat uit een ANPR captatie systeem, bekabeling naar een kast (wegkantkast of paalkast), Lokale Processing Unit (LPU), de nodige elektrische voeding en beveiligingen, en een netwerkmodule die communicatie opzet met de Back-Office. Figuur 1 Overzicht mogelijke opstelling op een verlichtingspaal illustreert dit waarbij gebruik gemaakt wordt van een kabelverbinding voor het netwerk (vb. glasvezel of koper).
Pagina 10 van 64
Figuur 1 Overzicht mogelijke opstelling op een verlichtingspaal 2.1.4.2 Kenmerken van de materialen 2.1.4.2.A 2.1.4.2.A.1
ANPR CAPTATIE SYSTEEM Camera
Het ANPR captatie systeem bestaat uit een ANPR camera die zowel overdag als tijdens de nacht nummerplaten capteren van voertuigen van een rijstrook met bijhorende randapparatuur (bijvoorbeeld een infrarood flits/licht). Indien het ANPR captatie systeem gebruik maakt van een Infrarood flits/licht dan moet zowel de kleur als de intensiteit van het flitslicht worden geoptimaliseerd in functie van de nummerplaten opgesomd in 2.1.4.2.A.3 Data, maar dient dit licht buiten het zichtbaar spectrum te blijven, dit zowel overdag als ’s nachts. Iedere afzonderlijke ANPR camera dient voorzien te zijn van een varifocale lens die een goede uitregeling mogelijk maakt. 2.1.4.2.A.2
Triggering
Het ANPR captatie systeem moet standaard beschikken over een interne trigger (vb. virtuele lussen). 2.1.4.2.A.3
Data
Het ANPR captatie systeem moeten minstens de Belgische, Nederlandse, Franse, Duitse, Britse, Luxemburgse, Poolse en Roemeense nummerplaten kunnen lezen. Upgraden tengevolge van een aanpassing van de wetgeving in verband met de samenstelling van deze nummerplaten moeten mogelijk zijn en zullen niet afzonderlijk worden vergoed. Het toevoegen van andere landtypes dient mogelijk te zijn.
Pagina 11 van 64
Iedere passage van een voertuig moet geregistreerd worden. Voor elke doortocht moet volgende data verzameld worden: tijdsstempel1,2, foto, nummerplaat, nationaliteit, betrouwbaarheidspercentage van elk karakter van de nummerplaat, betrouwbaarheidspercentage van de gehele nummerplaat, betrouwbaarheid van de nationaliteitsbepaling. De resolutie van de foto’s wordt zo gekozen dat de nummerplaatkarakters op de foto’s minimale een hoogte van 15 pixels hebben. 2.1.4.2.A.4
Performantie
Voor het bepalen van de performantie van een ANPR captatie systeem wordt gekeken naar volgende parameters3: -
totaal aantal gepasseerde voertuigen (T);
-
totaal aantal voertuigen waargenomen volgens het ANPR captatiesysteem (W);
-
totaal aantal correct gelezen nummerplaten (P);
-
totaal aantal correct gelezen nationaliteiten (N);
-
totaal aantal platen waar zowel nationaliteit als nummerplaat correct gelezen is (H)
Het ANPR captatie systeem dient continue en in alle weersomstandigheden minimaal 95% van de voertuigen waar te nemen.
WT =
W T
Het ANPR captatie systeem dient continue en in alle weersomstandigheden minimaal 85% van de nummerplaten van de waargenomen voertuigen correct te lezen.
PW =
P W
Het ANPR captatie systeem dient continue en in alle weersomstandigheden minimaal 85% van de nationaliteiten van de waargenomen voertuigen correct te lezen.
NW =
N W
Het ANPR captatie systeem dient continue en in alle weersomstandigheden minimaal 80% van de nummerplaten met bijhorende nationaliteit van de waargenomen voertuigen correct te lezen.
HW =
H W
Onder betrouwbare nummerplaten wordt een betrouwbaarheid van 99.9% verstaan: maximaal 0,1% wordt foutief als “betrouwbaar herkend” aangeduid. Bij de berekening van het herkenningspercentage worden enkel voertuigen uit de opgegeven landenset in rekening gebracht. Voertuigen waarvan de nummerplaat ontbreekt, of waarvan de nummerplaat niet door de mens leesbaar is (bij goede beeldkwaliteit), worden buiten beschouwing gelaten.
1
De tijdsstempel is minimum tot op duizendste van seconden (YYMMDDHHMMSSsss) (CET: GTM+1);
2
De tijdsstempel dient gesynchroniseerd te worden via NTP;
3
Alle parameters worden bekeken op uurbasis;
Pagina 12 van 64
Wanneer twee ANPR captatiesystemen in lijn geplaatst worden en dus dezelfde passanten te verwerken krijgen, dienen de betrouwbare registraties voor 99% overeen te stemmen. 2.1.4.2.A.5
Camerabehuizing
Alle camera’s (ANPR, bewakingscamera en HD bewakingscamera) worden ingebouwd in een weerbestendige en vandalismebestendige behuizing. De behuizing is vervaardigd uit aluminium en heeft een beschermingsgraad IP 65 (BS EN 60529). De behuizing kan gemonteerd worden op alle opgenomen locaties in de opdrachtdocumenten (eventueel door middel van koppelstukken of verschillende behuizingen). 2.1.4.2.B
LOKALE VERWERKINGSEENHEID (LPU)
2.1.4.2.B.1
Registraties
De LPU zorgt voor de verwerking en tijdelijke opslag van de ANPR registraties en de data komende van uitbreidingen. De LPU staat in voor de tijdelijke bewaring van registraties van minimaal 2 aangekoppelde ANPR captatiesystemen, inclusief bijhorende bewakingscamera’s en data van eventueel gekoppelde uitbreidingen. De LPU kan uitgebreid worden tot 4 aangekoppelde ANPR captatie systemen. De LPU moet alle registraties kunnen bewaren over een periode van minimaal 7 dagen. 2.1.4.2.B.2
Communicatieprotocol
De LPU zet een communicatie op met de Back-Office en creëert met een interval van X seconden gecomprimeerde datapakketten van de registraties in het desbetreffende interval en verstuurd deze datapakketten naar de Back-Office. Het tijdsinterval X kan vanuit het Back-Office vrij geprogrammeerd worden voor alle LPU’s afzonderlijk. Het tijdsinterval zal onder andere bepaald worden door de communicatieverbinding tussen de Front-Installation en de Back-Office. Bijvoorbeeld: - bij een glasvezelverbinding kunnen alle registraties als afzonderlijke pakketen verzonden worden zonder tijdsvertraging; - wanneer gebruik gemaakt wordt van een HSUPA draadloze verbinding is het door de beperktere bandbreedte makkelijker om pakketen maar om de paar minuten te versturen. De variabele X kan vanuit Back-Office manueel bepaald worden voor elke camera afzonderlijk of kan via een externe trigger automatisch gewijzigd worden (vb. wanneer een geseind voertuig gedetecteerd is, moeten alle camera’s onmiddellijk alle registraties doorsturen. De trigger komt dan van de BackOffice), X kan dus ook 0 zijn. 2.1.4.2.B.3
Lokaal beheer
De LPU moet de mogelijkheid beschikken om lokaal de gegevens te kunnen downloaden rechtstreeks op een laptop. Dit moet mogelijk zijn zonder het extra installeren van software. Er dient wel een autorisatie proces te zijn. Het lokaal downloaden heeft geen invloed op de normale werking. De datapakketten lokaal gedownload blijven verstuurd worden naar de Back-Office. Het verwijderen van registraties is lokaal niet mogelijk. 2.1.4.2.B.4
Beheer van op afstand
De LPU moet vanop afstand beheersbaar zijn. Updates van software moeten kunnen gebeuren vanuit de Back-Office. De LPU laat toe het gehele systeem (ANPR captatiesysteem, bewakingscamera, andere uitbreidingen) te configureren vanuit de Back-Office.
Pagina 13 van 64
2.1.4.2.B.5
Calamiteiten
Er wordt een noodvoeding voorzien zodat bij het wegvallen van de voeding de LPU en netwerkcomponent tijdelijk nog online blijft (zie paragraaf “Kast”). Alle gegevens dienen dan weggeschreven te worden zodat na het volledig spanningsloos zijn van de installatie, alle gegevens toch nog beschikbaar zijn. Tegelijk moeten de laatste statussen van defecten doorgestuurd worden naar de Back-Office. Bij wegvallen van de communicatie tussen Front-Installation en Back-Office dient de LPU de verschillende datapakketten tijdelijk te bufferen. Wanneer de communicatie hersteld is, dient de LPU te werken volgens een LIFO (Last In First Out) systeem waarbij het datapakket dat laatst aangemaakt is, eerst verstuurd wordt naar de Back-Office. 2.1.4.2.C 2.1.4.2.C.1
COMMUNICATIEMODULE NAAR BACK-OFFICE Communicatiemodule
Het opzetten van een beveiligd netwerk (VPN of VLAN) tussen de Front-Installation en de BackOffice is een verantwoordelijkheid van de opdrachtnemer. De communicatie moet werken met een watchdog die de goede werking van de verbinding tussen de Front-Installation Addition en de Back-Office bewaakt. Indien de communicatie tussen FrontInstallation en Back-Office wegvalt, dient de Front-Installation automatisch een “hard reset” uit te voeren van de communicatiemodule iedere 10 minuten. 2.1.4.2.C.2
Netwerkcomponenten
In casu artikel “2.1.4.3.C.1 Beschikbare Netwerken” is de levering van apparatuur een last van de bestellende overheid tenzij de bestellende overheid dit expliciet vraagt om deze apparatuur te leveren en te plaatsen. De bestellende overheid kan gebruik maken van zijn eigen interne werking om in te staan voor configuratie van het netwerk als kan ze dit bestellen bij de opdrachtnemer. Het aanleggen van bijkomende bekabeling wordt gecoördineerd door de opdrachtnemer, in casu artikel “2.1.4.3.C.2 Aanleg van bekabelde netwerken”. In de meetstaat zijn 4 verschillende posten opgenomen voor de levering, plaatsing en configuratie van netwerkcomponenten. Deze 4 posten komen overeen met 4 technieken om tot een verbinding te komen. 1. bekabeld netwerk (glasvezel/fiber); 2. bekabeld netwerk (DSL); 3. draadloos netwerk via 3G (HSUPA); 4. draadloos netwerk via WiMax. Alle voorgestelde netwerkcomponenten moeten in de paalkast kunnen ingebouwd worden. In deze 4 posten zitten alle nodige componenten en werken vervat om tot een verbinding te komen. Deze 4 posten dienen gebruikt te worden wanneer men een netwerkstudie opmaakt volgens artikel “2.1.4.3.C.4 Netwerkstudie”. Alle netwerkcomponenten worden voorzien van voldoende netwerkpoorten zodat er bovenop de benodigde poorten minimaal 2 reservepoorten zijn voor extra uitbreidingen niet opgenomen in dit contract. 2.1.4.2.C.3
Dataprotocol
Het dataprotocol tussen de Front-Installation en de Back-Office is vrij bepaalbaar door de opdrachtnemer. Voor de communicatie tussen de Back-Office en andere 3de partijen (vb. Vlaamse Verkeercentrum VVC) wordt wel een communicatieprotocol opgelegd. De laatste versie van dit communicatieprotocol is op te vragen bij de aanbestedende overheid.
Pagina 14 van 64
2.1.4.2.C.4
WiMax
Onderdeel van deze opdracht is het uitbouwen van een draadloos breedbandig netwerk met middelgroot bereik volgens de standaard IEEE 802.16. Er worden multipoint-to-point en point-topoint draadloze verbindingen voorzien. Volgende eisen gelden voor alle voorgestelde producten: •
Wwrken over frequentieband 4.9 GHz tot 6 Ghz;
•
snelheid aggregated/Asymmetrisch (dynamisch beheer van de download en uploadverhouding);
•
5, 10 Mhz en 20 Mhz kanaal;
•
een minimaal mogelijke afstand van 10 kilometer tussen twee access punten in Line of sight en volle belasting.
Voor de point-to-point verbinding dienen twee producten aangeboden te worden: Point-to-point met: •
minimaal 20 Mbps;
Point-to-point met: •
minimaal 50 Mbps;
Voor de multipoint-to-point dient één product aangeboden te worden: Multipoint-to-point met: •
minimaal 200 Mbps;
•
dedicated bandwidth instelbaar.
Alle voorgestelde producten moeten kunnen werken in een licentievrije band en in een licentie gebaseerde band. Alle coördinatie en aanvragen van de vergunningen (onder andere monumentenzorg, brandbeveiliging) voor het plaatsen van de producten zijn een last van de opdrachtnemer. Inplantingstudie Bij de opstart van een nieuw WiMax netwerk wordt een studie opgemaakt die een analyse maakt van de regio en een voorstel doet van inplanting. De studie maakt een inschatting van huidige en toekomstige behoeften, onderzoekt mogelijke locaties op haalbaarheid en bekijkt hoe de communicatie tussen de Back-Office en het WiMax netwerk opgebouwd wordt. Het resultaat van de studie is een studiedocument met bijhorende bestelstaat voor het uitvoeren van de werken. 2.1.4.2.D 2.1.4.2.D.1
KAST Wegkantkast en paalkast
In de nabijheid van het ANPR captatie systeem dient een kast voorzien te worden voor het opbergen van alle apparatuur. Afhankelijk van de lokale situatie kan gekozen worden voor een paalkast of een wegkantkast. Standaard wordt gekozen voor een paalkast. Op vraag van de bestellende overheid kan er ook gekozen worden voor een wegkantkast. Dit kan bijvoorbeeld wanneer de netwerkmodule wordt geleverd door de Vlaamse Overheid en er geen ruimte genoeg is om deze in de paalkast te plaatsen. Er zijn twee opstellingen: 1. de basisopstelling in een paalkast waarbij er ruimte voorzien is voor volgende apparatuur: a. (aansluiting) 4 ANPR captatie systemen; b. (aansluiting) Bijhorende Bewakingscamera’s; c. (aansluiting) detectiesensor voor de detectie van vrachtwagenverkeer; Pagina 15 van 64
d. de LPU; e. één netwerkcomponent (alle apparatuur voorgesteld door de opdrachtnemer of alle apparatuur van de meest courante publieke netwerken); f.
noodvoeding;
g. uitrusting trajectcontrole. 2. de uitgebreide opstelling waarbij bovenvernoemde hardware ondergebracht wordt in een wegkantkast en waar reserveplaats is voor het plaatsen van netwerkcomponenten van derde partijen (din-rail mountable) en een tellerkast van de energieleverancier; Voor de paalkast worden geen specificaties qua grootte opgelegd. De aanbestedende overheid dringt aan deze kast zo compact mogelijk te houden. Voor de wegkantkast dient, naast de ruimte nodig voor het plaatsen van 4 ANPR captatiesystemen + bewakingscamera’s en uitbreidingen, er extra vrije ruimte voorzien te zijn voor het monteren van een netwerkswitch geleverd door een derde partij (din-rail mountable) en het plaatsen van een tellerkast. In de kast (zowel de paal- als wegkantkast) dient de opdrachtnemer voldoende verwarmende en koelende elementen aan te brengen zodat alle apparatuur binnen zijn temperatuursgrenzen kan werken. Het leveren van deze apparatuur is onderdeel van de desbetreffende posten van levering van een paal of wegkantkast. Beide kasten zijn inclusief de nodige beveiligingen en bekabeling. De paalkasten hebben minimaal volgende kenmerken: - samengesteld uit glasvezelversterkt polyester, zelfdovend en halogeenvrij; - bestand tegen zouten, zuren, basen, oliën, vetten en organische oplosmiddelen; - gekleurd in de massa (RAL 7035); - de mechanische sterkte van de kasten mogen niet verminderen bij temperaturen begrepen tussen – 20°C en +80°C, noch afnemen in de tijd onder invloed van UV-straling; - bestand tegen trillen en windbelasting tot 1000 N/m²; - het binnendringen van water, sneeuw of ongedierte langs de ventilatieopeningen wordt verhinderd; - alle toebehoren zoals sloten, bouten, rails,… worden uit corrosievast materiaal vervaardigd; - de deuren zijn bevestigd door middel van corrosiebestendige scharnieren die van buitenuit niet bereikbaar zijn; - voorzien van een driepuntssluiting en een slot; - uitgerust met een deurcontact; - modulair uitgerust met de nodige bevestigingsramen en rails; - beschermingsgraad minimaal IP 54 volgens IEC 60529 en slagvastheid IK 08 volgens EN 62262; - alle apparatuur in de kast is makkelijk bereikbaar voor onderhoudsdoeleinden, in het bijzonder worden onderbrekingsklemmen, bedienbare elementen en signalisatie op het frontpaneel geplaatst; - voorzien van bedekkingslaag geschikt om eenvoudig graffiti, aanplakbiljetten, … te verwijderen en die na de verwijdering terug kan hersteld worden; - voorzien van een gegraveerd identificatieplaatje met het installatie nummer (inhoud en vormgeving af te stemmen met de aanbestedende overheid); - de aardingsweerstand van de kast dient uitgevoerd te worden volgens het AREI. Dit opgelegd kenmerk is een afwijking op de technische eisen opgenomen in het in het standaardbestek.
Pagina 16 van 64
- de wegkantkast is standaard uitgerust met extra beveiligingen voor het bijplaatsen van extra uitbreidingen, een stopcontact 20A en verlichting. De voetpadkasten hebben minimaal volgende kenmerken: - type D of groter in roestvast staal of aluminium volgens EN 60439-5; - de behuizing is vervaardigd in roestvast staal AISI 304 volgens EN 1.4452 en voorzien van een polyester oppervlaktebehandeling, standaard RAL 7034 of aluminium plaatdikte 3 mm met poedercoating; - voorzien van een driepuntssluiting en een slot; - bestand tegen zouten, zuren, basen, oliën, vetten en organische oplosmiddelen; - beschermingsgraad minimaal IP 54 volgens IEC 60529 en slagvastheid IK 10 volgens EN 62262; - montage op roestvrij stalen, polyester of beton DIN-genormaliseerde sokkel FP0 resp. FP2. 2.1.4.2.D.2
Noodvoeding
De kast dient voorzien te zijn van een noodvoeding zodat na het wegvallen van de spanning minimaal nog alle geregistreerde maar niet verzonden voertuigen kunnen doorgestuurd worden naar de BackOffice. Daarnaast dient, wanneer de noodvoeding actief wordt, onmiddellijk én een tweede maal na 2 minuten een overzicht doorgestuurd te worden van alle alarmen. Als er een bewakingscamera aanwezig is, dan dient onmiddellijk een overzichtsbeeld doorgestuurd te worden van de registratie bij het wegvallen van de voeding. 2.1.4.2.E
PAAL
De basispaal heeft een lengte van 4 meter, geplaatst in elk grondtype. Voor hogere palen zijn twee posten voorzien “Leveren van een extra meerlengte van 2 meter voor palen tot van 6 tot en met 12 meter” en “Leveren van een extra meerlengte van 2 meter voor palen tot van 14 tot en met 20 meter”. De paal moet corrosiebestendig zijn ofwel door galvanisatie, ofwel door gebruik te maken van aluminium of roestvrij staal. Stabiliteittechnisch dient de paal voorzien te zijn voor het plaatsen van alle onderdelen opgesomd in de opdrachtdocumenten. De paal moet voldoende sterk zijn om, belast met de onderdelen van de Front-Installation, zowel de statische als dynamische belastingen ten allen tijden te weerstaan. Bij twijfel kan de aanbestedende overheid een berekeningnota opvragen die de sterkte aantoont. Voor de paal kan optioneel een beschermingsbeugel geplaatst worden die vervaardigd is uit thermisch verzinkt staal. De beschermingsbeugel zal voornamelijk geplaatst worden bij palen geplaatst net na parkeerplaatsen om lichte/rechtstreekse aanrijdingen te vermijden. De beschermingsbeugel dient minimaal 500mm breder te zijn dan de diameter van de paal en dient een minimale diameter van 76mm te hebben. 2.1.4.2.F 2.1.4.2.F.1
BEWAKINGSCAMERA Beelden
Ieder ANPR captatie systeem dient voorzien te zijn van een vaste bewakingscamera die kleurbeelden neemt van de geregistreerde voertuigen waarbij voor iedere registratie minimaal het volledige voertuig zichtbaar is. De bewakingscamera wordt voorzien van een varifocale lens of de opdrachtnemer voorziet een reeks van vaste lenzen met een variërend aantal brandpuntafstanden waarbij de combinatie van één lens (met één bepaalde brandpuntafstand) én de bewakingscamera het mogelijk maakt een minimale
Pagina 17 van 64
pixelgrootte van 15 pixel te halen voor de nummerplaat en tegelijk het volledige voertuig in beeld te brengen. Er dient op locatie een tijdelijke opslag van de camerabeelden te gebeuren. De camerabeelden moeten per camera minimaal 7 dagen bewaard worden. Bij iedere registratie van het ANPR systeem dient een bijhorend overzichtsbeeld van de bewakingscamera toegevoegd te zijn. Dit overzichtsbeeld toont het gehele voertuig. Dit overzichtsbeeld wordt lokaal bewaard en kan opgevraagd worden vanuit de Back-Office. Het moet mogelijk zijn aan te geven dat bij iedere registratie het overzichtsbeeld automatisch mee verzonden wordt naar de Back-Office. Het moet ook mogelijk zijn realtime camerabeelden op te vragen en te streamen. Indien het ANPR captatie systeem een interne bewakingscamera bevat dan dienen de beelden van de bewakingscamera afzonderlijk van het ANPR captatie systeem beschikbaar en beheerbaar te zijn. De gegevens per registratie moeten lokaal even lang bewaard worden als de gegevens van het ANPR captatie systeem. 2.1.4.2.F.2
Communicatie
De bewakingscamera (IP-camera of via encoder) dient een signaal te genereren die rechtstreeks op de switch kan geplaatst worden. Volgende technische minimale eisen dienen voldaan te zijn voor de camera: - automatisch gestuurde, mechanische IR-filter; - minimum gevoeligheid in dagmode: 1 lux (1/50s shutter, F1.4, 89% reflectie, 50IRE); - minimum gevoeligheid in nachtmode: 0,1 lux (1/50s shutter, F1.4, 89% reflectie, 50IRE); - MPEG4, H264 of gelijkwaardig + M-Jpeg; - ONVIF compatible; - ondersteuning voor timeserver protocol; - met varifocale lens van minimaal 4 tot 20 mm of hoger of vaste lenzen met een brandpuntafstand van respectievelijk 4, 6, 8, 10, 12, 14, 16, 18 en 20 mm of hoger; - ondersteunen van Snmp voor opvraging van statusinfo door centraal platform/snmpbeheerssysteem. De volgende snmp-requests dienen minimaal ondersteund te worden: videosignaal ja/nee, laatste herstart van firmware (datum en tijd) en andere parameters waarbij de health van de encoder/IP-camera kan worden nagegaan (vb. temperatuur van de processor e.d. …); - webinterface: elke encoder of IP-camera moet over een interface beschikken waarop alle instellingen kunnen gebeuren. Daarnaast dienen de meest courante parameters uitleesbaar en wijzigbaar te zijn vanuit de Back-Office. 2.1.4.3 Kenmerken van de uitvoering 2.1.4.3.A
ANPR CAPTATIE SYSTEEM
Het ANPR captatie systeem dient ondergebracht te worden in een neutrale onopvallende, UVbestendige behuizing(en), vandaalbestendig. Het ANPR captatie systeem kan zowel aan de linker of rechter zijberm als in de middenberm geplaatst worden. Het bevestigingsprincipe van het ANPR captatie systeem laat toe alle vrijheidsgraden met een hoge graad van nauwkeurigheid te positioneren en te borgen. De bekabeling en een wachtbuis tot aan de kast en de montageonderdelen is onderdeel van de post
Pagina 18 van 64
“Het leveren, plaatsen en configureren van een ANPR captatie systeem”. Eventuele grondwerken4 tot aan de kast worden wel afzonderlijk vergoed worden. De bekabeling, bevestigingsonderdelen en afscherming (AREI ART. 159) op het straatmeubilair (palen, portiek, ... excl. bevestiging op een brug en tunnelfronton) worden niet afzonderlijk vergoed. Alle voedingskabels, netwerkkabels… ,ook van andere gevoede elementen, die zich bovengronds bevinden worden continu tot op een minimale hoogte van 2,5m boven het maaiveld beschermd door een aluminium buis of omhulsel. De bevestiging van de buis of omhulsel dient extra vandaalbestendig te zijn. 2.1.4.3.B
LOKALE VERWERKINGSEENHEID (LPU)
De LPU kan rechtstreeks in elk ANPR captatie systeem afzonderlijk ingewerkt zijn of in de (paal)kast. Deze opstelling dient rekening te houden met de verschillende mogelijke uitbreidingen. Indien een LPU in elk ANPR captatie systeem geplaatst wordt, dan dienen deze afzonderlijk adresseerbaar te zijn en dient de Back-Office aangepast te zijn zodat de Front-Installation zowel individueel als in groep bereikbaar is. 2.1.4.3.C 2.1.4.3.C.1
COMMUNICATIEMODULE NAAR BACK-OFFICE Beschikbare Netwerken
Door de sterk variërende regionale verschillen ivm beschikbare netwerken, vb. 3G, dient het geheel de mogelijkheid te beschikken om gebruik te maken van een grote variatie van netwerken: •
Communicatie via het private netwerk van de Vlaamse Overheid; Het Vlaamse overheidsnetwerk (Telematica) is beschikbaar voor het opzetten van een communicatiepad. De installatie van deze apparatuur en bekabeling is een last van de overheid.
•
Netwerk via het private netwerk van de bestellende overheid; Het is mogelijk dat de bestellende overheid (vb. politiezone) een eigen privaat netwerk bezit. De opdrachtnemer dient zich te vergewissen van de eigenschappen van dit netwerk en dient aan te geven naar de bestellende overheid wat minimaal nodig is. De levering van apparatuur is een last van de bestellende overheid tenzij de bestellende overheid dit expliciet vraagt om deze apparatuur te leveren en te plaatsen. De bestellende overheid kan gebruik maken van zijn eigen interne werking om in te staan voor configuratie van het netwerk en het aanleggen van bijkomende bekabeling, als kan ze dit bestellen bij de opdrachtnemer.
•
Netwerk via een externe partij; Op de markt zijn verschillende publieke netwerken beschikbaar. Het opzetten van communicatie over deze publieke netwerken is toegestaan mits gebruik te maken van extra beveiliging bepaald in samenspraak met de desbetreffende bestellende overheden (politie, vlaamse overheid,…). De opdrachtnemer dient hierbij rekening te houden dat elke bestellende overheid qua veiligheid van hun netwerk een verschillende politiek kunnen voeren. Het is de verantwoordelijke van de opdrachtnemer zich aan te passen naar de unieke restricties van elke bestellende overheid Wanneer het netwerk geleverd wordt door een externe partij staat de opdrachtnemer in voor alle coördinatie voor de realisatie van de verbinding. De opdrachtnemer legt de afspraken vast met de externe partij, zorgt dat de nodige apparatuur geplaatst wordt en zorgt dat het netwerk opgezet wordt. De opdrachtnemer dient vooraf een kostenraming op te stellen opdat de bestellende overheid weet wat zijn kosten zullen zijn voor het realiseren van een verbinding en de maandelijkse abonnementskost. Deze kostenraming wordt voorgelegd aan de bestellende
4
de grondwerken, dus het graafwerk of een boring, en de bekabeling, en wachtbuis die in de grond worden geplaatst;
Pagina 19 van 64
overheid ter goedkeuring en ondertekening. De plaatsing kan van start gaan nadat de bestellende overheid een contract afgesloten heeft met een externe partij. De coördinatie hiervan is een last van de aanneming Naast de publieke netwerken vallen private netwerken ook onder de noemer externe partijen. Een voorbeeld hierin kan zijn het netwerk van de spoorwegen. 2.1.4.3.C.2
Aanleg van bekabelde netwerken
Er wordt verondersteld dat de netwerkkabel van de desbetreffende techniek aanwezig is in de directe nabijheid van de router. Echter kan een uitbreiding van het net noodzakelijk zijn: - de aanbestedende overheid kan worden aangesproken om in synergie glasvezel en kopernetwerken uit te bouwen. De bestellende overheid is op dat moment een klant van de aanbestedende overheid. De aanbestedende overheid dient dan aangesproken te worden om een offerte aan te leveren; - bij het aansluiten van netwerken via een externe partij, zijn de bekabelingwerken onderdeel van de offerte die de opdrachtnemer opstelt naar de bestellende overheid. 2.1.4.3.C.3
Coördinatie
De coördinatie voor het opzetten van een netwerk is in casu artikel “2.1.4.3.C.1Beschikbare Netwerken “ steeds een verantwoordelijkheid van de opdrachtnemer. De opdrachtnemer legt de afspraken vast met bestellende overheid, de netwerkbeheerder, de externe partijen en is de eindverantwoordelijke voor de goede installatie en configuratie van het netwerk. Dit zowel bij de Front-Installation als bij de Back-Office. Deze coördinatie is een last van de opdrachtnemer. 2.1.4.3.C.4
Netwerkstudie
Om duidelijkheid te geven over de meest geschikte netwerktechnologie voor een bepaalde locatie kan op aanvraag van de bestellende overheid een netwerkstudie besteld worden voor de bepaling van de meest rendabele vorm van netwerk voor die locatie. Het bestellen van een netwerkstudie is een keuze van de bestellende overheid en is geen standaard bestelling. De studie dient minimaal volgende elementen op te nemen: •
beschikbare netwerktechnieken voor de locatie (zowel de private als publieke);
•
beperkingen van de netwerktechnieken (vb. maximale bandbreedte, geschatte werkelijke bandbreedte locatie, maximaal aantal voertuigen die met deze bandbreedte kunnen verstuurd worden, ..);
•
kostprijsanalyse voor de installatie met onder andere de kosten voor eventuele bekabelingwerken;
•
kostprijsanalyse over 1 jaar;
•
kostprijsanalyse over 5 jaar;
•
te verwachten levensduur van de netwerkverbinding;
•
eindconclusie met onder andere een ranglijst van de technieken, uitgeschreven in een rapport.
Deze lijst is niet limitatief en wordt in samenspraak met de bestellende overheid eventueel uitgebreid. De netwerkstudie dient rekening te houden met andere bestaande en nieuwe locaties/netwerkstudies. Bijvoorbeeld: sommige kosten kunnen gedeeld worden over meerder locaties (kostprijs voor het opzetten van een draadloos netwerk) of dienen er aanpassingen te gebeuren ter hoogte van de BackOffice bij capaciteitsverhoging. De netwerkstudie geeft ook aan welke communicatiemethode gekozen dient te worden zodat de
Pagina 20 van 64
gecomprimeerde datapakketten zonder noemenswaardige vertragingen kunnen doorgestuurd worden naar de Back-Office. 2.1.4.3.D 2.1.4.3.D.1
KAST Fundering wegkantkast
Rondom de wegkantkast wordt een met wapeningsnet voorzien betonnen “platform” gegoten dat enerzijds extra stabiliteit biedt aan de kast en anderzijds de toegankelijkheid tot de kast bevordert. Dit platform heeft een nuttig oppervlak van min. 20 cm. rondom de kast. 2.1.4.3.D.2
Coördinatie voor het opzetten van een voedingspunt
De coördinatie voor het opzetten van een voedingspunt is een verantwoordelijkheid van de opdrachtnemer. De opdrachtnemer legt de afspraken vast met bestellende overheid, de distributienetbeheerder en de energieleverancier van de bestellende overheid en de opdrachnemer is de eindverantwoordelijke voor de goede installatie en configuratie. De coördinatie voor het opzetten van een voedingspunt is een last van de opdrachtnemer. 2.1.4.3.D.3
Aansluiten
De effectieve aansluiting op de netspanning van het huishoudelijke net kan slechts gebeuren nadat elke kast individueel is gekeurd door een erkend keuringsorganisme. Deze keuring is een last van de opdrachtnemer. De kast moet gekeurd zijn volgens het AREI. 2.1.4.3.D.4
Synergrid
De opdrachtnemer dient een synergrid aanvraag te doen van een forfaitaire aansluiting van de paalkast. Hierbij dient gewerkt te worden via een veiligheidstransformator. Dit maakt beperkte uitbreidingen mogelijk zolang er gewerkt wordt binnen de grenzen van de veiligheidstransformator. 2.1.4.3.D.5
Voeding via verlichtingsnet
De opdrachtnemer dient batterijenopstelling te voorzien die geplaatst kan worden op een verlichtingspaal en die een 24V spanning creëert voor de Front-Installation, gebruik makende van de stroomvoeding van het verlichtingnet. De capaciteit van de batterijen moet voldoende zijn om tijdens de nachturen de batterijen op te laden zodat de goede werking van de Front-Installation ook overdag gegarandeerd wordt. Waar nodig dient de opdrachtnemer de coördinatie op te zetten met de beheerder van de verlichtingspaal en dient de opdrachtnemer concrete afspraken vast te leggen. 2.1.4.3.E 2.1.4.3.E.1
PAAL Opstelling
De funderingswerken voor het plaatsen van de steunpaal is een last van de aanneming. 2.1.4.3.E.2
Coördinatie voor het opzetten van een paal
Het aanvragen van een vergunning en het coördineren van de werken tot het veilig opzetten van een paal zijn een last van de opdrachtnemer. 2.1.4.3.F 2.1.4.3.F.1
BEWAKINGSCAMERA Opstelling
Pagina 21 van 64
De bewakingscamera wordt opgesteld ter hoogte van het ANPR captatie systeem met dezelfde kijkrichting. 2.1.4.3.F.2
Opstelling pictogram bewakingscamera
Per bewakingscamera-nummerplaatlezer, moet 1 wettelijk voorzien pictogram “bewakingscamera” (Zie KB 10 februari 2008, BS 21/02/2008, tot vaststelling van de wijze waarop wordt aangegeven dat er camerabewaking plaatsvindt) geplaatst worden. Het leveren en plaatsen van dit pictogram is een last van de opdrachtnemer. Er is wel een post voorzien voor het leveren en plaatsen van een kleine paal (hoogte maximaal 2,5 meter en diameter 76mm) voor de bevestiging van een pictogram bewakingscamera. 2.1.4.3.F.3
Coördinatie naar privacy commissie
Niet alle bestellende overheden hebben zelf de kennis om een aangifte te doen van hun bewakingscamera bij de privacy commissie. De vraag voor het opzetten van de coördinatie met alle bijhorende administratie kan daarom besteld worden bij de opdrachtnemer.
2.1.5
Controles
2.1.5.1 Dataprotocol De voorlopige oplevering van het leveren en plaatsen van een Front-Installation kan niet worden uitgevoerd vooraleer het volledige communicatieprotocol is uitgeschreven en beschikbaar kan worden gesteld aan de aanbestedende overheid en de bestellende overheid. 2.1.5.2 Communicatie Back-Office De voorlopige oplevering van het leveren en plaatsen van een Front-Installation kan niet worden uitgevoerd vooraleer de communicatie is opgezet naar de Back-Office. 2.1.5.3 Kast De energieaansluiting kan niet uitgevoerd worden vooraleer de installatie gekeurd is. 2.1.5.4 Meetresultaten Voor elke voorlopige oplevering heeft de bestellende overheid het recht de correcte werking van het ANPR captatie systeem te testen. Het ANPR captatie systeem kan maar opgeleverd worden als de herkenningsgraad van het systeem hoger is dan de herkenningsgraad die behaald werd bij de gunningtesten – 2%. Iedere test uitgevoerd in dit kader zal opgedeeld worden in één over meerdere omstandigheden. Een voorbeeld ter illustratie: veronderstel dat het ANPR captatie systeem tijdens de gunningsfase en op het onderdeel tijdens regenweer 90% van de voertuigen detecteert en volledig correct uitleest. Dan moet er bij de testen een 88% van de voertuigen gedetecteerd worden en volledig correct uitgelezen worden.
2.2 Front-Installation Additions 2.2.1
Detectie van vrachtwagenverkeer
2.2.1.1 Beschrijving De Front-Installation Standard dient modulair uitbreidbaar te zijn met een systeem voor de detectie van vrachtwagenverkeer.
Pagina 22 van 64
2.2.1.2 Kenmerken van de materialen Het systeem moet vrachtwagens (meer dan 3,5 ton en hoger dan 2,5 meter) kunnen onderscheiden van andere voertuigen. De manier waarop dit gebeurd is een vrije keuze van de opdrachtnemer, voorbeelden hiervan zijn: detectielussen, laser, hoogtesensor,…. maar ook een softwarematige classificatie is toegelaten. Het gekozen systeem moet minimaal 98% (excl. alle fout geclassificeerde personenvoertuigen) van het vrachtwagenverkeer detecteren. De detectie dient in eerste instantie als een indicatie. Bij verbalisatie (vb. een vrachtwagensluis) zal in de Back-Office een manuele controle gebeuren van de registratie. Wanneer gebruik gemaakt wordt van een softwarematige detectie, dan mag de nodige rekenkracht geen invloed hebben op de goede werking van het gehele ANPR systeem. De detectie van vrachtverkeer moet minimaal over twee rijstroken mogelijk zijn en moet kunnen gelinkt worden aan de ANPR registratie. De gegevens per registratie moeten lokaal even lang bewaard worden als de gegevens van het ANPR captatie systeem.
2.2.2
Trajectcontrole – Hardware
2.2.2.1 Beschrijving Trajectcontrole is een functionaliteit om conform het KB van 25.10.2010 de gemiddelde snelheid van een voertuig te bepalen tussen twee verschillende detectiepunten. 2.2.2.2 Kenmerken van de materialen De opdrachtnemer dient in zijn inschrijving een omschrijving mee te geven hoe over een gekend traject de gemiddelde snelheid van een voertuig op wettelijk verantwoorde manier bepaald wordt. Het behalen van een modelgoedkeuring voor het geplaatste systeem is integraal onderdeel van deze opdracht en is een voorwaarde voor deelname aan deze opdracht. Het trajectcontrolesysteem moet minimaal behoren tot klasse A met een meetbereik gaande van ten hoogste 30 km/h tot ten minste 250km/h. Alle gegevens nodig voor de toepassing van trajectcontrole dienen samen met de gegevens van het ANPR captatie systeem overgemaakt worden naar de Back-Office. De gegevens moeten lokaal even lang bewaard worden als de gegevens van het ANPR captatie systeem. 2.2.2.3 Kenmerken van de uitvoering De in dit contract beoogde trajectcontroletoepassing dient te beschikken over een modelgoedkeuring conform KB 25.10.2010. De inschrijver dient deze modelgoedkeuring toe te voegen aan zijn offerte of dient uiterlijk op datum van de gunning te zijn uitgereikt. Om deel te kunnen deelnemen aan de selectie, dient de opdrachtnemer te voldoen aan de bijzondere uitvoeringsmodaliteiten vermeldt in artikel “1.3.1Modelgoedkeuring”. De extra kosten voor herconformiteitskeuring of herijking in gevolge een defect of een foutieve of onvolledige uitvoering van de installatie door de opdrachtnemer, zijn ten laste van de opdrachtnemer. De nodige coördinatie en communicatie met de betrokken instanties voor de certificatie van een installatie zijn een last van de opdrachtnemer.
2.2.3
HD bewakingscamera
Indien de bestellende overheden dit wensen kunnen ze een HD bewakingscamera bestellen. 2.2.3.1 Kenmerken van de materialen Een HD bewakingscamera dient minimaal te voldoen aan onderstaande modaliteiten. - minimaal 1/2 inch CMOS of 1/3 MOS sensor progressieve scan;
Pagina 23 van 64
- (indien aanwezig) automatisch gestuurde, mechanische IR-filter; - minimale gevoeligheid in dagmode (kleur): 1 lux (F1.4, 89% reflectie, 50IRE, zonder compensaties); - minimale gevoeligheid in nachtmode (kleur of zwart-wit): 0.1 lux (F1.4, 89% reflectie, 50IRE, zonder compensaties); - minimum 25 fps aan 1 MEGA in nachtmode (1280x960 of hoger); - minimum 25 fps aan 2 MEGA in dagmode (1280x960 of hoger); - minimale dynamisch range 52 dB; - MPEG4, H264 of gelijkwaardig + M-Jpeg; - ONVIF compatible; - ondersteuning voor timeserver protocol; - lokale dataopslag voor minimaal 7 dagen; - motion detection; - backlight compensation; - privacy maskering; - PoE; - selecteerbaar op continue, alarm, event, geplande recording; - ondersteunen van Snmp voor opvraging van statusinfo door centraal platform/snmpbeheerssysteem. De volgende snmp-requests dienen minimaal ondersteund te worden: videosignaal ja/nee, laatste herstart van firmware (datum en tijd) en andere parameters waarbij de health van de encoder/IP-camera kan worden nagegaan (vb. temperatuur van de processor e.d. …); - webinterface: elke encoder of IP-camera moet over een interface beschikken waarop alle instellingen kunnen gebeuren. Daarnaast dienen de meest courante parameters uitleesbaar en wijzigbaar te zijn vanuit de Back-Office; - met twee verschillende lenzen leverbaar: - varifocale lens met een maximale kijkhoek van 60 graden; - 180 graden lens (fish-eye). De Back-Office moet de beelden van deze bewakingscamera kunnen beheren met behulp van de module beschreven in artikel “2.3.2.2.N Offline Data analyse-Module nazicht Camerabewaking”. 2.2.3.2 Kenmerken van de uitvoering Een sitevisit zal bepalen hoe de uitvoering zal gebeuren op locatie. Het plaatsen van de HD camera zit inbegrepen in de post leveren en plaatsen van een HD camera. Alle grondwerken worden apart vergoed volgens de desbetreffende posten. De bekabeling tussen HD camera en switch wordt gerealiseerd door middel van een UTP kabel volgens de desbetreffende post.
Pagina 24 van 64
2.3 Back-Office 2.3.1
Back-Office Standard
2.3.1.1 Beschrijving De Back-Office omvat alle soft- en hardware die geleverd en geplaatst wordt bij de bestellende overheid voor het beheren en de verwerken van alle gegevens afkomstig van Front-Installations. Alle software van de Back-Office en de softwaremodules worden modulair opgebouwd. Iedere ontwikkeling van een nieuwe softwaremodule wordt in overleg gerealiseerd met minimaal de aanbestedende overheid en eventueel bestellende overheden. De Back-Office Standard, is de basis soft- en hardware die opgesteld wordt voor de opbouw van de Back-Office bij de gebruiker. De Back-Office Standard kan onder andere data ontvangen, data verwerken, data bewaren, data beschikbaar stellen voor de (software-)uitbreidingsmodules, gebruikers beheren, gebruikersrechten toekennen en bevat bewaking- en monitoringssoftware. De Back-Office Standard bevat ook het framework waarop de verschillende uitbreidingsmodules modulair kunnen opgebouwd worden. De Back-Office fungeert als platform. De Back-Office Standard wordt opgesplitst in twee functionaliteiten die overeen stemmen met twee verschillende systemen/servers: a. Dataserver; b. Basis applicatieserver. Alle servers geleverd binnen deze opdrachtdocumenten dienen schaalbaar te zijn en uitbreidbaar afhankelijk van de noden. De dataserver dient RAID-5 te zijn. In de opdrachtdocumenten is er een post voorzien voor de levering en plaatsing van een serverkast. Dit om bij bestellende overheden een nieuw serverruimte te creëren indien zij dit wensen. 2.3.1.2 Kenmerken van de materialen 2.3.1.2.A
DATASERVER
De dataserver wordt gebruikt voor het ontvangen, verwerken en bewaren van alle gegevens horende bij een registratie van een Front-Installation (gegevens ANPR captatiesysteem en uitbreidingen) en schrijft deze gegevens weg naar zijn database. De dataserver dient over een onafhankelijke partitie te beschikken voor gegevens die langer dan 30 dagen dienen bewaard te worden. Dit zijn gegevens die een gerechtelijke finaliteit bezitten. Deze gegevens dienen bewaard te worden minimaal tot het vervallen van de strafvordering. Alle verschillende uitbreidingsmodules dienen over een automatische export te beschikken om de data met een gerechtelijke finaliteit automatisch langer dan 30 dagen te bewaren. Daarnaast dient de software ook de mogelijkheid te hebben registraties manueel aan te duiden dewelke langer dan 30 dagen dienen bewaard te blijven. Hoe dit exact gebeurd zal vastgelegd worden tijdens de opbouw van de software en is in samenspraak tussen opdrachtnemer en aanbestedende overheid. 2.3.1.2.B
BASIS APPLICATIESERVER
De basis applicatieserver realiseert de interfaces die communiceren met de Front-Installations. Alle interfaces naar de gebruiker toe dienen webbased te zijn. 2.3.1.2.C
BEWAKING- EN MONITORINGSSOFTWARE
De bewaking- en monitoringssoftware staat in voor de technische bewaking van alle apparatuur.
Pagina 25 van 64
De Front-Installation brengt automatisch bij zijn opstart de applicatieserver op de hoogte van alle optredende alarmen. Nadien stuurt hij iedere 5 minuten een update van alle gewijzigde technische informatie. Naast alarmen stuurt de Front-Installation altijd een watchtdog ter bewaking van de communicatie. Op deze manier wordt de communicatie met de Back-Office bewaakt. Wanneer de communicatie met de Back-Office tijdelijk afwezig is na een probleem of reset en terug opkomt dan stuurt de Front-Installation zijn laatst gekende toestand door. Het applicatiesysteem filtert alle inkomende alarmen op een intelligente manier zodat niet-relevante secundaire problemen ten gevolge van primaire alarmen onderscheiden worden. Een voorbeeld hiervan is wanneer de voeding van een installatie wegvalt, zal kort erna geen communicatie meer mogelijk zijn met het systeem. Het wegvallen van de communicatie is een direct gevolg van het wegvallen van de voeding, het alarm “communicatieprobleem” is dus een secundair alarm. De basis applicatieserver koppelt aan de primaire en secundaire alarmen een prioriteit (dringend, nietdringend). Beelden De basis applicatieserver dient over meerdere beelden te beschikken waar iedere bestellende overheid een overzicht kan krijgen van de verschillende Front-Installations die op zijn Back-Office zijn geregistreerd: •
een grafisch overzicht van alle Front-Installations met per Front-Installation een aanduiding of er alarmen voorkomen en van welke graad die zijn;
•
een grafisch overzicht van alle alarmen van per Front-Installation;
•
een overzicht van alle alarmen met hun beschrijving en hun bijhorende mogelijke oorzaken met hun prioriteit;
•
logboek van alarmen waarbij een opsplitsing mogelijk is per Front-Installation.
Bij de ontwikkeling van de alarmbewaking- en monitoringssoftware zal vooraf een kleurencode vastgelegd worden door de aanbestedende overheid. 2.3.1.2.D
BEHEERSOFTWARE
De beheersoftware laat toe ‘on-site’ en vanuit de Back-Office via het opgezette netwerk, de volledige configuratie van de Front-Installation en Back-Office te beheren, inclusief het bewaren, up- en downloaden van configuratieparameters. Wanneer een Front-Installation een eerste maal geconfigureerd wordt en online komt, dan bewaart hij zijn identiteit. De beheersoftware houdt de laatste configuratie bij van de verschillende FrontInstallations. Wanneer een systeem, door bijvoorbeeld een reset, zijn configuratie verliest, zal deze zijn laatste configuratie kunnen ophalen via de centrale beheersoftware. Deze software dient in eerste instantie de voornaamste software te zijn van de opdrachtnemer voor het beheren en configureren van zijn systemen. De beheersoftware heeft een interface bestaande uit 3 tabbladen. Het eerste tabblad, configuratietabblad, toont de configuratie en alle technische specificaties van de Front installations met onder andere: -
een overzichtsbeeld van alle installaties met indicatie of deze installaties online zijn;
-
een configuratiescherm per Front-Installation met alle beschikbare informatie over die Front-Installation;
-
technische informatie met onder andere alle informatie van de As-Built van iedere FrontInstallation;
Pagina 26 van 64
Het tweede tabblad, interventieboek bevat alle informatie over de uitgevoerde interventies op de verschillende systemen.(zie artikel 2.6 Full omnium onderhoud na waarborgperiode). Het interventieboek bevat onder meer: -
een overzicht van alle uitgevoerde correctief onderhouden, preventief onderhouden, spoedeisend onderhouden, adaptief onderhouden, perfectief onderhouden en een overzicht van alle uitgevoerde tussenkomsten ten gevolge van averijen;
-
een ingevulde checklist van alle uitgevoerde correctief onderhouden, preventief onderhouden, spoedeisend onderhouden, adaptief onderhouden, perfectief onderhouden;
-
gedetailleerde informatie in verband met elk uitgevoerd correctief onderhoud, preventief onderhoud, spoedeisend onderhoud, adaptief onderhoud, perfectief onderhoud. De gedetailleerde info bevat minstens het tijdstip het laatste onderhoud per type onderhoud, het tijdstip van oproep, het tijdstip van eerste tussenkomst, het tijdstip van voorlopige herstelling, het tijdstip van definitieve herstelling, een gedetailleerde beschrijving van het probleem, een gedetailleerde beschrijving van de herstelling,.. Deze gedetailleerde informatie is via een kleurencode gekoppeld aan de interventietermijnen. Indien de opdrachtnemer de vastgelegde termijnen niet respecteert dient dit automatisch aangeduid te worden via de afgesproken kleurencode;
Het derde tabblad van de beheersoftware bevat een overzicht van alle met onder andere per averij een dossier met de foto’s van de averij en een bijhorende meetstaat en kleurencode aan de hand van de status van een averij. In samenspraak met de aanbestedende overheid kan deze beheersoftware nog uitgebreid worden om bijvoorbeeld de vooruitgang in bestelopdrachten op te volgen. Dit is echter geen vereiste. 2.3.1.2.D.1
Koppeling Beheersoftware en Bewaking- en monitoringssoftware
In de bewaking- en monitoringssoftware moet een koppeling gemaakt worden met de beheersoftware voor het automatisch genereren van oproepen. Via een simpele knop in het overzicht van elke Front installation wordt een automatische oproep gegenereerd met een overzicht van alle alarmen en twee extra tekstvakken voor het toevoegen van een titel en extra informatie. Deze oproepen kunnen gegenereerd worden door de bestellende overheid of de opdrachtnemer. Iedere interventie ter plaatse dient geregistreerd te worden. ABBAMELDA Voor het beheren van oproepen en interventies wordt gebruik gemaakt van de 24 uur permanentie van de aanbestedende overheid. De registratie van deze permanentie gebeurt via ABBAmelda van de aanbestedende overheid. Alle oproepen en terugmeldingen voor correctief onderhoud en averijen die geregistreerd worden in het interventieboek dienen gepushed te worden naar ABBAmelda. De opdrachtnemer moet onder andere registeren wanneer hij ter plaatse is, welke defecten er waren en welke handelingen hij uitgevoerd heeft en wanneer hij zijn taken heeft afgerond. Het communicatieprotocol naar ABBAmelda zal ter beschikking gesteld worden tijdens de ontwikkeling van de Back-Office. IIR, Inventarisatie, Inspectie en Rapportering De aanbestedende overheid is momenteel volop bezig met de ontwikkeling van IIR, inventarisatie, inspectie en rapportering. Een beheersysteem voor het beheren van installaties, om de toestand van het patrimonium bij te houden en hierover te rapporteren. Indien de opdrachtnemer dit wenst kan in samenspraak met aanbestedende overheid het IIR verhaal, na de ontplooiing bij de aanbestedende overheid, geïntegreerd worden in de beheersoftware om een makkelijkere opvolging mogelijk te maken. De functionaliteiten die IIR aanbiedt worden dan ook beschikbaar voor de opdrachtnemer. Tijdens de ontwikkeling van beheersoftware zal een overlegmoment ingepland worden tussen de verantwoordelijk ingenieur van IIR bij de aanbestedende overheid en de opdrachtnemer om te bekijken wat mogelijk is.
Pagina 27 van 64
2.3.1.2.E
BEWAKING- EN MONITORINGSSOFTWARE, EN BEHEERSOFTWARE OPDRACHTNEMER
Iedere Back-Office bevat een eigen bewaking- en monitoringsoftware voor het bewaken van de FrontInstallations aangesloten op die Back-Office. Voor de opdrachtnemer is een overzicht van alle Front-Installations over de Back-Offices heen nuttig. Er moet een overkoepelende bewaking- en monitoringssoftware ontwikkeld worden die een overzicht heeft van alle Front-Installation. Bij het opstarten van deze software haalt hij automatisch alle alarmen op van alle Front-Installations via de verschillende Back-Offices. Na de opstart gebeurt dit niet meer automatisch en dient via een refresh de laatste gegevens opgehaald worden. De aanbestedende overheid dient toegang te krijgen tot deze software. 2.3.1.2.F
KALENDERSTURING
Een basisonderdeel van de software is een kalendersturing waarbij de werkingstijden van de verschillende modules aangegeven kan worden. Een voorbeeld ter illustratie: veronderstel een politiezone die gebruik maakt van de module trajectcontrole. Deze politiezone wenst vooral de veiligheid te verhogen en te beboeten tijdens de spitsuren. Dit moet aangegeven kunnen worden via de kalendersturing. Een tweede voorbeeld: Een politiezone heeft de module toegangscontrole in zijn softwarepakket. Deze politiezone wenst echter enkel actief controle uit te voeren tijdens het dagregime wanneer twee interventieteams ter beschikking zijn. Deze politiezone moet dit dynamisch en integraal kunnen beheren. De kalendersturing dient gebruik te maken van het iCal formaat. De kalender moet bestaan uit minimaal 2 verschillende regimes: 1. weekoverzicht, een tabblad waar het normale weekregime bepaald wordt; 2. speciale dagen, een tabblad met maandkalenders waar afwijkingen ten opzichte van de weekkalender aangegeven worden. (vb. een verlofperiode wanneer de politie minder mankracht ter beschikking heeft of een focusperiode waar meer wordt gecontroleerd). 2.3.1.2.G
GEBRUIKERS- EN RECHTENBEHEER
In de basis applicatiesoftware wordt een volledig gebruiker- en rechtenbeheersysteem uitgewerkt. In onderliggende figuur wordt een schets gegeven van het systeem.
Pagina 28 van 64
De Back-Office bevat 4 verschillende onderdelen op niveau van gebruikers- en rechtenbeheer: 1. Entiteit, een bestellende overheid die een aantal Front-Installations bezit en die beschikt over een aantal modules; 2. Module, een applicatie van de Back-Office die de registraties analyseert (vb. Trajectcontrole of DIV bevraging,…); 3. Gebruikersprofiel, een profiel die bepaald welke modules een bepaalde groep kan gebruiken, welke acties een bepaalde groep allemaal kan uitvoeren, enz…; 4. Gebruiker, een gebruiker die een unieke ID heeft en tot bepaalde gegevens en applicaties toegang heeft bepaald volgens zijn gebruikersprofiel; De bestellende overheid beschikt minimaal over de modules, Queries, Black List, DIV bevraging en beide GIS interfaces, en bezit mogelijks ook enkele uitbreidingsmodules, vb. Trajectcontrole om zijn gegevens van de Front-Installations te analyseren. Deze modules kan hij gebruiken binnen zijn Entiteit. De bestellende overheid zelf bestaat uit verschillende teams die zelf allemaal verschillende verantwoordelijkheden hebben. Deze verantwoordelijkheden worden opgedeeld in gebruikersprofielen die rechten hebben over enkele modules die de bestellende overheid/Entiteit in zijn bezit heeft. Een voorbeeld is een team die zich voornamelijk bezig houdt met verkeershandhaving. Dit team zal verantwoordelijk zijn voor de module trajectcontrole, vrachtwagensluis,… Een tweede team, een interventieteam, is dan meer geïnteresseerd in de DIV bevraging om bestuurders die niet verzekerd zijn tegen te houden. Dit team zal dan ook enkel over deze module beschikken. Ieder team/gebruikersprofiel bestaat op zijn beurt uit een aantal verschillende gebruikers die allemaal dezelfde mogelijkheden en rechten tot modules hebben. Iedere gebruiker wordt gekenmerkt door een eigen uniek ID en alle gebruikersacties dienen gelogd te worden in een logboek der gebruikersacties. Standaard wordt er één hoofd-gebruikersprofiel gecreëerd die het beheer van de verschillende gebruikersprofielen mogelijk maakt. Deze gebruiker kan nieuwe gebruikersprofielen aanmaken, kan modules en gebruikers toewijzen aan gebruikersprofielen. Hij kan deze gebruikerprofielen altijd aanpassen.
Pagina 29 van 64
Gebruikers die toegang hebben tot het vast ANPR netwerk en het interne netwerk waarop de BackOffice draait, moet via zijn/haar PC door op basis van een webinterface kunnen inloggen op de BackOffice en de functionaliteiten tot zijn/haar beschikking hebben afhankelijk van zijn/haar persoonlijke gebruikersrechten. 2.3.1.2.H
PUSH – PULL SERVICE PDA/SMARTPHONE
Om de bestellende overheden (vb. een politiekorps) op locatie te ondersteunen, dient bijkomend een “lite” versie van de Back-Office beschikbaar te zijn die het mogelijk maakt de Back-Office te consulteren via webinterface op een PDA of smartphone. Er dient hierbij een sms push service geïntegreerd te worden die zorgt voor automatische berichtgeving op deze PDA’s of smartphones. Deze sms push-berichtgeving kan getriggerd worden door een hit in de Black-lists van de Back-Office, door een hit in de module patronen of kan door een gebruiker van de Back-Office doorgestuurd worden naar één of meerdere personen op locatie. De politie op locatie moet pull opzoekingen kunnen uitvoeren mobile webbased, in de database via de module queries en DIV bevraging. (meer uitleg betreft deze modules in de artikels “2.3.2.2.J Offline data analyse-Module Queries (STANDAARD)” en “2.3.2.2.L Offline Data analyse-Module DIV bevraging (STANDAARD)”). Voor het activeren van deze service bij een bestellende overheid wordt een aparte post voorzien. 2.3.1.2.I
AANPASSING NUMMERPLAATREGISTRATIE
In modules dienen manuele aanpassingen van de nummerplaat mogelijk te zijn. Wanneer een nummerplaat aangepast wordt dan dient de dataserver geüpdate te worden met de nieuwe nummerplaat en dienen de modules deze nummerplaat opnieuw te verwerken alsof het een nieuwe registratie is. 2.3.1.2.J 2.3.1.2.J.1
GEDEELDE VAST ANPR NETWERK Gedeelde server
In onderliggende figuur worden twee verschillende entiteiten getoond. Het moet mogelijk zijn om op één Back-Office verschillende entiteiten (verschillende onafhankelijke politiezones) te creëren die onafhankelijk van elkaar werken maar die wel dezelfde server gebruiken en dezelfde modules (de modules worden per Back-Office maar één maal besteld). Dit laatste zal vooral gebruikt worden om de investeringskost in servers en vooral de investering in een goede serverruimte voor kleinere bestellende overheden te drukken. Op een centrale plaats (bijvoorbeeld in het serverlokaal van een grotere zone) wordt een dataserver en applicatieserver voorzien waarbij kleinere bestellende overheden met beperktere noden, enkele camera’s en enkele modules beheren. De servercapaciteit dient gedeeld te worden over de verschillende gebruikers.
Pagina 30 van 64
Overheden die een vast ANPR netwerk wensen te delen, leggen dit vast in een samenwerkingsovereenkomst. Deze samenwerkingsovereenkomst ligt buiten de scope van deze opdrachtdocumenten. In deze samenwerkingsovereenkomst kan staan welke overheid wat bestelt en wat de verdeelsleutel is in financiering.Voor de opdrachtnemer verandert er niets. De opdrachtnemer krijgt een bestelbrief van een bestellende overheid. 2.3.1.2.J.2
Gemeenschappelijke palen
Op grensgebieden of over grotere regio’s heen kan het gebeuren dat locaties met een ANPR captatiesysteem nuttig informatie levert voor meerdere partijen. De verschillende Back-Offices moeten daarom in staat zijn gegevens van palen automatisch te delen. Het kan hierbij gaan over een locatie die op de grens van twee politiezones ligt of palen die op de grens liggen van bepaaldeprovincies. Onderstaande figuur heeft aan hoe deze gegevens dienen gedeeld te worden:
Pagina 31 van 64
De data van een paal wordt naar de hoofdeigenaar van de paal gestuurd, Back-Office A. Deze BackOffice stuur daarna onmiddellijk alle registraties door naar Back-Office B. In Back-Office A wordt bijgehouden wie allemaal rechten heeft om gegevens te ontvangen. De technische bewaking wordt enkel opgevolgd door Back-Office A. Merk op dat er ook nog derde partijen bijvoorbeeld het Vlaamse Verkeerscentrum de gegevens van een paal versleuteld wil ontvangen. Dit wordt verder besproken en maakt geen deel uit van de BackOffice Standaard. 2.3.1.3 Kenmerken van de uitvoering 2.3.1.3.A.1
Voorstudie
Voor de onderdelen van de Back-Office Standard wordt één volledige voorstudie opgesteld waarbij alle onderdelen van de Back-Office Standard gelinkt worden met elkaar. De studie omvat verschillende overlegmomenten tussen opdrachtnemer, aanbestedende overheid en de eerste bestellende overheid waarbij een overzicht opgesteld wordt van de structuur van de Back-Office Standard, het operating system van de Back-Office. Het resultaat van deze voorstudie is een werkdocument die alle onderdelen van de Back-Office Standard bespreekt, inclusief functionaliteiten van alle onderdelen. In het werkdocument is het protocol uitgeschreven hoe de uitbreidingsmodules gegevens beheren, gebruik makende van de BackOffice Standard en bevat het werkdocument een bespreking van het dataprotocol tussen de FrontInstallation en de Back-Office en de verschillende Back-Offices onderling.
Pagina 32 van 64
2.3.1.3.A.2
Studie bewaking- en monitoringsoftware
Voor het ontwerp van de bewaking- en monitoringssoftware, en het alarmbeheer dient er in samenspraak met de aanbestedende overheid een studie gerealiseerd te worden voor onder andere het bepalen van: •
de beschikbare (technische) alarmen, het bepalen van de alarmfilter en het opdelen van de alarmen in dringendheid;
•
de verschillende communicatieprotocollen tussen apparatuur naar LPU, tussen LPU – Basis applicatieserver en tussen Basis Applicatieserver – centraal afstandsbewakingssysteem;
•
de inhoud en lay-out van de beelden beschikbaar op het bewaking- en monitoringssoftware van de basis applicatieserver;
2.3.1.3.A.3
Ontwikkeling
De gehele software wordt ontwikkeld op een plug-and-play principe. Er is een softwarebasis/platform die voor alle verschillende gebruikers dezelfde is en daarbovenop worden softwaremodules geïntegreerd. De verschillende bestellende overheden stellen zelf een pakket op van softwaremodules die zij wensen te bestellen. Er zijn standaard vijf softwaremodules voorzien in de Back-Office voor alle bestellende overheden: - black Lists; - DIV bevraging; - queries; - beide GIS interfaces. Er zijn softwaremodules die gelinkt zijn met elkaar. De ontwikkeling dient hiermee rekening te houden. Alle modules kunnen afzonderlijk besteld worden. De aanneming heeft geen recht de gekoppelde module aan te rekenen indien de bestellende overheid dit niet wenst. 2.3.1.3.A.4
Ontwikkeling softwarebasis (BASIS)
De ontwikkeling van softwarebasis dient te gebeuren volgens een scrum principe waarbij het gehele platform opgesplitst wordt in kleine onderdelen. Deze opbouw moet de aanbestedende overheid, de bestellende overheid en de opdrachtnemer toelaten makkelijk bij te sturen tijdens de ontwikkeling wanneer blijkt dat de opdrachtnemer niet het gewenst resultaat zal behalen of behaald heeft. In eerste fase van de ontwikkeling wordt een grafische dummy gemaakt van ieder softwarebasisonderdeel. De dummy heeft als doel alle functionaliteiten en relaties weer te geven, en een consensus te creëren over de te ontwikkelen softwarebasis. Na de eerste fase wordt een werkbestand gecreëerd waar minimaal volgende onderwerpen aan bod komen: - de grafische lay-out; - functionaliteiten; - gekozen oplossing; - met belangrijkste voor- en nadelen van deze oplossing; - grafisch overzicht van de datastromen; - een werkschema met een opdeling van de software ontwikkeling in sprints; - een wenselijke en werkelijke tijdslijn die een goed overzicht heeft van de vooruitgang en doelen. Het werkbestand krijgt een versienummer en wordt als levend bestand regelmatig geüpdate tijdens de ontwikkeling van de software met de stand van zaken, wijzigingen,…
Pagina 33 van 64
Na iedere sprint krijgt de software ook een aparte versienummer zodanig dat altijd kan teruggekeerd worden naar voorgaande versies. 2.3.1.3.A.5
Ontwikkeling softwaremodules (modules)
De ontwikkeling van softwaremodules dient te gebeuren volgens een scrum principe waarbij het elke softwaremodule opgesplitst wordt in kleine onderdelen. Deze opbouw moet de aanbestedende overheid, de bestellende overheid en de opdrachtnemer toelaten makkelijk bij te sturen tijdens de ontwikkeling wanneer blijkt dat de opdrachtnemer niet het gewenst resultaat zal behalen of behaald heeft. In eerste fase van de ontwikkeling wordt een grafische dummy gemaakt van ieder softwaremoduleonderdeel. De dummy heeft als doel alle functionaliteiten en relaties weer te geven, en een consensus te creëren over de te ontwikkelen softwaremodule. Na de eerste fase wordt een werkbestand gecreëerd waar minimaal volgende onderwerpen aan bod komen: - de grafische lay-out; - functionaliteiten; - gekozen oplossing; - met belangrijkste voor- en nadelen van deze oplossing; - grafisch overzicht van de datastromen; - een werkschema met een opdeling van de software ontwikkeling in sprints; - een wenselijke en werkelijke tijdslijn die een goed overzicht heeft van de vooruitgang en doelen. Het werkbestand krijgt een versienummer en wordt als levend bestand regelmatig geüpdate tijdens de ontwikkeling van de software met de stand van zaken, wijzigingen,… Een belangrijke leidraad in de ontwikkeling van de softwaremodules is grafische uniformiteit tussen de verschillende softwaremodules en gebruiksvriendelijkheid.
2.3.2
Back-Office Additions
2.3.2.1 Beschrijving Bovenop de basis applicatieserver worden verschillende modules gebouwd volgens plug-and-play. Onderstaand worden alle modules functioneel omschreven. De ontwikkeling van deze modules verloopt volgens “2.3.1.3.A.3 Ontwikkeling”. In onderstaande uitleg worden suggesties gegeven voor de effectieve uitvoering/lay-out. Deze suggesties zijn geen absolute voorwaarden maar eerder indicaties hoe de aanbestedende overheid de softwaremodules ziet. Ze worden onder andere ook meegegeven om een beter kader te schetsen van de gewenste functionaliteiten. Afhankelijk van de noden binnen de bestellende overheden zijn er in onderstaande modules een onderscheid gemaakt in type modules, met name modules met doel aan verkeershandhaving te doen, modules met als doel verkeerskundige gegevens te analyseren, modules met als doel offline data analyse uit te voeren en tot slot modules met betrekking tot het toepassen van typische listings. In de omschrijving van de modules wordt telkens verwezen naar een tabblad voor de creatie van trajecten. Aangewezen is dit te integreren in “2.3.2.2.I Verkeerskunde-Module GIS (STANDAARD)” en “2.3.2.2.O Offline data analyse-Module GIS (STANDAARD)”. In de omschrijving voor de beide GIS modules is een onderdeel opgenomen betreft het creëren van een interface voor het maken van trajecten. Ook alle tabbladen “grafisch overzicht” kunnen geïntegreerd worden in “2.3.2.2.I Verkeerskunde-Module GIS (STANDAARD)” en “2.3.2.2.O Offline data analyse-Module GIS (STANDAARD)”. Eventuele uitbreiding van de hardware data- en applicatieserver ten gevolge van de bestelling van een Back-Office modules maakt integraal deel uit van de posten van de Back-Office modules.
Pagina 34 van 64
2.3.2.1.A
VERKEERSHANDHAVING
De verkeershandhavingmodules, zijn de modules die gegevens analyseren om te bepalen of de weggebruiker zich houdt aan de verkeersregels. Aan deze modules zijn automatische handhavingsystemen gekoppeld voor het opstellen van PV’s. 2.3.2.1.B
VERKEERSKUNDEMODULES
De verkeerskundemodules, zijn de modules die via versleutelde gegevens analysedata aanleveren met het oog om een tool toe te reiken aan bestellende overheden opdat zij een gericht beleid kunnen voeren (aanleg parkings, ingebruikname spitsstrook, verlengen afritten, mobiliteitsbeleid, …) en waarbij zij realtime verkeersinformatie kunnen verstrekken. De Back-Office laat toe om reistijden in kaart te brengen, tellingen te verrichten, herkomst en bestemming na te gaan, de bezettingsgraad te bepalen en dat alles te exporteren in een GIS-toepassing (geolocatie). 2.3.2.1.C
OFFLINE DATA ANALYSE MODULES
De modules voor offline data-analyses omvat alle opzoekingen en analyses van data van het ANPR netwerk voor politionele doeleinden. Alle analyses die uitgevoerd worden gebeuren op de niet versleutelde gegevens. Enkele offline data analyse modules vertonen een gelijkheid met de verkeerskundemodules. Bij deze modules zullen de gegevens geconsulteerd worden van de database. Bij iedere consultatie (queries en politionele beeldvorming) dient een reden opgegeven te worden door de gebruiker waarom de opzoeking gedaan wordt. Alle opzoekingen en de gegevens van de gebruiker moeten in een afzonderlijke lijst bijgehouden worden en moeten voor onbepaalde tijd consulteerbaar zijn in een logboek van de opzoekingen. 2.3.2.1.D
LISTINGS
Onder listings worden alle modules ondergebracht die realtime data analyseren en daaruit automatisch meldingen genereren ter ondersteuning van het politiekorps. Een list is een lijst van een aantal nummerplaten, voertuigen, die niet volgens dezelfde voorwaarden behandelt worden door de Back-Office als de andere voertuigen. Een Black List is een lijst van nummerplaten van voertuigen die zich een bepaald recht ontnomen zijn, zoals toegang. Een White List is een lijst van nummerplaten van voertuigen die een privilege hebben ten opzichte van andere voertuigen zoals hulpdiensten die bepaalde dienstwegen wel mogen gebruiken. Alle white en black lists worden onderverdeeld in 3 types: •
lokale lijsten die enkel gebruikt worden door een politiekorps;
•
beperkt gedeelde lijsten die gebruikt worden door enkele politiekorpsen/Back-Offices;
•
universeel gedeelde lijsten die uitgewisseld worden tussen alle Back-offices.
- Lokale lijsten Dit zijn lijsten gecreëerd door het lokale politiekorps en enkel gebruikt op één Back-Office. - Beperkt gedeelde lijsten Dit zijn lijsten gecreëerd door en voor verschillende lokale politiekorpsen. Een voorbeeld is een gemeenschappelijke white list van alle ziekenwagens die opereren over een bepaalde regio die niet overeenstemt met één politiekorps maar over meerdere is uitgestrekt. De lijsten zijn updatebaar door de verschillende politiekorpsen. Wanneer een aanpassing gebeurt door één Back-Offices dient de List automatisch geüpdate te worden in de andere Back-Offices. Pagina 35 van 64
De politiezones kunnen hierbij opgedeeld worden in groepen en deze groepen kunnen gekoppeld worden aan beperkt gedeelde black lists. Enkele voorbeelden van groepen: •
alle politiezones/Back-Offices in een bepaalde provincie;
•
alle politiezones/Back-Offices langs een bepaalde snelweg;
•
alle politiezones die samen het beheer doen van bijvoorbeeld een haven.
- Universeel gedeelde lijsten Dit zijn lijsten meestal gegeneerd door externe partijen die voor alle politiezones gelden. Twee voorbeelden: 1. de door de federale politie aangeleverde Black List van alle gestolen voertuigen; 2. de veridas Black-list van alle niet verzekerde voertuigen. Deze lijsten dienen automatisch opgevraagd te worden bij de betrokken instanties en verdeeld te worden over de verschillende Back-Offices. De bevraging dient te gebeuren per Back-Office om de X minuten met X een instelbare tijd. Een onderdeel van de ontwikkeling van listing is het opzetten van een communicatie tussen de verschillende Back-Offices voor het delen van het tweede en derde type lijsten. Hoe dit juist moet gebeuren zal vastgelegd worden tijdens de ontwikkeling van de Back-Office. Er wordt geen afzonderlijke post voorzien voor deze ontwikkeling. Een laatste onderdeel is patronen, een module die op zoek gaat naar voertuigen die een vooraf gedefinieerd patroon volgen. De output van de module patronen is een lijst met voertuigen die voldoen aan het vooraf gedefinieerde patroon. Zowel Black lists als patronen zullen in vele gevallen leiden tot een interventie van het voertuig. In beide systemen moet kunnen ingesteld worden wat de graad van overtreding is. Aan deze graad worden acties gekoppeld, bijvoorbeeld het doorsturen van de gegevens van de overtreder naar alle gebruikers gedefinieerd in het systeem of naar alle Back-Offices lite op de PDA’s/smartphone van het politiekorps. De opbouw van graden en gekoppelde acties zullen tijdens het ontwerp van de BackOffice bepaald worden in samenspraak tussen de opdrachtnemer, aanbestedende overheid en eventueel verschillende bestellende overheden. Deze graden kunnen verschillend zijn tussen de verschillende Back-Offices onderling, en zijn bijgevolg parametreerbaar. Grafische weergave hits: voor de verschillende modules onder listing wordt geen afzonderlijke GIS ontwikkeling gedaan. Wanneer er een hit is moet de locatie op kaart getoond worden. De ontwikkeling van deze GIS wordt gezien als onderdeel van de ontwikkeling van de GIS onder offline data-analyse. 2.3.2.2 Kenmerken van de uitvoering 2.3.2.2.A 2.3.2.2.A.1
VERKEERSHANDHAVING-MODULE INHAALVERBOD (OVER EEN TRAJECT) Omschrijving
De module inhaalverbod dient om over een traject een verbod op inhalen te handhaven. Op twee verschillende punten van een traject wordt een ANPR captatie systeem voorzien. Het captatiesysteem registreert elke passant met onder andere zijn nummerplaat, tijdstempel en een overzichtsbeeld. Wanneer een bepaald voertuig A op een traject met inhaalverbod bij het eerste captatiepunt geregistreerd wordt met een tijdstempel > de tijdstempel van voertuig B en bij het tweede captatiepunt geregistreerd worden met een tijdstempel < de tijdstempel van voertuig B dan heeft voertuig A een inhaalbeweging gedaan op dat traject. Vooraf is een doorreistijd gedefinieerd (DTdoor) die een indicatie is voor de tijd dat een voertuig nodig heeft om rechtstreeks, zonder stoppen, van het ene naar het andere meetpunt te rijden. Deze doorreistijd is een constante die opgegeven kan worden door de bestellende overheid per traject. Enkel Pagina 36 van 64
de voertuigen die een snellere doorreistijd hebben dan DTdoor tussen de twee captatiepunten worden meegenomen in de verwerkingssoftware voor het bepalen van overtredingen dit zowel voor overtreders als voor ingehaalde voertuigen.
Figuur 2- Module inhaalverbod (traject) 2.3.2.2.A.2
Module
De module moet toepasbaar zijn voor zowel inhaalverbod van al het voertuigverkeer als een inhaalverbod voor enkel vrachtverkeer, bij dit tweede wordt de extra variabele voor de detectie van vrachtverkeer in rekening gebracht. De module maakt gebruik van het ANPR captatiesysteem, de overzichtscamera en in sommige gevallen de detectie van vrachtwagenverkeer. De module wordt opgedeeld in 3 verschillende onderdelen: 1. configuratie; 2. validatie; 3. processen-verbaal. Deze onderdelen worden telkens voorzien met een eigen tabblad. 2.3.2.2.A.3
Tabblad Configuratie
In dit tabblad is het mogelijk trajecten, elk met een unieke naam, te configureren waar inhaalverboden gelden. Er moet kunnen aangegeven worden welk twee captatiepunten met elkaar vergeleken worden en wat de doorreistijd (DTdoor) is over dit traject. De bestellende overheid moet ook over de mogelijkheid beschikken om aan te vinken als de gegevens moeten gefilterd worden zodat enkel vrachtwagenverkeer beboet kan worden. 2.3.2.2.A.4
Tabblad Validatie
In dit tabblad krijgt de gebruiker een overzicht van alle vaststellingen. De gebruiker zal hier altijd een manuele controle doen van de correctheid van de registratie. Hij krijgt een overzicht van de overtreder met de twee beelden van elke registratie, twee beelden van een ingehaald voertuig. Deze vier beelden
Pagina 37 van 64
worden voorzien van een tijdstempel, een foto van de nummerplaat en een mogelijkheid om manueel de geregistreerde nummerplaat aan te passen. Een bevestigingsknop om een overtreding te valideren en een knop om de overtreding af te wijzen. Wanneer een overtreding gevalideerd wordt, wordt er automatisch een PDF bestand opgesteld met daarop volgende gegevens: - Op de bovenste helft van het blad -
de gelezen nummerplaat van de overtreder aan het eerste captatiepunt;
-
bijhorende datum;
-
bijhorende tijdsgegevens (tot op de seconde);
-
locatie van het eerste captatiepunt;
-
overzichtsfoto van de overtreder aan het eerste captatiepunt;
-
overzichtsfoto van het ingehaalde voertuig aan het eerste captatiepunt;
-
bijhorende datum;
-
bijhorende tijdsgegevens (tot op de seconde).
- Op de onderste helft van het blad -
de gelezen nummerplaat van de overtreder aan het tweede captatiepunt;
-
bijhorende datum;
-
bijhorende tijdsgegevens (tot op de seconde);
-
locatie van het tweede captatiepunt;
-
overzichtsfoto van de overtreder aan het tweede captatiepunt;
-
overzichtsfoto van het ingehaalde voertuig aan het tweede captatiepunt;
-
bijhorende datum;
-
bijhorende tijdsgegevens (tot op de seconde).
2.3.2.2.A.5
Tabblad Processen-verbaal
In dit tabblad krijgt de gebruiker een overzicht van alle gevalideerde overtredingen per record voor de creatie van het PV. Van iedere record doet het systeem een automatische DIV bevraging voor het ophalen van de gegevens en stelt een volledig dossier samen. Via een knop kan de gebruiker dan dit dossier afdrukken. De PDF gegenereerd in de stap validatie wordt automatisch al bijlage gekoppeld aan de PV. 2.3.2.2.B 2.3.2.2.B.1
VERKEERSHANDHAVING-MODULE TRAJECTCONTROLE Omschrijving
De module trajectcontrole bewaakt een traject op gemiddelde snelheid van een voertuig. Op twee verschillende punten op een traject wordt een nummerplaat geregistreerd en door middel van de verschillende tijdstempels van de twee registraties wordt berekend welke snelheid een voertuig gereden heeft over het gekende traject. De exacte werking van dit systeem wordt voornamelijk bepaald door de behaalde modelgoedkeuring.
Pagina 38 van 64
Figuur 3 - Module trajectcontrole
2.3.2.2.B.2
Module
De module maakt gebruik van het ANPR captatiesysteem, overzichtscamera en eventueel andere apparatuur bepaald door de modelgoedkeuring. De module wordt opgedeeld in 3 verschillende onderdelen: 1. configuratie; 2. validatie; 3. processen-verbaal. Deze onderdelen worden telkens voorzien met een eigen tabblad. 2.3.2.2.B.3
Tabblad Configuratie
In dit tabblad is het mogelijk trajecten, elk met een unieke naam, te configureren waar trajectcontrole toegepast wordt. Er moet kunnen aangegeven worden welk twee captatiepunten met elkaar vergeleken worden en wat de gemiddelde snelheid is dat hier gereden mag worden. De configuratie wordt bepaald door de modelgoedkeuring. 2.3.2.2.B.4
Tabblad Validatie
In dit tabblad krijgt de gebruiker een overzicht van alle vaststellingen. De gebruiker zal in dit tabblad altijd een manuele controle doen van de correctheid van de registratie. Hij krijgt een overzicht van de overtreder met twee beelden van elke registratie. Deze twee beelden worden voorzien van een tijdstempel, een foto van de nummerplaat en een mogelijkheid om manueel de geregistreerde nummerplaat aan te passen. Een bevestigingsknop om een overtreding te valideren en een knop om de overtreding af te wijzen.
Pagina 39 van 64
Wanneer een overtreding gevalideerd wordt, wordt er automatisch een PDF bestand opgesteld met daarop volgende gegevens: - Op de bovenste helft van het blad -
de gelezen nummerplaat van de overtreder aan het eerste captatiepunt;
-
bijhorende datum;
-
bijhorende tijdsgegevens (tot op de seconde);
-
locatie van het eerste captatiepunt;
-
overzichtsfoto van de overtreder aan het eerste captatiepunt.
- Op de onderste helft van het blad -
de gelezen nummerplaat van de overtreder aan het tweede captatiepunt;
-
bijhorende datum;
-
bijhorende tijdsgegevens (tot op de seconde);
-
locatie van het tweede captatiepunt;
-
overzichtsfoto van de overtreder aan het tweede captatiepunt.
De lijst is indicatief en wordt mede nog bepaald door de modelgoedkeuring. 2.3.2.2.B.5
Tabblad Processen-verbaal
In dit tabblad krijgt de gebruiker een overzicht van alle gevalideerde overtredingen per record voor de creatie van het PV. Van iedere record doet het systeem een automatische DIV bevraging voor het ophalen van de gegevens en stelt een volledig dossier samen. Via een knop kan de gebruiker dit dossier afdrukken. De PDF gegenereerd in de stap validatie wordt automatisch als bijlage gekoppeld aan de PV. 2.3.2.2.C 2.3.2.2.C.1
VERKEERSHANDHAVING-MODULE SLUIKVERKEER/VRACHTWAGENSLUIS Omschrijving
De module sluikverkeer dient om over een traject een verbod op doorgaand verkeer te handhaven. Voornamelijk zal gecontroleerd worden of vrachtwagens die een stadcentrum doorkruisen dit doen om te laden en/of te lossen, dan wel om tijd te winnen. In het laatste geval wordt er gesproken van sluikverkeer en kan er geverbaliseerd worden. Alhoewel de module voornamelijk gebruikt zal worden voor vrachtwagenverkeer wordt ook sluikverkeer van personenvervoer in rekening gebracht. Op twee verschillende punten van een traject wordt een ANPR captatie systeem voorzien. Het captatiesysteem registreert elke passant met onder andere zijn nummerplaat, tijdstempel, een overzichtsbeeld en, in bepaalde gevallen, de detectie van vrachtwagenverkeer. Vooraf is een doorreistijd gedefinieerd (Tsluik) die een indicatie is voor de tijd dat een voertuig maximaal nodig heeft om rechtstreeks, zonder stoppen, van het ene naar het andere meetpunt te rijden. Indien de tijdstempel op captatiepunt 2 < de tijdstempel op captatiepunt 1 + Tsluik dan heeft de bestuurder geen stop gemaakt en wordt deze beschouwd als doorgaand verkeer, overtreder. Daarnaast wordt een periode gedefinieerd DTvar. Deze periode is de periode die extra aandacht verwacht. De voertuigen die een doorreistijd hebben kleiner dan Tsluik + DTvar maar groter dan Tsluik zijn vermoedelijke overtreders. Een kunnen beboet worden na een extra manuele controle van de bestellende overheid. In alle andere geval wordt de vrachtwagen beschouwd als bestemmingsverkeer Pagina 40 van 64
2.3.2.2.C.2
Module
De module maakt gebruik van het ANPR captatiesysteem, overzichtscamera en de apparatuur nodig voor detectie van vrachtwagenverkeer. De module wordt opgedeeld in 3 verschillende onderdelen: 1. configuratie; 2. validatie; 3. processen-verbaal. Deze onderdelen worden telkens voorzien met een eigen tabblad. 2.3.2.2.C.3
Tabblad Configuratie
In dit tabblad is het mogelijk trajecten, elk met een unieke naam, te configureren waar sluikverkeer toegepast wordt. Er moet kunnen aangegeven worden welk twee captatiepunten met elkaar vergeleken worden en wat de doorreistijd (Tsluik) is welke de grens van bestemmingsverkeer en doorgaand verkeer bepaald en wat de variatieperiode DTvar is voor het bepalen van de vermoedelijke overtreders. De bestellende overheid moet ook over de mogelijkheid beschikken om aan te vinken als de gegevens moeten gefilterd worden zodat enkel vrachtwagenverkeer beboet kan worden, een vrachtwagensluis. 2.3.2.2.C.4
Tabblad Validatie
In dit tabblad krijgt de gebruiker een overzicht van alle vaststellingen. De gebruiker zal hier een manuele controle doen van de correctheid van de registratie. Hij krijgt een overzicht van de overtreder met twee beelden van elke registratie. Deze twee beelden worden voorzien van een tijdstempel, een foto van de nummerplaat en een mogelijkheid om manueel de geregistreerde nummerplaat aan te passen. Een bevestigingsknop om een overtreding te valideren en een knop om de overtreding af te wijzen. Er wordt aangegeven het een overtreder is of een vermoedelijke overtreder. Wanneer een overtreding gevalideerd wordt, wordt er automatisch een PDF bestand opgesteld met daarop volgende gegevens: - Op de bovenste helft van het blad -
de gelezen nummerplaat van de overtreder aan het eerste captatiepunt;
-
bijhorende datum;
-
bijhorende tijdsgegevens (tot op de seconde);
-
locatie van het eerste captatiepunt;
-
overzichtsfoto van de overtreder aan het eerste captatiepunt.
- Op de onderste helft van het blad -
de gelezen nummerplaat van de overtreder aan het tweede captatiepunt;
-
bijhorende de datum;
-
bijhorende tijdsgegevens (tot op de seconde);
-
locatie van het tweede captatiepunt;
-
overzichtsfoto van de overtreder aan het tweede captatiepunt.
2.3.2.2.C.5
Tabblad Processen-verbaal
In dit tabblad krijgt de gebruiker een overzicht van alle gevalideerde overtredingen per record voor de creatie van het PV. Van iedere record doet het systeem een automatische DIV bevraging voor het ophalen van de gegevens en stelt een volledig dossier samen. Via een knop kan de gebruiker dit Pagina 41 van 64
dossier afdrukken. De PDF gegenereerd in de stap validatie wordt automatisch als bijlage gekoppeld aan de PV. 2.3.2.2.D 2.3.2.2.D.1
VERKEERSHANDHAVING-MODULE TOEGANGSCONTROLE Omschrijving
De module toegangscontrole dient om plaatselijk verkeer te handhaven. Toegangscontrole zal ingezet worden op trajecten waar bijvoorbeeld enkel openbaar vervoer is toegelaten, hulpdiensten of andere nutstoepassingen maar waar geen gewoon personenvervoer is toegelaten. Ook voetgangerszones kunnen hiermee gecontroleerd worden, verbod op vrachtwagenverkeer, enz. Toegangscontrole is een vorm van white-lists maar dan met bijhorende koppeling aan de DIV database. Op een punt wordt een ANPR captatie systeem met overzichtscamera voorzien. Het captatiesysteem registreert elke passant met onder andere zijn nummerplaat, tijdstempel, een overzichtsbeeld en, in bepaalde gevallen, de detectie van vrachtwagenverkeer. De gegevens worden doorgegeven aan de Back-Office die de gegevens aan verschillende voorwaarden onderwerpt. Registraties die niet voldoen aan de voorwaarden worden gecatalogeerd onder overtreders. Onder deze module dient ook een ontwikkeling te gebeuren om de rijrichting van het voertuig te achterhalen. De rijrichting van een voertuig kan gebruikt worden om toegangscontrole te doen op eenrichtingswegen of lokaal een inhaalverbod te controleren.
Pagina 42 van 64
Figuur 4 - Module toegangscontrole 2.3.2.2.D.2
Module
De module maakt gebruik van het ANPR captatiesysteem, overzichtscamera en de in sommige gevallen de apparatuur nodig voor detectie van vrachtwagenverkeer. De module wordt opgedeeld in 3 verschillende onderdelen: 1. configuratie; 2. validatie; 3. processen-verbaal. Deze onderdelen worden telkens voorzien met een eigen tabblad. 2.3.2.2.D.3
Tabblad Configuratie
In dit tabblad worden de verschillende toegangspunten gedefinieerde, elk met een unieke naam. Er moet kunnen aangegeven worden waar geen verkeer is toegelaten en er kan een white-list worden aan toegekend. Deze toekenning kan dynamisch in de tijd zijn, en dit ook eveneens op basis van een kalender. Deze white-list wordt gecreëerd volgens de modaliteiten in onderstaande artikel “2.3.2.2.P Listing module-White List”. De bestellende overheid moet ook over de mogelijkheid beschikken om te filteren op vrachtwagenverkeer zodat vrachtwagenverkeer beboet kan worden. Het gebruik van de white list is hier niet noodzakelijk. Of omgekeerd deze toepassing moet ook gefilterd worden op personenverkeer. Dit kan bijvoorbeeld
Pagina 43 van 64
gebruikt worden voor de het controleren van busbanen waarbij de nummerplaten van de bussen niet gekend zijn. 2.3.2.2.D.4
Tabblad Validatie
In dit tabblad krijgt de gebruiker een overzicht van alle vaststellingen. De gebruiker zal hier een manuele controle doen van de correctheid van elke registratie. Hij krijgt een overzicht van de overtreder met een overzichtsbeelden van de registratie. Het beeld wordt voorzien van een tijdstempel, een foto van de nummerplaat en een mogelijkheid om manueel de geregistreerde nummerplaat aan te passen. Een bevestigingsknop om een overtreding te valideren en een knop om de overtreding af te wijzen. Wanneer een overtreding gevalideerd wordt, wordt er automatisch een PDF bestand opgesteld met daarop volgende gegevens: -
de gelezen nummerplaat van de overtreder aan het eerste captatiepunt;
-
bijhorende datum;
-
bijhorende tijdsgegevens (tot op de seconde);
-
locatie van het captatiepunt;
-
overzichtsfoto van de overtreder aan het captatiepunt.
2.3.2.2.D.5
Tabblad Processen-verbaal
In dit tabblad krijgt de gebruiker een overzicht van alle gevalideerde overtredingen per record voor de creatie van het PV. Van iedere record doet het systeem een automatische DIV bevraging voor het ophalen van de gegevens en stelt een volledig dossier samen. Via een knop kan de gebruiker dit dossier afdrukken. De PDF gegenereerd in de stap validatie wordt automatisch als bijlage gekoppeld aan de PV. 2.3.2.2.E
VERKEERSKUNDE-MODULE VERSLEUTELING GEGEVENS
2.3.2.2.E.1
Omschrijving
Belangrijk is aan te stippen dat de gegevens onomkeerbaar versleuteld worden alvorens ze worden verstuurd naar de verkeerkundige verwerkingsmodules. Op die manier worden geen traceerbare gegevens, maar louter statistische data gegenereerd. Deze gegevens hebben geen politionele finaliteiten. Om dit te realiseren wordt een onderliggende module gebouwd waar de bovenliggende modules, onder andere. reistijden, bezetting, enz. gebruik van maken. De Back-Office dient een tweede (virtuele) dataserver op te bouwen waar de verschillende registraties van alle Front-Installations aanwezig op de basis dataserver gedupliceerd worden en versleuteld bewaard worden. De verkeerskunde-modules kunnen deze gegevens ophalen. Daarnaast kunnen de gegevens ook opgevraagd worden door derde partijen bijvoorbeeld het Vlaamse Verkeerscentrum. Van elke registratie dienen minimaal volgende gegevens versleuteld bewaard te worden: - tijdstempel; - nummerplaat; - nationaliteit; - betrouwbaarheidspercentage van de gehele nummerplaat; - betrouwbaarheidspercentage van de nationaliteitsbepaling; - (indien beschikbaar) de detectie van vrachtwagenverkeer; - een unieke ID die aangeeft welk ANPR captatiesysteem de registratie gedaan heeft.
Pagina 44 van 64
Alle data zoals overzichtsfoto’s enz. worden niet versleuteld en zijn niet beschikbaar voor verkeerskundige analyse. De versleutelde gegevens dienen voor alle camera’s dezelfde te zijn zodat het mogelijk wordt om op anonieme wijze voertuigen te volgen over het wegennet. 2.3.2.2.E.2
Module
De module draait op de achtergrond van elke Back-Office voor elke entiteit. Er worden een eenmalig post voorzien voor de ontwikkeling van deze module. De functionaliteiten van de module is tweezijdige. 1. de module zorgt voor een automatische versleutelde duplicaat van elke registratie van alle camera en stelt deze gegevens ter beschikking; 2. een werkbestand wordt opgesteld waarin bepaald wordt hoe andere modules versleutelde gegevens opvragen en ook waar aangegeven wordt hoe 3de externe partijen de versleutelde gegevens kunnen opvragen, hoe ze zich kunnen abonneren op registraties van een bepaalde paal. Het moet mogelijk zijn aan te vinken dat enkel de 100% betrouwbare registraties worden doorgestuurd5. De data die deze module genereert moet bewaard worden voor langere tijd, langer dan 30 dagen tot maximaal 2 jaar. 2.3.2.2.E.3
Datastructuur
Voor het bewaren van versleutelde gegevens wordt door de aanbestedende overheid een datastructuur opgelegd zodat minimaal het Vlaamse Verkeerscentrum onmiddellijk aan de slag kan met de versleutelde gegevens. In artikel “2.5.2Datastructuur versleutelde gegevens” is het dataformaat omschreven die momenteel gebruikt wordt bij het Vlaamse Verkeerscentrum, deze datastructuur dient gevolgd te worden. Hoe de gegevens moeten gecodeerd worden is niet opgelegd en dient ontwikkeld te worden in deze aanneming. 2.3.2.2.F 2.3.2.2.F.1
VERKEERSKUNDE-MODULE REISTIJDEN Omschrijving
De module reistijden dient om over een traject de gemiddelde reistijd te bepalen van de voertuigen. Op twee verschillende punten van een traject waar een ANPR captatie systeem voorzien is wordt de gemiddelde tijdsduur bepaald dat een voertuig nodig heeft om de afstand tussen de twee locaties te overbruggen. Het captatiesysteem registreert elke passant met onder andere zijn nummerplaat en tijdstempel. Wanneer een voertuig twee captatie systemen voorbij rijdt, is het mogelijk te bepalen hoe lang hij hierover gedaan heeft, de individuele reistijd DTr ind. Van de verschillende individuele reistijden worden data gecreëerd over een gemiddelde tijd van alle passanten, er worden minuutdata gecreëerd: DTr min, uurdata DTr uur en dagdata DTr dag. Merk op dat er voor de reistijden een richtingsafhankelijkheid is. Een traject kan twee verschillende reistijden berekenen. De reistijden zullen zowel gebruikt worden voor real time toepassingen (dynamisch verkeersbeheer en verkeersinformatie) maar ook voor offline analyse voor het bepalen van onder andere structurele maatregelen enz. 2.3.2.2.F.2
Module
5
100% is een relatief begrip en afhankelijk van de definitie van elke ANPR leverancier. Met 100% worden alle registraties bedoeld die correct zijn.
Pagina 45 van 64
De module maakt gebruik van het ANPR captatiesysteem. De module wordt opgedeeld in 3 verschillende onderdelen: 1. configuratie; 2. tekstueel overzicht; 3. grafisch overzicht. 2.3.2.2.F.3
Tabblad Configuratie
In dit tabblad worden de verschillende trajecten gedefinieerd, elk met een unieke naam. Voor elk traject worden een rijrichting meegegeven. Bij elk traject kan aangegeven worden wat de normale reistijd is over een traject. 2.3.2.2.F.4
Tabblad Tekstueel overzicht
In dit tabblad wordt een overzicht gegeven in tabelvorm van alle gedefinieerde trajecten. Per traject wordt er een overzicht gegeven van de individuele reistijd en de minuutdata. De data die getoond wordt, is via filters selecteerbaar: •
op trajecten;
•
tijdsinterval waarover de gegevens bekeken worden;
•
verschillende tijdsdata (minuut, uur, dag)?
De gegevens van deze module moeten importeerbaar en exporteerbaar zijn naar een csv bestand. Dit csv bestand kan waar mogelijk ook in andere modules worden ingeladen. Het importeren en exporteren moet mogelijk zijn via twee knoppen die telkens op dezelfde plaats voorkomen in iedere module. 2.3.2.2.F.5
Tabblad Grafisch overzicht
In dit tabblad wordt een grafisch overzicht gegeven van de verschillende gedefinieerde trajecten met bijhorende een overzicht van de laatste minuutdata in tekstvorm. De lay-out van dit grafisch overzicht zal in overleg met de aanbestedende overheid en een eerste bestellende overheid bepaald worden tijdens de ontwikkeling van deze module. Om echter een idee te krijgen van een mogelijke invulling wordt verwezen naar het grafische overzicht op www.verkeerscentrum.be , bijvoorbeeld: http://www.verkeerscentrum.be/verkeersinfo/reistijden/buitenring . Standaard worden 3 grafische overzichten per bestelde module Reistijden voorzien. Extra grafische overzichten worden besteld via software uur prestaties. In het grafische overzicht is een makkelijke selectiemogelijkheid voorzien om snel te kunnen wisselen tussen de verschillende ontwikkelde grafische overzichten. 2.3.2.2.G 2.3.2.2.G.1
VERKEERSKUNDE-MODULE TELLINGEN Omschrijving
De module tellingen dient om per locatie een overzicht te verkrijgen van het verkeer en de verkeersintensiteit en dit zowel ogenblikkelijk als over een periode in de tijd (minuutbasis, uurbasis, dagbasis) per ANPR captatiesysteem. Het captatiesysteem registreert elke passant met onder andere zijn nummerplaat, tijdstempel en (optioneel) de detectie van vrachtwagenverkeer. Wanneer een voertuig een captatie systeem langs rijdt, wordt dit voertuig geregistreerd wanneer hij dit gedaan heeft en of het een vrachtwagen is of niet (optioneel). Via deze gegevens kan de BackOffice verschillende statistieken genereren per gecontroleerde rijstrook. 2.3.2.2.G.2
Module
Pagina 46 van 64
De module maakt gebruik van het ANPR captatie systeem en (optioneel) van de detectie van vrachtwagenverkeer. De module bestaat uit een tekstueel overzicht in tabelvorm per rijstrook van volgende gegevens: •
aantal passanten op: o
minuutbasis;
o
5 minuutbasis;
o
uurbasis;
o
dagbasis;
•
bezettingsgraad;
•
tussentijd van de individuele doortochten met bijhorende schatting van de tussenafstand;
•
aandeel vrachtwagenverkeer.
Om de bezettingsgraad te bepalen wordt een schatting gemaakt door middel van de data op minuutbasis ten opzichte van de maximale bezettinggraad gekenmerkt door het type weg waar het ANPR captatie systeem geplaatst is. Om dit te doen zal vooraf in samenspraak met de aanbestedende overheid een tabel opgesteld worden waarbij verschillende wegcategorieën gedefinieerd worden met elk hun eigen maximale bezettingsgraad. Iedere ANPR captatie systeem dient dan ondergebracht te worden in één van de vooraf gedefinieerde categorieën. De data die getoond wordt, is via filters selecteerbaar: •
per Front-Installation;
•
tijdsinterval waarover de gegevens bekeken worden;
•
verschillende tijdsdata (minuut, uur, dag).
De gegevens van deze module moeten importeerbaar en exporteerbaar zijn naar een csv bestand. Dit csv bestand kan waar mogelijk ook in andere modules worden ingeladen. Het importeren en exporteren moet mogelijk zijn via twee knoppen die telkens op dezelfde plaats voorkomen in iedere module. 2.3.2.2.H 2.3.2.2.H.1
VERKEERSKUNDE-MODULE HERKOMST/BESTEMMING Omschrijving
De module herkomst/bestemming dient een overzicht te verkrijgen van de verkeerspatronen. Het captatiesysteem registreert elke passant met onder andere zijn nummerplaat, tijdstempel en (optioneel) de detectie van vrachtwagenverkeer. Wanneer een voertuig een captatiesysteem langs rijdt wordt geregistreerd wanneer hij dit gedaan heeft en of het een vrachtwagen is of niet (optioneel). Via deze gegevens kan de Back-Office statistieken genereren die de individuele registraties over de verschillende ANPR captatie systemen met elkaar linkt. Via deze module kan er in kaart gebracht worden of de hoofdwegen van een stad voornamelijk gebruikt worden voor doorgaand verkeer of voor lokaal verkeer. 2.3.2.2.H.2
Module
De module maakt gebruik van het ANPR captatiesysteem en (optioneel) van de detectie van vrachtwagenverkeer. De module wordt voornamelijk gebruikt voor de generatie van rapporten over het verkeer. De module wordt opgedeeld in 3 verschillende onderdelen: 1. configuratie opzoekingvoorwaarden;
Pagina 47 van 64
2. tekstueel overzicht; 3. grafisch overzicht. 2.3.2.2.H.3
Tabblad Configuratie opzoekingvoorwaarden
In dit tabblad worden de voorwaarden gedefinieerd hoe de herkomst/bestemming gegevens onderzocht worden, ieder analyse van het herkomst/bestemmingverkeer kan uniek zijn. De gebruiker kan aangeven welke camera’s hij wil meenemen in de analyse, kan aangeven of hij personenverkeer en/of vrachtwagenverkeer wil bekijken, kan de periode opgeven waarover hij wil kijken, de rijrichting die hij wil meenemen in de resultaten, enz. Enkele voorbeelden ter illustratie: - in kaart brengen van vrachtwagenverkeer rond een stad tijdens de ochtendspitst (lokaal/doorgaand verkeer); - het in kaart brengen van het gehele verkeerspatroon na een ongeval op een belangrijk kruispunt van de stad; - bestemmingverkeer van voertuigen die één bepaald punt voorbij rijden. 2.3.2.2.H.4
Tabblad Tekstueel overzicht
In dit tabblad wordt een overzicht gegeven in tabelvorm van alle data gegenereerd volgens de configuratie opzoekingvoorwaarden. De data die getoond wordt, is via filters selecteerbaar. 2.3.2.2.H.5
Tabblad Grafisch overzicht
In dit tabblad wordt een grafisch overzicht gegeven van alle data, gegenereerd volgens de configuratie opzoekingvoorwaarden. Het is belangrijk dat de veranderdingen in de tijd duidelijk zijn, in de grafisch patronen moet getoond worden vanwaar naar waar voertuigen zich bewegen. Hierbij speelt de tijdsstempel een belangrijke rol. De gegevens van deze module moeten importeerbaar en exporteerbaar zijn naar een csv bestand. Dit csv bestand kan waar mogelijk ook in andere modules worden ingeladen. Het importeren en exporteren moet mogelijk zijn via twee knoppen die telkens op dezelfde plaats voorkomen in iedere module. 2.3.2.2.I 2.3.2.2.I.1
VERKEERSKUNDE-MODULE GIS (STANDAARD) Omschrijving
Om een aangename werking te garanderen naar de gebruiker toe wordt een geografisch informatiesysteem (GIS) geïntegreerd in de Back-Office. De GIS zorgt voor een grafische voorstelling van de verschillende captatie systemen op een (dynamische) kaart en toont de verkeerskundige analyse van de andere modules. De GIS moet opgebouwd zijn uit verschillende lagen van de verschillende modules die afzonderlijk selecteerbaar zijn. De GIS dient onder andere volgende functionaliteiten te bezitten. •
toevoegen van nieuw ANPR captatie systeem met bijhorende uitbreidingen;
•
creëren van trajecten tussen verschillende ANPR captatie systemen;
•
overzicht op kaart van de verschillende events.
•
dynamische interface tussen de verschillende grafische overzichten van de verschillende modules;
•
mogelijk zijn om een aantal Front-Installation te selecteren waarop de analyses van de modules op gebeurt.
De grafische interface is gelijkaardig als producten zoals mappoint, targetmap. De gegevens van deze module moeten importeerbaar en exporteerbaar zijn naar een csv bestand. Dit
Pagina 48 van 64
csv bestand kan waar mogelijk ook in andere modules worden ingeladen. Het importeren en exporteren moet mogelijk zijn via twee knoppen die telkens op dezelfde plaats voorkomen in iedere module. 2.3.2.2.I.2
Studie
Voor de ontwikkeling van de GIS voor verkeerkundige analyse wordt een afzonderlijke post voorzien voor diepgaande studie ivm de GIS. De GIS wordt de toegangpoort tot de Back-Office voor de gemiddelde gebruiker. In de studie wordt in samenspraak met minimaal de aanbestedende overheid de opbouw vastgelegd en alle functionaliteiten. 2.3.2.2.J
OFFLINE DATA ANALYSE-MODULE QUERIES (STANDAARD)
2.3.2.2.J.1
Omschrijving
Een belangrijke tool voor opzoekingen van politionele aard is een goede zoekmodule. Via de module queries bouwt de gebruiker verschillende vragen op die aan de gehele database gesteld worden. Dit moet mogelijk zijn op gebruiksvriendelijke manier. Volgende data moet kunnen gebruikt worden door de queries: - nummerplaat(en); - land(en); - locatie(s); - trajecten; - tijdstip en periode; - rijrichting; - vrachtwagen; - kleur (zie module kleuranalyse). De queries dienen opgebouwd te worden uit verschillende logische functies (EN, OF, NEN, NOF, XOR, …). Belangrijk is dat de gebruiker een makkelijk opgebouwde module krijgt waarbij hij zonder veel inspanningen ingewikkelde queries kan vragen aan de database zonder dat hij zelf over diepgaande kennis te beschikken van logische functies. Enkele voorbeelden ter illustratie van opzoekingen: - alle voertuigen met Franse nummerplaat die tussen 12u en 17u via captatiepunt X de stad zijn binnengereden; - alle voertuigen met nummerplaat startend met RSW die een blauwe of groene kleur hebben; - alle Vrachtwagens met nummerplaat 1-ZR?-??? die tussen 12u en 13u een bepaald captatiepunt voorbij gereden zijn (de vraagtekens zijn wildcards). In deze voorbeelden moet ook aangevinkt kunnen worden dat hij ook moet filteren op gelijkaardige kenmerken vb. 0, O en Q. Gebouwde queries moeten kunnen bewaard worden en later terug opgeroepen worden en queries moeten kunnen gedeeld worden met andere Back-Offices. 2.3.2.2.J.2
Module
De module wordt opgedeeld in 3 verschillende onderdelen: 1. opbouwmodule van queries; 2. tekstueel overzicht van alle registraties die voldoen aan de query in tabelvorm;
Pagina 49 van 64
3. een record overzicht per registratie die voldoet aan de query waarbij de beelden van de overzichtcamera en de nummerplaat getoond wordt. 2.3.2.2.J.3
Tabblad Opbouwmodule van queries
In dit tabblad bouwt de gebruiker de queries gebruik makende van verschillende logische functies toegepast op de data van alle registratie. De lay-out en mogelijkheden van deze pagina worden vastgelegd bij ontwikkeling van de module in samenspraak tussen opdrachtnemer, aanbestedende overheid en eventueel bestellende overheden. 2.3.2.2.J.4
Tekstueel overzicht
Dit is het tabblad die een overzicht heeft van een uitgevoerde querie in tabelvorm. De gegenereerde tabel moet zelf nog kunnen gesorteerd worden per kolom (vb. oplopend, op nummerplaat, op locatie, rijrichting,…). De gegevens van deze module moeten importeerbaar en exporteerbaar zijn naar een csv bestand. Dit csv bestand kan waar mogelijk ook in andere modules worden ingeladen. Het importeren en exporteren moet mogelijk zijn via twee knoppen die telkens op dezelfde plaats voorkomen in iedere module. 2.3.2.2.J.5
Tabblad Overzicht per record
Dit is een tabblad die een overzicht heeft van een uitgevoerde query per record afzonderlijk. In het tabblad kan er makkelijk veranderd worden naar de opeenvolgende records. De module queries wordt enkel gebruikt om opzoekingen te doen en niet voor wijzigingen aan te brengen aan de database. Vanuit de module queries moet automatisch de module DIV bevraging kunnen opgestart worden om de gegevens die horen bij een nummerplaat op te halen. Deze module wordt verder in de opdrachtdocumenten besproken onder artikel “2.3.2.2.LOffline Data analyseModule DIV bevraging”. 2.3.2.2.K 2.3.2.2.K.1
OFFLINE DATA ANALYSE-MODULE KLEURANALYSE Omschrijving
Een extra tool voor opzoekingen van politionele aard is een analyse van de registraties op kleur van het voertuig. Via deze module wordt voor iedere registratie een beeldanalyse uitgevoerd op het overzichtbeeld zodat het hoofdkleur van een voertuig achterhaald wordt. Deze kleuranalyse wordt gekoppeld aan de gegevens van de registratie. In totaal wordt het totale kleurenspectrum opgedeeld worden in 13 delen: - bruin; - rood; - orange; - geel; - groen; - cyaan; - blauw; - indigo; - violet; - magenta; - wit;
Pagina 50 van 64
- grijs; - zwart. Iedere registratie dient gecatalogeerd te worden onder één van deze kleuren. 2.3.2.2.K.2
Module
De module is een optie die de verschillende bestellende overheden kunnen laten activeren. Er is geen gebruikersinterface voor de module. De gegevens worden aan elke registratie gekoppeld. 2.3.2.2.L 2.3.2.2.L.1
OFFLINE DATA ANALYSE-MODULE DIV BEVRAGING (STANDAARD) Omschrijving
De module DIV bevraging is een module die gegevens ophaalt vanuit de DIV database, horende bij een bepaalde nummerplaat. DIV staat voor dienst voor inschrijving van voertuigen en de dienst heeft een overzicht van gegevens zoals onder andere de nummerplaat, kenmerken van een voertuig en de eigenaar van het voertuig. Het ophalen van deze gegevens is een essentieel onderdeel voor het uitvoeren van interventies. Deze module zorgt dat de gegevens die aan een nummerplaat gekoppeld zijn, opgehaald worden zodat ze bij de politiezone beschikbaar zijn. Deze gegevens kunnen dan gebruikt worden voor onder andere de creatie van PV’s, te koppelen aan een query/opzoeking, aan patronen. 2.3.2.2.L.2
Module
De module bestaat uit twee onderdelen: een deel dat zichtbaar is voor de gebruiker en een deel dat onzichtbaar is, waar andere modules van gebruik maken om gegevens op te halen. Het zichtbaar deel bestaat uit een tabblad waar de gebruiker een nummerplaat kan ingeven en de gegevens laten ophalen bij DIV. In de Back-Office moet ook een snelkoppeling voorzien worden zodat makkelijk een DIV opzoeking kan gebeuren van een geselecteerde nummerplaat/record in de verschillende tabbellen van de andere modules. 2.3.2.2.M OFFLINE DATA ANALYSE-MODULE POLITIONELE BEELDVORMING 2.3.2.2.M.1
Omschrijving
De module politionele beeldvorming is de politionele uitbreiding van de herkomst/bestemming module beschreven in artikel “2.3.2.2.HVerkeerskunde-Module herkomst/bestemming”. De module bekijkt de patronen van het voertuigverkeer maar dan gericht op politionele doeleinden. In plaats van naar gehele verkeerstromen te kijken zal er meer naar individuele voertuigen gekeken worden. Enkele algemene voorbeelden om de functionaliteit van deze module te schetsen: - verkeerspatroon verdachten drugstrafiek in kaart brengen; - voertuigen in kaart brengen die in een bepaalde periode een gebied bezocht hebben; - voertuigen in kaart brengen die na bepaalde gebeurtenissen de regio verlaten hebben. Enkele concrete voorbeelden ter illustratie van een opzoekingen: - alle voertuigen met Franse nummerplaat die tussen 12u en 17u via captatiepunt X het stad zijn binnengereden en die na 17u het stad terug verlaten hebben via captatiepunt Y; - alle voertuigen met nummerplaat startend met RSW die een blauwe of groene kleur hebben; - alle Vrachtwagens met nummerplaat 1-ZR?-??? die tussen 12u en 13u een bepaald captatiepunt voorbij gereden zijn in beide rijrichtingen.
Pagina 51 van 64
De module wordt voornamelijk gebruikt voor het achterhalen van criminele feiten. Deze module maakt gebruik van twee andere modules om zijn gegevens voorstelling op te bouwen: module queries en module GIS. De gebruiker bouwt een query op dewelke de database analyseert. Deze gegevens kan hij in de module politionele beeldvorming bewaren en kan hij via de module GIS op kaart laten tonen. Op deze manier kan de gebruiker zich een beeld van bepaalde vragen die hij aan het systeem vraag. Ten opzichte van de module queries dient de module politionele beeldvorming verschillende queries met elkaar te kunnen vergelijken en gemeenschappelijke gegevens aan te duiden. Vb. Een query die alle wagens vergelijkt die op punt X rond 13u het stad zijn binnengereden, ten opzichte van de wagen die een uur later de stad terug verlaten hebben via punt Y en dit getoond op kaart. Alle resultaten van de politionele beeldvorming moeten exporteerbaar zijn naar een csv bestand en moeten in de toekomst terug opgeroepen kunnen worden om te hergebruiken. 2.3.2.2.M.2
Module
De module bestaat uit drie onderdelen: een deel waar de queries kunnen gecreëerd worden (de queries moeten afzonderlijk opgeslaan kunnen worden zodat ze snel terug kunnen opgeroepen worden in de toekomst), een deel waar geselecteerd wordt welke verschillende queries met elkaar vergeleken worden en waar de resultaten getoond worden. Een derde deel dat de gegevens toont op kaart in een GIS. 2.3.2.2.N 2.3.2.2.N.1
OFFLINE DATA ANALYSE-MODULE NAZICHT CAMERABEWAKING Omschrijving
De module nazicht camerabewaking heeft een interface waarbij de camerabeelden van de beschikbare bewakingscamera’s kunnen gestreamd worden en waar historische beelden kunnen opgevraagd worden. De HD camera’s dienen ook opgenomen worden in dit tabblad. 2.3.2.2.N.2
Module
De module bestaat uit drie verschillende tabbladen: 1. tabblad met een screen capture van de verschillende camera’s. Bij het oproepen van dit tabblad wordt bij elke camera een screen capture opgevraagd van de huidige situatie. Al deze screen capture worden dan getoond op het overzicht op het moment dat ze volledig gedownload zijn naar de Back-Office. Op het tabblad is een refresh knop voorzien om op elk later moment de laatste screen capture op te halen. Wanneer een screen capture aangeklikt wordt, wordt een tweede tabblad geopend met een livestream van de locatie; 2. tabblad met een livestream van één locatie. Via de screencapture wordt overgegaan naar livesteam camerabeelden. Merk op dat er meerdere livestreams op verschillende tabbladen als floating tabs naast elkaar moeten kunnen getoond worden. Het openen van een tweede livestream vanuit een screencap opent een nieuwe floating tab; 3. tabblad met een historische beelden van één locatie. Merk op dat op verschillende tabbladen moeten kunnen naast elkaar gemonitord worden als floating tabs; In deze module moet een periode kunnen geselecteerd worden via een tijdlijn waarvoor de beelden opgehaald worden. De beelden die op dat moment open staan op de verschillende floating tabs moeten dan synchroon afgespeeld worden. Er wordt ook een knop voorzien om beelden van een bepaalde periode weg te schrijven naar een database waar de beelden voor een onbepaalde periode kunnen bewaard worden. In de tijdslijn kunnen ook events toegevoegd worden. 2.3.2.2.O
OFFLINE DATA ANALYSE-MODULE GIS (STANDAARD)
Pagina 52 van 64
2.3.2.2.O.1
Omschrijving
De GIS voor offline data-analyse is een grafische voorstelling van de verschillende modules onder offline data-analyse. Deze GIS is gelijkvormig opgebouwd zoals “2.3.2.2.IVerkeerskunde-Module GIS (STANDAARD) “. Er wordt ook gebruik gemaakt van een interface gelijkaardig aan de producten mappoint of targetmap. De belangrijkste reden van de opsplitsing is het verschil in gebruik. Deze GIS wordt onder andere gebruikt voor de analyse van gegevens die niet versleuteld zijn terwijl de gegevens van de verkeerskundige analyse via versleutelde gegevens voornamelijk gebruik maakt van historische gegevens. In het eerste geval zal er veel dynamischer omgegaan worden met de gegevens. De vragen die gesteld worden aan de Back-Office kunnen voor elke opzoeking anders zijn. Bij de verkeerskundige analyse zullen veel meer telkens dezelfde vragen gesteld worden. De twee GIS interfaces zullen daarom afzonderlijk ontwikkeld worden. De belangrijkste functie van deze GIS is het grafisch weergeven van uitgevoerde queries zoals besproken onder politionele beeldvorming. De gegevens van deze module moeten importeerbaar en exporteerbaar zijn naar een csv bestand. Dit csv bestand kan waar mogelijk ook in andere modules worden ingeladen. Het importeren en exporteren moet mogelijk zijn via twee knoppen die telkens op dezelfde plaats voorkomen in iedere module. Belangrijk onderdeel van deze csv bestanden is de locatie van een ANPR captatie systeem en ook de trajecten. Deze GIS staat in voor de offline data-analyse maar staat ook in voor de GIS van alle modules onder artikel “2.3.2.1.DListings”. 2.3.2.2.O.2
Studie
Voor de ontwikkeling van de GIS voor Offline data-analyse en de GIS voor listing wordt een afzonderlijke post voorzien voor diepgaande studie ivm de GIS. De GIS wordt de toegangpoort tot de Back-Office voor de gemiddelde gebruiker. In de studie wordt in samenspraak met minimaal de aanbestedende overheid de opbouw vastgelegd en alle functionaliteiten. 2.3.2.2.P 2.3.2.2.P.1
LISTING MODULE-WHITE LIST Omschrijving
De module white list geeft de gebruiker de mogelijkheid lijsten aan te maken van nummerplaten die meer rechten hebben dan de standaard voertuigen. De lijsten moeten kunnen gekoppeld worden aan onder andere ANPR captatie systemen, trajecten en modules. Een voorbeeld ter illustratie is een traject waar één rijstrook vrijgehouden is voor het openbaar vervoer. Via de module toegangscontrole wordt het toegangsverbod voor voertuigen gemonitord. Alle nummerplaten van de bussen zijn opgenomen in een white list en mogen gebruik maken van deze rijstrook. Doordat ze opgenomen zijn in de white list gekoppeld aan de toegangscontrole worden de bussen niet gecatalogeerd onder overtreders. Veronderstel nu dat op hetzelfde traject ook trajectcontrole wordt toegepast. Alle bussen die op dit traject rijden worden niet onderworpen aan het toegangsverbod maar dienen zich wel aan de snelheidregels te houden op dit traject. Bussen die dus te snel rijden dienen toch beboet te worden alhoewel ze opgenomen zijn in de white list “toegangscontrole”. Alle list worden dus gekoppeld aan de modules. 2.3.2.2.P.2
Module
De module bestaat uit een tabblad waar de verschillende white list kunnen gecreëerd worden en beheerd. De nummerplaten die in een white list zitten kunnen aangepast worden. De lists kunnen gekoppeld worden aan ANPR captatie systemen, trajecten, modules, enz. Merk op dat universele lijsten niet geëditeerd mogen worden door de lokale gebruiker. Pagina 53 van 64
2.3.2.2.Q 2.3.2.2.Q.1
LISTING MODULE-BLACK LIST (STANDAARD) Omschrijving
De module black list geeft de gebruiker de mogelijkheid lijsten aan te maken van nummerplaten die minder rechten hebben dan de standaard voertuigen. De lijsten moeten kunnen gekoppeld worden aan onder andere ANPR captatie systemen, trajecten en modules. Voorbeelden zijn de universele black list van alle niet verzekerde voertuigen of de lijst van alle gestolen voertuigen. Een voorbeeld van een lokale lijst is een lijst van alle voertuigen waarvan het politiekorps verdenkt dat ze deelnemen aan bepaalde criminele feiten. Deze lijst kan echter evengoed ook gedeeld worden met de naburige politiekorpsen. In deze module moet het mogelijk zijn om nummerplaten toe te voegen met één of meerdere wildcards. Bijvoorbeeld: enkel een hit geven bij “ABC123” maar ook een hit geven bij “AB(A…Z)123” met “AB?123” in de black list. Er moeten ook black list gecreëerd kunnen worden die een alarm generen wanneer een voertuig gedetecteerd wordt van een bepaald land. Bijvoorbeeld bij een overval in de grensstrook met Frankrijk moet een black list geactiveerd kunnen worden die een alarm heeft bij elke registratie van een voertuig met Franse Nummerplaat. 2.3.2.2.Q.2
Module
De module bestaat uit een tabblad waar de verschillende black list kunnen gecreëerd worden en beheerd. De nummerplaten die in een black list zitten kunnen aangepast worden. De lists kunnen gekoppeld worden aan ANPR captatie systemen, trajecten, modules, enz. Aan iedere black list kan in deze module een graad gekoppeld worden met daaraan gekoppelde acties. Bijvoorbeeld wanneer een bepaald voertuig gecatalogeerd wordt onder de graad “onmiddellijke interventie”, dient bij een hit automatisch alle gebruikers gewaarschuwd te worden. Bij een niet verzekerd voertuig dient er echter enkel een melding te komen bij een bepaalde categorie gebruikers. Merk op dat universele lijsten niet geëditeerd mogen worden door de lokale gebruiker. 2.3.2.2.R 2.3.2.2.R.1
LISTING MODULE-PATRONEN Omschrijving
De module patronen wordt gebruikt om patronen te herkennen die individuele voertuigen of een groep voertuigen volgen. Het gedragpatroon van deze voertuigen wijkt af van dat van de modale weggebruiker en kan wijzen op criminele activiteiten. De module werkt op basis van een combinatie van querys (offline data-analyse) De gebruiker creëert in dit geval verschillende queries die allemaal verschillende vragen stellen op de realtime data. De verschillende queries worden op onderling met elkaar vergeleken en de gemeenschappelijke data wordt getoond in aan de gebruiker. Een voorbeeld ter illustratie: een query die alle voertuigen filtert die geen Belgische nummerplaat hebben gecombineerd met een query die alle voertuigen starten met de cijfer 231. Een sets van queries die in realtime de inkomende data analyseert wordt een bazooka genoemd. Verschillende bazooka’s kunnen naast elkaar gecreëerd en actief zijn om patronen te herkennen. De bazooka’s moeten ook kunnen opgeslaan worden om ze ten allen tijde terug kunnen oproepen en actief maken. Naast het manueel creëren van bazooka’s die actief de inkomende data bevragen, kunnen ook 3 scenario’s geïntegreerd in deze module: 1. Parkingbewaking: Het eerste scenario is de controle van voertuigen die op een korte tijdspanne verschillende autosnelwegparkings aandoen of in andere woorden een voertuig die een vooraf gedefinieerd patroon van ANPR captatie systemen systematisch passeert. In het scenario Pagina 54 van 64
parkingbewaking moeten verschillende deelpatronen kunnen gecreëerd worden en afzonderlijk bewaard en actief gemaakt kunnen worden onder een unieke naam. Een variant van deze parkingbewaking die onder hetzelfde scenario valt is een nummerplaat die tijdens een bepaalde periode eenzelfde parking, locatie aandoet. 2. Internationale criminaliteit: Het tweede scenario houdt de internationale trafiek in de gaten. Het scenario waaraan de voertuigen moet voldoen is het volgende: veronderstel twee voertuigen met Franse nummerplaat die met een interval van enkele minuten de landsgrens in België vanuit Frankrijk overrijden. Beide voertuigen rijden onmiddellijk volledig door naar Nederland. Een tijd later komen dezelfde voertuigen in dezelfde volgorde de omgekeerde beweging terug van Nederland via België richting Frankrijk. De kans is reëel dat deze bestuurders van deze voertuigen criminele feiten hebben uitgevoerd in Nederland of verboden goederen aan het vervoeren zijn. In het scenario internationale criminaliteit moeten verschillende deelpatronen kunnen gecreëerd worden en afzonderlijk bewaard en actief gemaakt kunnen worden onder een unieke naam. 3. Inbraak door (buitenlandse) criminelen: In het derde scenario worden buitenlandse voertuigen gemonitord die tijdens een bepaalde periode (bijvoorbeeld tussen 0u en 4u s’nachts) een bepaalde regio/stad binnenrijdt en terug verlaat. Alle voertuigen worden in rekening gebracht die langer in de regio zijn dan 30 min. In deze module kunnen de landen geselecteerd worden die in rekening gebracht worden. In het scenario inbraak door (buitenlandse) criminelen moeten verschillende deelpatronen kunnen gecreëerd worden en afzonderlijk bewaard en actief gemaakt kunnen worden onder een unieke naam. Deze scenario’s zijn concrete uitwerkingen van bazooka’s. Het doel van de integratie is een efficiënter werken van de Back-Office. De voornaamste taak van de aanneming is bij de ontwikkeling van deze scenario’s de bevraging te optimaliseren. Aan de verschillende gecreëerde patronen dmv querys en scenario’s moet een graad kunnen gekoppeld worden met daaraan gekoppelde acties. Alle patronen dmv querys en scenario’s moeten afzonderlijk gekoppelde kunnen worden aan een kalender wanneer ze actief moeten zijn. 2.3.2.2.R.2
Module
In de module kunnen de verschillende patronen door middel van querys gecreëerd en geactiveerd en scenario’s geactiveerd worden, en kan er een graad gekoppeld worden aan het patroon. Er kunnen trajecten gedefinieerd worden en ANPR captatie systemen toegewezen worden aan een bepaald patroon. 2.3.2.2.R.3
Ontwikkeling van extra scenario’s
Voor de ontwikkeling van 3 scenario’s zijn 3 posten voorzien met telkens een forfaitaire prijs. Het is echter de bedoeling dat in de toekomst nog extra scenario’s ontwikkeld van veel gebruikte patronen dmv querys. Er is een post voorzien “Opmaak van een projectcharter voor de ontwikkeling van een nieuw scenario “. Deze post is de kostprijs voor een voorstudie voor het vastleggen van een nieuw scenario’s. De inhoud van dit projectcharter is een volledige functioneel uitgeschreven scenario’s met bijhorend voorbeeld scenario en bijhorende bestelstaat met een aantal dagen werkt (per halve dag) dat de opdrachtnemer zal nodig hebben om de volledige ontwikkeling en programmatie te doen van dit scenario’s en dit te activeren op de Back-Office van de bestellende overheid en beschikbaar te stellen voor de andere bestellende overheden.
2.4 Bijkomende ontwikkelingen Dit hoofdstuk omvat verschillende bijkomende ontwikkelingen die extra functionaliteiten toevoegen aan de Back-Office. Wanneer bijkomende ontwikkelingen worden besteld door een bestellende overheid, dan dienen deze na de voorlopige oplevering ervan, als standaard te worden beschouwd en zijn deze ontwikkelingen ook beschikbaar voor alle Back-Offices die in de toekomst geplaatst worden.
Pagina 55 van 64
Voor Back-Offices die reeds zijn geplaatst dienen bijgekomen ontwikkelingen in het volgende onderhoud van de Back-Office geïnstalleerd te worden op vraag van de bestellende overheid. Deze installatie tijdens het onderhoud is een last van de opdrachtnemer.
2.4.1
Verwerking PV’s via gewestelijk verwerkingscentrum, 3de partij.
2.4.1.1 Beschrijving Momenteel worden PV’s nog verwerkt door politiezones zelf. Naar de toekomst toe is er echter een optie om alle PV’s te verwerken via een gewestelijk verwerkingscentrum of een 3de partij. Deze partij zal dan de verwerking doen van alle overtredingen afkomstig van de verschillende bestellende overheden via een eigen Back-Office. 2.4.1.2 Kenmerken van de uitvoering Er dient bij iedere module voor verbalisatie een mogelijkheid toegevoegd te worden om de gegevens van de verbalisatie over te brengen naar de Back-Office van een andere partij. Na goedkeuring of afkeuring in de Back-Office van de andere partij, dient een terugkoppeling te gebeuren naar de BackOffice die verantwoordelijk is voor de betrokken Front-Installations. Het beheer van de PV gebeurt wel volledig in de Back-Office van de andere partij.
2.4.2
Beheer van verschillende Back-Offices vanuit een centraal systeem
2.4.2.1 Beschrijving Niet alle politiezones zijn voorzien om hun Back-Offices 24u/24u te bemannen. Het is gebruikelijk dat tijdens de bepaalde uren van de dag (voornamelijk ’s nachts) taken overgenomen worden door een centrale gebruiker die meerdere Back-Offices tegelijk beheerd. In de praktijk kan deze taak vervuld worden door het CIC, door bijvoorbeeld de Federale politie in het Vlaamse Verkeerscentrum of door een naburige politiezone. Al deze 3de partijen zullen in dit geval zelf beschikken over een Back-Office. 2.4.2.2 Kenmerken van de uitvoering Er dient bij iedere Back-Office een mogelijkheid toegevoegd te worden om tijdens bepaalde momenten de gegevens (ook) door te geven naar een ander Back-Office. In de Back-Office van de verschillende bestellende overheden moet via de kalender geselecteerd kunnen worden welke andere Back-Office de taken van de politiezone overneemt en wanneer. Het overgeven van gegeven en overnemen van taken moet onafhankelijk van elkaar kunnen beheerd worden. Het overnemen dient transparant te gebeuren voor de verschillende gebruikers en de overgenomen Back-Office moet blijven gebruikt kunnen worden door de betrokken politiezone zelf. De centrale gebruiker moet zelf een filter kunnen instellen voor welke lists en patronen hij allemaal hits wil te zien krijgen. De centrale gebruiker wil bijvoorbeeld enkel maar een hit krijgen wanneer een wagen gesignaleerd is die gecarjackt is, of wil meldingen krijgen wanneer een wagen voldoet aan een bepaald patroon.
2.4.3
Ontwikkeling procotol van een extra type ANPR camera
2.4.3.1 Beschrijving Er zijn enkele partijen die reeds beschikken over ANPR captatie systemen van diverse leveranciers. De gegevens die deze camera’s genereren kunnen nuttig zijn voor politiezones die gebruik maken van een Back-Office. Om de koppeling tussen deze ANPR captatie systemen en de Back-Office van dit contract mogelijk te maken wordt een post voorzien voor de ontwikkeling van een conversiebox die de datastructuur van het externe ANPR captatie systeem vertaald naar de datastructuur van de BackPagina 56 van 64
Office. Deze conversiebox kan werken in twee richten. Hij kan de datastructuur van een extern ANPR captatie systeem vertalen naar de datastructuur van de Back-Office en kan omgekeerd ook de datastructuur van de Back-Office vertalen naar datastructuur van een extern ANPR captatie systeem. In de conversiebox kunnen de data gepushed worden of gepulled.
2.4.4
Ontwikkeling protocol externe list van 3de partijen
2.4.4.1 Beschrijving Om Black- en White-lists uit te wisselen met externe Back-Offices/systemen van 3de partijen wordt een post voorzien voor de ontwikkeling van een List conversiebox. Deze box vertaalt de datastructuur van andere partijen naar de datastructuur van de Back-Office en omgekeerd.
2.4.5
Ontwikkeling van extra software
2.4.5.1 Beschrijving De werking van een vast ANPR netwerk is onderhevig aan technische evoluties. Daarom kunnen tijdens de duurtijd van het contract bijkomende ontwikkelingen voor nog nader te bepalen software mogelijks besteld worden. Dit is geen verplichting voor de bestellende overheden. 2.4.5.2 Kenmerken van de uitvoering De ontwikkeling van de software start eerst met een voorstudie voor het vastleggen van de functionaliteiten en de werking van de nieuwe software. De inhoud van deze voorstudie of projectcharter is een volledig functioneel uitgeschreven softwarebeschrijving gelijkaardig opgedeeld als bepaald onder artikel 2.3.1.3.A.3 Ontwikkeling met bijhorend een bestelstaat met het aantal dagen werk (per halve dag) dat de opdrachtnemer zal nodig hebben om de volledige ontwikkeling en programmatie te doen van de software. Na de voorlopige oplevering van het projectcharter kan overgegaan worden tot de ontwikkeling van de extra software. Het aantal werkdagen om de ontwikkeling af te werken is conform het projectcharter dat is opgesteld. De administratieve bepalingen zijn diezelfde als deze van de opdrachtdocumenten. Het is een plicht van de opdrachtnemer de aanbestedende overheid in kennis te stellen wanneer een projectcharter wordt besteld voor de ontwikkeling van extra software. Indien de aanbestedende overheid van mening is dat deze extra ontwikkelingen van algemeen belang is, dan kan de aanbestedende overheid overgaan tot het opmaken van onvoorzien posten opdat, na de voorlopige oplevering van de extra software, zodat deze ook beschikbaar is voor andere bestellende overheden.
2.5 Datacommunicatie 2.5.1
Koppeling Front-installation – Back-Office en Back-Office naar BackOffice
Voor het communicatieprotocol tussen Front-Installation en de Back-Office, en tussen de verschillende Back-Office wordt geen protocol opgelegd.
2.5.2
Datastructuur versleutelde gegevens
2.5.2.1 Kenmerken van de uitvoering Voor het bewaren van versleutelde gegevens wordt gebruik gemaakt van de structuur die momenteel gebruikt wordt binnen het Vlaamse Verkeerscentrum. De manier van versleuteling wordt niet vastgelegd. De opdrachtnemer dient in samenspraak met de aanbestedende overheid een module te ontwikkelen die elke registraties omzet naar versleutelde Pagina 57 van 64
gegevens. De module moet zo geschreven worden als stand-alone module die in de toekomst met beperkte aanpassing kan geïntegreerd worden in andere systemen. Bij deze integratie in systemen van 3de zal een conversiebox (artikel 2.4.3 Ontwikkeling procotol van een extra type ANPR camera) gebruikt worden om de gegevens in de goede structuur te plaatsen. Alle Back-Offices verbonden met het Vlaamse Overheidnetwerk sturen automatisch via een push functionaliteit hun registraties door naar het Vlaamse Verkeerscentrum. De versleutelde gegevens worden verstuurd in XML formaat. Op de Back-Offices kunnen ook nog 3de partijen toegevoegd worden die volgens hetzelfde dataprotocol de gegevens ontvangen. Onderstaand overzicht in artikel “2.5.2.1.A Datastructuur Vlaams Verkeerscentrum” is het huidige protocol opgenomen in artikel “2.5.2.1.A.3 Datastructuur” is het overzicht van de dataopbouw opgenomen. De informatie bij statusbericht is informatief. Op het moment van ontwikkeling van de Back-Office zal de laatste versie van datastructuur van het Vlaamse Verkeerscentrum overhandigd worden aan de opdrachtnemer. 2.5.2.1.A
DATASTRUCTUUR VLAAMS VERKEERSCENTRUM
Onderstaande is het dataprotocol ALPR zolang nu gebruikt. Deze versie werd opgesteld in samenspraak tussen AWV, EMT en VVC. De versie is van 28 september 2011. 2.5.2.1.A.1
Realtime data (FTP)
Voor de realtime data (enkel data, geen foto’s) zit het initiatief bij de Back-Office. De Back-Office stuurt actief per doortocht een tekstfile (zie artikel 2.5.2.1.A.2 Historische data (FTP)) met een tekstueel dataformaat verder beschreven in artikel “2.5.2.1.A.3 Datastructuur” naar maximaal 2 FTPservers van het bestuur. Ook de statusberichten (zie artikel 2.5.2.1.A.2 Historische data (FTP)) worden 1 keer per minuut doorgestuurd. 2.5.2.1.A.2
Historische data (FTP)
De historische data wordt in een cyclische buffer bijgehouden. Hier is plaats voor data van 1 maand doortochten per site. De data kan opgehaald worden via FTP. FTP-user en paswoord worden per Back-Office meegedeeld. Nummerplaatgegevens worden gecodeerd. De FTP-server heeft een map per site, per dag, en ziet er als volgt uit (een site beperkt zich tot een bepaalde rijrichting): siteID\YYYYMMDD\ De tekstuele data wordt bijgehouden in een txt-file. - 1 data-txt-file per doortocht - 1 statusbericht per minuut per camera/rijstrook De naam van de file wordt als volgt opgebouwd: - data: - status:
D_siteID_YYYYMMDD_HHMMSS_sss_rijstrook.txt S_siteID_YYYYMMDD_HHMMSS_sss_rijstrook.txt
SiteID is het EM-installatienummer (alfanumerieke karakters, variabele lengte). De verschillende tekstbestanden worden per site per 5 minuten gegroepeerd in een zip-file. De 5-minuten-intervallen starten op “volle 5 minuten”: 00:00 -00:05 - 00:10 - 00:15 - … De zipfile met gegevens is pas beschikbaar op het einde van het interval. Bestandsnaam: - zipfile:
Z_siteID_YYYYMMDD_HHMMbegin_HHMMeind.zip
Vb. Z_123A4_20090417_1425_1430.zip
Pagina 58 van 64
Indien gedurende een bepaalde tijd de site niet operationeel is, zijn voor deze periode geen statusberichten beschikbaar. (Er worden geen statusberichten retroactief aangemaakt waarin de status “kunstmatig” op Niet-OK gezet wordt.) 2.5.2.1.A.3
Datastructuur
De data en statusberichten worden opgebouwd als een csv-bestand (comma separated values) met als scheidingsteken een puntkomma. De velden beginnen tekens met 2 identificatiekarakters gevolgd door een ‘=’ –teken. Indien parameters er niet zijn, worden ze niet meegegeven. De data berichten worden gemaakt onmiddellijk na de voertuigdoortocht. De statusberichten worden periodiek (elke minuut) gemaakt. Elk bericht is 1 regel en wordt beëindigd met een CR+LF. - Databericht Positie Code
Naam
Omschrijving
*1
NR=
Volgnummer
Volgnummer van de databerichten 0 tot 99999
*2
TP=
Type
Type bericht D voor data
*3
ID=
Identificatie
siteID van het meetpunt
*4
MT=
Meettijd
Tijdstip YYYYMMDDHHMMSSsss (CET: GTM+1)
*5
ST=
Status
Status van het meetpunt OK/NOK – mogelijkheden
*6
VN=
Versienaam+nummer Versie van interface (voor interpretatie van variabelen)
*7
RN=
Rijstrooknummer
Cameranummer/Rijstrooknummer
PL=
Nummerplaat
Geen plaat = “no-read”
NA=
Nationaliteit
B, NL, D, F, GB, PL, -- = niet in set, ADR
BP=
Betrouwbaarheid plaat
%
BN=
Betrouwbaarheid nationaliteit
%
FT=
Fotonaam
indien aanwezig
MC=
Mac-id
bvb: 00:1A:22:84:C6:0F
VT=
Volgtijd
in ms
SN=
Snelheid
in km/h
LO=
Lengte ongecorrigeerd
in dm
LG=
Lengte gecorrigeerd
in dm
RT=
Richting
N=normaal; c=tegenverkeer
KL=
Voertuigklasse
Velden met een * worden altijd meegegeven, op de voorgeschreven positie. Overige velden worden meegegeven voor zover beschikbaar. Een statusbericht beperkt zich tot deze velden. Het nummer van het databericht start opnieuw vanaf 0 bij het herstarten van de installatie (bv. na uitval). Voor de tijdsaanduiding wordt CET gebruikt, (GMT+1, geen zomeruur). - Statusbericht
Pagina 59 van 64
Positie Code
Naam
Omschrijving
*1
NR=
Volgnummer
Volgnummer van de statusberichten 0 tot 99999
*2
TP=
Type
Type bericht S voor status
*3
ID=
Identificatie
ID van het meetpunt
*4
MT=
Meettijd
Tijdstip YYYYMMDDHHMMSSsss
*5
ST=
Status
Status van het meetpunt OK/NOK – mogelijkheden?
*6
VN=
Versienaam+nummer Versie van interface (voor interpretatie van variabelen)
*7
RN=
Rijstrooknummer
Cameranummer/Rijstrooknummer
Het nummer van het statusbericht start opnieuw vanaf 0 bij het herstarten van de installatie (bv. na uitval). - Voorbeelden -
Databericht NR=15668;TP=D;ID=123Z4;MT=20090305144020097;ST=OK;VN=TS1;RN=1;PL=d41d8c d98f00b204e9800998ecf8427e;NA=B;BP=87;BN=96;SN=97;LG=42;
-
Statusbericht NR=1254;TP=S;ID=WO00054;MT=20090305144400000;ST=OK;VN=WIM1;RN=2;
2.6 Full omnium onderhoud na waarborgperiode 2.6.1
Beschrijving
De opdracht “Full omnium onderhoud na waarborgperiode” wordt gegund met afzonderlijke bestelling, voor de duur van 1 jaar. De opdracht wordt stilzwijgend jaar per jaar verlengd tot maximum 4 jaar voor zover de bestellende overheid er niet aan verzaakt bij een aangetekend schrijven dat ten minste 15 (vijftien) kalenderdagen voor de jaarlijkse einddatum verzonden wordt. De opdracht per bestellende overheid vangt aan de eerste dag van de maand die volgt op de definitieve oplevering van de afgewerkte installatie. De bestellende overheden houden zich het recht voor de opdracht “Full omnium onderhoud na waarborgperiode” niet te bestellen. In dit geval kan de aannemer geen enkel recht op enige vergoeding doen gelden. Aan onderstaande eisen dient te worden voldaan teneinde een kwalitatief full omnium onderhoud te bekomen voor: - de geleverde materialen en uitgevoerde werken bij de bestellende overheden; - het overstijgende belang. De opdrachtnemer dient in staat te zijn, binnen deze aankoopcentrale een kwalitatief natraject te verzorgen voor de bestellende én aanbestedende overheid. - de perfecte werking van een vast ANPR netwerk. Het hebben van een full omnium onderhoud is voor de aanbestedende overheid en de bestellende overheid een middel om dit te bewerkstelligen. - de continuïteit in de werking van de installaties. Er worden enkel downtimes toegelaten voor vooraf gemeld preventief onderhoud, averijen, interventietermijnen bij oproepen, stormschade, waterschade en bliksemschade.
Pagina 60 van 64
2.6.1.1 Kenmerken van de materialen 2.6.1.1.A
INCIDENT MANAGEMENT
De modaliteiten waaraan het incident management systeem dient te voldoen staan beschreven in het artikel “2.3.1.2.D Beheersoftware”. 2.6.1.1.B
PROBLEM MANAGEMENT
De modaliteiten waaraan het incident management systeem dient te voldoen staan beschreven in het artikel “2.3.1.2.D Beheersoftware” 2.6.1.1.C
CHANGE MANAGEMENT
De modaliteiten waaraan het change management systeem dient te voldoen staan beschreven in het artikel “2.3.1.2.D Beheersoftware” De aanbestedende overheid wordt door de opdrachtnemer in kennis gesteld van alle activiteiten die zich kaderen binnen change management. De aanbestedende overheid behoudt op die wijze een overzicht en historiek van de changes die zijn uitgevoerd op alle vaste ANPR netwerken die worden geplaatst en beheerd binnen deze opdracht. Heirbij een aantal voorbeelden van gegevens die de aanbestedende overheid minimaal dient ter beschikking te hebben: - downtimes per bestellende overheid/vast ANPR netwerk; - downtimes, overkoepelend van alle vaste ANPR netwerken; - aantal oproepen, averijen per bestellende overheid/vast ANPR netwerk; - aantal oproepen, averijen overkoepelend van alle vaste ANPR netwerken; - inventaris van geleverde en geplaatste onderdelen, software, vast ANPR netwerk per bestellende overheid/vast ANPR netwerk; - inventaris van geleverde en geplaatste onderdelen, software vast ANPR overkoepelend van alle vaste ANPR netwerken; - versiebeheer software en modulebeheer bestellende overheid/vast ANPR netwerk; - versiebeheer software en modulebeheer overkoepelend van alle vaste ANPR netwerken; 2.6.1.2 Kenmerken van de uitvoering 2.6.1.2.A 2.6.1.2.A.1
INCIDENT MANAGEMENT Oproepen
Wanneer een installatie niet of abnormaal werkt of een installatiegedeelte dat te wijten is aan de installatie zelf, niet of abnormaal werkt dan is deze defect. Wanneer de bestellende overheid, de aanbestedende overheid of een burger een defect vaststelt aan de installatie dan kan zij een oproep genereren met vraag tot tussenkomst volgens de technische werkwijze beschreven in artikel 2.3.1.2.D Beheersoftware. Een tussenkomst is een prestatie of levering uit te voeren binnen een bijzonder korte termijn, die aanvangt vanaf de kennisgeving aan de aannemer hetzij per telefoon, per fax of door middel van email. De interventietermijnen voor een vraag tot tussenkomst bij defecten, gegenereerd door bestellende overheden, aanbestedende overheid of burger bedraagt:
Pagina 61 van 64
- Tijdens werkdagen (meldingen op werkdagen 24u/24u): Een eerste tussenkomst/terugmelding moet gebeurd zijn binnen een termijn van 24u na de oproep en de voorlopige herstelling moeten uitgevoerd worden binnen een termijn van 48u na de oproep. Bij de eerste tussenkomst/terugmelding wordt er verwacht dat in deze tijdspanne de opdrachtnemer reageert en een eerste inschatting maakt van het probleem. Bij de voorlopig herstelling dient de installatie terug in dienst te zijn, maar misschien nog niet helemaal zoals het hoort. - In het weekend of op een officiële feestdag: De eerste tussenkomst/terugmelding moet gebeuren vóór 12 uur op de eerste volgende werkdag en voorlopige herstelling moeten uitgevoerd worden op de eerstvolgende werkdag. Bij de eerste tussenkomst/terugmelding wordt er verwacht dat in deze tijdspanne de opdrachtnemer reageert en een eerste inschatting maakt van het probleem. Bij de voorlopig herstelling dient de installatie terug in dienst te zijn, maar misschien nog niet helemaal zoals het hoort. - Kleine herstellingen vanop afstand waar geen interventie ter plaatse nodig is (vb. software reset) dienen gebeurd te zijn binnen een termijn van 24u. Een kleine herstelling doorloopt dezelfde stappen terugmelding – voorlopige herstelling- definitieve herstelling, met die uitzondering dat de termijnen voor de terugmelding en de voorlopige herstelling 24u zijn. De definitieve herstelling dient uiterlijk uitgevoerd binnen de 120 uren (5 dagen) na de oproep. Een herstelling is pas definitief als de installatie terug is hersteld en werkt zoals in de opdrachtdocumenten bepaald,eventuele structurele problemen zijn verholpen. 2.6.1.2.A.2
Averijen
Herstelling bij averij is een tussenkomst ten gevolge van een defect of een daaruit voortvloeiend defect dat ondubbelzinnig te wijten is aan overmacht zoals schade berokkend door derden en waarvoor de opdrachtnemer niet verantwoordelijk kan worden gesteld (averij, vandalisme, stormschade, uitvallen van netspanning langer dan de autonomie van de noodvoedingen). Wanneer de bestellende overheid, de aanbestedende overheid of een burger een averij vaststelt aan de installatie dan kan zij een oproep genereren met vraag tot tussenkomst. De opdrachtnemer dient binnen de 5 werkdagen een gedetailleerde offerte volgens de posten van de samenvattende opmetingsstaat voor de herstelling van de infrastructuur ingediend te worden aan de bestellende overheid. Bij deze offerte zijn de nodige afdrukken van de digitale foto’s gevoegd die een totaalbeeld geven van de beschadigingen en de mogelijkheid bieden de eventuele contacten en discussies met het parket, de veroorzaker of zijn afgevaardigde (verzekering, …) te voeren en af te ronden. De offerte en foto’s dienen bijgehouden te worden volgens artikel “2.3.1.2.D Beheersoftware”. Wanneer de bestellende overheid zijn fiat geeft, kan worden overgegaan tot herstelling. De betaling van een averij geschiedt per averij. Het is een plicht van de opdrachtnemer, bij het uitvoeren van onderhoud, zelf geconstateerde averijen te melden aan de bestellende overheid. Wanneer blijkt dat onderhoud is uitgevoerd zonder averijen te melden dan kan de opdrachtnemer zich niet meer beroepen op zijn schadeloosstelling ten gevolge van de averij. De interventietermijnen voor het oplossen van averijen gegenereerd door bestellende overheden bedraagt diegene die de inschrijver in zijn GANTT-diagram opgeeft. De tussenkomst van de opdrachtnemer voor een averij bestaat desgevallend uit: onder spanning staande delen van de gehavende installatie die een gevaar kunnen betekenen voor de weggebruikers worden spanningsloos gesteld of geïsoleerd en mechanisch afgeschermd;
Pagina 62 van 64
alle maatregelen worden getroffen om verdere beschadiging of storingen aan de gehavende installatie, zijn onderdelen of andere uitrustingen (teletransmissie) te voorkomen; de volledige installatie wordt uitgemeten, de fouten opgespoord, hersteld en de installatie in dienst gesteld; er wordt een voldoend aantal geslaagde digitale foto's van de averij genomen, met een minimum van 3, die toelaten een oordeel te vormen over de omvang en locatie van de beschadigde uitrustingen; de materiaalresten die zich op de openbare weg bevinden en die ten gevolge van een averij een gevaar vormen voor de weggebruikers dienen opgeruimd te worden. De gedemonteerde uitrustingen kunnen desgevallend tijdelijk naast de openbare weg gelegd worden, voor zover zij daardoor de toegang tot de woningen en terreinen niet hinderen; het gedemonteerde beschadigde materiaal wordt per averij verzameld, wordt onuitwisbaar en eenduidig gemerkt met het nummer van de averij en blijft beschikbaar tot het wordt vrijgegeven door de bestellende overheid. Daarna wordt het gehavende materiaal eigendom van de opdrachtnemer. Het gedemonteerde materiaal dat niet beschadigd is en opnieuw gebruikt kan worden, blijft eigendom van de bestellende overheid. De bestellende overheid heeft het recht recuperatiemateriaal te laten opstellen. Wanneer een onderdeel of toebehoren weggenomen wordt op vraag van de bestellende overheid, wordt dit door de opdrachtnemer in een magazijn onder gepaste omstandigheden opgeslagen. De opdrachtnemer is er toe gehouden om het gerecupereerde materiaal dat eigendom blijft van de bestellende overheid in een goede staat van werking te houden en een afzonderlijke gedetailleerde stocklijst bij te houden. Bij het indienen van een vorderingsstaat wordt bij levering uit deze stock de aangepaste stocklijst toegevoegd. Transport van het gerecupereerde materiaal van de werf naar het magazijn en vice versa, het stapelen en het uitpakken evenals andere prestaties nodig voor het verwerken en het opstellen van het geleverde of gerecupereerde materiaal is begrepen in de post “Forfaitair bedrag als vergoeding voor verplaatsing ingeval van averij”. 2.6.1.2.B
PROBLEM MANAGEMENT
Alle onderhoudswerken dienen uitgevoerd te worden volgens de processen ingeschreven in het onderhoudsdraaiboek. 2.6.1.2.B.1
Correctief onderhoud
Voor elke installatie vangt de deelopdracht correctief onderhoud aan op de eerste dag die volgt op de voorlopige oplevering van de bijhorende bestelopdracht in het kader van “Leveringen en werken”. Voor elke installatie vangt het correctief onderhoud aan op de eerste dag van de maand die volgt op de geplaatste bestelling “Full omnium onderhoud na waarborgperiode” door een bestellende overheid. Het correctief onderhoud wordt uitgevoerd tijdens de gewone dienstregeling, tijdens de fileongevoelige momenten (beperkte ginder voor de weggebruiker) en wordt uitgevoerd tijdens maximum 2 opeenvolgende werkdagen binnen de gewone dienstregeling. Herstellingen van defecten dienen uitgevoerd te worden volgens de voorwaarden en termijnen beschreven in het artikel 2.6.1.2.A.1 Oproepen. Het correctie onderhoud omvat alle leveringen, werken en prestaties (personeel, materieel, werktuigen, meettoestellen, vervoer, diensten, ...), nodig om de installatie van vaste ANPR netwerken, zijn onderdelen of andere uitrustingen opgesteld in het kader van onderhavige aanneming in volmaakte staat van werking terug te brengen. 2.6.1.2.B.2
Preventief onderhoud
Pagina 63 van 64
Voor elke installatie vangt het preventief onderhoud aan op de eerste dag van de maand die volgt op de voorlopige oplevering van de bijhorende bestelopdracht in het kader van “Leveringen en werken”. Voor elke installatie vangt het preventief onderhoud aan op de eerste dag van de maand die volgt op de geplaatste bestelling “Full omnium onderhoud na waarborgperiode” door een bestellende overheid. Het preventief onderhoud wordt uitgevoerd tijdens de gewone dienstregeling, tijdens de fileongevoelige momenten (beperkte ginder voor de weggebruiker) en wordt uitgevoerd tijdens maximum 2 opeenvolgende werkdagen binnen de gewone dienstregeling. Herstellingen van defecten, vastgesteld tijdens het preventief onderhoud, dienen uitgevoerd te worden volgens de voorwaarden en termijnen van het correctief onderhoud (zie artikel 2.6.1.2.A.1 Oproepen). Preventief onderhoud is het corrigeren van componenten van het vast ANPR netwerk, zonder aanleiding in de vorm van een incident. Doel van preventief onderhoud is het voorkomen van toekomstige problemen en het verhogen van de onderhoudbaarheid. Het preventief onderhoud omvat alle leveringen, werken en prestaties (personeel, materieel, werktuigen, meettoestellen, vervoer, diensten, ...), nodig om de installatie van vaste ANPR netwerken, zijn onderdelen of andere uitrustingen opgesteld in het kader van onderhavige aanneming in volmaakte staat van werking te behouden. Het preventief onderhoud wordt uitgevoerd tijdens de gewone dienstregeling. De processen opgegeven in het onderhoudsdraaiboek moeten gevolgd worden. 2.6.1.2.C
CHANGE MANAGEMENT
Bij Change Management is onderscheid te maken tussen: - spoedeisend correctief onderhoud (emergency-fixes); - adaptief onderhoud; - perfectief onderhoud. 2.6.1.2.C.1
Spoedeisend correctief onderhoud (emergency fixes)
Als voor het oplossen van een incident een wijziging in de programmatuur noodzakelijk is, zal een zogenaamde Emergency Fix op het vaste ANPR netwerk plaatsvinden. Deze aanpassing zal ook in de eerstvolgende reguliere release moeten worden meegenomen. 2.6.1.2.C.2
Adaptief onderhoud
Behalve de emergency fixes vindt al het onderhoud releasematig plaats. (reguliere release) Adaptief onderhoud is het aanpassen van één of meer delen van het vast ANPR netwerk als gevolg van wijzigingen in de omgeving van die delen. Adaptief onderhoud kan worden veroorzaakt door onderhoud aan een ander deel (meestal in een onderliggende laag) van het vast ANPR netwerk. Per release dienen één of meerdere wijzigingen meegenomen te worden. Fall back naar vorige releases dient mogelijk te zijn. Om adaptief onderhoud te kunnen uitvoeren dient een planning opgesteld te worden. Releases dient goedgekeurd te worden door de aanbestedende overheid. Een technische omschrijving wat de release inhoud en resultaten van een test bij de opdrachtnemer moet aangeleverd worden aan de aanbestedende overheid. 2.6.1.2.C.3
Perfectief onderhoud
Het perfectief onderhouden van een vast ANPR netwerk heeft als doel het kwaliteitsniveau te verhogen van vast ANPR netwerk.
Pagina 64 van 64
