Opgelet, er zijn andere versies van deze deliverable beschikbaar.
Inleiding
Deze pagina bevat de eerste versie van het VLOCA model. Het is een niet finale versie die we V0.1 noemen. Dit kwam tot stand na de inhoudelijke intro met de initiatiefnemer van dit VLOCA traject en een studie van de aangeleverde informatie bij de start van het project.
Situering van deze deliverable in het traject
Deze eerste versie van het VLOCA model is een werkdocument dat in een latere fase van het traject verder verfijnd en uitgewerkt wordt. Het is in de V0.1-vorm nog geen finaal en afgewerkt document; we baseren ons voor de opmaak ervan op informatie en inzicht die in deze fase van het traject bekend is. Dit document vormt een basis voor het verdere verloop van het traject. In dit overzicht kan je de fasering en andere deliverables binnen een VLOCA traject bekijken.
Doel en doelgroep
Initiatiefnemers (lokale en bovenlokale besturen): De initiatiefnemers en hun project partners werken aan de hand van deze pagina de inhoud verder uit, waarna validatie en prioritering volgt.
Lokale besturen: Lokale besturen worden uitgenodigd om inhoudelijk mee te werken aan aan de co-creatie over dit thema.
Laat ons weten dat je wenst deel te nemen, en geef je inhoudelijke opmerkingen door op vloca@vlaanderen.be.
Dit kan je in de nabije toekomst doen door op de discussie pagina van deze wiki pagina. (op dit moment nog in ontwikkeling)
Bedrijven en kennisinstellingen: Heb je als bedrijf een visie op de generieke business vereisten van dit thema, dan nodigen we je uit om samen deze oefening verder mee vorm te geven.
Ben je leverancier aan overheden, vragen we je specifieke oplossingen niet te vermelden maar de generieke business en IT architectuur in co-creatie mee uit te werken.
Burgers en burgergroeperingen:
Voel je je als burger aangesproken door dit onderwerp en je hebt een visie op de ontwikkeling van oplossingen van dit thema, laat het ons zeker weten.
Aanpak (korte beschrijving)
In dit VLOCA model V0.1 vertrekken we van de visie, missie en doelen zoals ze geformuleerd worden door de initiatiefnemer. Deze gegevens worden verder verfijnd en uitgesplitst in objectieven, en hun de daaraan gelinkte business capabilities, data vereisten, functionele capabilities en technische vereisten. Een volledige omschrijving van het VLOCA-model kan je hier lezen. In deze fase exploreert team VLOCA tevens de extra mogelijkheden rond deze use case. Deze worden in het project gevalideerd en al of niet in scope van het project genomen. Wanneer ze niet in scope worden genomen, kan deze bijdragen aan het uitwerken van een ander of een vervolgproject.
Overzicht andere versies van deze deliverable
| Deliverable | Versie | |
|---|---|---|
| VLOCA-model V0.1 Slimme stadsdistributie – Hasselt | VLOCA-Model | V0.1 |
| VLOCA-model V0.2 Slimme stadsdistributie – Hasselt | VLOCA-Model | V0.2 |
Inhoud
Hieronder kan je de elementen van versie V0.1 van dit VLOCA model bekijken.
| CoT Slimme stadsdistributie – Hasselt | |||
| 2022 | VLOCA-model versie 0.1 | ||
| VLOCA analyse - Vlaamse Open City Architectuur | vloca@vlaanderen.be | |||
| Beschrijving en aanpak: | https://vloca-kennishub.vlaanderen.be/Deliverable:_VLOCA-model | ||
Strategie van de open city uitdaging | |||
| Status | Toelichting | Beschrijving | |
| Visie | Voorstel | Wat is de bestaansreden ? | Stadsdistributie in de vorm van vrachtverkeer in de stadskern wordt alsmaar belangrijker en genereert een paradox mbt het autoluw maken van de binnenstad. Dit resulteert in alsmaar meer problemen zonder enige vorm van sturing. |
| Missie | Voorstel | Wat willen we bereiken ? | Het verkeer in de binnenstad aangenamer maken door het vrachtverkeer te minimaliseren door betere planning ifv verkeer (huidig of ingeschatte) alsook het verminderen van 'onnodige' transporten (beschikbare lege volume, lege terugkeer, ed meer) |
| Doel | Voorstel | Wat is het doel van dit project ? | (1) Een 'cockpit' bouwen die het vrachtverkeer volledig weergeeft om inzichten te verschaffen mbt beleidsvorming, sturing en evaluatie (2) Een 'dashboard' voor de 'vervoerder' om zijn transport te registreren en 'toestemming' te krijgen met een voorgestelde routeplanning (3) Het dashboard moet ook de mogelijkheid geven om aan de vervoerder een optimale planning te kunnen doen door op basis van de andere registraties, wegenwerken, ed meer. (4) Ontsluiten van alle mogelijke data (via APIs bvb) naar commerciele 'logistieke planningstools' om die data te integreren, of nieuwe VAS toe te laten. |
| Succesfactor | Voorstel | Hoe meten we succes ? (SMART) | Tegen 2024 moet Hasselt een cockpit hebben die de toegang van vrachtverkeer reguleert en visualiseert waarbij alle data de OSLO standaarden respecteert. |
Use cases | |||
| ID | Status | Samenvatting | Beschrijving |
| UC1 | Voorstel | UC1: Registratie Levering | Een visuele applicatie (='Dashboard') waar de vervoerder een reservatie/registratie, om de binnenstad binnen te rijden, kan aanvragen en ifv het flankerend beleid al dan niet toestemming krijgt om de gevraagde route te kunnen gebruiken. Alternatieve 'routes' (welke wagen, tijdstip, geografische route, enz) worden ook voorgesteld. |
| UC2 | Voorstel | UC2: Beleids Cockpit | De steden krijgen een 'cockpit' die het volledige vrachtverkeer (registraties, sensoren, camera's data, ANPR, Toegangscontrole,...) grafisch en in cijfers weergeeft om zo een beter beleid te kunnen vormen, sturen en evalueren. |
| UC3 | Voorstel | UC3: Beleids Cockpit uitvoering | Het flankerend beleid moet kunnen ingevoerd worden in de 'cockpit' zodat elke aanvraag (= registratie) ifv de gevraagde routes, maar ook de type wagen, ed meer de toegestane routes kan beslist en gevisualiseerd worden via een algoritme die een 'nudging' mogelijk maakt om bvb indien mogelijk een alternatieve moment te gebruiken bij 'piek momenten' |
| UC4 | Voorstel | UC4: Toegang Binnenstad | De Binnenstad kan toegankelijk gemaakt worden enkel voor de degenen die zich geregistreerd en ook aan de 'beleids' criteria voldoen, via paaltjes of via ANPR camera's. |
| UC5 | Voorstel | UC5: Inname openbaar domein | Via de dashboard kan ook openbaar domein gereserveerd worden met 'vergunning' met betaling (per dag, per week,...) |
| UC6 | Voorstel | UC6: Laad- en Losplaatsen reserveren | De vervoerder/handelaar/leverancier moet een laad- en losplaats kunnen 'reserveren' om zeker te zijn dat de levering zo optimaal zou kunnen verlopen. (Betaling ? : misschien ifv EURO normen van de (vracht)wagen) |
| UC7 | Voorstel | UC7: Matchmaking | Door alle verzamelde data, alsook de 'registratie' aanvragen, kan de 'waste' in de transport worden weggewerkt door de 'lege'/'beschikbare' volumes te benutten door andere vervoerders, handelaars en leveranciers. |
| UC8 | Voorstel | UC8: Open Data | Alle data die uiteindelijk gecapteerd worden moet kunnen opengesteld worden om zo de ganse quadruple helix de mogelijkheid te bieden om 'Value Added Services' te kunnen bouwen op die data. |
| UC9 | Voorstel | ||
| UC10 | Voorstel | ||
Metadata | |||
Business capabilities, data vereisten, functionaliteiten en techniciteiten volgens use cases | |||
| ID | Type | Samenvatting | Beschrijving |
| UC1 | Use case | UC1: Registratie Levering | Een visuele applicatie (='Dashboard') waar de vervoerder een reservatie/registratie, om de binnenstad binnen te rijden, kan aanvragen en ifv het flankerend beleid al dan niet toestemming krijgt om de gevraagde route te kunnen gebruiken. Alternatieve 'routes' (welke wagen, tijdstip, geografische route, enz) worden ook voorgesteld. |
| BC1.1 | Business capability | Inlog en authenticatie systeem om 'kentekens' of 'badges' te kunnen 'aanmaken' voor de eerste keer met bijbehorende vragen (type van wagen, ed meer) | |
| BC1.2 | Business capability | 'Registreren'/Invoeren van gewenste leverings of afhalingstermijn aan een adres. | |
| BC1.3 | Business capability | Voorstel van (alternatieve) routes, wanneer en via welke route, die toegelaten zouden zijn en kan gevalideerd worden door de vervoerder met een muisklik in de tool. | |
| BC1.4 | Business capability | dossier beheer | Aanvragen moet kunnen aangepast of zelfs geannuleerd door de vervoerder, met een visuele/grafische algemene overzicht van alle aanvragen per kenteken/badge |
| BC1.5 | Business capability | rapportering | Opvolging van 'uitvoering/gebruik' van de aanvragen (om misbruiken tegen te gaan door bepaalde 'badge'/'kentekens' te blokkeren) alsook handhaving van ongeoorloofde leveringen (om te beboeten) |
| ID | Type | Samenvatting | Beschrijving |
| UC2 | Use case | UC2: Beleids Cockpit | De steden krijgen een 'cockpit' die het volledige vrachtverkeer (registraties, sensoren, camera's data, ANPR, Toegangscontrole,...) grafisch en in cijfers weergeeft om zo een beter beleid te kunnen vormen, sturen en evalueren. |
| BC2.1 | Business capability | rapportering | Alle 'registraties', 'aanvragen' en 'uitvoering' te visualiseren samen met andere 'stadsdrukte' metingen van gemotorizeerde vervoer. |
| BC2.2 | Business capability | Lineaire programmatie | Simulatie om de beleidsbeslissings parameters te callibreren (hoe streng moeten we zijn) om het verkeer zo minimaal te maken alsook de aanvragen zo maximaal te beantwoorden |
| BC2.3 | Business capability | Actuatie | Via IoT actuatoren (?) kunnen vervoerders al dan niet in de binnenstad of in een straat binnengelaten worden doordat bvb de paaltjes al dan niet in de grond zinken, of de hefbomen open gaan, of de ANPR camera de niet toegestande vervoerder capteert en beboet. |
| ID | Type | Samenvatting | Beschrijving |
| UC3 | Use case | UC3: Beleids Cockpit uitvoering | Het flankerend beleid moet kunnen ingevoerd worden in de 'cockpit' zodat elke aanvraag (= registratie) ifv de gevraagde routes, maar ook de type wagen, ed meer de toegestane routes kan beslist en gevisualiseerd worden via een algoritme die een 'nudging' mogelijk maakt om bvb indien mogelijk een alternatieve moment te gebruiken bij 'piek momenten' |
| BC3.1 | Business capability | Beslissingsboom | Een gekozen (zie BC2.2) beslissingsboom die bepaald wie waar al dan niet mag binnenrijden, moet kunnen ingevoerd worden, zodat er 'automatisch' de actuatoren aangestuurd worden, alsook de handhaving via GAS of andere boetes quasi automatisch kan uitgevoerd worden. |
| BC3.2 | Business capability | Rapportering | De beslissingsboom moet kunnen ge 'versioneerd' worden, zodat er een historiek kan zijn van de gebruikte parameters die evt geleid hebben tot een zekere verkeersdrukte in de binnenstad in het verleden. |
| BC3.3 | Business capability | Visualisatie | De beslissingsboom moet ook visueel kunnen voorgesteld worden zodat de aanvrager het voorstel van de tool beter kan begrijpen en in de toekomst zijn logistieke aanvraag beter kan afstemmen om de kansen tot aanvaarding te verhogen. |
| ID | Type | Samenvatting | Beschrijving |
| UC4 | Use case | UC4: Toegang Binnenstad | De Binnenstad kan toegankelijk gemaakt worden enkel voor de degenen die zich geregistreerd en ook aan de 'beleids' criteria voldoen, via paaltjes of via ANPR camera's. |
| BC4.1 | Business capability | Actuator systeem | Fysieke toegangen gelinkt aan de databank waarin de toestemmingen opgeslagen zijn in real time. |
| ID | Type | Samenvatting | Beschrijving |
| UC5 | Use case | UC5: Inname openbaar domein | Via de dashboard kan ook openbaar domein gereserveerd worden met 'vergunning' met betaling (per dag, per week,...) |
| BC5.1 | Business capability | Booking.com toepassing | Een visueel overzicht van de beschikbare tijdslot per operbaar domein (laad- en losplaats?), en reservatie mogelijkheid met een muisklik. |
| ID | Type | Samenvatting | Beschrijving |
| UC6 | Use case | UC6: Laad- en Losplaatsen reserveren | De vervoerder/handelaar/leverancier moet een laad- en losplaats kunnen 'reserveren' om zeker te zijn dat de levering zo optimaal zou kunnen verlopen. (Betaling ? : misschien ifv EURO normen van de (vracht)wagen) |
| BC6.1 | Business capability | Booking.com toepassing | Een visueel overzicht van de beschikbare tijdslot per operbaar domein (laad- en losplaats?), en reservatie mogelijkheid met een muisklik. |
| BC6.2 | Business capability | Beheer van dossier | Beheer van het dossier van reservaties : overzicht aanvragen met status, aanpassen en annuleren van aangevraagde reservering, enz. Eventueel ook een 'betalings' module indien die reservaties niet gratis zal zijn. |
| BC6.3 | Business capability | Rapportering | Overzicht van alle aanvragen van reservaties (en uitvoering van die reservaties) |
| ID | Type | Samenvatting | Beschrijving |
| UC7 | Use case | UC7: Matchmaking | Door alle verzamelde data, alsook de 'registratie' aanvragen, kan de 'waste' in de transport worden weggewerkt door de 'lege'/'beschikbare' volumes te benutten door andere vervoerders, handelaars en leveranciers. |
| BC7.1 | Business capability | Vergunningen | Door de vervoerders/handelaars/leveranciers in kaart te brengen alsook de gedeclareerde 'lege' volume in de vrachtwagen kan een matchmaking voorgesteld worden waarbij er maximaal volume met een minimum aan verplaatsing zou kunnen uitgevoerd worden. |
| BC7.2 | Business capability | Vraag | Aanvraag mogelijkheid van een vervoerder/handelaar/leverancier om van adres A tot adres B tijdens periode X een vracht met volume Y en dimensie Z te kunnen mee vervoeren. |
| BC7.3 | Business capability | Aanbod | Aanbod mogelijkheid van een vervoerder om een 'lege' volume voor te stellen om door een handelaar/andere vervoerder/leverancier te kunnen benutten. |
| ID | Type | Samenvatting | Beschrijving |
| UC8 | Use case | UC8: Open Data | Alle data die uiteindelijk gecapteerd worden moet kunnen opengesteld worden om zo de ganse quadruple helix de mogelijkheid te bieden om 'Value Added Services' te kunnen bouwen op die data. |
| BC8.1 | Business capability | OSLO-VLOCA | Alle data die opengesteld zullen worden moeten de OSLO standaarden alsook de VLOCA charter voldoen, zodat er andere spelers op de markt die data kunnen gebruiken om toegevoegde waarde applicaties te kunnen bouwen. |
| BC8.2 | Business capability | Open Data Platform | Open data moet via centrale datavindplaats kunnen gevonden worden en toegang gegeven worden. |