Upload
others
View
6
Download
0
Embed Size (px)
Citation preview
NVBR Programma van Eisen DBK-dataserver 7 september 2010 Concept Concept v0.6
NVBR Programma van Eisen DBK-dataserver
ing. E.J. van Capelleveen drs. A. van Duijn i.s.m. leveranciers en BVIM/NIM Amersfoort, 7 september 2010 551556/ECA/AKQ
Stationsplein 1
Postbus 907
3800 AX Amersfoort
Telefoon 033 4677777
www.twynstragudde.nl
Versie Toevoeging Opmerking
0.5 H4 aangepast Frank Terpstra (ICTU) heeft aanvullingen gedaan in het hoofdstuk terugmeldingen. Het PvE volgt nu de Rotter-damse oplossing (zie stuk Rotterdamse Terugmeldsoft-ware in de map OSB en TMF).
0.6 Diverse kleine wijzigingen
Wijzigingen nav feedback veld NVBR mail OdK 01/09/10
Inhoudsopgave
1 Inleiding 1 1.1 Opdrachtgever & opdrachtnemer 1 1.2 Proces van totstandkoming 1 1.3 Beoogd gebruik PvE 1 1.4 Diepgang van de specificatie 1 1.5 Beoogde overdracht naar BVIM 2 1.6 Structuur van het document 2
2 DBK-dataserverconcept 3 2.1 Conceptueel 3 2.2 Netwerk van DBK-servers 4 2.3 Uitwijkprincipe bij uitval 5 2.4 Synchronisatie DBK-dataservers 5 2.5 Cascadesystematiek 6 2.6 De DBK-gegevensset 7 2.6 Basisgegevens (objectgebonden) 7 2.6 Preventieve gegevens 9 2.6 Preparatieve gegevens 9 2.6 Repressieve gegevens 10 2.7 Koppelvlakken 10 2.8 Berichtsoorten 10 2.8 Berichtsoorten naar basis- en themaregistraties 11 2.8 Berichtsoorten van de DBK-programmatuur 12 2.8 Interregionale berichten 13
3 Incidentberichten uit GMS 15 3.1 GMS-bericht – inschieten incident 15 3.2 Aan en afmelden bij DBK-server 16 3.3 Distributie incidentgegevens naar eenheid 17 3.4 Accepteren incidenten door eenheden 19 3.5 Incidentupdatebericht 20
4 Terugmeldberichten 22 4.1 Terugmeldingen 22 4.1 Terugmelden aan basisregistratie (via landelijke TMF (Digimelding) 26 4.1 Lokale terugmeldingen brandweer 28 4.1 Terugmeldingen naar VEWIN-servers 28 4.1 Terugmelding naar PRK server 28
5 Berichten van DBK-programmatuur 30 5.1 Interne verwerking van berichten 30 5.2 Leesberichten 31 5.3 Schrijfberichten 32 5.4 Doorgeefberichten 33
6 Interregionale berichten 36 6.1 Informatieverzoeken 36 6.2 Synchronisatieverzoeken 36
7 Eisen aan beheer 38 1. Relatietabel
1
1 Inleiding
1.1 Opdrachtgever & opdrachtnemer
Opdrachtgever voor het opstellen van dit Programma van Eisen (PvE) voor de DBK-dataserver is de Stuurgroep DBK1. Opdrachtnemer is de projectorganisa-tie DBK en de BVIM Brandweer Vraagorganisatie Brandweer. Leden van het netwerk Informatiemanagement, vertegenwoordigers van de betrokken bron-houders van de aan te sluiten gegevensregistraties en leveranciers van DBK-programmatuur hebben hun bijdrage geleverd bij het articuleren van de vraag en het opstellen van deze specificaties.
1.2 Proces van totstandkoming
Dit PvE is langs de onderstaande weg via co-creatie tot stand gekomen. Redactie en penvoering is uitgevoerd door Twynstra Gudde in samenwerking met de BVIM en de leden van het netwerk NIM. Leveranciers en bronhouders hebben hierop hun commentaar gegeven en deze zijn in deze specificaties verwerkt.
1.3 Beoogd gebruik PvE
Dit PvE is bedoeld om bouwers van programmatuur en services gerichte informatie te geven over wat we als brandweersector onder de DBK-server verstaan, welke functionaliteit deze server moet bezitten en hoe we het gebruik van deze DBK-dataserver zien. Ze dient tevens de bouw van een aantal DBK- dataservers gedurende de tweede proef in fase 2b van de Proof of Concept (POC) fase van het project DBK.
1.4 Diepgang van de specificatie
Deze specificatie is bedoeld om een DBK-dataserver te kunnen bouwen die met andere DBK-dataservers en programmatuur van uiteenlopende makelij kan werken. Daartoe is uniformering van het berichtenverkeer en services benut. De specificaties zijn op logisch niveau geformuleerd. Technische uitwerking kan door leveranciers/bouwers op verschillende wijze plaatsvinden. Op verzoek van de leveranciers hebben we met hulp van Geonovum wel zogeheten XSD schema’s gemaakt om het bouwproces en uniformering te kunnen versnellen.
1 DBK Digitale Bereikbaarheids Kaart
2
Getracht is die diepgang van specificatie toe te passen, die de benodigde uniformering bereikt en tegelijk voldoende vrijheid laat voor leveranciers in de technische implementatie.
1.5 Beoogde overdracht naar BVIM
Dit document wordt als concept PvE opgeleverd binnen fase 2b van het NVBR-project DBK. Het zal daarna voorzien van het commentaar van de leveranciers, bronhouders, infrastructuuraanbieders en andere betrokkenen worden over gedragen aan de BVIM-organisatie.
1.6 Structuur van het document
Dit document is zo opgebouwd dat de lezer na het doornemen van de concept- beschrijving in hoofdstuk 2, de andere hoofdstukken in principe los van elkaar kan benutten. In hoofdstuk 2 wordt de beschrijving van het DBK dataserverconcept beschre-ven . Een concept dat door Alex Janssen van de gemeente Roermond is ingebracht. In hoofdstuk 3 wordt beschreven hoe incidentberichten vanuit de GMS-server worden verwerkt door de DBK-dataserver en hoe deze vervolgens worden doorgestuurd naar de DBK-gebruiksapplicaties. In hoofdstuk 4 staat beschreven hoe het terugmeldproces dient te worden vormgegeven op de DBK-dataserver. Hierin is onderscheid gemaakt voor terugmelden richting de basisregistraties en terugmelden richting themaregi-straties. In hoofdstuk 5 wordt in detail beschreven hoe de communicatie tussen de DBK-dataserver en de DBK-applicaties dient te werken. Hoofdstuk 6 gaat in welke mogelijkheden er benodigd zijn voor DBK-dataservers om onderling met elkaar te communiceren. In de bijlagen treft u ten slotte het informatiemodel DBK en de XSD-schema’s van de verschillende berichten aan.
3
2 DBK-dataserverconcept
2.1 Conceptueel
De DBK-dataserver is een via uniforme gestandaardiseerde services/berichten te bereiken gegevensbank waarin de minimale set van gegevens van de DBK voor een groot gebied in zijn opgeslagen. Deze databank is via webservices benaderbaar voor een reeks van DBK-applicaties en andere DBK-dataservers. Tevens houdt een DBK-dataserver contact met de landelijke voorzieningen van de relevante basisregistraties waarmee ze een gebiedsgebonden deelverzame-ling van deze basisregistraties biedt om tijdkritische veelal object of gebieds-gebonden vragen te beantwoorden. De DBK-dataserver ken een cascadesyste-matiek om afwijkende en aanvullende gegevens te kunnen registreren. Hiermee wordt zowel het proces van terugmelden als een verantwoorde omgang met brandweerspecifieke uitzonderingen ondersteund.
DBK dataserver concept
BAG
BRO
BGT
VEWIN
PRK MAKEN BEHEREN
GEBRUIKEN
DBK server
DBK
ap
plic
atie
s
netwerknetwerknetwerknetwerk
kaart
inzet
prep
prev
object
TMF
DBKserver
BRW TMF
kaart
inzet
prep
prev
object
Brandweer specifieke applicaties
Meldkamer
Uitrukvoortuig
Landelijke voorzieningen
Figuur 1. DBK-concept Ook ontvangt de DBK-dataserver incidentmeldingen vanuit het meldkamersys-teem GMS/NMS. Op deze wijze kunnen deze incidentgegevens ingeschoten worden op de desbetreffende mobiele data terminals (MDT) van de uitrukken-de vaar- en voertuigen. Op deze MDT’s draait de DBK-programmatuur.
4
2.2 Netwerk van DBK-servers
Het concept gaat uit van een serie DBK-dataservers die primair de DBK-gegevens van een verzorgingsgebied serveren. Deze DBK-servers worden onderling in een netwerk geplaatst waardoor ze onderling kunnen gegevens kunnen uitwisselen en synchroniseren. We gaan in deze beschrijving uit van een netwerk van 25 servers die elk minimaal het verzorgingsgebied van hun brandweer/veiligheidsregio en bij voorkeur ook dat van de aangrenzende regio’s afdekken. Elk van deze DBK-dataservers communiceert met de landelijke voorzieningen van de basisregistraties en de landelijke of gebieds-specifieke voorzieningen van themaregistraties, waar er geen landsdekkende voorziening bestaat.
Figuur 2. Netwerk van DBK-servers Elke DBK-applicatie, op een MDT of op een andere computer, kan via de geüniformeerde webservices de gegevens van een object en de daarbij beho-rende DBK-gegevens ophalen en gebruiken voor beheer dan wel gebruik bij een uitruk.
5
2.3 Uitwijkprincipe bij uitval
Wanneer het landsdekkende netwerk van DBK-dataservers er is, en de gege-vens van de aangrenzende regio’s ook geladen zijn bij de DBK-dataserver, kan ingeval van uitval van deze DBK-datserver de gegevens ook opgehaald worden bij één van de aangrenzende regios’. Dit veronderstelt dat de DBK-gegevens regelmatig gesynchroniseerd worden. Dat betekent dat de gehele DBK-dataset van een verzorgingsgebied ter syn-chronisatie opvraagbaar moet zijn. We stellen ons voor dat deze synchronisatie dagelijks plaatsvindt en de oorspronkelijke set na het volledig binnen halen van de geactualiseerde set vervangen wordt. Dit principe waarbij via rechthoeken de datavensters van de verzorgingsgebieden zijn gemarkeerd, is in de onder-staande tekening weergegeven.
Figuur 3. Uitwijk en synchronisatie
2.4 Synchronisatie DBK-dataservers
Dit zou dus betekenen dat de DBK-dataserver van regio 23 Brabant Zuid Oost, naast zijn eigen DBK-gegevens , ook de gegevens van de aangrenzende regio’s te weten 21, 22 en 24 zou bevatten en zo deze regio’s ook als uitvalvoorziening kan functioneren. De DBK-data van deze aangrenzende regio’s moet dan dus periodiek gesynchroniseerd worden.
6
Dat kan bijvoorbeeld door de gehele DBK- dataset van die aangrenzende regio’s gewoon periodiek te vervangen. In de figuur 4 is aangegeven welke synchronisaties noodzakelijk zijn.
#x25
x#xxx24
x#xx23
xx#xx22
xx#xxx21
x#xx20
xx#xxxx19
xx#xx18
xx#xxxx17
xx#16
#xxx15
xx#xxxx14
xx#xx13
xx#xx12
xx#xx11
xxxx#xxx10
xxxxx#x9
xx#xx8
xxxxxx#xxx7
xx#xx6
x#x5
xxx#xx4
x#xx3
x#x2
xxxxx#1
25242322212019181716151413121110987654321regio
#x25
x#xxx24
x#xx23
xx#xx22
xx#xxx21
x#xx20
xx#xxxx19
xx#xx18
xx#xxxx17
xx#16
#xxx15
xx#xxxx14
xx#xx13
xx#xx12
xx#xx11
xxxx#xxx10
xxxxx#x9
xx#xx8
xxxxxx#xxx7
xx#xx6
x#x5
xxx#xx4
x#xx3
x#x2
xxxxx#1
25242322212019181716151413121110987654321regio
+ Figuur 4. Synchronisatietabel (zie ook bijlage)
2.5 Cascadesystematiek
De cascade systematiek is bedacht om vanuit brandweerperspectief om te kunnen gaan met veranderingen in de reikwijdte van in basis- en themaregistra-ties opgenomen objecten. De interesse van de brandweer in objecten wijkt, zo is gebleken, af van de afbakening die bij bijvoorbeeld de basisregistraties BAG en WOZ maar ook een themaregistratie als die van de PRK en WABO is gekozen. De cascade systematiek zorgt ervoor dat de identificatie van de DBK-objecten de unieke sleutel zijn naar objecten binnen de DBK-applicatie en DBK-dataserver. De relevante gegevens van de BAG, WOZ, PRK en WABO- objecten kunnen als het ware gepast worden boven op het DBK-object. Hiermee worden de relaties tussen deze objecten in relationele zin gelegd. Zo kan aanvullende informatie op het goede niveau worden geplaatst en is de samenhang bekend. Een voorbeeld hiervan is in onderstaand schema gevisuali-seerd.
7
Figuur 5. Cascadesystematiek Het is zaak dat deze cascadesystematiek in de DBK-databank wordt onder-steund.
2.6 De DBK-gegevensset
De minimale DBK-dataset bestaat uit gegevens over een object en is verdeeld naar vier themagebieden aangevuld met een geografische ondergrond. De geografische ondergrond maakt dus geen deel uit van de DBK-dataset maar wordt gebruikt om deze op af te beelden. Deze vier themagebieden zijn: - Basisgegevens object - Preventieve gegevens - Preparatieve gegevens - Repressieve gegevens. Welke gegevens van elke groep opgenomen worden in de DBK-dataset is hieronder weergegeven.
2.6.1 Basisgegevens (objectgebonden)
Objecten zijn panden bestaande uit één of meerdere verblijfsobjecten die volgens de regels van de BAG adresseerbaar zijn. Het kunnen ook ligplaatsen of standplaatsen zijn. Andere soorten objecten die voor de brandweer ook van belang zijn, maar niet binnen de spelregels van de BAG passen worden als brandweerobject vastgelegd. Op deze wijze kunnen bouwwerken, inrichtingen en terreinen die niet binnen de BAG-regels vallen, maar wel voor de brandweer van groot belang zijn, opgenomen worden. Een cascadesysteem voor opslag zorgt ervoor dat eerst de spelregels van de basisregistraties gevolgd worden en wanneer dat niet kan dat de onderliggende benadering gevolgd kan worden. Daarbij wordt dan ook onderscheid gemaakt naar:
8
- objecten zoals deze in de basisregistraties voorkomen - tijdelijke objecten die geen vermelding in de basisregistraties krijgen
(bijvoorbeeld grote tenten op evenementen) - objecten die aansluitend op objecten uit de basisregistraties voorkomen
(bijvoorbeeld een buitenpandige gasflessenopslag) - objecten waar een terugmelding op loopt en nog niet geaccepteerd zijn. De vast te leggen basisgegevens (entiteiten)2 zijn: - objectidentificatie (uniek) - identificatie verblijfsobject (link naar de BAG) - code object zoals bekend in spraakverkeer - naam object zoals bekend in spraakverkeer “lokaal bekend als” - OMS-nummer - vlakgeometrie van het object (pandgeometrie). Gegevens over het adres en locatie die ook worden vastgelegd maar ontleend worden aan de basisregistratie BAG zijn: - gemeente - woonplaats (naam & geometrie) - openbare ruimte (straat) - nummeraanduiding (inclusief postcode) - verblijfsobject /ligplaats/standplaats (inclusief coördinatie/geometrie en
BAG gebruiksdoel) - pand ( inclusief pandgeometrie). In onderstaand figuur is de relationele samenhang van deze begrippen weerge-geven.
Nummeraanduiding
Openbare ruimteWoonplaats
Gemeente
Basis Registratie Adressen
LigplaatsVerblijfsobject Standplaats
PandBasis Gebouwen Registratie
Nummeraanduiding
Openbare ruimteWoonplaats
Gemeente
Basis Registratie Adressen
LigplaatsVerblijfsobject Standplaats
PandBasis Gebouwen Registratie
Figuur 6. Inhoud van de BAG
2 Uitwerking naar de bij de entiteit vast te leggen attributen wordt in de
berichtspecificaties vermeld
9
Tevens worden op objectniveau vastgelegd: - aantal bouwlagen (laagste; hoogste) - gebruikstype (Prevap-code) - secties/gebouwdelen - tijdvakken verblijf gesplitst naar aantallen bewoners/bezoekers - zelfredzaamheid (J/N inclusief toelichting) - gevelfoto’s en verwijzing naar cyclorama’s - terrein toegang aanrijdpunt vanuit navigatie.
2.6.2 Preventieve gegevens
De laag preventieve voorzieningen bevat informatie die betrekking heeft op het voorkomen en beperken van gevaar. De gegevens uit deze laag zijn deels geografisch en daardoor terug te vinden in het kaartbeeld van de DBK. Tevens zijn er gegevens die administratief van aard zijn en deze worden daarom als tekst weergegeven op de DBK (in de tabel naast het kaartbeeld of als tekstlabel in de kaart). De vast te leggen gegevens uit de preventieve sfeer zijn: - BHV - brandweercompartimentering - brandmeldpaneel - automatische blusinstallatie - rook en warmteafvoer installatie - overdruk, -stuwinstallatie.
2.6.3 Preparatieve gegevens
De laag preparatieve voorbereidingen bevat informatie ter voorbereiding op een mogelijke inzet bij het object. Richt zich vooral op de toegang van het object en de vindbaarheid van sleutels en bluswatervoorzieningen. De gege-vens uit deze laag zijn deels geografisch, deel middels symbolen NEN 1414 en daardoor terug te vinden in het kaartbeeld van de DBK. Er zijn gegevens die administratief van aard zijn en deze worden als tekst weergegeven op het DBK. De preparatieve gegevens die moeten worden vastgelegd zijn: - ingang brandweer en overige ingangen - sleutelbuis/kluis - brandkranen (Vewin-bedrijven) - open water - geboorde put (BRO) - bluswaterriool - droge stijgleiding, blusleiding
10
- hoofdafsluiter - afwijkend communicatiesysteem.
2.6.4 Repressieve gegevens
De kaartlaag ‘gevaren en inzetbijzonderheden’ bevat informatie over eigen-schappen van het betreffende object die in potentie gevaar op leveren ten tijde van een incident of die een specifieke inzetprocedure vereisen die afwijkt van de standaardprocedure. De gegevens van van repressieve aard die moeten worden vastgelegd zijn: - gebouwconstructie - gevaarlijke stoffen - kabels en leidingen (groot) - inzetprocedure - bijzonderheden (overig) - opstelpunt.
2.7 Koppelvlakken
De DBK kent koppelvlakken naar de onderstaande bronhouders en gegevens-producenten.
Tabel 1. Koppelvlakken
Bron Soort gegevens LV BAG Adressen/Gebouwen Adressen/gebouwen LV BRO Ondergrond Brandputten LV BGT Grootschalige Topografie Kaartondergrond VEWIN lid server Brandkranen PRK Risicokaart Risico’s alsmede onderliggende
vergunningen en kabels en leidingen Meldkamer GMS/NMS Incident DBK-dataservers Alle DBK-gegevens DBK-applicaties Alle DBK-gegevens Deze koppelvlakken zijn weergegeven in figuur 1.
2.8 Berichtsoorten
We maken onderscheid naar de volgende berichtsoorten: - Informatieverzoeken (ophalen gegevens) - Notificatieverzoeken (ophalen wijzigingen) - Terugmeldberichten (melden wijzigingen aan bronhouders) - Incidentberichten (ontvangen incidenten) - Schrijfberichten (schrijven gegevens vanuit de programmatuur) - Synchronisatieberichten (aanbieden/ophalen volledige DBK-dataset van een
verzorgingsgebied).
11
We geven u een overzicht van alle berichtsoorten verbijzonderd naar de drie communicatiegebieden: - naar de basis- en themaregistraties (halen gegevens bij de bron) - naar de gebruikende DBK-programmatuur - ten behoeve van synchronisatie en interregionaal verkeer.
2.8.1 Berichtsoorten naar basis- en themaregistraties
Informatieverzoek Informatieverzoeken omvatten verzoeken vanuit de DBK-applicatie aan de bronhouders. Het informatieverzoek kent twee vraagvormen: - op geografisch gebied - op specifiek object. Uitvraag op geografisch gebied wordt via een venster (X1,Y1 – X2, Y2) gedaan om DBK-objectinformatie aan te leveren. Uitvraag op specifiek object wordt via object-ID gedaan. Vertaling vanuit een adres, 6PPC Postcode met huisnummeraanduiding of een X,Y die binnen de objectgeometrie valt, heeft dan al plaatsgevonden. Teruggeleverd worden door de webservices de uitgevraagde gegevens van de basis- of themaregistratie behorende bij de ID of het gevraagde gebied. Notificatieverzoek Een notificatieverzoek vraagt aan een bronhouder naar de relevante wijzigin-gen binnen een tijdsvenster en gebiedsvenster, die doorgevoerd zijn door de bronhouder. Dit veronderstelt dat de bronhouder een was/wordt bestand bijhoudt. De afnemer stuurt een verzoek naar de bronhouder met daarin aangegeven de gevraagde gegevens, de gewenste periode en het object of het gebied waarover deze gegevens worden gevraagd. Na ontvangst van het verzoek wordt de gevraagde gegevensset vanuit de bronhouder naar de aanvra-ger gestuurd. Terugmeldberichten Terugmeldberichten zijn berichten die door de DBK-dataserver worden doorgegeven vanuit de DBK-applicatie naar de bronhouder. De gebruiker meldt dat een afwijkende situatie is aangetroffen. Tevens geeft deze aan waaruit die afwijkende situatie bestaat door een deze als een was/wordt-bericht te specificeren. Van alle drie de berichttypen komen varianten voor omdat de status van het bericht anders is. We onderscheiden statussen als Melding, Geweigerd en Begrepen. Deze status wordt aan het bericht toegevoegd.
12
2.8.2 Berichtsoorten van de DBK-programmatuur
DBK-programmatuur bestaat uit drie applicatiegebieden te weten gebruiken, maken en beheren van DBK’s. Deze applicaties communiceren met de DBK- dataserver om gegevens vast te leggen en te lezen. Theoretisch kan de pro-grammatuur gebruik maken van lokale opslag van DBK-gegevens en alleen synchroniseren met de DBK-dataserver. Wij denken dat deze situatie alleen wenselijk is voor de gebruikssituatie (waarin hoge prestaties door de program-matuur geleverd moet worden) en als buffer voor het vastleggen van mutaties (in situ vastgelegd) terwijl er geen verbinding met de DBK-dataserver is. In deze situatie kennen we drie berichtsoorten: - Leesberichten - Schrijfberichten - Doorgeefberichten. Leesberichten Leesberichten komen overeen met de informatieverzoeken zoals ervoor gespecificeerd. Deze berichten worden evenwel aan de DBK-datserver gericht, die de gegevens levert uit de kopie DBK databank en indien mogelijk/gewenst zelf een verversingsbericht stelt aan de bronhouder en daarmee de DBK- datasubset ververst en deze gegevens doorgeeft aan de vragende applicatie. Schrijfberichten Deze berichten komen voor indien door de DBK-applicatie een datasubset gewijzigd is en deze wil laten vastleggen in de DBK-datserver. Daarbij wordt de wijziging tevens als een was/wordt bericht gelogd op de DBK-dataserver. Daarmee kan partiële synchronisatie plaatsvinden. Doorgeefberichten Berichten die de DBK-dataserver door moet geven zijn: - Terugmeldberichten - Incidentberichten. Terugmeldberichten zijn aangemaakt door de DBK-applicatie en worden aan de desbetreffende bronhouder van de thema- of basisregistratie doorgegeven. Incidentbericht Een incidentbericht is een bericht dat vanuit de meldkamer naar de DBK- dataserver wordt gestuurd en gegevens bevat over de actieve incident. Deze gegevens worden gebruikt om de DBK-applicatie in de MDT van het uitruk-kende vaar-/voertuig te voeden met de incidentgegevens. Binnengekomen incidentberichten worden gelogd in de DBK-dataserver en automatisch na 72 uur gewist.
13
2.8.3 Interregionale berichten
Er zijn twee soorten interregionale berichten: - Informatieverzoeken - Synchronisatieverzoeken. Informatieverzoeken Informatieverzoeken gesteld vanuit een DBK-dataserver van een andere regio zijn dezelfde als de informatieverzoeken die vanuit de DBK-applicaties gesteld worden. Dit zijn berichten die tussen twee DBK-servers worden uitgewisseld op het moment dat er grensoverschrijdende inzet plaatsvindt. De brandweer-specifieke DBK-gegevens worden dan op vensterniveau opgevraagd en geleverd door de DBK-server die de gegevens van de incidentlocatie bezit. Synchronisatieverzoeken De Synchronisatieverzoeken die een DBK-regio stelt aan zijn aangrenzende verzoeken betreffen het toeleveren van alle DBK-gegevens op dat moment aan de vragende DK dataserver. Deze vervangt na correcte ontvangst van de gehele dataset de oorspronkelijke dataset van het verzorgingsgebied van die regio. Nummer van eisen
Functionele eis Hardheid eis
Alg01 Een DBK-server moet de eigen en omliggende regio’s kunnen bedienen
Alg02 Een regio moet in grootte instelbaar kunnen zijn Alg03 De DBK-server moet (geüniformeerde) berichten
door middel van (geo-)webservices kunnen opstellen, versturen en verwerken
Alg04 Een DBK-dataserver dient, bij uitval, het berich-tenverkeer van een naburige data server te kunnen overnemen
Alg05 DBK-dataservers dienen onderling gesynchroni-seerd te worden
Alg06 Een DBK-dataserver dient door middel van een synchronisatietabel ingesteld te kunnen worden met welke naburige regio’s de DBK-dataserver wordt gesynchroniseerd
Alg07 De DBK-dataserver dient de cascadesystematiek te ondersteunen
Alg08 Nearline is minimum eis voor contact met basis en thema registraties
Alg09 Online is minimumeis voor WFS verkeer binnen brandweer
Alg10 Standaarden van Geonovum /Nora/Gemma zijn leidend
14
Nummer van eisen
Functionele eis Hardheid eis
Alg11 De DBK-dataserver moet ook mogelijkheid hebben om mutaties te halen i.p.v. alleen mutaties brengen. Was / wordt validatie van de dataset moet mogelijk zijn
15
3 Incidentberichten uit GMS
3.1 GMS-bericht – inschieten incident
Dit bericht wordt vanuit de meldkamer via het GMS-systeem aangemaakt en verzonden naar de desbetreffende DBK-dataserver van de regio waar het incident plaatsvindt. Op deze manier worden de primaire incidentgegevens aan de DBK-server bekend gemaakt. De DBK-dataserver legt de gegevens vast in de incidententabel en stuurt het bericht één op één door naar de DBK-applicatie op een MDT in het voer-/vaartuig dat aan het incident is gekoppeld. Dit betekent dat op de DBK-dataserver alle in de regio beschikbare MDT’s in een voor de beheerder toegankelijke tabel zijn opgenomen en dat daarin tevens de adressering voor het doorzenden van het bericht is opgenomen.
GMS database
MDTkoppelserver
Overige GMS services
GMS clients
Incidenttabel
Eenheidtabel
MDT Host Brandweer(DBK server)
DBK gebruiksapplicaties
DBK gebruiksapplicaties
GMS
Figuur 7. GMS MDT-koppeling
Nummer van eisen
Functionele eis Hardheid eis
Inc01 DBK-dataserver moet in staat zijn incidentberich-ten van MDT-koppelserver te kunnen ontvangen, verwerken en versturen
Inc02 DBK-dataserver moet een incidenttabel bevatten waarin alle incidenten worden vastgelegd.
Inc03 Een DBK-dataserver dient een tabel te bevatten waarin alle beschikbare MDT’s voor een regio (inclusief adressering) zijn opgenomen
16
3.2 Aan en afmelden bij DBK-server
Een DBK-gebruikapplicatie moet zich aanmelden bij een DBK-dataserver om incidentgegevens te kunnen ontvangen. Door zich aan te melden op de server kan een centralist de eenheid zien en incidentgegevens aan de eenheid koppe-len en daarmee versturen.
MDTkoppelserver
Incidenttabel
Eenheidtabel
MDT Host Brandweer(DBK server)
DBK gebruiksapplicaties
DBK gebruiksapplicaties
Aanmelden / afmeldenAanmelden / afmeldenAanmelden / afmeldenAanmelden / afmelden
BevestigenBevestigen
Figuur 8. Aan- en afmelden bij DBK-server
Tabel 2. Aanmeldbericht gebruikapplicatie DBK-server
rubriek omschrijving opm
Eenheid eenheid die zich aanmeldt verplicht
ComUnit communicatie-unit waarmee de
eenheid zich aanmeldt
verplicht
Voertuig identificatie van het voertuig optioneel
EenheidStatus externe statuscode bij
aanmelden
optioneel. indien
leeg behoudt de
eenheid de
actuele status
LoginRadios Radio’s (C2000-radio’s)
waarover de eenheid beschikt.
optioneel, kan
meerdere keren
voorkomen
AvlsCode avlscode van de eenheid optioneel
Chauffeur personeelsnummer chauffeur
AMBU
optioneel
Bemanningslid personeelsnummer bemannings-
lid AMBU
optioneel
Tabel 3. Eenheid afmeldbericht
Rubriek omschrijving opm
ComUnit Communicatie-unit van de eenheid
die zich afmeldt
verplicht
EenheidStatus externe statuscode bij afmelden optioneel. indien
leeg behoudt de
eenheid de
actuele status
17
3.3 Distributie incidentgegevens naar eenheid
In de meldkamer wordt het incident gekoppeld aan een eenheid of eenheden die aangemeld en beschikbaar zijn. Vervolgens wordt het incident ingeschoten in het voertuig door de gegevens door te sturen aan de DBK server. De DBK server stuurt een bevestiging van ontvangst terug naar de MDT koppelserver. Vervolgens worden de incidentgegevens vanuit de DBK server doorgestuurd naar de DBK gebruiksapplicaties in het veld.
MDTkoppelserver
Incidenttabel
Eenheidtabel
MDT Host Brandweer(DBK server)
DBK gebruiksapplicaties
DBK gebruiksapplicaties
BevestigingBevestiging
IncidentgegevensIncidentgegevens
DBK gebruiksapplicaties
DBK gebruiksapplicatiesDBK
gebruiksapplicatiesDBK
gebruiksapplicatiesIncidentgegevensIncidentgegevens
Figuur 9. Incident inschieten in voertuig
In het incidentgegevensbericht zijn de onderstaande gegevens opgenomen:
Tabel 4. Gegevens in incident naar eenheid bericht
rubriek Omschrijving opm
discipline BAP-string van het incident verplicht
incidentnummer Nummer van het incident verplicht
te koppelen eenheden distributielijst: communicatie-units
naar welke het bericht gestuurd
dient te worden
optioneel
te informeren eenheden distributielijst: Lijst van communi-
catie-units naar welke het bericht
als tekstbericht gestuurd dient te
worden
optioneel
naam melder Naam van de melder optioneel
adres melder adres, postcode en woonplaats van
de melder
optioneel, alleen
gevulde rubrieken
worden in het bericht
opgenomen
telefoon melder telefoonnummer van de melder optioneel
incidentlocatie adres, postcode, plaats van het
incident
optioneel, alleen
gevulde rubrieken
worden in het bericht
opgenomen
gemeente gemeente waarin de incidentlocatie
valt
Optioneel
18
rubriek Omschrijving opm
incident-coordinaten X, Y-coordinaat van de incident-
locatie
optioneel, (0,0)-
coordinaten worden
niet verstuurd
locatieaanduiding objectnaam, objectfunctie,
kruispuntnaam, type locatie
optioneel
meldingsclassificatie aard van de melding, classificatie optioneel, betreft
een komma
gescheiden
concatenatie van alle
beschikbare nivo’s.
karakteristiek primaire of secundaire karakteris-
tiek, karakteristiek-naam + waarde
optioneel, kan
meerdere keren
voorkomen
prioriteit prioriteit van de melding verplicht
gekoppelde eenheden Lijst van Eenheden: alle aan dit
incident gekoppelde eenheden
verplicht
geinformeerde eenheden Lijst van Eenheden: alle geinfor-
meerde eenheden
optioneel
kladblok kladblokregels (door centralisten
ingetoetst of d.m.v. rapportagebe-
richten aan het kladblok toege-
voegd)
optioneel, kan meerdere keren voorkomen
aol afspraak op locatie optioneel, kan
meerdere keren
voorkomen
De DBK-dataserver beantwoordt het incidentbericht met de volgende bevestiging: - status ‘succes’ en een leeg cause-veld in normale situaties - status ‘fout’ en een verklarende tekst in het cause-veld wanneer het bericht
niet of niet geheel verwerkt wordt. De body van het bevestigingsbericht heeft de volgende indeling:
Tabel 5. Body bevestigingsbericht
rubriek omschrijving opm
eenheid-informatie informatieblok per eenheid optioneel
19
Het informatieblok per eenheid bestaat uit:
Tabel 6. Informatieblok per eenheid
rubriek omschrijving opm
ComUnit Communicatie-unit van de
eenheid waarnaartoe het sturen
van de incidentinformatie niet
gelukt is
verplicht
cause foutboodschap verplicht
3.4 Accepteren incidenten door eenheden
Als een incident is ingeschoten in het voertuig dient het desbetreffende voer-tuig dit incident nog te accepteren. Dit acceptatiebericht wordt naar de DBK- server gestuurd. De DBK-server stuurt het bericht door naar de MDT-koppelserver, deze zal ter bevestiging van ontvangst een bericht naar de DBK- server terugsturen.
MDTkoppelserver
Incidenttabel
Eenheidtabel
MDT Host Brandweer(DBK server)
DBK gebruiksapplicaties
DBK gebruiksapplicaties
BevestigingBevestiging
IncidentacceptatieIncident
acceptatie
IncidentacceptatieIncident
acceptatie
Figuur 10. Incidentacceptatie
Inhoud van het acceptatiebericht:
Tabel 7. Incidentacceptatiebericht
rubriek omschrijving opm
ComUnit Communicatie-unit van de
eenheid die het incident
accepteert
verplicht
incidentnummer nummer van het incident optioneel
incident geaccepteerd verplicht
EenheidStatus de actuele eenheid-statuscode optioneel. indien
leeg behoudt de
eenheid de
actuele status
20
Wanneer GMS een acceptatiebericht ontvangt wordt een bevestiging (Een-heidAccepteertIncidentAck) teruggestuurd met: - status ‘succes’ en een leeg cause-veld wanneer de eenheid bestaat in GMS - status ‘fout’ en de tekst “Eenheid bestaat niet in GMS” in het cause-veld
wanneer de eenheid niet bestaat. - status ‘fout’ en de tekst ‘Eenheid is niet gekoppeld aan een incident’ in het
cause-veld wanneer geen incidentnummer in het acceptatiebericht is opge-nomen, en GMS geen incident kan vinden waaraan de eenheid is gekoppeld.
3.5 Incidentupdatebericht
Het kan gebeuren dat er aanrijdend naar het incident er nieuwe incidentgege-vens aan de meldkamer worden doorgegeven. In zo’n geval kan de meldkamer een update van de incidentgegevens naar de eenheid doorsturen.
Tabel 8. Incidentupdatebericht
rubriek Omschrijving opm
discipline BAP-string van het incident verplicht
incidentnummer Nummer van het incident verplicht
ComUnits lijst van communicatieunits naar
welke een update het incident
gestuurd dient te worden
bevat een of meerdere
ComUnits
naam melder Naam van de melder optioneel, komt alleen voor
wanneer gewijzigd
adres melder adres, postcode en woonplaats van
de melder
optioneel, komt alleen voor
wanneer gewijzigd
telefoon melder telefoonnummer van de melder optioneel, komt alleen voor
wanneer gewijzigd
incidentlocatie adres, postcode, plaats van het
incident
optioneel, komt alleen voor
wanneer gewijzigd
gemeente gemeente waarin de incidentloca-
tie valt
optioneel, komt alleen voor
wanneer gewijzigd
incident-coordinaten X, Y-coordinaat van de incident-
locatie
optioneel, komt alleen voor
wanneer gewijzigd
locatieaanduiding objectnaam, objectfunctie,
kruispuntnaam, type locatie
optioneel, komt alleen voor
wanneer gewijzigd
Meldingsclassifica-
tie
aard van de melding, classificatie optioneel, komt alleen voor
wanneer gewijzigd. betreft een
komma gescheiden concatena-
tie van alle beschikbare nivo’s.
karakteristiek primaire of secundaire karakteris-
tiek
optioneel, komt alleen voor
wanneer gewijzigd
prioriteit prioriteit van de melding optioneel, komt alleen voor
wanneer gewijzigd
21
rubriek Omschrijving opm
gekoppelde
eenheden
Lijst van Eenheden: alle aan dit
incident gekoppelde eenheden
optioneel, komt alleen voor
wanneer gewijzigd
De MDT-host beantwoordt het IncidentUpdate-bericht met een bevestinging: - status ‘succes’ en een leeg cause-veld in normale situaties - status ‘fout’ en een verklarende tekst in het cause-veld wanneer het bericht
niet of niet geheel verwerkt wordt. Het bevestigingsbericht heeft dezelfde indeling als het bevestigingsbericht uit de distributiecyclus Nummer van eisen
Functionele eis Hardheid eis
Inc01 DBK-dataserver moet in staat zijn incidentberich-ten van MDT-koppelserver te kunnen ontvangen, verwerken en versturen
Inc02 DBK-dataserver moet een incidenttabel bevatten waarin alle incidenten worden vastgelegd
Inc03 Een DBK-dataserver dient een tabel te bevatten waarin alle beschikbare MDT’s voor een regio (inclusief adressering) zijn opgenomen
Inc04 DBK-dataserver moet aan- en afmeldberichten kunnen verwerken en de eenhedentabel vervol-gens bij werken
Inc05 De DBK-dataserver moet bovenstaande incident-berichten kunnen verwerken en beantwoorden zoals in voorgaande paragrafen 3.1 t/m 3.5 staat beschreven
Inc06 De DBK-dataserver dient een incidentbericht door te kunnen sturen naar(de DBK-applicatie in) het aangewezen beschikbare voertuig
Inc07 Eerste wagens krijgt melding ingeschoten, andere wagens moeten melding op halen uit de DBK- server
Inc08 De DBK-dataserver dient incidentacceptatiebe-richten van DBK-applicaties te kunnen verwerken
Inc09 De DBK-dataserver dient incidentupdate berich-ten te kunnen verwerken en versturen naar de aan het incident gekoppelde eenheden
22
4 Terugmeldberichten
4.1 Terugmeldingen
Het terugmeldproces van de brandweer verloopt over meerdere schijven. Een terugmelding wordt gedaan op een beheer (of gebruik/maak? ) applicatie en wordt verstuurd naar de DBK-dataserver. Deze maakt contact met de landelijke voorziening terugmeldingen brandweer(LVTB). Vanaf de LVTB worden terugmeldingen gerouteerd naar de correcte themaregistratie(Vewin & PRK), of naar de DIGIMELDING (TMF) als het gaat om basisregistraties (BAG, BRO, BGT).
LVTBLVTB
TMF
Vewin
PRK
TerugmeldingTerugmelding
TerugtrekkingTerugtrekking
StatusupdateStatusupdate FoutmeldingFoutmelding
StatusupdateStatusupdate FoutmeldingFoutmelding
StatusupdateStatusupdate FoutmeldingFoutmelding
TerugtrekkingTerugtrekking
StatusupdateStatusupdate FoutmeldingFoutmelding
TerugmeldingTerugmelding
DBK applicatie
DBK applicatie
TerugtrekkingTerugtrekking
TerugmeldingTerugmelding
StatusupdateStatusupdate FoutmeldingFoutmelding
DBK ServerDBK
Server
Figuur 11. Schijven van terugmelden
De LVTB zal waarschijnlijk een kopie zijn van de DIGIMELDING (TMF). Dit betekent dat de wijze van terugmelden en de opbouw van de berichten, zoals bij de DIGIMELDING (TMF) gebruikelijk is, wordt overgenomen voor alle terugmeldingen binnen de brandweer. Dit houdt ook in dat de LVTB een doorgeefluik zal zijn van terugmeldberichten en reacties op die berichten. Er zijn in het kader van terugmelden 4 soorten berichten benoemd: Terugmelding Wanneer een fout wordt geconstateerd in een registratie wordt een terugmel-ding opgesteld waarin staat aangeven wat incorrect is aan de huidige aandui-ding van het object en hoe dit veranderd zou moeten worden. Intrekking Het kan voorkomen dat een geconstateerde fout achteraf wel niet correct is geïdentificeerd. Met behulp van dit bericht kan een terugmelding worden ingetrokken.
23
Ontvangstbevestiging Als een bronhouder de terugmelding op correcte wijze heeft ontvangen wordt hiervan melding gemaakt door middel van een ontvangstbevestiging aan de melder. Foutmelding Mocht het niet mogelijk zijn om het bericht af te leveren of kan de inhoud van het bericht niet geduid worden dan zal hiervan een foutmelding worden verzonden aan de melder. Hieronder worden de gegevenselementen van de generieke berichten benoemd. Deze worden specifiek gemaakt voor elke basis en thema registratie in het stuk erna. Het is mogelijk de aan de LVTB te vragen op welke registraties kan worden teruggemeld. Er kan voor elke registratie worden opgevraagd welke objecttypen deze kent en wat de attributen van deze objecttypen zijn(tabel 9 t/m 14). In feite kan hiermee het gegevensmodel van iedere aangesloten registratie worden uitgevraagd. Voor iedere thema en basis registratie zal na de generieke berichten het gegevens model worden gegeven.
Tabel 9. Raadpleeg (basis)registraties
Groep/Element Betekenis raadpleeg (ba-sis)registraties
verzoek om lijst met te raadplegen (ba-sis)registraties.
Tabel 10. Basisregistraties
Groep/Element Betekenis (basis)registraties
(basis)registratie naam van de basisregistratie
tag afkorting (basis)registratie
bevraagbaar Indicatie of (basis)registratie bevraagbaar is
Tabel 11. Raadpleeg objecttypen
Groep/Element Betekenis raadpleeg objecttypen verzoek om lijst met objecttypen horende bij een
(basis)registratie
(basis)registratie naam van de (basis)registratie
Tabel 12. Objecttypen
Groep/Element Betekenis objecttype
objecttype naam van het objecttype
tag afkorting objecttype
tntructie instructie t.b.v. Het terugmelden op dit type
bevraagbaar indicatie of objecttype bevraagbaar is
24
Tabel 13. Raadpleeg attribuuttypen en attribuut waarden
Groep/Element Betekenis raadpleeg attribuuttypen en attribuut waarden
(basis)registratie aanduiding (basis)registratie waartoe objecttype behoort
objecttype aanduiding objecttype
Tabel 14. Attribuuttypen
Groep/Element Betekenis
objecttype naam van het objecttype
object tag Informatie over het object
(basis)registratie naam tag van het objecttype
bevraagbaar indicatie of de actuele waarde kan worden opge-vraagd
instructie intructie t.b.v. terugmelden
attribuuttypen de attributen van object-type
code code die attribuuttype aanduid
naam naam van attribuuttype
lengte maximale lengte van de attribuuttype
toelichting Toelichting op de attribuuttype
reguliere expressie reguliere expressie die gebruikt wordt voor de validatie op de attribuuttype
attribuutwaarden waarden van het attribuuttype
attribuutwaarde waarde van het attribuuttype
code code die attribuutwaarde aanduid
waarde waarde van attribuutwaarde
25
Tabel 15. Terugmeldbericht
Groep/Element Betekenis terugmelding terugmelding van afnemersysteem
melding kenmerk kenmerk volgens afnemersysteem
tijdstempel aanlevering tijdstip van aanleveren volgens afnemersysteem
basis- of themaregistratie aanduiding basis of themaregistratie waaraan gemeld wordt
objecttype aanduiding objecttype
object sleutel sleutel van het concrete object waarover wordt
teruggemeld
toelichting motivatie voor de gerede twijfel
bijlage additionele informatie of een afschrift van een
bewijsstuk
attribuuttypen
attribuuttype aanduiding attribuuttype
betwijfelde waarde actuele waarde in basisregistratie volgens
terugmelder
voorstel vermoede/waargenomen waarde volgens
terugmelder
contact-naam naam van de terugmelder
contact-telefoonnummer telefoonnummer van de terugmelder
contact-email e-mail adres van de terugmelder
Tabel 16. Terugtrekbericht
Groep/Element Betekenis intrekking
melding kenmerk uniek kenmerk van intrekking volgens
meldersysteem
tijdstempel aanlevering tijdstip van aanleveren volgens afnemersysteem
betreft LVTB kenmerk uniek kenmerk van terugmelding volgens de LVTB
toelichting motivatie voor de intrekking
26
Tabel 17. Ontvangstbevestiging
Groep/Element Betekenis ontvangstbevestiging
LVTB-kenmerk uniek kenmerk volgens LVTB
classificatie 'informatief'
code '0'
tekst boodschap
Tabel 18. Foutmeldbericht
Groep/Element Betekenis foutmelding
LVTB-kenmerk uniek kenmerk volgens LVTB
classificatie 'fout'
code foutcode
tekst boodschap
4.1.1 Terugmelden aan basisregistratie (via landelijke TMF (Digimelding)
Digimelding (TMF) is beschikbaar voor terugmeldingen aan de BAG, BRO en BGT. Terugmeldingen worden via de LVTB naar Digimelding (TMF) gerou-teerd. Digimelding (TMF) stuurt de meldingen vervolgens door naar de correcte basisregistratie. De bericht specificatie en nadere uitwerking van het terugmeld proces is via Digimelding (TMF) is te vinden in Digimelding (TMF) koppelvlak specificatie (TMF koppelvlak specificatie v1.2 Peter Schipperheijn & Sing Hsu 2009-11-10) BAG Een terugmelding aan de BAG kan om een aantal redenen. Hieronder worden een aantal veel voorkomende redenen genoemd: - adreswijziging/toevoeging/verwijdering - contourwijziging/toevoeging/verwijdering. Terugmeldingen vinden plaats op objecten. Het unieke ID van een BAG-object is de Pand_ID. GBKN Terugmelden naar GBKN is niet mogelijk met TMF 1.2
27
BRO Voor de BRO is invulling gegeven aan het data model voor brandputten. Terugmeldingen op de BRO zullen zijn op ondergenoemde attributen:
Tabel 19. Type meldingen BRO
registerWell Verzoek tot registratie van een nieuwe put die voor de brandweer bruikbaar is
unregisterWell Verzoek tot het verwijderen van de put achter de opgege-ven id
mutateWell
Verzoek tot het muteren van de gegevens van een specifie-ke put
getStatus
Verzoek tot een overzicht van de status van de terugmel-dingen
Tabel 20. Datatype terugmelden BRO
Well Omschrijving Datatype Veldnaam Brandput-id Character
string WELL_ID
Positie x-coördinaat (rijksdriehoekstelsel)
Double WELL_X
Positie y-coördinaat (rijksdriehoekstelsel)
Double WELL_Y
Laatst bekende capaciteit (m3/s)
Double WELL_CAPACITY
Laatste controledatum Date WELL_INSPECTION_DATE Status (bruikbaar of onbruikbaar)
Character string
WELL_STATUS
Reporter Omschrijving Datatype Veldnaam Naam Character
string NAME
E-Mail Adres Character string
EMAIL_ADDRESS
Telefoon nummer Character string
TELEPHONE_NR
Status Omschrijving Datatype Veldnaam Status-Id Character
string STATUS_ID
Indicatie dat het bericht ontvangen is in het systeem
Boolean ACCEPTED
Indicatie dat het bericht met de mutatiegegevens verwerkt is in het systeem.
Boolean PROCESSED
28
4.1.2 Lokale terugmeldingen brandweer
..
4.1.3 Terugmeldingen naar VEWIN-servers
Daarvoor dient een combinatie van de volgende gegevens teruggestuurd te worden, al naar gelang de afwijking en de bronhouder: Terugmeldingen kunnen plaatsvinden over de volgende eigenschappen van een brandkraan: - locatie van de brandkraan - de capaciteit van de brandkraan - status van de brandkraan. Afhankelijk van of het een gemeentelijke brandkraan is of een van een leveran-cier zullen de bijbehorende id’s worden gebruikt om in het terugmeldbericht op te nemen. Tabel 21. Terugmeldatrributen brandkranen Geografisch 1. FID (Object ID) 2. Shape: Point (Geometry) Administratief 3. brkr_id uniek brandkraannummer per leverancier (Double) 4. leveranc naam van de leverancier/bronhouder (Text) 5. gembrkr_nr uniek brandkraannummer per gemeente (Double) 6. gem gemeentenaam (Text) 7. capaciteit in m3/sec (Double) 8. status brandkraan op controle datum(Text):
‘goed’ (vindbaar en bruikbaar), ‘matig’ (vindbaar, buikbaar maar heeft onderhoud nodig), ‘slecht’ (vind-baar maar niet bruikbaar of onvindbaar)
4.1.4 Terugmelding naar PRK server
Er staan vele soorten risico’s op de PRK. De risicokaart kent een aantal unieke identifiers waarover teruggemeld kan worden. Zie onderstaande tabel.
Tabel 22. Unieke identifiers PRK
Unieke identifiers risicokaart RRGS inrichtingen: RRGS_ID RRGS transport: TRNSD_VOLGNUMMER ISOR objecten (overige ramptypen): ROT_CODE
29
Verder is er nog weinig bekend over het terugmelden aan de PRK. Tabel 23. Eisen aan terugmelden Nummer van eisen
Functionele eis Hardheid eis
Terug01 De DBK-dataserver dient per type registratie instelbaar te zijn naar welke (landelijke) voorzie-ning deze terugmeldt.
Terug02 De DBK-dataserver dient de 4 berichtsoorten, terugmelding, intrekking, ontvangstbevestiging en foutmelding conform de berichtspecificaties zoals geleverd door de bronhouders. (Zie bijlagen voor berichtspecificaties).
30
5 Berichten van DBK-programmatuur
De volgende berichten worden uitgewisseld tussen de DBK-dataserver en de DBK-programmatuur.
DBK applicatieGEbruiken
Berichten tussen DKB server en programmatuur
OmgevingRegio
DBK dataserver24 x 7
Lage uitval
DBK applicatieMaken/beheren
informatieverzoekinformatieverzoek
kopiedata
was /wordt
kopiedata
Was /wordt
DBK Data Levering gevraagde gegevenns
XY Venster
Data binnenXY Venster
XminYmin
XmaxYmax
SchrijfberichtSchrijfbericht
InformatieverzoekInformatieverzoek
DBK Data
kopiedata
IncidentberichtIncidentbericht
incident
Bevestiging ontvangst
Bevestiging verwerkt
Figuur 12. Berichten tussen DBK-server en programmatuur In deze situatie kennen we drie berichtsoorten: - Leesberichten (informatieverzoeken) - Schrijfberichten - Doorgeefberichten
5.1 Interne verwerking van berichten
Geonovum heeft alle gegevenselementen die onderdeel zijn van de DBK verder uitgewerkt tot een informatimodel DBK (zie bijlage x). Dit is een subset van het informatiemodel OOV. In dit informatiemodel DBK zijn alle informa-tie elementen uit het visiedocument DBK* onderling tot elkaar in relatie gebracht en zijn attribuutwaarden ingevuld. Dit is uitgeschreven in een XSD- schema. Dit XSD-schema is als bijlage x toegevoegd. In IM DBK wordt het DBK-object als uitgangspunt genomen. Het DBK-object is de unieke kijk van de brandweer op risicovolle objecten. Deze wijkt af van hoe andere organisaties naar objecten kijken. Daarom is het DBK-object leiden gemaakt voor gebruik binnen de brandweer organisatie. Koppeling met andere registraties vindt plaats op basis van een unieke DBK-objectcode.
31
Uitgangspunt is dat een bericht wordt samengesteld op basis van de onderlig-gende gegevens van de bronhouders en van die gegevens waar men zelf bronhouder van is. Alleen in het kader van de cascade systematiek wordt hier vanaf geweken.
5.2 Leesberichten
Alle applicaties kunnen een verzoek om informatie doen aan de DBK-dataserver. Deze komen overeen met informatieverzoeken aan de individuele informatieverzoeken aan de diverse bronhouders. Informatie kan per object worden opgevraagd en per x-,y-venster. Regulier leesbericht Bij het beantwoorden van informatie(lees)verzoekenberichten wordt een intern antwoord bericht opgesteld conform IM DBK. Op basis van het XSD-schema wordt uit de database het leesbericht samengesteld en verstuurd naar de vrager. Cascadesystematiek bij leesberichten Stel dat in een eerder stadium afwijkende informatie van een externe bronhou-der is vastgelegd. De oorspronkelijke gegevens van de bronhouder wordt niet overschreven, afwijkende informatie wordt vastgelegd in extra velden. Deze extra velden zijn leidend bij het vormgeven van een leesbericht. Als bijvoor-beeld een afwijkende naam of adresnotatie bij een object is vastgelegd (bij-voorbeeld voor betere herkenbaarheid bij een brandweerman in het veld) wordt deze notatie verkozen boven de oorspronkelijke naam in de basisregistratie. Verversingsberichten De data op de DBK-dataserver wordt dagelijks gesynchroniseerd met de bronhouder. Gegevens zijn dus maximaal één dag oud. Mocht men de gege-vens van een bepaald object willen verversen dan kan men ook een verver-singsverzoek sturen. Dit verzoek wordt dan door de DBK-dataserver doorge-stuurd naar de betreffende bronhouder(s). Het antwoord wordt doorgestuurd naar de vragende applicatie en bijgewerkt op de DBK-dataserver. (extra functionaliteit in de applicaties)
DBK DBK DBK DBK dataserverdataserverdataserverdataserver
DBK DBK DBK DBK applicaties:applicaties:applicaties:applicaties:
•maakmaakmaakmaak•gebruikgebruikgebruikgebruik•beheerbeheerbeheerbeheer
DBK DBK DBK DBK applicaties:applicaties:applicaties:applicaties:
•maakmaakmaakmaak•gebruikgebruikgebruikgebruik•beheerbeheerbeheerbeheer
Intern antwoordGML obv XSD)Intern antwoordGML obv XSD)
Bronhouder(s)Bronhouder(s)Bronhouder(s)Bronhouder(s)
Verversingsbericht(GMS obv XSD)
Verversingsbericht(GMS obv XSD)
Database
Externinformatieverzoek
Externinformatieverzoek
Intern leesbericht(GMS obv XSD)Intern leesbericht(GMS obv XSD)
AntwoordVerversingsbericht
(GMS obv XSD)Verversingsbericht
(GMS obv XSD)
Figuur 13. Leesberichten tussen DBK-dataserver en DBK-applicaties
32
Bij een vraag om verversing bij de bron wordt het GML-bericht vertaald naar een of meerdere berichten aan de bronhouders. Deze berichten worden vorm-gegeven conform de eerder geleverde specificaties door de bronhouders. De antwoorden op deze berichten worden weer conform het XSD-schema vertaalt naar een correct GML-bericht wat weer wordt verstuurd naar de vragende applicatie.
5.3 Schrijfberichten
Een schrijfbericht dient opgebouwd en aan de DBK-server aangeleverd te worden. De brandweer dient de gegevens aan te kunnen passen in de brand-weerspecifieke gegevensset. Dit zijn gegevens waar de brandweer zelf bron-houder van is. Deze gegevens kunnen zonder verdere gevolgen op de database overschreven worden. Brandweerspecifieke gegevens van het object: - objectidentificatie (uniek) - code object zoals bekend in spraakverkeer - naam object zoals bekend in spraakverkeer “lokaal bekend als” - OMS-nummer - controledatum - verblijf aantal (max. GV. Bewoners, bezoekers, personeel / pand) - verblijf tijdvakken - zelfredzaamheid (bewoner, bezoeker / pand) - toegang terrein (inrit, obstakels) - gevel- en eventueel detailfoto. Brandweerspecifieke gegevens van de preventieve voorzieningen: - BHV. Brandweerspecifieke gegevens van de preperatieve voorzieningen: - ingang Brandweer, overige - sleutelbuis/-kluis - open water (capaciteit) - bluswaterriool - C2000-binnendekking. Brandweerspecifieke gegevens onderkende gevaren en inzetbijzonderheden: - gebouwconstructie - inzetprocedure - bijzonderheden (overig) - opstelpunt.
33
Alle andere gegevens worden betrokken van externe bronhouders. De brand-weer wordt dagelijks gevoed met de meest recente gegevens van deze bron-houders. Constateert men fouten in deze registraties dienen deze teruggemeld te worden aan de desbetreffende bronhouder(s). Gegevens van externe bronhouders: - object ID BAG - adres BAG - bouwlagen (vergunning). Preventieve voorzieningen externe bronhouders: - brandcompartimentering Gemeente – bouwvergunning - brandmeldpaneel Gemeente – bouwvergunning - automatische blusinstallatie Gemeente – bouwvergunning - rook- en wamte-afvoerinstallate Gemeente – bouwvergunning - overdruk-, stuwdrukinstallatie (parkeergarage, tunnel)Gemeente – bouw-
vergunning. Preparatieve voorzieningen bronhouders: - brandkranen (capaciteit) drinkwatermaatschappij - geboorde put (capaciteit, open en gesloten) Brandweer, Prov/TNO - bluswaterriool gemeente - droge stijgleiding, blusleiding gemeente – bouwvergunning - hoofdafsluiter gemeente – bouwvergunning. Ondergekende gevaren en inzetbijzonderheden externe bronhouders: - gevaarlijke stoffen gemeente – milieuvergunning - kabels en leidingen (groot) LV Kadaster. Cascadesystematiek bij schrijfberichten Gegevens van externe bronhouders kunnen niet overschreven worden. Maar het is wel wenselijk om met de meest actuele informatie te werken. Om die reden moet het mogelijk zijn om volgens de cascadesystematiek aanvullen-de of afwijkende informatie te registreren en te gebruiken. Dit houdt in dat de gegevenselementen uit de bronregistraties niet worden aangepast, maar dat bij wijziging van een informatie element of een geometrie deze wijzigingen onder aanvullende velden worden vastgelegd en weggeschreven. Daarnaast dient ook te worden vastgelegd hoelang dit tijdelijk element in het systeem moet staan. Na het verstrijken van deze termijn dient een notificatiebericht naar de beheer-applicatie te worden gestuurd.
5.4 Doorgeefberichten
De doorgeefberichten zijn berichten die worden doorgestuurd door de DBK- dataserver van en naar gebruiksapplicaties.
34
Het gaat om de volgende berichten: - Terugmeldingen - Incidentberichten. Beiden zijn al gespecificeerd in desbetreffende hoofdstukken. Deze zullen hier niet meer verder worden uitgewerkt. Terugmeldberichten dienen op de DBK-datserver bewaard te blijven tot een antwoord van de bronhouder is ontvangen en het antwoord is verwerkt. Incidentberichten worden 72 uur bewaard op de DBK-dataserver en worden daarna verwijderd. Tabel 24. Eisen aan DBK-databerichtverkeer Nummer van eisen
Functionele eis Hardheid eis
Intern01 De DBK-dataserver dient voor interne gegevens-uitwisseling leesberichten, schrijfberichten en doorgeefberichten te kunnen verwerken
Intern02 Gegevens dienen in de database te worden opgeslagen conform IM DBK
Intern03 Berichten tussen de DBK-dataserver en de DBK applicaties dienen te worden vormgegeven conform de bijgevoegde XSD
Intern04 De DBK-dataserver moet informatieverzoeken kunnen beantwoorden per object of per x,y venster
Intern05 De DBK-dataserver moet ook tussentijds verver-singsberichten van DBK-applicaties kunnen verwerken en vervolgens versturen naar de externe bronhouders. Deze verversingsberichten kunnen alleen per object worden opgesteld, niet per x,y venster.
Intern06 In de DBK dataserver mogen brandweerspecifieke gegevens overschreven worden, wel dienen overschreven gegevens als was /wordt informatie beschikbaar te blijven
Intern07 De DBK dataserver mag nooit gegevens van bronhouders overschrijven. Wel dient tijdelijke informatie over een informatie element van het object toegevoegd te kunnen worden
Intern08
De DBK-server dient bij het opstellen van leesberichten informatie elementen van externe bronhouders te kunnen passeren ten gunste van handmatig toevoegde tijdelijke gegevens conform de cascade systematiek
35
Nummer van eisen
Functionele eis Hardheid eis
Intern09 Het opgeven van een einddatum is een verplicht veld bij het invoeren van een tijdelijk gegevens-element
Intern10 Na afloop van de termijn van een tijdelijk infor-matie element dient een notificatiebericht ver-stuurd te worden naar de DBK-beheerapplicatie over het verstrijken van deze termijn
Intern11 De DBK-dataserver dient incidentberichten en terugmeldberichten door te kunnen geven aan de desbetreffende voorziening
Intern12 Incidentberichten dienen 72 uur op de DBK- dataserver bewaard te blijven
Intern13 Terugmeldberichten dienen op de DBK-datserver bewaard te blijven tot een antwoord van de bronhouder is ontvangen en het antwoord is verwerkt
36
6 Interregionale berichten
Er zijn twee soorten interregionale berichten: - Informatieverzoeken - Synchronisatieverzoeken
6.1 Informatieverzoeken
Informatieverzoeken gesteld vanuit een DBK-dataserver van een andere regio zijn dezelfde als de informatieverzoeken die vanuit de DBK-applicaties gesteld worden. Dit type berichten is al gespecificeerd in het vorige hoofdstuk onder paragraaf 5.2 Er wordt verwezen naar deze paragraaf voor een verdere toelich-ting op de informatieverzoeken.
6.2 Synchronisatieverzoeken
De Synchronisatieverzoeken die een DBK-regio stelt aan zijn aangrenzende regio betreffen het toeleveren van alle DBK-gegevens op dat moment aan de vragende DBK-dataserver. Een synchronisatieverzoek dient een of meerdere regio’s tegelijkertijd op te kunnen vragen. Na binnenkomst van een dergelijk verzoek worden alle DBK-gegevens van de gevraagde regio, inclusief de was-/wordt-informatie, geëxtraheerd, gecompri-meerd (is dit nodig) en verzonden naar de aanvrager. Deze synchronisatiever-zoeken zullen niet via webservices worden uitgewisseld maar als reguliere datatransfer via een ftp-verbinding. Dit is om zo snel mogelijk de gehele dataset te kunnen verzenden. Na aankomst worden alle nog aanwezige informatie elementen op de ontvan-gende server verwijderd en wordt de opgevraagde regio op de server geplaats. Tabel 25. Eisen aan interregionale berichten Nummer van eisen
Functionele eis Hardheid eis
Inter14 Informatieverzoeken tussen DBK-servers dienen te worden vormgegeven en afgehandeld conform eerder gesteld eisen aan interne informatieverzoe-ken/leesberichten
Inter15 Synchronisatieverzoeken dienen alle DBK- informatie van één of meer regio’s te kunnen opvragen bij naburige regio’s. Deze gehele DBK- dataset dient via FTP te kunnen worden verstuurd
37
Nummer van eisen
Functionele eis Hardheid eis
Inter16 De oorspronkelijke DBK-dataset van de aange-vraagde regio dient op de DBK-dataserver server van de aanvrager te worden verwijderd alvorens de aangevraagde dataset wordt geplaatst op de DBK-dataserver
38
7 Eisen aan beheer
In de DBK-dataserver dient minimaal de volgende beheerfunctionaliteiten te bevatten: - beheer van de DBK-datasever (wat moet instelbaar/veranderbaar zijn voor
een beheerder). - berichtspecificaties van interne en externe berichten - synchronisatietabel - directe toegang tot de DBK-database en mogelijkheden om daar bewerkin-
gen te kunnen doen. Tabel 26. Eisen aan beheer Nummer van eisen
Functionele eis Hardheid eis
Beheer01 Berichtspecificaties van interne berichten dienen aanpasbaar3 te zijn
Beheer02 Berichtspecificaties en mapping van externe berichten dient instelbaar4 te zijn
Beheer03 Synchronisatietabel dient instelbaar te zijn Beheer04 Regiogrootte dient instelbaar te zijn Beheer05 Er moet directe toegang tot de database mogelijk
te zijn
Beheer06 Er dient autorisatie en authenticatie mogelijk te zijn (voor beheerders, maar ook voor interne en externe DBK applicaties en andere externe voorzieningen)
Waar dit te plaatsen: - Piekbelasting beter weergeven hoe dit werkt? - MDT-kopppeling is niet bedoeld voor server to hos koppeling maar alleen
rechtstreeks naar voertuigen. Wellicht is LV incidenten nodig vanuit NVBR of wellicht AZN server AVL benutten of lokaal hosten op 25 plekken? De oplossingen moeten beide uitgewerkt worde en voorgelegd aan de bandweer en de veiligheidsraad.
3 Aanpasbaar = naast instellingen moeten ook nieuwe onderdelen kunnen worden toegevoegd aan de berichtspecificatie
4 Instelbaar = via keuzelijst berichtonderdelen kunnen kiezen
Bijlage 1
Bijlage 1. Relatietabel
regio 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25
1 # x x x x x 2 x # x 3 x x # x 4 x x # x x x 5 x # x 6 x x # x x 7 x x x # x x x x x x 8 x x # x x 9 x # x x x x x
10 x x x # x x x x
11 x x # x x 12 x x # x x
13 x x # x x
14 x x x x # x x
15 x x x #
16 # x x
17 x x x x # x x
18 x x # x x
19 x x x x # x x
20 x x # x
21 x x x # x x
22 x x # x x 23 x x # x
24 x x x # x
25 x #