YAVC komt met de mogelijkheid analyse data te ontsluiten via een publieke API. Publiek wil hier zeggen: beschikbaar voor zover de server waarop de API draait beschikbaar is. Vaak is dit dus enkel binnen een (al dan niet virtueel) privaat netwerk, waardoor de API dus alsnog is afgeschermd van de buitenwereld. Sowieso geldt dat een gebruiker van de API zich moet authenticeren.
Kenmerken API
De API van YAVC is opgebouwd volgende principes van REST. De belangrijkste consequenties hiervan zijn: er is geen ‘status’, elke aanroep van de API gebeurt afzonderlijk zonder relatie met andere aanroepen. Daarnaast is de data op te roepen via eenduidige endpoints en kan sprake zijn van caching van data.
De API is uitsluitend benaderbaar na authenticatie van de client middels OAuth 2.0. Hioervoor is een identity provider (IdP) nodig waarmee, bijvoorbeeld middels client credentials, een access token kan worden opgehaald.
Technische kenmerken: de API is gemaakt met ASP.NET Core en draait normaal gesproken achter een reverse proxy webserver. Het versiebeheer van de API verloopt via de http-headers.
Het is raadzaam enige voorzichtigheid te betrachten bij gebruik van de publieke API: zeer intensief gebruik (wanneer bv. meerdere gebruikers continu veel data op gaan vragen) zal de server belasten, alsook de database; dit kan de werking van YAVC negatief beïnvloeden. De API buffert geen data/gebruikt geen cache en zal dus bij elke call de database raadplegen.
Bij regulier gebruik van de API, bv. voor periodiek ophalen van nieuwe analyse data, is hiervan evenwel geen sprake, ook niet wanneer het meerdere apps betreft. Wordt intensief gebruik voorzien, dan is een proxy service die zorgt voor buffering/caching aan te bevelen.
Authenticatie
De API kan pas worden bevraagd nadat is geauthenticeerd: voor het bevragen van de API is namelijk een Json Web Token (JWT) ofwel bearer token nodig dat met elke API call moet worden meegestuurd. Het gehanteerde protocol heet OAuth 2.0, met gebruik van de client credentials flow. Zie dit artikel voor details.
Gebruik van de API
De API is voorzien van ingebakken documentatie middel “swagger”, wat voldoet aan de OpenAPI stndaard. De documentatie is na installatie benaderbaar via https://<server>:<poort>/swagger. De API is momenteel opgedeeld in twee delen, met elk een aantal endpoints (=mogelijkheden data op te vragen). Hieronder een zeer beknopt overzicht, zie verder via swagger:
/{id} = meta data voor kruising met id (dit is een getal)
/{id}/analysis/{analysisId} = opvragen analyse data van type analysisId voor kruising id (zie swagger voor details)
YAVC (https://<server>:<poort>/api/yavc):
/analysisdetails = opvragen lijst met alle beschikbare typen analyse
/metaconfiguration = opvragen lijst met geconfigureerde meta data velden – inclusief statische velden die altijd mee komen
De documentatie omvat informatie over de beschikbare API calls, alsook de data objecten die terug komen als resultaten van dergelijke calls. De informatie komt default in json formaat terug. Is er noodzaak om te werken met XML dan kan CodingConnected dit in overleg mogelijk maken.
Praktisch gebruik: een typische use case
Een gebruikelijke use case voor de api is bijvoorbeeld: ontsluiten van intensiteitsdata naar een externe applicatie. Hieronder een beknopt stappenplan waarmee dit mogelijk wordt gemaakt.
Opvragen analyse data
Ten eerste moet de authenticatie via OAuth2 worden geregeld. Zie hier boven bij authenticatie: client id en secret moeten bekend zijn, alsook het juist ip of domein waar de identity server draait. Het is raadzaam het ophalen van een token te testen, bijvoorbeeld met gebruik van de tool insomnia.
Om analyse data op te halen hebben we aantal gegevens nodig:
Type analyse: voor de aanvraag hebben we het id nodig. Voor intensiteiten is dit 1. Alle id’s zijn op te vragen via het endpoint https://<server>:<poort>/api/yavc/analysisdetails
Interval: in blokken van welke grootte moet de data terugkomen? Het minimum is 5 minuten, en het is raadzaam een interval te kiezen waarvan een veelvoud precies in een uur past. Bv.: 15 min.
Start en einde van de periode waarover we data willen hebben
Als we dit hebben kunnen we een endpoint opbouwen om de data op te vragen, bijvoorbeeld:
Stel we gaan uit van kruispunt 1, analyse intensiteiten ofwel id 1, interval 15 min, start datum/tijd is 16-03-2021 08:00, eind is 16-03-2021 10:00
Dan wordt het endpoint: https://<server>:<poort>/api/intersections/1/analysis/1?intervalInMinutes=15&from=20210316080000&to=20210316100000
Let vooral op de omzetting van de datum/tijd waarden naar tekst: dit volgt het formaat yyyyMMddHHmmss
Sturen we dit verzoek naar de api, en zijn we geauthenticeerd, dan komt de data, indien aanwezig terug
Api respons
Uitgaande van het stappenplan hierboven zal het volgende terugkomen:
We zien hier dat we de kruispunt en analyse id terugkrijgen, alsook de bijbehorende namen. Tevens komen start en einde voor de volledigheid terug in het resultaat. Vervolgens komt de eigenlijke data, met per resultaat per item een item in de lijst “data”. Per item is er een index nummer, een naam, een tijd (de start tijd van de data voor dit blok) en een waarde. Merk hierbij op:
De tijd is de start tijd. De data is opgedeeld in blokken conform het opgegeven interval. Waar staat “time”: “2021-03-16T08:00:00” geldt dus dat de navolgende waarde, de waarde is voor het tijdvak vanaf dat moment tot ‘interval’ minuten daarna. In dit voorbeeld dus 15 minuten, dus 40 voertuigen tussen 8:00 en 8:15
De “waarde” heeft uitsluitend betekenis gerelateerd aan enerzijds het interval, en anderzijds het type analyse. Zonder die informatie is de waarde zomaar een getal
Ten slotte volgen nog twee velden: ‘dataIncomplete’ en ‘missingRanges’. De eerste is een boolean (waar of onwaar) en geeft aan of er sprake is van gaten in de data. De tweede is een lijst van evt. perioden waarvoor de data ontbreekt in het opgevraagde tijdvak. Hieronder een voorbeeld, wanneer we data opvragen uit de toekomst:
Het veld ’type’ is hier een placeholder en wordt momenteel niet gebruikt.
Geen data beschikbaar?
Behoudens gaten in de data kan het ook zijn dat er überhaupt niet beschikbaar is. Dit is zo wanneer er voor (een deel van) de opgevraagde periode geen analyse configuratie beschikbaar is. Niet-beschikbaar-zijn geldt natuurlijk ook voor de toekomst, maar gezien de interne werking van YAVC is er wel een geldende analyse configuratie voor de toekomst, namelijk de laatst geldende configuratie die geldig is tot in de eeuwigheid.
Wordt data opgevraagd voor een periode waarvoor geen geldige analyse configuratie beschikbaar is, dan geeft de api een 500 melding terug, met de volgende inhoud:
{
"type": "https://tools.ietf.org/html/rfc7231#section-6.6.1",
"title": "An error occurred while processing your request.",
"status": 500,
"detail": "Intersection with id 1 has no analysis configuration for the period between 3/16/1874 8:00:00 AM and 3/16/1874 10:00:00 AM",
"traceId": "|503635f1-4f4e1ef976386b46."
}
Dit geldt tevens wanneer voor de opgevraagde periode er meer dan één configuratie geldig is; dit wordt niet ondersteund want er kunnen geen eenduidige resultaten worden teruggegeven.
Binnen YAVC wordt VLOG data verzameld en opgeslagen: dit is (vooralsnog) de voornaamste databron, en dit is om die reden een cruciaal systeemonderdeel. Zonder data kan er geen fasenlog worden getoond, en niets worden geanalyseerd. Een goede omgang met en rapportage omtrent fouten in de dataverzameling is daarom van cruciaal belang.
Bij dataverzameling geldt als uitgangspunt voor omgang met fouten:
Zodra het stilvallen van de dataverzameling de integriteit van de analyse in gevaar brengt, moet YAVC hierover een melding (kunnen) afgeven.
In de praktijk betekent dit dus dat zodra er sprake is van het gevaar op permanent dataverlies, de centrale in staat moet zijn hier melding van de maken.
Aanpak bepalen gevaar op dataverlies
YAVC kan data verzameling op een aantal manieren:
Streaming VLOG:
direct vanaf de automaat, of
indirect vanaf een service die de VLOG stream beluisterd en verder distribueert
File based VLOG:
ftp
sftp
lokaal benaderbare map die wordtr doorzocht op nieuwe aanwezig bestanden
Afhankelijk van het type dataverzameling is er meer of minder snel sprake van een urgente situatie wanneer er geen data binnen komt:
Streaming VLOG:
Gezien de aard van streaming VLOG ontstaat er een gat in de data zodra de verbinding wordt onderbroken. Ook een kortstondige onderbreking veroorzaakt direct dataverlies.
Een sporadisch gat in de data van 5 minuten hoeft niet altijd direct een ‘gevaar’ op te leveren, en is vaak onvermijdelijk omdat bijvoorbeeld draadloze verrbindingen vroeg of laat een keer uitvallen
Filebased VLOG:
Bij filebased verzamelen wordt er op de automaat een buffer bijgehouden van VLOG data. De lengte van deze buffer verschilt qua tijdsduur, omdat deze doorgaans een bepaalde grootte heeft qua bytes. Hoe omvangrijker de data (meer items, meer berichten) hoe sneller de buffer vol is, en oude de data dus verwijderd moet worden.
Normaal gesproken zijn altijd enkele uren aan data op de VRI aanwezig
Een complicerende factor bij filebased VLOG is dat de binnenkomende data altijd achter loopt op de actuele tijd. De mate waarin dit zo is verrschilt sterk per VRI: van 5 minuten tot meer dan een uur.
Bepalen urgentieniveau van fouten in de dataverzameling
Om op de juiste/gewenste momenten en in de juiste situatie melding te kunnen maken moet het juist urgentieniveau kunnen worden bepaald. De volgende niveau’s worden onderscheiden:
Laag – geen direct gevaar op dataverlies; er is een fout opgetreden, maar directe actie is niet vereisd
Middel – geen direct gevaar op dataverlies; er zijn een of meer fout opgetreden, actie wordt aangeraden
Hoog – grote waarschijnlijkheid op permanent dataverlies; actie nodig
Acuut – acuut dataverlies
Per type dataverzameling wordt anders invulling gegeven aan het bepalen van het niveau. Uitgangspunt is dat een sporadisch verlies van weinig data lage urgentie krijgt, en vaak terugkerend dataverlies, of dataverlies over langere tijd, een hoge urgentie krijgt. Hierbij gelden de volgende uitgangspunten:
Afhankelijk van het type dataverzameling en de situatie, wordt het urgentieniveau periodiek of acuut bepaald
Periodiek bepalen van foutmeldingen wordt herhaald met een instelbare frequentie; default elke 15 minuten.
Streaming VLOG:
Dataverzameling staat stil: afhankelijk van de duur van de stilstand wordt de urgentie bepaald:
<= 5 minuten: laag
<= 10 minuten: middel
<= 15 minuten: hoog
> 15 minuten: acuut
De urgentie voor deze situatie wordt bepaald vooraf aan het leggen van een verbinding met een automaat; indien de verbinding wegvalt wordt dit zo steeds opnieuw gedaan bij het herstarten van de verbinding.
Dataverzameling bevat gaten: afhankelijk van de dekking over de afgelopen 24 uur wordt de urgentie bepaald:
>= 99%: geen melding
>= 95%: laag
95 – 85%: middel
85 – 75%: hoog
< 75%: accuut
De urgentie voor deze situatie wordt periodiek bepaald
Filebased VLOG:
Maatgevend voor het bepalen van de urgentie van eventuele fouten zijn 2 factoren:
1) De laatste succesvolle poging data op te halen:
<= 30 min. geleden: geen melding
30 – 45 min. geleden: laag
45 – 60 min. geleden: middel
60 – 120 min. geleden: hoog
> 120 min. geleden: accuut
2) De dekking over de afgelopen 24 uur; gerekend vanaf de laatst beschikbare data
De hoogste van deze 2 geldt als maatgevend voor het urgentieniveau
Versturen en verwerken van meldingen
Wanneer is bepaald dat sprake is van een fout, zal dit al naar gelang het urgentieniveau aanleiding zijn voor het versturen van een melding, of weergeven van de fout in de client.
Administator gebruikers kunnen instellen wie precies welke meldingen moet ontvangen.
Aangemaakte (al dan niet verstuurde) meldingen worden opgeslagen in de database van YAVC
Naast afgeven van meldingen kunnen geconstateerde fouten en hun urgentie ook worden weergegeven in de client. Zo is bv. mogelijk alleen bij het niveau “acuut” een email te laten versturen, maar reeds bij niveau “middel” in de client een kruispunt als problematisch aan te merken.
In de client is het mogelijk een melding als “afgedaan” aan te merken.
Bepalen van welke meldingen aan een gebruiker verstuurd moeten worden gebeurt door te kijken of een gebruiker bepaalde meldingen moet ontvangen, en zo ja, vanaf welke niveau
Beperken aantal meldingen
Met name bij meldingen via de mail moet worden voorkomen dat deze in aantal te omvangrijk worden. Hiertoe zijn een aantal voorwaarden en uitgangspunten gespecificeerd:
Status van meldingen:
Meldingen kunnen “actueel” zijn of “niet actueel”. Actueel houdt in dat de situatie momenteel nog van toepassing is. Niet actueel houdt in dat de betreffende situatie zich in het verleden voor deed en niet langer actief is.
Meldingen kunnen al dan zijn afgehandeld. Dit is tbv. weergave of verbergen in de client: afgehandelde meldingen worden default verborgen.
Aanmaken/verzenden van meldingen:
Per kruispunt wordt éénmalig een melding aangemaakt en – indien van toepassing – verzonden naar gebruikers waarvoor dit is ingesteld.
Wanneer bij een check ergens een fout wordt geconstateerd, wordt gekeken of er reeds een melding van hetzelfde type in de database aanwezig is, die niet als “actueel” is aangemerkt.
Zo nee: aanmaken nieuwe melding, indien van toepassing versturen
Zo ja: melding informatie updaten.
Volgende meldingen voor dezelfde kruising veroorzaken geen nieuwe email of andere alert.
Tenzij: het niveau is gewijzigd, is nu hoger, eerder is geen melding verzonden, maar dat nu wel moet gebeuren. YAVC houdt hiertoe bij welke gebruikers een melding wel/niet hebben ontvangen.
Verwerken van meldingen:
Tijdens de periodieke check wordt gekeken of evt. meldingen al dan niet actueel zijn. Indien meldingen niet langer actueel zijn kunnen ze worden afgehandeld.
Meldingen van niveau ‘middel’ of lager kunnen automatisch worden afgehandeld. Dit gebeurt indien tijdens de periodieke check geen fout meer wordt geconstateerd.
Meldingen van niveau ‘hoog’ of ‘acuut’ kunnen enkel handmatig als afgehandeld worden bestempeld. Hiermee wordt voorkomen dat een groot gat in de dataverzameling van enkele dagen geleden over het hoofd kan worden gezien.
Wel geldt: nadat een melding niet langer actueel is, kan een nieuwe melding zorgen voor een nieuwe alert.
Bufferen van meldingen:
Om een stormvloed aan meldingen te voorkomen, worden deze gebufferd. Nieuw te versturen meldingen worden in een buffer gezet.
Acute meldingen blijven maximaal 5 minuten in de buffer staan
Overigen meldingen blijven maximaal 15 minuten in de buffer staat
Zodra voor de eerste melding de gestelde termijn afloopt worden alle meldingen in de buffer verzonden, in één bericht
Bij VLOG data hoort een configuratie. Zonder configuratie is bijvoorbeeld onbekend welk voertuigtype een bepaalde signaalgroep heeft, welke lus welk type heeft, bij welke signaalgroep die hoort, en waar die precies ligt, etc. Die type informatie is echter noodzakelijk om de data correct te kunnen visualiseren in de fasenlog, en correct filtering en analyses uit te kunnen voeren.
Dit artikel omschrijft de manier waarop binnen YAVC (grotendeels automatisch) wordt omgegaan met configuraties. Zie voor concrete analyse instellingen per kruising dit artikel.
Samenvatting:
YAVC maakt automatisch configuraties aan voor verzamelde VLOG data: zo ontstaat een lijst met opeenvolgende configuraties, die elk geldig zijn voor een bepaald tijdvak
Automatisch gegenereerde configuraties zijn niet gevalideerd; pas na validatie door de gebruiker start filtering en analyse van de data
Het is mogelijk configuraties te bewerken, ook na validatie; wel moet dan (desgewenst) filtering en analyse data opnieuw worden doorgerekend
Algemene omgang met configuraties
YAVC verzorgt het aanmaken en configureren van kruispunten zoveel mogelijk geautomatiseerd. Na configuratie van een kruispunt in YAVC wordt automatisch gestart met verzameling van VLOG data (indien ingeschakeld). Bij indexatie van de eerste VLOG data maakt YAVC een eerste configuratie aan.
Betreft het VLOG versie 3, dan wordt de VLOG configuratie (beter bekend als CFG of VLT bestand) elke uur op het hele uur met de VLOG data mee gestuurd. YAVC gebruikt dit om automatisch de namen van elementen in te laden, en met gebruik van default waarden een voorzet te doen voor welke detector bij welke signaalgroep hoort, waar welke detector ligt en hoe lang die is.
Validatie van configuraties
Een automatisch aangemaakte configuratie is aanvankelijk niet gevalideerd. YAVC zal daarom nog geen filtering en analyse uit kunnen voeren. Pas na validatie van de configuratie door de gebruiker zal YAVC (met terugwerkende kracht vanaf de start van de periode waarvoor de configuratie geldig is) starten met validatie en analyse van data. Het kan vervolgens afhankelijk van de hoeveelheid te verwerken data enige tijd duren voor alle analyse resultaten beschikbaar zijn.
Herberekenen: ja of nee?
Omdat YAVC analyse data continu doorrekend, is het bij het wijzigen van een configuratie nodig de filtering/analyse data te herberekenen om te zorgen dat de in de database aanwezig data weer overeenstemt met de configuratie. Daarbij is soms de vraag: is dit eigenlijk wel nodig?
Zeker bij veel data kan het herberekenen geruim tijd in beslag nemen. Het rekenen zelf kost relatief weinig tijd, het ophalen van de VLOG data om mee te rekenen kost echter ook enige tijd. En vooral geldt: er veel database operaties mee gemoeid om de nieuwe data op te slaan en bij te houden wat reeds wel/niet is bijgewerkt. Vooral dit type operaties kost relatief veel tijd.
Daarom enige tips omtrent het al dan niet herberekenen van data:
Bij zeer veel data kan herbereken lang duren: bv. bij een jaar of meer aan data kan dit 12 uur of meer duren, al naar gelang de grootte van de kruising, de omvang van de brondata en het type systeem waar YAVC draait; in zo’n geval is de afweging: hoe belangrijk is het dat de wijziging wordt verwerkt in historische data?
Koplussen zijn voor veel analyses allesbepalend: intensiteiten, roodrijders, vroegstarters, wachttijd eerstwachtend, etc. Wijzigt er dus wat op dit vlak, dan is herberekenen eigenlijk onontbeerlijk, want de eventueel reeds berekende data is waarschijnlijk foutief.
Idem. voor wijziging van de ligging van detectie (rijstrook, afstand tot ss) waardoor de volgorde per rijstrook wijzigt: de eventueel reeds berekende data is waarschijnlijk incorrect, met mogelijk onbedoeld effect (met name qua filtering) op de data en daarmee op de uitkomst van analyses
Niet alle wijzigingen aan een configuratie hebben effect op de filtering/analyse. Hieronder een overzicht van wijzigingen die wel belangrijk zijn:
ligging: dit is enkel relevant wanneer daardoor de volgorde wijzigt, behalve voor de analyse “gemiddelde wachttijd fiets“, waarbij de ligging van verweg detectie invloed heeft op de resultaten
Handmatige toedeling DSI: van belang voor de analyses OV inm. tot uitm. en OV inm. tot SG
Wijzigingen aan instellingen van een of meer filters: dit heeft invloed op álle data, want wijzigt mogelijk de feitelijke brondata zoals de analyses die te zien krijgen
Wijzigingen aan instellingen van een analyse: enkel van belang voor de betreffende analyse
Toekomst: voor YAVC staat op de ontwikkellijst om intelligentie in te bouwen waarmee de (client) applicatie op basis van de wijzigingen zelf kan bepalen welke data wel/niet verwijderd hoeft te worden om de data gelijk te trekken met de configuratie.
Geldigheid van configuraties & omgang met wijzigingen
Een regeling kan wijzigen, waarbij bijvoorbeeld een signaalgroep of detector wordt verwijderd of toegevoegd. Dit betekent dat er vanaf het moment van de wijziging een nieuwe configuratie moet gelden. VLOG configuraties hebben daarom altijd een bepaalde periode waarvoor ze geldig zijn. In YAVC geldt dat de laatste configuratie geen einddatum heeft: deze is dus geldig tot nader order.
In YAVC geldt dus:
Een configuratie is altijd geldig vanaf een bepaald moment
Een configuratie is altijd geldig tot een bepaald moment
Er is dus een lijst met configuraties, die achtereenvolgens gelden voor een bepaald tijdvak
De laatste configuratie heeft geen eind datum, en is daarmee altijd de ‘huidige’ configuratie: bij binnenkomst van nieuwe data wordt gekeken of die past bij de actieve configuratie
Tijdens de indexatie van nieuwe data voert YAVC een check uit om te kijken of de nieuwe data past bij de actieve configuratie. Hiertoe:
Worden de aantallen signaalgroepen/detectoren/ingangen en uitgangen in de nieuwe data vergeleken met diezelfde aantallen in de actieve configuratie
Bij VLOG3 wordt bij binnenkomst van de configuratie (normaliter komt op het hele uur de VLOG config (“CFG”) mee met de data) gekeken of de naamgeving en rangering van elementen nog identiek is
Deze optie is uitschakelbaar bij de geävanceerde instellingen per kruispunt; dit is bijvoorbeeld relevant wanneer er handmatig elementen (bv. een signaalgroep) zijn toegevoegd aan een configuratie
Is er een match, dan blijft de actieve configuratie gelden.
Is er geen match, dan maakt YAVC een nieuwe configuratie aan. Hierbij worden zoveel mogelijk instellingen uit de geldende configuratie overgenomen in de nieuwe configuratie. Hier geldt wederom: deze is aanvankelijk niet gevalideerd.
Wordt een nieuwe configuratie aangemaakt, dan maakt YAVC een issue aan en verrstuurt aan gebruikers voor wie dit is ingesteld een alert. Het betreffende issue wordt automatisch gesloten zodra de configuratie is gevalideerd door een gebruiker.
Handmatig configuraties toevoegen of verwijderen
Het is ook mogelijk handmatig configuraties toe te voegen. Hiermee kan bijvoorbeeld vóór een wijziging aan een regeling reeds de nieuwe configuratie worden ingericht en gevalideerd, zodat de filtering en analyse na de wijziging direct door kan lopen.
Let wel op:
Het tijdstip vanaf wanneer de nieuwe configuratie van toepassing is moet in de toekomst worden gelegd; anders zal YAVC automatisch een nieuwe configuratie aanmaken voor data zoals die momenteel binnen komt
Het tijdstip van de wijziging moet bekend zijn
Ligt dit uiteindelijk eerder dan ingesteld, dan zal YAVC momenteel een fout constateren: het “invoegen” van een nieuwe configuratie ergens midden in de lijst met opeenvolgende configuraties wordt nog niet ondersteund.
Ligt het moment uiteindelijk later, dan zal YAVC reeds zelf een (niet gevalideerde) configuratie aanmaken bij binnenkomst van de eerste data waarop de huidige configuratie niet meer van toepassing is
Op de wensenlijst staat de mogelijkheid van het aanmaken van een reeds vooraf gevalideerde “kandidaat” configuratie: bij een geconstateerde wijziging kan YAVC dan nagaan of de kandidaat past bij de nieuwe data, en deze direct toepassen. Dan is het exacte moment van de wijziging niet meer van belang
Toevoegen van een configuratie kan uitsluitend aan het einde van de lijst met configuraties. Dit geldt eveneens voor het verwijderen van configuraties en wijzigen van de datum vanaf wanneer een configuratie geldt: uitsluitend de laatste configuratie – die dus geen einddatum heeft en ‘nu’ geldt – kan worden verwijderd of geldigheidsduur worden gewijzigd. Wordt van de laatste configuratie de start datum gewijzigd, dan wijzigt de eind datum van voorlaatste configuratie automatisch mee.
Indien een configuratie wordt verwijderd, dan wordt de bijbehorende filtering en analyse data ook verwijderd. Wordt de start datum van de laatste configuratie gewijzigd, dan wordt alle data in de periode tussen de oude en de nieuwe start datum verwijderd.
