Onlangs heeft minister Eurlings de kamer gecharmeerd en sindsdien lijken de ergste tegengeluiden verstomd. De echte behandeling van de wet-Kilometerprijs zal in het voorjaar van 2010 plaatsvinden, maar ik denk dat we er van uit kunnen gaan dat de uitvoering van de wet ter hand zal worden genomen. Kortom, we gaan betalen per kilometer en er komen kastjes in onze auto’s. Kan het zijn dat dit een aanjager gaat worden voor een servicegeoriënteerde infrastructuur voor het wegverkeer?
In het kastje, of OBU (on board unit), zitten straks drie mogelijkheden voor draadloze communicatie: GNSS (gps en dergelijke) voor plaatsbepaling, gsm (umts, hsdpa en dergelijke) voor communicatie met de backoffice en DSRC (dedicated short-range communications) voor onderweg. Vooral die laatste is interessant. DSRC is een verzameling standaarden op het gebied van netwerken, connectiviteit en applicatiediensten, respectievelijk vergelijkbaar met OSI-lagen 1, 2, en 7. Alles bij elkaar vormt een DSRC-netwerk dus een basis voor een netwerk-, communicatie- en applicatie-infrastructuur voor onderweg. De standaard is al ruim tien jaar oud en tot nu toe is er weinig mee gebeurd. Ik heb de indruk dat deze uitrol een van de grotere gaat worden. Binnen de applicatiestandaarden van DSRC worden verschillende soorten diensten gegroepeerd, denk hierbij aan emergency management services , traffic and travel information services , electronic tolling services (aha), vehicle safety systems services etc. 'This is service oriented architecture, Jim, but not as we know it!'
Stel je eens voor hoe dat werkt in de praktijk, je rijdt rond en voortdurend leg je netwerkverbindingen aan met alle voertuigen om je heen en met road-side equipment (RSE). Dit lijkt op een ad-hoc WiFi-netwerk, maar dan met hoge snelheid. Het resultaat is dat je, zeker in stedelijke gebieden of op een drukke weg, voortdurend een netwerkverbinding hebt, met wisselende partners. Stel je nu voor dat er berichtverkeer over een dergelijk netwerk gerouteerd moet worden… Inderdaad zijn broadcast storms en betrouwbaarheid belangrijke onderwerpen van onderzoek in dit veld. Verdere interessante beperkingen zijn de omvang van de payload van de berichten (enkele tientallen bytes), de bandbreedte (enkele honderden bits per seconde), de reikwijdte van één verbinding (in de tientallen meters) en de beveiliging (wie autoriseert? Hoe controleert de ontvanger de autorisatie?). Overigens, de kilometerbeprijzing die bij ons wordt ingevoerd, zal alleen maar enkelvoudige verbindingen (request-reply) met RSE voor handhavingdoeleinden nodig hebben; technische uitdagingen zijn er wel degelijk, maar ze lijken behapbaar.
Marktpartijen krijgen een belangrijke rol in het realiseren van deze infrastructuur en dit zal hen een interessante uitgangspositie geven om een servicelandschap te ontwikkelen. Gesteld dat de technische uitdagingen opgelost kunnen worden, welke services kunnen wij dan verwachten? Goede voorbeelden helpen en in een experiment in Frankrijk (AIDA) zijn een een paar leuke ontwikkeld: verkeersservices met informatie over onder andere ongelukken, files; weerservices met zware regen- en sneeuwval, gladheid; persoonlijke navigatie : toeristische tips, tankstations met prijzen onderweg, de aanbieding van de dag in het wegrestaurant; en nog een spannende categorie: de interactieve service waarbij je zelf informatie mag inbrengen: rommel op de weg, incidenten en dergelijke.
Wat ik me nou afvraag is of deze services, volgens goed gebruik, hun eigen wielen gaan uitvinden of dat er principes van servicegeoriënteerde architectuur kunnen worden toegepast. Het lijkt me een geweldige uitdaging, want realiseer je dat je vrijwel alle zekerheden overboord kunt gooien. Maak je geen illusies over beschikbaarheid, een service is voorbijgereden voordat je er erg in hebt. Vergeet soap, vergeet xml, vergeet http, vergeet tcp. Hou in de gaten dat deelname aan sommige services (noodwaarschuwingen, tolbetalingen) verplicht is. Met welk SOA-architectuurprincipe, welke REST- en WS-*-standaard maken we een voor SOA-voor-onderweg?
“REST- en WS-*-standaard”
Wat is dat?
@M:
REST: Representational state transfer
WS: web service
http://en.wikipedia.org/wiki/Representational_State_Transfer
Tegengeluiden verstomd? Ik krijg toch een andere indruk van de publieke opinie momenteel. Maar los daarvan:
een fijne brave new world zal dat worden, zo’n kastje in de auto met al deze mogelijkheden.
Maar reken maar dat de kilometerheffing tegen die tijd in het rijtje HSL/Betuwelijn/NoordZuidlijn en andere megalomane overheidsprojecten zal zijn bijgeschreven. Het is gewoon veel te complex, en vooral techniekgedreven.
Jaja, echt wel!
Niemand bekend met http://www.kilometerheffingnee.nl?
En inderdaad een heel mooi droombeeld wat de lobbyclub van NXP en IBM Camiel ook voorspiegelen, maar doe wat onderzoek en je komt er snel achter dat er vele miljoenen belastinggeld in deze utopie is gestoken en de meest essentiele zaken nog steeds niet opgelost zijn…
Even door het verhaal heenkijkend: Het komt er op neerdat de plussen “door marktpartijen” gelever ga worden. Echter zitten die plussen al in een “beetje” TomTom, dus wat is de toegevoegde waarde anders dan dat de overheid precies kan zien waar je bent en met welke snelheid je rijdt? En voor die gereden kilometers betaal je al de hoofdprijs en voor de snelheid ontvang je vervolgens post uit Leeuwarden?
Ik begrijp dat Marc Fleischeuers met de KMheffing zijn brood vedient maar de argumenten voor de KMheffing zijn van puur financiel aard (in het voordeel van de overheid) ten koste gaand van de vrijheid en privacy van de burger. Ik zou het een onverdraglijke gedachte vinden om aan een dergelijk project mijn medewerking te verlenen.
Ik vind bovenstaande reacties niet echt de moeite waard. Ze gaan voorbij aan de uitdaging die wordt geschetst. Ontstaat er een service landschap bij de invoering van kilometerheffing en, zo ja, hoe ziet dat er uit. Mijn verwachting bij dit soort trajecten is dat er geen sprake zal zijn van services in de letterlijke zin, maar dat er wel over service wordt gesproken als bijvoorbeeld al XML wordt gebruikt. Services vergen een volledig andere architectuur met dienstverleners die services aan gebruikers leveren. Wie zijn hier gebruikers en wie dienstverleners? Is er sprake van een verplichte rapportage van OBU’s naar een verrekenpunt? Laten we het systeem nu wel op services baseren, dan wordt het testen van het volledige systeem ook veel eenvoudiger. Services zijn dan afzonderlijk te testen en vervolgens zijn de procescomponenten te testen. Zoals het er nu naar uit ziet, wordt een stelsel van afhankelijke, interacterende componenten gemaakt waarvan het totaal lastig te testen valt. Kortom, groot afbreukrisico.
@Wout: alsof die van jou wel de moeite waard is.
Techniekgedreven geneuzel noem je ‘uitdaging’, maar nergens een business case te bekennen.
Niemand zit te wachten op dit megalomane en belastinggeld verspillende brok 1984. En over 5 jaar is services en SOA weer helemaal uit en hebben we weer volop andere hypes.
Betalen naar gebruik kan heel goed op andere wijze plaatsvinden, maar nee.. het moet en het zal met ‘kastjes’ plaatsvinden. Uiteraard is het de bedoeling, dat die kastjes voor meer zaken gebruikt gaan worden. Waarom anders zo moeilijk doen?
Er zijn nog genoeg andere technische uitdagingen…
Betalen via de brandstof zou het meest eenvoudige zijn (zonder wegenbelasting, opcenten, BPM, etc.).
Doordat de politiek de files wil beperken via rekeningrijden, wordt de zaak erg complex. Er worden in Nederland al meer dan 20 jaar lang studies uitgevoerd naar het rekeningrijden. Dat heeft al aardig wat gekost en wat heeft het opgeleverd?
Er is nog geen enkel plan voor rekeningrijden ontwikkeld waarbij het zeker is dat het niet alleen technisch goed werkt, maar ook de juiste effecten oplevert, moeilijk te kraken is en de overhead niet groter wordt. In Nederland zijn we niet eens in staat om een goed werkend tunnelbeveiligigingsysteem of een spoorbeveiligigingsysteem op tijd af te leveren. Dus wat is de kans dat het met rekeningrijden alsnog goed gaat?