Technologie werkgroep
Deze thematische werkgroep richt zich op het identificeren en in kaart brengen van de technologie die nodig is om het traject technisch werkbaar te maken. Onder technologie verstaan we hardware, software en hybride infrastructuur. In deze werkgroep kijken we samen welke bouwstenen nodig zijn om tot de oplossing(en) te komen voor de use cases die tijdens de vorige werkgroepen werden gedefinieerd. De Werkgroep staat open voor deelname door de gehele quadruple helix.
De tweede thematische werkgroep vond plaats op 23 mei 2024.
Context
Initiatief
VERA werkt samen met verschillende lokale besturen en de provincie Vlaams-Brabant om het probleem van modderstromen als gevolg van bodemerosie aan te pakken. Meer dan 100 gemeenten in Vlaanderen ondervinden bodemerosie, wat aanzienlijke schade kan veroorzaken aan zowel private eigendommen als publieke infrastructuur. Door klimaatverandering, trends in de landbouw en verharding zal dit probleem naar verwachting in de toekomst verder versterkt worden. Op dit moment worden erosiepoelen gebruikt als oplossing. Deze poelen worden onderaan de helling aangelegd om modderstromen op te vangen en te voorkomen dat ze schade veroorzaken. Deze erosiepoelen zijn uitgerust met sensoren en overlopen, waardoor het water op een gecontroleerde en langzame manier kan wegstromen. De vraag die zich stelt, is of deze erosiepoelen effectief zijn. Er bestaat onzekerheid over hun capaciteit en functionaliteit, vooral in noodsituaties. Het is essentieel om dit op een kostenefficiënte manier te monitoren, met als doel zowel acute waarschuwingen bij rampen als proactieve oplossingen voor het probleem. Er wordt nagedacht over het gebruik van peilmeters of debietsensoren om de erosiepoelen te monitoren. Hiermee kan worden bijgehouden hoeveel water door de overlopen gaat. Hoewel dit geen exacte voorspellingen oplevert, biedt het wel inzicht in de hoeveelheid neerslag.
Het overkoepelende doel van het project is om een gecentraliseerd dataplatform op te zetten en een raamcontract te ontwikkelen voor de sensoren. De verzamelde data kunnen gedeeld worden met rioolbeheerders, landbouwers en verzekeringsmaatschappijen, omdat deze informatie waardevol kan zijn voor alle betrokken partijen.
VLOCA
VLOCA, de Vlaamse Open City Architectuur, is een initiatief van het Agentschap Binnenlands Bestuur van de Vlaamse Overheid. De hulp van VLOCA aan lokale besturen start bij het scherpstellen van duidelijke, verstaanbare use cases en loopt door tot de aanbestedingsfase van het project. VLOCA vormt op deze manier een duidelijke brug tussen de beleidsdoelstellingen van het lokale bestuur en de technische laag waarin de oplossingen beschreven en geïmplementeerd worden. We stellen de juiste vragen en verzamelen de noden en behoeften van alle stakeholders (lokale besturen, kenniscentra, bedrijven en burgerorganisaties). Door een gestructureerde aanpak en verwerking van deze informatie wordt de ontwikkeling van herbruikbare bouwblokken, standaarden en normen gestimuleerd die van Vlaanderen één grote interoperabele slimme regio kunnen maken. De opgedane kennis en ervaring wordt ontsloten via een kennishub waarop onder andere draaiboeken, architectuur componenten en modellen ter beschikking gesteld worden voor alle andere lokale besturen en stakeholders.
VLOCA-model
De start van elk VLOCA-traject begint bij een VLOCA-model:
| ID | Samenvatting | Beschrijving |
| UC1 | UC1: Sensoren | Verschillende actoren willen verschillende types sensoren kunnen plaatsen en beheren (bv. onderhoudsplan). |
| UC2 | UC2: Data Captatie | Ik wil als gebruiker alle informatie correct binnenkrijgen (context, data, goede transmissie) |
| UC3 | UC3: Dataplatform | Ik wil als gebruiker een visualisatie zien van alle data zodat ik deze kan analyseren.Ik wil als gebruiker data kunnen toevoegen, aanpassen, delen en opslaan. |
| UC4 | UC4: Dashboarding | Ik wil als gebruiker een dashboard kunnen hanteren met KPI's (bv kleurencodes) die ik zelf kan beheren in functie van de data. |
| UC5 | UC5: Message Center | Ik wil als gebruiker via mijn tool contacten kunnen aanspreken, toevoegen, wijzigen en behandelen (messaging systeem). |
| UC6 | UC6: Predictie | Op basis van de verworven data wil ik modellen kunnen gebruiken om predicties uit te voeren zodat er tactisch advies gegeven kan worden. |
| UC7 | UC7: Mitigatie | Op basis van real time data en advies wil ik als lokaal bestuur kunnen reageren om de schade te minimaliseren (crisis management). |
| UC8 | UC8: Preventie | Als lokaal bestuur wil ik een overzicht krijgen van adviezen, acties en aanbevelingen om modderstromen te vermijden. |
| UC9 | UC9: Advies | Op basis van data van modderstromen wil ik dit kunnen analyseren, correlaties zien en advies verlenen. |
| UC10 | UC10: Marktplaats | ik wil als gebruiker data en datasciencemodellen kunnen aanbieden en verkrijgen. |
| UC11 | UC11: ROI | Business Modelling |
| UC12 | UC12: Helpdesk | Helpdesk - FAQ - Reviews |
Tijdens deze werkgroep staan we stil bij use cases 2-5.
In de onderstaande figuur zie je een visuele voorstelling van dit VLOCA-model:
Brainstormsessie
Het doel en de aanpak van de brainstormsessie worden hieronder beschreven. Tevens wordt de uitkomst van de brainstorm hierin samengevat.
Doel
Het doel van de brainstormsessie is het volgende:
- Zicht krijgen op de wensen mbt het dashboard
- Zicht krijgen op de wensen mbt het message center
- Inzicht krijgen in het data management
- Valkuilen en principes identificeren
- Nadenken over verduurzaming ifv de keuze voor een bepaalde databron
In de onderstaande figuur wordt het proces weergegeven dat zich afspeelt binnen het dataplatform:
Oefening 1
Instructies
Bij deze oefeningen stonden we stil bij de volgende vragen:
Welke soort dashboards zijn interessant voor de verschillende doelgroepen? Welke parameters wil je kunnen monitoren? Hoe wil je dat je data gevisualiseerd wordt? Welke inzichten wil je krijgen? Wie heeft toegang tot het dashboard? Wie heeft welke rechten om wat te kunnen?
Voorbeeld:
-Als rampen coördinator wil ik toegang tot het regionaal dashboard
-Ik wil de waterstand van een bepaalde stroom kunnen zien
-Een rapport trekken over temperatuur
-Een visualisatie over luchtvochtigheid over een bepaalde periode
-Ik wil een melding zien wanneer een bepaalde waarde overschreden is
Output
| Parameters |
| Hoeveelheid (voorspelde) neerslag in grafiek |
| Check of alle sensoren nog werken |
| Werking sensoren/ status batterij/GPS... |
| Iets zoals bij waterinfo VMM : https://www.waterinfo.be/Themas#item=overstroming/actueel |
| Vullingsgraad van de poel (in kader van technisch onderhoud) |
| Zelfs over historische data moeten snelle queries mogelijk zijn |
| Performantie Queries |
| Alerts moeten op verschillende applicaties/devices mogelijk zijn en configureerbaar wie welke alerts krijgt. Elke stad kan zijn eigen configuratie hierin doen. Scheiding op tenant=stadsniveau? (je kunt niet in de data van een andere stad kunnen zien) |
| Scheidingslijnen : data governance => is dit relevant voor modderstromen ? |
| Rechtstreekse koppeling naar brondata met dashboardapplicaties zodat eigen dashboards met bijv. PowerBi makkelijk gemaakt kunnen worden en automatisch geupdated worden (read only). Dit wel met al de security vereisten: alleen eigen data kunnen zien, binnen een stad een hierarchie wie wat mag zien. |
| vaste dashboard, vs dynamische/self service dashboard, integratie in bestaande lokale dashboard |
| Stakeholder : Academici : Inzicht: vul- en ledigingscurves |
| Stakeholder : Academici : Inzicht: historische data |
| Stakeholder : Academici : Inzicht: makkelijk data kunnen downloaden voor verder onderzoek |
| Stakeholder : Academici : Maximale vulpeilen van buffers (of andere %) in grafiek |
| Rampcoördinatie: predictie van tijdstip van overlopen (+ aftelklok) |
| Rampcoördinatie: op kaart groen/geel/oranje/rood |
| Technische teams : Onderhoud: datum laatste onderhoud (poelen & sensoren) |
| Technische teams : Onderhoud: percentage van oorspronkelijke buffercapaciteit die er nog is |
| Technische teams : Onderhoud: bijhouden wie onderhoud heeft uitgevoerd |
| Lokale input interface van alle informatie bij het ruimen bvb. (feedback loop) |
| Landbouwers goed bij betrekken |
| Bodemvocht |
| Stakeholder |
| Jonge vs oudere generaties |
| Neerslag gegevens |
| Stakeholders: omwonenden goed bij betrekken |
| Als landbouwer toegang tot de volgende data: hoeveelheid grond die afgestroomd is, bodemvocht (via de sensoren), hoeveelheid neerslag die gevallen is, ... en dit allemaal overzichtelijk gepresenteerd in de tijd. Ook eventuele alerts (van het vollopen) gaan handig zijn voor hem |
| Overzicht van de statussen van de buffers op kaart (gekleurde puntjes bvb) |
| Mobiel toegankelijke website |
| Bedenking: mogelijkheid aansluiting met andere toepassingen (vb Sirio van sumaque of flood4cast van hyrdroportal) - deze tool moet niet allés zelf kunnen, focus op poelen |
| Data space ? |
| Dashboard dient te kunnen linken met datalake in de cloud, real time gevoed kunnen worden door IoT standaard technologie om metingen van de sensoren via fabrikant en globale protocollen tot in de omgeving te krijgen die het dashboard kan gebruiken, een service die OSLO compliant data publiceert van dezelfde bron is beter te gebruiken vanaf de service of de store. Dashboard dient geo selecties mogelijk te maken en kan native integreren met MS PowerBI, MS Excel en heeft open API. Parameters moeten niet beperkt zijn in type |
Discussie
Oefening 2
Instructies
Wie wanneer contacteren? Welke type van communicatie gaan we hebben met de gebruikers en in welke scenario? Hoe verzamel je de contactpersonen? Hoe kan je een goede opvolging implementeren?
Voorbeeld:
·Contact persoon x moet gecontacteerd worden in geval een erosiepoel is overstroomd om efficiënte en snelle ontruiming te voorzien?
Output
| Notificaties, communicatie en procesflow |
| Eerste melding: 75% vulling en neerslag voorspeld |
| Melding als poel overstort |
| Melding als poel aan schoonmaak toe is |
| Afhankelijk van voorspelde impact - voorbeeld poel in buurt van veel kritische infrastructuur |
| Een opt-in voor verschillende soorten meldingen (inschrijven wie wil) |
| GDPR |
| Status van afhandeling van alerts. Als er actie moet ondernomen worden, moet er kunnen aangeduid worden dat het ontvangen is en in verwerking door die persoon of dat team. Dus alerts leven ook op een desk waar status aanpassingen, comments en doorverwijzingen mogelijk zijn. |
| Burgemeester |
| Brandweer |
| De Lijn (als er bus passeert) |
| Omwonenden |
| Riool-beheerder |
| Valkuil: hoe spamming/te veel aan berichtjes vermijden. |
| bvb "be alert" |
| Proces ? |
| bvb "bin" (buurt informatie netwerken) via de politie |
| Ramp- coördinator |
| Technische dienst |
| Politie |
| Provincie |
| Ploeg van wacht als eerste contact bvb ? |
| Zou hiervoor standaard technologie gebruiken zodat je ontwikkeling en onderhoud minimaliseert. Je hoeft dan enkel configuratie te doen en je kan zowel emails, SMS, ... sturen als ook pompen aansturen of andere acties automatiseren. Bijvoorbeeld GeoEvent Server |
| Alert voor stroomafwaarts liggende buurtbewoners indien kans op overlopen poel (en indien relevant natuurlijk) |
| Koppeling met BE-Alert |
| Afhankelijk van urgentie een ander kanaal. Niets is zo storend/ineffectief als een kanaal met overbodige alerts waar geen acties aan gekoppeld moeten worden. |
| Hoogdringend: gsm |
| Belangrijk maar geen onmiddellijke actie: email |
| Om in de achtergrond in de gaten te houden: dashboard specifiek voor monitoring |
| proces uittekenen wie krijgt wat wanneer en hoe (welke kanaal)? |
| Opsplitsing wie men op de hoogte brengt in functie van evolutie situatie metingen in poel. |
Discussie
Oefening 3
Instructies
Hoe ga je data beheren/gebruiken eens dat je deze gecapteerd hebt via de verschillende databronnen? Hoe lang wil je de data bijhouden? Hoe vaak moet de data verzameld worden (frequentie)? Wie neemt de verantwoordelijkheid voor data? Hoe er voor zorgen dat data juist geïnterpreteerd wordt? Welke profielen/rollen zullen met de data werken? Hoe zorgen we voor continuïteit bij ingebruikname van bvb nieuwe sensoren?
Voorbeeld:
-De milieu ambtenaar die voorheen geen data had, wilt nu kunnen inloggen op het dashboard om de ruwe data te downloaden voor analyses te kunnen doen
-Je hebt een data ingenieur nodig van data captatie tot ontsluiten van de data
Output
Discussie
Oefening 4
Instructies
Welke zijn de valkuilen waar we volgens jou rekening mee moeten houden?
Formuleer enkele basisprincipes waaraan de oplossing moet voldoen
Voorbeeld:
•Te veel dashboarden waardoor je geen overzicht meer hebt
•Complexe dashboard
•Verantwoordelijkheid van data
Output
Discussie
Oefening 5
Instructies
Hoe kunnen we de oplossing verduurzamen?
-Hoe houden we het budget onder controle?
-Wat met ‘coverage’? Hoeveel sensoren heb ik nodig om een representatief beeld te krijgen? Is dit haalbaar en beheersbaar?
-Uitbesteden vs zelf data capteren
-Uitrol project in grotere regio
-Hoe bouwen we een business model op hiermee?
-Schaalbaarheid, rol van provincie, Vlaanderen. Wie heeft/beheerd zo’n platform?
Output
Discussie
Opname en Miro bord
Miro bord
Het Miro bord kan je consulteren via deze link.
Opname
De opname van deze sessie is te bekijken via deze link.
Volgende stappen
Wat na deze werkgroep?
- Verwerking van de input van de brainstorm oefening.
- Verder onderzoek en voorbereiding van de analyse.
- Publicatie op de Kennishub.
Feedback kan bezorgd worden aan laurien.renders@vlaanderen.be
Andere werkgroepen
| Werkgroep | Type werkgroep | Datum | Tijd | Locatie |
|---|---|---|---|---|
| Business werkgroep | Business werkgroep | 2024-02-29 | 13u30-16u30 | Provinciehuis Leuven |
| Thematische werkgroep 1 | Data en informatie werkgroep | 2024-03-19 | 9u-12u | Teams |
| Thematische werkgroep 2 | Functionele werkgroep | 2024-04-18 | 9u-12u | Teams |
| Thematische werkgroep 3 | Technologie werkgroep | 2024-05-23 | 9u-12u | Teams |