Technisch ontwerp. Koppeling GMS i-bridge. Versie 1.0. Datum 22 December 2010

Technisch ontwerp Koppeling GMS – i-Bridge Versie 1.0

Datum Status

22 December 2010 Final

Technisch ontwerp koppeling GMS – i-Bridge | 22 December 2010

Colofon

IVENT A&A CDC Madame Curielaan 4-6 Postbus 20703 2289 CA Rijswijk Contactpersoon

Patrick Brooijmans Teamleider Functionele Integratie M +31 6 51313575 [email protected]

Versie Opdrachtgever Auteur(s) Projecten

1.0 i-Bridge2.0 Geodan i-Bridge2.0

Pagina 2 van 28


Inhoud Colofon ............................................................................................................2 1 Inleiding ...................................................................................................4 1.1 Algemeen ............................................................................................ 4 1.2 Leeswijzer ............................................................................................ 4 1.3 Uitgangspunten .................................................................................... 4 1.4 Begrippenlijst ....................................................................................... 5 1.5 Versie historie ...................................................................................... 5 1.6 Distributielijst ....................................................................................... 5 2 Algemene architectuur..............................................................................6 3 Componenten van het meldkamersysteem ...............................................7 3.1 GMS-interface ...................................................................................... 7 3.2 OVI-tool............................................................................................... 7 3.3 GMS-database ...................................................................................... 7 4 Componenten van het CMS .....................................................................10 4.1 CMS-Plot ............................................................................................ 10 4.2 CMS-Tekst ......................................................................................... 11 4.3 Onderliggende CMS-componenten ......................................................... 12 5 Koppeling tussen het GMS en het CMS (KGC) ..........................................14 5.1 Uitgangspunten voor de koppeling ........................................................ 14 5.2 Algemene architectuur ......................................................................... 15 5.3 Definities ........................................................................................... 15 5.4 Classificaties ...................................................................................... 17 5.5 Activiteiten KGC .................................................................................. 17 5.6 Systeemeisen KGC .............................................................................. 20

Pagina 3 van 28


1

Inleiding

1.1

Algemeen

Informatie over de incidenten die in een meldkamer binnenkomen wordt in het Gemeenschappelijk Meldkamersysteem (GMS) ingevoerd. De meldkamer van Hulpverlening Gelderland Midden (HGM) gebruikt daarnaast een crisismanagementsysteem (CMS) om gegevens van een calamiteit of ramp te presenteren, bij te werken en te archiveren. De kracht van het laatste systeem is dat incidentgegevens zowel geografisch als tekstueel worden weergegeven en automatisch tussen betrokkenen bij het incident gedeeld en uitgewisseld kunnen worden. Het GMS en het CMS zijn op dit moment twee onafhankelijke systemen. Binnen het I-Bridge project is besloten via een Proof of Concept (PoC) te onderzoeken of het mogelijk is een technische koppeling tussen beide systemen te realiseren. Hiermee zouden de incidentgegevens die in het GMS aanwezig zijn automatisch in het CMS beschikbaar moeten komen,.zodra de Calamiteiten Coördinator (CaCo) beslist om een bepaald incident op te schalen..Daarnaast dient de koppeling voor een optimale informatievoorziening op ieder moment te zorgen en dient aan gebruikers aantoonbare toegevoegde waarde te bieden ten opzichte van de huidige situatie. In dit document staat het Technisch Ontwerp (TO) beschreven. Het beschrijft de technische aspecten van de koppeling tussen GMS en CMS (KGC) die voor de PoC zal worden gerealiseerd. Het TO is gebaseerd op de resultaten van een inventarisatie van bestaande documentatie, systemen, gesprekken met betrokkenen en workshops over ontwerpbeslissingen die bij HGM genomen zijn. Voor het Functioneel Ontwerp (FO), waarin de functionele aspecten van de KGC zijn gedefinieerd, is een apart document opgesteld. 1.2

Leeswijzer

Hoofdstuk 1 bevat de uitgangspunten van dit document en een verklarende woordenlijst van begrippen die binnen dit document gebruikt zijn. In hoofdstuk 2 vindt u een algemene beschrijving van de systeemarchitectuur binnen de meldkamer. Hoofdstuk 3 en 4 beschrijven respectievelijk de softwarecomponenten van het meldkamersysteem en van het crisismanagementsysteem. Hoofdstuk 5 beschrijft hoe de koppeling gerealiseerd zal worden en aan welke eisen deze moet voldoen. 1.3

Uitgangspunten

Bij de totstandkoming van het TO is gebruik gemaakt van onderstaande documenten en overlegmomenten:      

FO; Bijeenkomsten op 10 december 2009 en 27 januari 2010; Workshops op 5 februari 2010; Document met het GMS database schema, ERD06 INCIDENT.pdf (vtsPN, Eric Canjels); Document met de lijst van tabellen, Tablelisting GMS4.8.0.pdf (vtsPN, Eric Canjels); Technische documentatie van het CMS van HGM (Geodan); Pagina 4 van 28


1.4

Begrippenlijst

De onderstaande tabel geeft een overzicht van begrippen en afkortingen die binnen dit document gebruikt worden. Term CaCo CMS CMS-Plot

CMS-Tekst FO GMS HGM Kladblok KGC MK MKB ODBC OVI-tool TO vtsPN UML 1.5

Verklaring Calamiteiten Coördinator Crisismanagementsysteem Module van het CMS waarin geografische informatie en context van het incident (kaartbeeld) wordt gevisualiseerd, gewijzigd en geanalyseerd. Module van het CMS waarin de tekstuele informatie wordt getoond en gewijzigd. Functioneel Ontwerp Gemeenschappelijk Meldkamer Systeem Hulpverlening Gelderland Midden Ruwe informatie over een geregistreerd incident zoals deze door de centralist in GMS wordt ingetypt. Koppeling GMS-CMS („meldkamerkoppeling‟) Meldkamer Meldkamerbeeld Open Database Connectivity Applicatie die incidentgegevens uit GMS ophaalt, deze filtert en classificeert en er een Melkamerbeeld mee opbouwt.

Technisch Ontwerp Voorziening tot samenwerking Politie Nederland Unified Modeling Language Versie historie

Status: versie 1.1 Versie

Datum

Naam

0.1

19-02-2010

Alessandra Scotta‟

Eerste versie

0.2

19-03-2010

Niels Bourgonjen

Gereviewde versie

1.0

22-03-2010

Niels Bourgonjen

Extern concept

1.1

31-03-2010

Alessandra Scotta‟

Aanpassingen van vstPN toegevoegd

1.6

Opmerkingen

Distributielijst

Versie

Datum

Aan

Opmerkingen

1.0

22-03-2010

HGM, vstPN

Eerste oplevering

Pagina 5 van 28


2

Algemene architectuur

Het GMS is bedoeld om incidenten, die telefonisch aan een meldkamercentralist gemeld zijn, te registreren en de informatie erover zo snel mogelijk en op een zo efficiënt mogelijke manier aan de eindverantwoordelijken ter beschikking te stellen. Onderdelen van het meldkamersysteem zijn:   

GMS-interface; OVI-tool, inclusief Meldkamerbeeld; GMS-database.

Elke component van de architectuur van het meldkamersysteem wordt in het hoofdstuk Fout! Verwijzingsbron niet gevonden. toegelicht. Binnen de meldkamer van HGM draait daarnaast een crisismanagementsysteem dat de mogelijkheid biedt real-time informatie uit te wisselen tussen verschillende actoren die bij de rampen- en crisisbestrijding zijn betrokken. Het CMS is in hoofdstuk Fout! Verwijzingsbron niet gevonden. beschreven. Figuur 1 schetst de globale architectuur van het meldkamersysteem en het

crisismanagementsysteem.

Figuur 1: Meldkamersysteem en crisismanagementsysteem

Pagina 6 van 28


3

Componenten van het meldkamersysteem

Dit hoofdstuk beschrijft in het kort de componenten van het meldkamersysteem die in Figuur 1 geschetst zijn. 3.1

GMS-interface

De kernapplicatie van het meldkamersysteem is het GMS. Centralisten voeren incidenten in GMS in, zodra het incident telefonisch wordt gemeld. De CaCo beslist of een incident een hogere GRIP-alarmstatus krijgt. Alleen bepaalde incidenten, met een GRIP-alarmstatus van 2 of hoger, komen in aanmerking om naar het crisismanagementsysteem (CMS) gestuurd te worden. Die beslissing wordt door de CaCo genomen. 3.2

OVI-tool

3.2.1

GMS Incidenten Informatie

In de meeste meldkamers wordt de OVI-tool, ook aangeduid met „GMS Incidenten Informatie‟, door de CaCo gebruikt. De OVI-tool is een applicatie die incidentgegevens uit GMS ophaalt door polling van de GMS-database via ODBC. De OVI-tool filtert incidentinformatie (zoals incidentnummer, tijdstip, incidentlocatie,en ingezette eenheden) en toont die op een gebruikersvriendelijke en overzichtelijke manier aan de gebruiker. Bovendien worden de berichten uit het zogenaamde Kladblok uit GMS getoond. Dit Kladblok bevat de ruwe, door GMS-gebruikers toegevoegde, informatie over een geregistreerd incident die bij de meldkamer binnenkomt. Kladblokgegevens kunnen handmatig worden overgezet naar het Meldkamerbeeld door deze te selecteren en door middel van de rechtermuisknop te kopiëren naar een te kiezen veld van het MKB. 3.2.2

MKB

Zoals in de vorige paragraaf al beschreven is, bevat de OVI-tool functionaliteit om een MKB op te bouwen en het uit te printen. Informatie uit het Kladblok kan geselecteerd worden en naar het MKB gestuurd. Deze informatie is door GMSgebruikers (centralisten) toegevoegd als aanvullende informatie van een bepaald incident. Het MKB bestaat uit diverse tabbladen. Elk tabblad bevat specifieke informatie over een bepaald veld (slachtoffers, verkeer, veiligheid, enz.). 3.3 3.3.1

GMS-database Overzicht

Figuur 2 op de volgende bladzijde toont het GMS-databaseschema. De schema‟s

van de tabellen (kolommen en datatype) zijn beschreven in het document Tablelisting GMS4.8.0.pdf dat door vtsPN is opgesteld. Welke incidentgegevens naar het CMS gestuurd moeten worden en waar elke waarde in de GMS-database te vinden is, staat beschreven in de volgende paragraaf.

Pagina 7 van 28


Figuur 2: GMS database schema

3.3.2

Voor het CMS relevante incidentgegevens

In onderstaand lijstje staan de gegevens opgesomd, die uit de GMS-database gelezen moeten worden en naar het CMS worden gestuurd, zodra een GMSincident naar het CMS doorgezet wordt:      

GMS-incidentnummer Incidentnaam X,Y-ocatie Ingezette eenheden (zie ook paragraaf 5.3) Tijdstip Kladblokinformatie

Deze informatie is in de GMS-database terug te vinden. De tabel op de volgende bladzijde geeft aan waar de informatie in het GMS te vinden is. Incident gegevens GMS incident nummer Incident naam

Tabelnaam.column naam in GMS database gms_incident.nr_incident

Opmerking van vtsPN

Zie opmerking van vtsPN

Bestaat niet als zodanig. Vaak wordt de locatie gebruikt om een incident te identificeren. Dan is het gms_incident.t_gui_locatie + gms_incident.plaats_naam

X,Y locatie

gms_incident.t_x_coord_loc en gms_incident.t_y_coord_loc Zie opmerking van vtsPN

GMS

Pagina 8 van 28

Voor


ingezette eenheden

Tijdstip

gms_incident.dtg_start_incident

Kladblok informatie

gms_kladblok.inhoud_kladblok_regel

Pagina 9 van 28

eenheden: gms_inzet_eenheid.roepnaam_eenheid (alleen eenheden waar dtg_opdracht_inzet en dtg_start_actie zijn gevuld en waar dtg_eind_actie leeg is zijn op dat moment ingezet). Voor functionarissen: gms_inzet_functie (alleen records waarbij dtg_opdracht_inzet_fsrt is gevuld;). Functienaam staat in gms_functiesooort.oms_functiesoort. Als een specifieke persoon is gekoppeld staat de naam in gms_persoon.naam_persoon. De relatie loopt dan via gms_functie_persoon. Voor brandweerploegen: gms_inzet_ploeg (alleen als dtg_opdr_inzet_ploeg is gevuld). De ploegnaam staat in gms_ploeg.naam_ploeg. De relatie loopt via gms_ploeg_ploegsoort. Het begintijdstip van het incident staat in gms_incident.dtg_start_incident. Er zijn verschillende typen kladblokregels. Afhankelijk van wat je wilt laten zien, kun je bepaalde typen wel of niet gebruiken.


4

Componenten van het CMS

Dit hoofdstuk beschrijft in het kort de componenten van het CMS die in Figuur 1 (op bladzijde 7) geschetst zijn. Het systeem bestaat uit een aantal applicaties die deels gebaseerd zijn op dezelfde componenten. Voor de koppeling tussen GMS en CMS zijn de volgende twee CMS applicaties van belang: CMS-Plot en CMS-Tekst. Voor meer informatie over de technische en functionele specificaties van de CMSsuite wordt verwezen naar de CMS documentatie. 4.1

CMS-Plot

CMS-Plot bestaat uit een drie applicaties die deels gebaseerd zijn op dezelfde componenten:   

CMS Desktop. Applicatie voor het delen van geografische informatie voor gebruik achter het bureau. De benodigde componenten zijn ArcGIS (ArcView), .Net 2.0 en Groove. CMS Light. Lichtgewicht variant van CMS Desktop, gebaseerd op ArcEngine. De benodigde componenten zijn ArcEngine, .Net 2.0 en Groove. CMS Mobile. Vergelijkbaar met CMS Light, maar dan speciaal gemaakt voor gebruik in het voertuig. De benodigde componenten zijn ArcEngine, .Net 2.0, Groove en de EAL-software voor de connectie met de GPSontvanger.

De koppeling GMS-CMS (KGC) zal voor de PoC in eerste instantie alleen voor CMS Desktop ontwikkeld worden. Figuur 3 toont de interface van CMS-Plot (Desktop deel). CMS Desktop draait als een extensie binnen ArcMap en de interface is dus ArcMap. CMS voegt hieraan een aantal elementen toe, te weten een dockable window, en een toolbar met daarop een aantal menu‟s en commands.

Figuur 3: Interface van CMS-Plot (Desktop deel)

Pagina 10 van 28


4.2

CMS-Tekst

CMS-Tekst is een .NET 2 Windows Forms applicatie (zie ook paragraaf 4.3.1). De applicatie kan ingezet worden om te communiceren tussen actoren die zich op verschillende locaties bevinden. CMS-Tekst bestaat globaal gezien uit 2 onderdelen:  Het maken van een totaal beeld.  Het bijhouden van een logboek. Het hoofdscherm ziet er als volgt uit:

Figuur 4: Interface van CMS-Tekst

CMS-Tekst maakt gebruikt van een incident workspace. De workspace dient niet door de CMS-Tekst gebruikers bediend te worden. De controle van het incident vindt volledig plaats in de applicatie. De workspace ziet er in Groove alsvolgt uit:

Figuur 5: Interface van een CMS-Tekst Workspace

Een incident workspace heeft een aantal form tools:    

Beelden: hierin staan alle beelden die beschikbaar zijn voor het incident SituationeelBeeldParagraaf: hierin staan alle door actoren aangeleverde paragraaf teksten Logboek: hierin staan alle door actoren aangeleverde logboekteksten Members: hierin wordt bijgehouden welke actoren online zijn Pagina 11 van 28


  4.3

ConceptParagraaf: Hierin staan paragraafteksten die in aanmerking komen om een totaalbeeld te maken Sitplot Kaart: in deze werkruimte wordt het gedeelde beeld van Sitplot gezet Onderliggende CMS-componenten

CMS-Plot en Tekst zijn gebaseerd op de volgende software componenten:  .NET 2.0  Groove 2007  ArcGIS 9.3.1  ArcEngine 9.3.1 4.3.1

Het .NET 2.0 framework

.NET (uitspraak dotNET) is een applicatieframework ten behoeve van de naadloze samenwerking van applicaties en bibliotheken geschreven in verschillende programmeertalen. Het is ontwikkeld door Microsoft. CMS-Plot en Tekst zijn beide ontwikkeld in de .NET framework. Voor meer informatie over .NET 2.0 wordt verwezen naar: http://msdn.microsoft.com/en-gb/library/zw4w595w.aspx. 4.3.2

Microsoft Groove

Het CMS maakt voor de uitwisseling van gegevens tussen deelnemers gebruik van MS Groove. Groove kan direct tussen twee computers gegevens uitwisselen (peerto-peer) of, indien dit door het ontbreken van netwerkverbindingen of de aanwezigheid van firewalls onmogelijk is, via een relay server. Deze relay server kan een publieke server van Microsoft zijn of een server in eigen beheer. Groove synchroniseert data die zich in een zogenaamde workspace bevindt. Er zijn twee typen workspaces: de file sharing workspace, wat gewoon een folder op het Windows file systeem is die door Groove met andere gebruikers gesynchroniseerd wordt en de gewone Groove workspace. In het CMS wordt alleen gebruik gemaakt van dit laatste type. Een workspace is een verzameling van verschillende „tabbladen‟ die in Groove „tools‟ worden genoemd. Er zijn verschillende type tools zoals file tools waarin files kunnen worden opgeslagen en gedeeld, form tools waarin data in tabelvorm wordt gedeeld, picture tools voor plaatjes, discussion tools en zo meer. Iedere gebruiker van Groove kan workspaces aanmaken. Deze workspaces worden opgeslagen in het lokale profiel van de gebruiker. Vervolgens kan degene die de workspace heeft aangemaakt andere gebruikers voor deze workspace uitnodigen. Wanneer die gebruiker de uitnodiging accepteert wordt de complete workspace direct van de een andere deelnemer op zijn computer gekopieerd, hiervoor wordt nooit een relay server gebruikt. Leden van een workspace kunnen verschillende rechten hebben. Er bestaan drie rollen: manager (minimaal een, meestal de aanmaker van de workspace), participant (uitnodigen, tool toevoegen, files toevoegen, alle files wijzigen, eigen files verwijderen) en guest (alleen kijken). Voor iedere gebruiker van Groove (en dus van het CMS) moet een Groove account bestaan. Deze Groove account kan lokaal gedefinieerd zijn (bijvoorbeeld tijdens de installatie van Groove) of door een beheerder zijn aangemaakt op de Groove manager server. Groove synchroniseert data via het netwerk. Dit kan via verschillende protocollen. Het eigen protocol van Groove heet Simple Symmetric Transport Protocol (SSTP). Voor dit verkeer moet port 2492 in firewalls open staan. Wanneer deze poort niet open staat gaat het Groove verkeer via port 80, Pagina 12 van 28


geëncapsuleerd in HTTP, wat de communicatie aanzienlijk kan vertragen. Meer informatie over de protocollen die Groove gebruikt kan op de volgende website worden gevonden: http://technet.microsoft.com/en-us/library/cc261835.aspx

4.3.3

ArcGIS Desktop, ArcEngine

CMS Desktop maakt gebruik van ESRI ArcGIS Desktop (ArcMap), versie 9.2 of 9.3. Een ArcView licentie is hiervoor minimaal vereist. CMS Mobile maakt gebruik van ESRI ArcEngine, versie 9.2 of 9.3. Een ArcGIS Engine run-time licentie is hiervoor minimaal vereist, maar indien ArcGIS Desktop op de machine is geïnstalleerd en gelicenseerd, kan de Desktop licentie ook gebruikt worden voor CMS Mobiel.

Pagina 13 van 28


5

Koppeling tussen het GMS en het CMS (KGC)

Dit hoofdstuk beschrijft de technische aspecten van de koppeling tussen het GMS en het CMS (Koppeling GMS-CMS, of afgekort KGC). In paragraaf 5.1 worden de uitgangspunten opgesomd. Paragraaf 5.2 beschrijft de algemene systeemarchitectuur. In de twee paragrafen daarna (5.3 en 5.4) wordt een aantal definities en classificaties besproken. Paragraaf 5.5 geeft een detaillering van de KGC door middel van UML activiteitendiagrammen. Tot slot geeft paragraaf 5.6 een overzicht van functionele en niet-functionele eisen waarvan het systeem moet voldoen. 5.1

Uitgangspunten voor de koppeling

Algemene uitgangspunten voor het ontwerp en ontwikkelen van de KGC zijn; 1. Voorlopig wordt de KGC-applicatie ontwikkeld voor een Proof of Concept (PoC). De PoC heeft als doel te bevestigen dat de KGC een belangrijke verbetering brengt voor het werkproces binnen de meldkamer. Keuzes die tijdens de PoC zijn gemaakt (bijvoorbeeld voor de Userinterface of functionele specificaties) kunnen altijd achteraf aangepast worden na afstemming met de opdrachtgever. 2. Voor de PoC zal een testversie van het GMS gebruikt worden (in iedere geval versie 4.7 of hoger). Op dit moment is bij HGM versie 4.7 van het GMS in gebruik. Versie 4.8 is de eerste versie waarin ook de X,Y-coördinaten van het incident door de centralist kunnen worden ingevoerd. In eerdere versies werden x-y-coördinaten op basis van adres ook al opgeslagen. Van deze functionaliteit zal de KGC gebruik gaan maken. 3. Tijdens een van de georganiseerde workshops, werd besloten dat het Incident in één richting (van GMS naar CMS) continue gerepliceerd wordt met updateberichten. In het CMS kan het incident wel uitgebreid worden met informatie die niet in het GMS voorkomt. Deze uitbreidingen kunnen wel gewijzigd worden in het CMS, maar leiden verder niet tot aanpassingen binnen het GMS. 4. De CaCo neemt de beslissing over welke GMS-incidenten naar het CMS gestuurd worden. De KGC applicatie is dus bedoeld voor CaCo en niet voor de andere gebruikers van het GMS. 5. De KGC zal ontworpen worden met zo min mogelijke afhankelijkheden van andere systemen, zoals GMS, Ovi-tool, MKB, enz. 6. De KGC kan gesplitst worden in een Plot en een Tekst-deel. Het Plot-deel zal incidentgegevens (bijvoorbeeld incidentnummer, locatie, tijdstip, actoren die uitgenodigd moeten worden om aan het incident deel te nemen) aan CMS-Plot sturen, terwijl het Tekst-deel ruwe Kladblokinformatie, meldingsclassificatie en karakteristieken aan CMS-Tekst zal sturen. 7. Wat betreft het Plot-deel, zal voor de PoC een koppeling ontwikkeld worden tussen GMS en de Desktop applicatie van het CMS. 8. Wat betreft het Tekst-deel zal tijdens de PoC in eerste instantie het volledige Kladblok van GMS 1 op 1 naar CMS-Tekst worden gestuurd. Daarnaast zal onderzocht worden hoe het MKB in CMS-Tekst moet worden vormgegeven om de informatie voor de CMS-gebruikers toegankelijker te maken. 9. Het filteren en de visuele verbetering van Kladblokinformatie binnen CMSTekst wordt beschouwd als „could have‟ functie voor de PoC, ofwel deze eis mag alleen aan bod komen als er tijd genoeg is. 10. De koppeling wordt geschreven in C# (.NET). VisualStudio 2008 wordt gebruikt als ontwikkelingomgeving. De koppeling wordt ontwikkeld en getest binnen Geodan in een Microsoft Windows XP besturing systeem. Voor de PoC wordt alleen die omgeving ondersteund.

Pagina 14 van 28


De meeste van de hierboven genoemde uitgangspunten zullen meegenomen worden tussen de eisen (functionele en niet functionele) van de eisen diagrammen. 5.2

Algemene architectuur

Figuur 6 schetst de globale architectuur van het Meldkamersysteem gekoppeld aan het CMS door middel van de KGC. De KGC heeft een user interface zoals in het FO beschreven is. De KGC gaat een lijst van open/actieve incidenten tonen waarmee de CaCo kan kiezen welke incidenten naar het CMS worden doorgezet. Verder zorgt de applicatie voor een automatische verversing van de incidentgegevens (zoals Kladblokinformatie) voor de incidenten die al naar CMS doorgezet zijn (abonnement op doorgezette incidenten). De lijst van incidenten in de KGC zal automatisch worden ververst. Nieuwe incidenten worden toegevoegd, incidenten die niet meer in het GMS actief zijn worden verwijderd.

Figuur 6: Meldkamersysteem en crisismanagementsysteem met KGC

5.3

Definities

In deze pararaaf worden de betekenis van GMS-eenheid, Groove Identity, CMS role en actor uitgelegd. GMS-eenheden, die bij een bepaald incident ingezet (of uitgenodigd) moeten worden, worden door middel van de GMS-applicatie gekozen. De eenheden worden opgeslagen in de tabel GMS_INZET_EENHEID, in de tabel GMS_INZET_FUNCTIE of in de tabel GMS_INZET_PLOEG van de GMS-database, zie ook paragraaf 3.3.2.

Pagina 15 van 28


Groove Identity is de “elektronische aanwezigheid” waarmee je herkenbaar bent voor andere Groove gebruikers en met hen interactie kunt hebben. Een Groove Account bevat een of meer Identities. Een identity kan maar aan één account gekoppeld zijn. Een Groove account is een bestand dat lokaal is opgeslagen en verschillende soorten informatie bevat, waaronder de Groove Identity. CMS roles worden binnen het CMS in een configuratiebestand, dat door de applicatie gebruikt wordt, gedefinieerd. Een CMS role bevat informatie over de CMS-gebruiker zoals:  naam;  welke CMS-applicatie hij/zij mag gebruiken;  emailadres;  URI van de bijbehorende Groove identity;  of hij/zij een standaard CMS-Plot/Tekst gebruiker is;  functies van CMS Desktop die beschikbaar voor die role zijn. Voor een compleet overzicht van de attributen van een CMS role element wordt naar de CMS-documentatie verwezen. Hieronder volgt als voorbeeld een fragment van een CMS role in het CMS-configuratiebestand: <externalLinks /> Het is van belang op te merken dat elke CMS role een Groove URI heeft die naar de bijbehorende Groove Identity van de CMS role verwijst. Vaak wordt een CMS role ook actor genoemd. Zodra een GMS incident naar CMS gestuurd wordt door middel van de KGC, worden de volgende acties uitgevoerd:      

Aanmaken CMS-Plot Groove workspace Aanmaken CMS-Tekst Groove workspace Opslaan Incident Plot-gegevens (GMS incident nummer, locatie, enz.) in de CMS-Plot Groove workspace Opslaan Incident Tekst-gegevens (kladblok informatie) in de CMS-Tekst Groove workspace Uitnodigen CMS-Plot actoren om deel te nemen aan de CMS-Plot Groove workspace (dus, let op, een GMS-uitnodiging van GMS-eenheden heeft een andere betekenis dan een CMS-uitnodiging van CMS-Plot actoren) Uitnodigen CMS-Tekst actoren om deel te nemen aan de CSM-Tekst Groove workspace (dus, let op, een GMS-uitnodiging van GMS-eenheden heeft een andere betekenis dan een CMS-uitnodiging van CMS-Tekst actoren)

Pagina 16 van 28


De bovengenoemde activiteiten worden verder in paragraaf 5.5 uitgewerkt. De lijst van CMS-Plot actoren en de lijst van CMS-Tekst actoren kunnen beschouwd worden als onafhankelijke lijsten: ofwel een actor kan uitgenodigd worden voor alleen maar CMS-Plot, voor alleen maar CMS-Tekst of voor beide en dit is in het CMS configuratiebestand vastgelegd. Voor de KGC applicatie moet dus een mapping aanwezig zijn tussen GMS-eenheid, Groove Identity en CMS role (of actor). De mapping tussen Groove Identity en CMS role is al in het configuratiebestand van het CMS vastgelegd, want een CMS role bevat o.a. de URI van de Groove Identity. Ook moet er aan een CMS role nog de GMSeenheid worden toegekend. De koppeling tussen een GMS-eenheid en een CMS role kan op verschillende manieren vastgelegd worden. Een mogelijkheid is de mapping vast te stellen in het CMS-configuratiebestand. De eenheid-ID kan in dat geval toegevoegd worden als attribuut van het CMS role element: …. 5.4

Classificaties

CMS-rollen of actoren die voor een GMS-incident uitgenodigd worden kunnen gegroepeerd worden in de volgende klassen: 1. GMS-eenheden: actoren die vanuit GMS naar CMS gestuurd zijn. Deze actoren worden door de KGC-applicatie vanuit de GMS-DB uitgelezen. De koppeling tussen GMS-eenheid en CMS actor kan in het CMSconfiguratiebestand vastgelegd worden, zie paragraaf 5.3. 2. Standaard CMS actoren: actoren die altijd uitgenodigd worden. Deze actoren worden in het CMS-configuratiebestand opgeslagen. 3. Eventueel: actoren die binnen het CMS handmatig door een CMS gebruiker (Plot of Tekst) uitgenodigd worden.

5.5

Activiteiten KGC

Het doorsturen van een incident van het GMS naar het CMS wordt door middel van het onderstaande UML-diagram beschreven. Het diagram toont de activiteiten die door de KGC-applicatie uitgevoerd worden. Voor elke activiteit is in deze paragraaf een toelichting opgenomen.

Pagina 17 van 28


act KGC Analysis Model

Verv ers incident gegev ens

Incident in CMS aanwezig?

Incident gegevens [aanwezig]

[niet aanwezig] Verv ers incident lij st Opstart KGC

Verv ers kladblok info

Kladblok info

Toon GMS-incidenten Invalide incident?

Kies CMS-incidenten

Zet incident door naar CMS

Maak nieuw e CMS-incident aan

[Valide]

Incident info + [Niet valide] actoren + kladblok info

Incident + actoren + kladblok info

CMS-Plot

CMS-Tekst

Incident + plot actoren Maak CMS-Plot Groov e Workspace aan Incident + plot actoren

Incident

Plot actoren

Zet of v erv ers incident gegev ens in CMS-Plot Groov e Workspace

Nodig uit/Verw ij der Plot actoren

Kladblok info + tekst actoren Maak CMS-Tekst Groov e Workspace aan Tekst actoren

Kladblok info

Tekst actoren Nodig uit/Verw ij der Tekst actoren

Zet of v erv ers kladblok gegev ens in CMS-Tekst Workspace

Toon incident in CMS-Plot

Gebruik incident in CMS-Plot

Gebruik incident in CMS-Tekst

EindActiviteit

Figuur 7: KGC Analysis Model

Opstart KGC Begin van de flow die de activiteiten van de KGC beschrijft. De CaCo is de gebruiker van de KGC. Toon GMS-incidenten Toont een lijst van GMS incidenten die niet afgesloten zijn. In de lijst, wordt de volgende incidentinformatie getoond: Zie FO Een voorbeeld van de interface is weergegeven in paragraaf 5.6.1 door middel van het UML user interface diagram. Kies CMS-incidenten Vanuit de lijst van GMS-incidenten, die op het KGC-scherm verschijnt, kunnen een of meer incidenten gekozen worden die naar het CMS gestuurd zullen worden. Indien geen keus wordt gemaakt, dan is de eindactiviteit van de KGC-activiteiten bereikt, anders wordt het gekozen incident of de gekozen incidenten naar het CMS doorgezet (activiteit: zet incident door naar CMS).

Pagina 18 van 28


Zet incident door naar CMS Incident gegevens bestaan uit: Incident informatie voor CMS-Plot:     

incidentlocatie (X,Y) incidentnaam GMS-incident nummer tijdstip CMS-Plot actoren ofwel CMS-Plot Groove gebruikers (te vinden in CMS configuratie bestand)

Incident informatie voor CMS-Tekst:  

CMS-Tekst actoren ofwel CMS-Tekst Groove gebruikers (te vinden in de CMS configuratie bestand) inhoud van het GMS Kladbok tabel (vanuit de GMS-database) _+ meldingsclassificatie en karakteristieken?

Invalide incident? Bij deze activiteit wordt gecheckt of een gekozen GMS incident een valide CMS incident is (minimaal moeten nummer, naam, locatie en tijdstip toegewezen worden). Indien het gekozen incident invalide is, dan is de eindactiviteit van de KGC activiteiten bereikt, anders wordt een nieuw CMS-incident aangemaakt (vervolgactiviteit: Maak nieuw CMS-incident aan). Maak nieuw CMS-incident aan Zodra een GMS-incident naar het CMS wordt gestuurd, wordt een CMS-incident aangemaakt. Vanuit deze activiteit worden de activiteiten gesplitst tussen CMS-Plot en CMS-Tekst activiteiten (zie grenzen CMS-Plot en Tekst in het diagram). Maak CMS-Plot Groove Workspace aan Een nieuwe CMS-Plot Groove workspace wordt automatisch aangemaakt door de KGC. Nodig Plot actoren uit Voor de classificatie van CMS-Tekst actoren zie paragraaf 5.4. Zet of ververs incident gegevens in CMS-Plot Groove Workspace Incidentgegevens (GMS-nummer, naam, X,Y-locatie, tijdstip) worden in een Groove form, opgeslagen. Een Groove form is een soort tabel. Hierin zitten records met allerlei informatie, waaronder ook de locatie van een object en incidentattributen. Toon incident in CMS-Plot Het incident wordt in CMS-Plot (Desktop) getoond. Gebruik incident in CMS-Plot Het incident wordt in CMS-Plot (Desktop) door de Plot actoren, die uitgenodigd zijn, gebruikt. Maak CMS-Tekst Groove Workspace aan Een nieuwe CMS-Tekst Groove workspace wordt automatisch aangemaakt door KGC. Nodig Tekst actoren uit Voor de classificatie van CMS-Tekst actoren zie paragraaf 5.4.

Pagina 19 van 28


Zet of ververs kladblok gegevens in CMS-Tekst Workspace De Kladblokinfo voor het gekozen GMS incident wordt 1:1 doorgezet naar het tekstdeel van CMS. Gebruik incident in CMS-Tekst Het incident wordt in CMS-Tekst door de Tekst actoren, die uitgenodigd zijn, gebruikt. Ververs incident gegevens De KGC zal elke N seconden automatisch gegevens van een doorgezet (en niet afgesloten) incident verversen (abonnement op doorgezette incidenten). Bijvoorbeeld als een nieuwe GMS-eenheid aan een doorgezette incident wordt toegekend, moet de informatie automatisch naar het CMS gaan. De verversingsfrequentie is instelbaar in een configuratiebestand. Incident in CMS aanwezig? Het wordt gecheckt of een gekozen GMS incident al in het CMS bestaat. Indien het incident niet in het CMS bestaat, dan is de eindactiviteit van de KGC-activiteiten bereikt. Anders worden de incidentgegevens ververst (vervolg activiteiten: Zet of ververs incident gegevens in CMS-Plot Groove Workspace, Nodig Plot actoren uit, Nodig tekst actoren uit). Ververs incidentlijst De KGC zal elke N seconden de lijst van GMS–incidenten, die niet afgesloten zijn, verversen. De verversingsfrequentie is instelbaar in een configuratiebestand. Ververs kladblok info De KGC zal elke N seconden de kladblok informatie, die naar CMS gestuurd is, automatisch verversen. De ververstijd is instelbaar in een configuratie bestand. EindActiviteit Eind van de flow die de activiteiten van het KGC systeem beschrijft. Eindactiviteit kan zijn: 1. 2. 3. 4. 5.

5.6

het GMS-incident is niet naar het CMS gestuurd het GMS-incident wordt naar het CMS gestuurd, maar het incident is invalide het GMS-incident is naar het CMS gestuurd en is valide GMS-kladblok gegevens voor een bepaald incident zijn ververst GMS-incident gegevens moeten ververst worden, maar het incident is niet in CMS aanwezig

Systeemeisen KGC

Deze paragraaf beschrijft de functionele en niet-functionele eisen, waaraan het systeem moet voldoen. De eisen worden beschreven door middel van UMLeisendiagrammen. 5.6.1

Functionele eisen

Functionele eisen beschrijven algemene eisen (features), business regels, functies die het voorgestelde systeem moet ondersteunen. Functionele eisen voor het KGC kunnen geklassificeerd worden in de volgende groepen of in UML-termen, packages die in Figuur 8 getoond zijn: 1. Beheer GMS-incidenten: deze package bevat systeemeisen m.b.t. de gebruikersinteractie. Hier worden eisen vastgesteld die in de usecase-

Pagina 20 van 28


diagrammen van het FO te vinden zijn. 2. Business rules: deze package beschrijft regels die binnen de applicatie geïmplementeerd moeten worden. Deze regels zijn acties die uitgevoerd worden door de applicatie zelf als gevolg van een interactie van de gebruiker met het systeem. De eisen van de business rules package worden dan gesplitst tussen eisen voor het CMS-Plot en Tekst gedeelte. 3. User interface: hier wordt een voorbeeld van de user interface in een UMLdiagram weergegeven. De user interface is verder uitgewerkt in het FO. In deze paragraaf worden de drie packages verder beschreven.

Figuur 8: Functionele eisen packages

"Beheer GMS-Incidenten" Package Figuur 9 toont de inhoud van de package “Beheer GMS incidenten”. De onderdelen van de package worden onderaan verder beschreven.

Pagina 21 van 28


custom Beheer GMS Incidenten

Figuur 9: Beheer GMS-Incidenten package

CaCo De CaCo is de gebruiker (actor) van de KGC. Beheer GMS Incidenten De CaCo beslist welk GMS-incident naar CMS gestuurd moet worden Lijsten GMS incidenten Zie FO Maak CMS incident aan Zodra een GMS-incident naar het CMS wordt gestuurd, wordt een CMS-incident aangemaakt. Stuur incident(en) naar CMS De CaCo kiest vanuit de lijst welk GMS-incident naar het CMS gestuurd moet worden.

"Business Logic" Package Figuur 10 toont de inhoud van de package “Business Logic”. De onderdelen van de package worden onderaan verder beschreven.

Pagina 22 van 28


Figuur 10: Business Logic package

Ververs incidentenlijst De KGC zal elke N seconden de lijst van GMS incidenten die niet afgesloten zijn verversen. De verversingsfrequentie is instelbaar.

"CMS-Plot" Package Figuur 11 toont de inhoud van de package “CMS-Plot”. De onderdelen van de package worden onder de figuur verder beschreven.

Pagina 23 van 28


custom CMS-Plot

Figuur 11: CMS-Plot package

Maak CMS-Plot Groove Workspace aan Zodra een GMS-incident naar het CMS is gestuurd, wordt een CMS-Plot Groove workspace aangemaakt waarin de Plot incidentinformatie wordt opgeslagen (locatie, nummer, naam, tijdstip, actoren). Puntlocatie wordt opgeslagen in WKT-formaat en de rest in een Groove form. Nodig Plot actoren uit Aan het incident wordt in de dagelijkse situatie automatisch in GMS een aantal actoren gekoppeld. Hier kan handmatig aan worden toegevoegd (in het GMS). Zodra opschaling plaats vindt en het incident wordt doorgezet naar het CMS moet deze lijst met actoren in het CMS terechtkomen (via de KGC). Vervolgens kunnen binnen het CMS meer actoren worden toegevoegd, indien nodig. Toon incident in CMS-Plot Het GMS incident wordt binnen de interface van CMS-Plot (ArcGIS Desktop) getoond. Ververs incident gegevens De KGC gaat automatisch gegevens van een doorgezet incident verversen (doorgezette incidenten). Bijvoorbeeld als een nieuwe GMS-eenheid aan een doorgezet incident wordt toegekend, moet de informatie automatisch naar het CMS gaan.

"CMS-Tekst" Package Figuur 12 toont de inhoud van de package “CMS-Tekst”. De onderdelen van de package worden onderaan verder beschreven.

Pagina 24 van 28


custom CMS-Tekst

Figuur 12: CMS-Tekst package

Maak CMS-Tekst Groove Workspace aan Zodra een GMS incident naar CMS gestuurd is, wordt een CMS-Tekst Groove workspace aangemaakt waarin de tekst incident informatie wordt opgeslagen (uit de GMS kladblok). De kladblokinfo uit het GMS wordt 1:1 doorgezet naar het tekstdeel van het CMS met dezelfde id als het incident in plot. Nodig Tekst actoren uit. Aan het incident worden in de dagelijkse situatie automatisch in GMS een aantal actoren gekoppeld. Hier kan handmatig aan worden toegevoegd (in het GMS). Zodra opschaling plaats vindt en het incident wordt doorgezet naar het CMS moet deze lijst met actoren in het CMS terechtkomen (via de KGC). Vervolgens kunnen binnen het CMS meer actoren worden toegevoegd, indien nodig. Ververs van kladblok info De KGC zal elke N seconden de kladblok informatie, die naar CMS gestuurd is, automatisch verversen. De verversingsfrequentie is instelbaar.

"User Interface" Package

Pagina 25 van 28


Figuur 13: toont de inhoud van de package “User Interface”. Dit is een voorbeeld van de user interface van de koppeling. Meer informatie over de functionele eisen van het systeem is in het FO te vinden.

UI: Zie FO. custom User Interface

Figuur 13: User Interface package

5.6.2

Niet-functionele eisen

Niet functionele eisen hebben vooral te maken met: softwareversie, performance, veiligheid en schaalbaarheid. Voor de KGC wordt vooral aandacht gegeven aan de software-eisen, die in Figuur 14 getoond zijn.

Pagina 26 van 28


Figuur 14: Non-Functional Requirements package

"Software Dependencies" Package Figuur 15 toont de inhoud van de package “Software Dependencies”. De onderdelen van de package worden onderaan verder beschreven. custom Softw are Dependencies

Figuur 15: Software Dependencies package

Pagina 27 van 28


CMS-Plot software-eisen CMS-Plot API wordt door de koppeling gebruikt om een incident van GMS naar CMS te sturen. Deze API maakt gebruik van ESRI ArcObjects en Groove API. Voor software eisen van de CMS-Plot API wordt verwezen naar de technische documentatie van het CMS. CMS-Tekst software-eisen Kladblok informatie en incidentgegevens worden naar CMS-Tekst gestuurd. Voor software-eisen van CMS-Tekst wordt verwezen naar de technische documentatie van het CMS. GMS 4.8 of hoger Op dit moment is bij HGM versie 4.7 van het GMS in gebruik. Versie 4.8 is de eerste versie waarin ook de X,Y-coördinaten van het incident kunnen worden opgeslagen. (zie eerdere opmerkingen over opslag en invoer x-y-coordinaten) Voor de PoC zal een testversie van het GMS gebruikt worden. Daardoor kan er voor de PoC met elke gewenste versie gewerkt worden (in iedere geval > 4.8). GMS-database connectie via ODBC In deze PoC wordt ODBC als koppeltechniek gebruikt. In een later stadium kan die vervangen worden door een koppeling met webservices. Webservices zijn voor het GMS gepland voor 2010.

Pagina 28 van 28

Technisch ontwerp. Koppeling GMS i-bridge. Versie 1.0. Datum 22 December 2010

Recommend Documents