Multifocaal netwerkmodel

Pieter Wisse en Jan van Til

Dit is een modelmatige verkenning, een oefening in conceptuele informatiemodellering met metapatroon. Daarvoor veronderstellen wij op z’n minst de mogelijkheid om procesmatige vervoersstromen met ruimer bereik te plannen dan wat als één enkel zgn netwerk onder beheer is van een bepaalde apàrte organisatie, te weten de (netwerk)beheerder. Daarom moet het vervoersperspectief apart vertegenwoordigd zijn. Dat proberen wij vanuit, zeg maar, elementen samen te stellen. Ons idee over een geschikt (basis)element is zoiets als een knooppunt.
Maar …, de aanduiding knooppunt vóóronderstelt netwerk. Hetzelfde geldt bijvoorbeeld voor station. Neutraler vinden wij: installatie.
Naarmate basisbegrippen algemener zijn, verkrijgt een informatiestelsel ruimer bereik. Want er passen daardoor navenant méér afleidingen, respectievelijk verschijningsvormen inclusief hun eventuele onderlinge verband.
Laten we eens uitgaan van een platte lijst met installaties. Met de dikke, horizontale streep als horizon van het beoogde informatiestelsel ziet dat er schematisch als volgt uit (figuur 1).

Figuur 1.

Dit is overigens nog de oude notatie voor metapatroon. De tekstballon geeft aan dat installatie weliswaar een contextueel-specifieke gedragsbeschrijving telt, maar dat die beschrijving nog even niet uitgewerkt is. Met zgn cardinaliteit 0,n is bedoeld dat het aantal geregistreerde installaties kan variëren van nul tot een vooraf ònbepaalde hoeveelheid.
De notatie wijkt hier voor het vervolg enigszins af van hoe de informatiemodellen getekend zijn in o.a. Metapattern: context and time in Information models (Pieter Wisse, Addison-Wesley, 2001). Wij gaan verder met een hoekiger tekenwijze. Figuur 2 heeft dezelfde dekking als figuur 1. De cardinaliteit staat niet expliciet vermeld (zolang die vanzelf spreekt).

Figuur 2.

Figuur 2 stelt: Binnen de horizon van het stelsel — waarvoor dit het begin vormt van een ontwerp voor een informatiestelsel-to-be — bevinden zich installaties an sich, dus zonder dat ze zich al op de één of andere manier gedragen. Het enige gedrag dat op dit universele punt gestipuleerd kan zijn, moet dienovereenkomstig altijd gelden. Daaraan voldoet — bijna — geen gedrag, dat immers contextuele verbijzondering volgt. Daarom blijft gedrag(sbeschrijving) op dit punt doorgaans beperkt tot kunstmatige identiteitstelling (met, nota bene, ‘slechts’ de reikwijdte van het informatiestelsel-to-be).
Vergeleken met figuur 1 is in figuur 2 de tekstballon ‘leeggelopen’ tot een rechthoek. De lijn met daarbij de tekst ‘installatie’ geldt als context, ‘grounded’ in de horizon/scope van het informatiestelsel-to-be. De rechthoek is één van de 0..n voorkomens (instances) van installatieobjecten.
Een — bepaalde — installatie behoort tot een — bepaald — beheerdomein. Zo’n domein kan diverse installaties omvatten.
Waarom het — hier — in het bijzonder gaat, zijn de installaties die als knooppunt, of liever gezegd als station dienen in een bepaald beheerdomein. Zie figuur 3.

Figuur 3.

Met (andere) woorden, binnen de horizon van het (informatie)stelsel-to-be bevinden zich installaties voor zover ze dienst doen als station in een bepaald beheerdomein. De pijl komt overeen met de derivate relationship uit Metapattern. Het is steeds een bepaald beheerdomein waarbinnen een bepaalde installatie als station haar betekenis heeft.
Wat er door de relatie tussen installatie en beheerdomein gebeurt, is dat er een contextuele verbijzondering van installatie geregistreerd kan worden. Die verbijzondering heet hier station en beheerdomein geldt — in dit geval — als context.
De zin van contextuele verbijzondering is om erop te kunnen voortborduren met navenant verbijzonderde gedragsbeschrijvingen. Daarom, wat als het ware ontstaat als relatie, moet verder (ook) als ‘ding’ opgevat kunnen worden. Hoe een verdingde relatie aangeduid wordt, staat in figuur 4 toegevoegd. Let wel, de gehéle relatie functioneert tevens, zeg maar, objectmatig. Een kleine staande rechthoek symboliseert dergelijke verdinging en dient vervolgens praktisch voor het — modelleren van het — aanknopen van eventuele verdere relaties.

Figuur 4.

De aangegeven richting van de relatie, zoals in figuur 4, is niet eens zo belangrijk. Die bestaat feitelijk in beide richtingen. Wat wij extra met de ene pijl proberen aan te geven is, zeg maar, de primaire richting. Zo van, je begint doorgaans vanuit een beheerdomein en dan kijk je naar de bijbehorende stations. Maar in omgekeerde richting kan je ook bij een installatie beginnen, kijken of dat een station is en zo bij het beheerdomein in kwestie uitkomen.
Op haar beurt kan aan de installatie-als-station-in-beheerdomein eenduidig gedrag toegeschreven zijn. (Opnieuw) zonder enige details toont figuur 5 die toevoeging. Als dat voor de verdere ontwikkeling van het informatiemodel niet relevant is, zeg op hoofdlijnen, kunnen dergelijke toevoegingen — vooralsnog — trouwens beter achterwege blijven.
Maar desgewenst biedt de toegevoegde rechthoek — zoals in figuur 5 voor station — dus ruimte voor het toeschrijven van eenduidig gedrag van een bepaalde installatie die als station dienst doet in een bepaald beheerdomein. Volgens Metapattern is dat een intext.

Figuur 5.

Wat omslachtige voorbereidingen lijken, moeten nu vruchten gaan afwerpen. Daarvoor breid ik het model uit met vervoerstelsel. Wij laten — vooralsnog — in het midden dat een — bepaald — vervoerstelsel één of meer beheerdomeinen omvat.

noot
Het bereik van een beheerdomein is vaak (nog) gelijk aan dat van een vervoerstelsel. Dit ‘geval’ past dus eveneens ‘in’ het model. Dat is veranderkundig gewoonlijk reuze handig voor eventuele ontwikkeling van informatievoorziening naar bredere horizon. Wie veiligheid aan continuïteit meent te ontlenen, kan redelijk gerustgesteld zijn.

Vervolgens nemen we aan dat juist de reden om ‘iets’ als een bepaald vervoerstelsel te beschouwen, eruit bestaat dat opdrachtgevers niets met de interne vervoerstromen te maken hebben. Wat voor opdrachtgevers telt is waar ze kunnen/moeten aanleveren, respectievelijk afnemen. Wij noemen die locaties de eindstations van het vervoerstelsel. Zo’n eindstation van het vervoerstelsel is op zijn beurt een contextuele verbijzondering van een station in een beheerdomein. Sommige stations zijn óók eindstation. Alle stations kunnen eindstation zijn (maar dat lijkt ons niet waarschijnlijk). Zie figuur 6.

Figuur 6.

Dat wil zeggen, een installatie kan dienst doen als een station in een beheerdomein. En, vervolgens, een station kan dienst doen als een eindstation in een vervoersstelsel.
Met zoals in figuur 5 overal — de mogelijkheid — van intext (lees ook: contextueel verbijzonderd gedrag) expliciet aangeduid, vormt figuur 7 ‘slechts’ een wat uitgebreidere versie van figuur 6.

Figuur 7.

De volgende modelleerstap hebben we eigenlijk al toegelicht. De opdrachtgevers komen in beeld. Een bepaalde opdrachtgever kan per eindstation aan- respectievelijk afvoermeldingen opgeven; zie figuur 8.

Figuur 8.

Kortom, een installatie kan dienst doen (functioneren) als een station in een beheerdomein. Op zijn beurt kan een station dan dienst doen (functioneren) als een eindstation in een vervoerstelsel. Een opdrachtgever produceert (gedrag) aan-/afvoermeldingen gerelateerd aan zo’n eindstation.
Onder de noemer van modelleren-voor-gevorderden blijkt dat volgens figuur 8 het opdrachtgeverschap impliciet, wat krom uitgedrukt, het melderschap omvat. Zouden melders ànder gedrag vertonen dan opdrachtgevers, dan moet allereerst melder afgeleid zijn van opdrachtgever (althans, volgens dit voorbeeld). Vervolgens (pas) geldt aan-/afvoermelding als gedragspecificatie van melder. Zie figuur 9.

Figuur 9

Verkenning van dergelijke modelleeralternatieven vormt de crux van metapatroon als contextuele verbijzonderingsmethode. Met zo’n extra detaillering kan de structuur zoveel rationeler worden. Of de toevoeging blijkt nodeloos, maar je kunt dan tenminste vanuit overzicht vragen beantwoorden zoals: Is dat extra detail productief? Of is het impliciet allang duidelijk? Zie verderop als voorbeeld van het laatste de introductie van federatie op hoog modelniveau; juist daardoor komt verdeling naar vervoer resp. voorraad als het ware 'vanzelf' op lager niveau(s) tot uitdrukking. Daarover beweren wij evenmin dat het een beter model oplevert. Wellicht, maar voorlopig is dat allemaal nog aftasten van alternatieven.
Onder de noemer van opdrachtgever laat zich trouwens illustreren hoe verbijzonderde informatievoorziening geënt kan zijn op, zeg maar, informatieve infrastructuur. Het is (ons) duidelijk dat allerlei informatieverzamelingen nadrukkelijk óók tot infrastructuur gerekend moeten — gaan — worden. Wat in Nederland nu basisregistraties heten zijn daar voorbeelden van.
Stel dat een opdrachtgever een erkende organisatie moet zijn, met erkend in de zin van ingeschreven in een (handels)register van een nationale, dus zgn soevereine staat en/of een supranationale organisatie. In figuur 10 geven wij eveneens in aanzet het (deel)model weer dat ik daarvoor allang toepasselijk acht.

Figuur 10.

Dit lijkt nodeloos ingewikkeld, maar het effect is juist dat veel informatiebeheer vervalt (omdat ‘de’ infrastructuur erin voorziet).
Het in figuur 10 toegevoegde symbool van de hoofdletter ‘h’ duidt een homogene hiërarchie aan. Figuur 11 toont een uitwerking.

Figuur 11.

Uitgaande van wat er volgens figuur 10 klaarstaat, dus wat paradoxaal uitgedrukt steeds teruggrijpend op zo’n basissamenstelling, kan je aanvullen hoe je, bijvoorbeeld, de eigenaar van een beheerdomein modelleert, En/of de onderhoudsmonteur van een station. Ga zo maar door, indien van toepassing. Voor dergelijke relaties geven wij overigens vaak de voorkeur aan positie, wat een samenstelling is van a. persoonsidentiteit, b. element-in-organisatiestructuur en c. element-in-functiestructuur. Zie voor nadruk op positie ook het boek Metapattern.
Naarmate dergelijke betekenisvolle infrastructuur groeit, kan je voor je 'eigen' contexten met bijbehorend informatiegedrag doorgaans volstaan met relaties leggen. Aan 'originele' intext (lees ook: de contextueel verbijzonderde, eenduidige gedragsbeschrijving) hoef je niet eens zoveel toe te voegen.
Dergelijk gebruik van infrastructuur ligt nog in de toekomst, zeker met internationaal bereik zoals figuur 10 toestaat. Maar het loont op de kortste termijn reeds om met vooralsnog ‘interne’ informatievoorziening zoveel mogelijk erop te mikken volgens het algeméne model. Dus, in elk geval net doen alsof. Met andere woorden, wees zo eigenwijs en neem wat-ooit-infrastructuur-wordt vooralsnog dan maar in je eigen informatievoorziening mee. Oké, daarin kan je je vergissen, maar nooit zoveel dat je later niet veel simpeler op wat-daadwerkelijk-infrastructuur-geworden-is kan aansluiten (met dienovereenkomstige verlichting van eigen informatiebeheer).
Terug. De aan-/afvoermelding is een geschikte aanleiding om een traditionele vraag over informatie te problematiseren. Van wie ‘is’ de melding eigenlijk?
Wat wij algemeen vinden, is dat via het begrip relatie duidelijk is dat de zoektocht naar enkelvoud misleidend kan zijn. Daarop wijst inderdaad dat voorbeeld van de contextuele (wissel)werking van enerzijds opdrachtgever resp. melder, anderzijds eindstation met melding als gezamenlijk resultaat. 'Is' nu de melding van de opdrachtgever/melder? Of is de melding via het eindstation van het vervoerstelsel? Of zelfs via eindstation naar station van het ene beheerdomein?
In de traditionele informatievoorziening, dus volgens apartheid, ontwijken alle partijen dergelijke vragen. Iedereen geeft immers in isolement hetzelfde antwoord: van mij! Dat leidt tot moeilijk, meestal zelfs totaal òngecoördineerde, want netzo aparte informatiesystemen.
De nieuwe realiteit van het ene stelsel roept uiteraard de vraag op naar gewijzigd informatiebeheer. Daarover schreef één van de auteurs eerder in Informatieverkeer in publiek domein (Pieter Wisse, Ictu, 2004) een agenderende inleiding (vanaf p. 70): van informatie-eigendom naar gebruiksrecht.
De overgang van oude naar nieuwe informatievoorziening zal vaak geleidelijk moeten gebeuren vooral ook koudwatervrees voor - verlies van - gebruiksrecht over informatie te temperen.
Ongehinderd door vakkennis over procesindustrie veroorloven wij ons wat verdere suggesties in modelvorm.
Indien een vervoerstelsel twee of méér beheerdomeinen telt, zijn de onderlinge passages, dwz. van het ene naar het andere beheerdomein, weliswaar niet relevant voor opdrachtgevers voorzover het hun aan- en/of afvoermeldingen betreft. Maar het goed resp. de stof (olie, water, gas, elektriciteit, data, …) dat/die daar wèrkelijk ‘passeert,’ vormt stellig de basis voor onderlinge afrekening en vervolgens voor wat de opdrachtgever betaalt. Hoe dan ook, het lijkt ons zinvol om met het informatiemodel te voorzien in ‘gedrag’ met zoiets als ‘doorvoer’ als context.
Ik zou zeggen dat steeds precies twee beheerdomeinen nul, één of zelfs méérdere (doorvoer)verbindingen kunnen onderhouden. Tot elke verbinding behoort dan van elk beheerdomein precies één station … als doorvoer- of overslagstation. Figuur 12 sluit met deze uitbreidingen op figuur 8 aan.

Figuur 12.

Nogmaals, een bepaald beheerdomein kan middels 0..n bepaalde passages verbonden zijn met precies één ander bepaald beheerdomein. Verder telt een bepaalde passage altijd precies twee doorvoerstations, eentje aan elke ‘kant.’
Zo’n doorvoerstation is overigens nooit tegelijk een eindstation. Een station is eventueel — verder — verbijzonderd tot òf een eindstation in een vervoerstelsel òf een doorvoerstation voor een passage. Overige stations zijn blijkbaar tussenstations ‘in’ een bepaald beheerdomein.
Een beheerdomein is ruimtelijk. Daarom houdt een beheerdomein naar zijn aard altijd tevens voorraadvorming in. Tijdens ‘rustige’ uren wordt goed/stof opgeslagen om uit voorraad te kunnen leveren op het moment dat vraag ontstaat. Klopt, voor elektriciteit is grootschalige opslag — nog? — extra problematisch.
Ondanks eventuele specifieke bezwaren zouden wij opslag enzovoort ter verkenning eveneens zo algeméén mogelijk tot uitdrukking willen laten komen. Voor modellering verdient het aanbeveling om zeker aanvankelijk een algemener perspectief te kiezen. Dan blijkt een term als buffer alweer vergaand beperkt tot een specifieke betekenis (met dienovereenkomstig gedrag), te weten het wellicht toch vooral als van-binnen-naar-buiten ervaren vraagstuk van optimale bezettingsgraad o.i.d.
Reservoir draagt een algemenere betekenis; dat geeft aanleiding om voorraadbeheer wat onafhankelijker te beschouwen, dwz. niet louter als afgeleide van vervoer(sregeling).
Het lijkt veelbelovend om voor voorraad een vergelijkbare differentiatie te verkennen als voor vervoer. Wij brengen daarvoor de aanhef van deze notitie in herinnering.
Ligt het dan niet netzo voor de hand de mogelijkheid om voorraadbeheer met ruimer bereik te plannen dan wat als één enkel zgn netwerk onder beheer is van een bepaalde netwerkbeheerder? Zo ja, dan begint dat toch — of? — met voorraadcapaciteit die noodzakelijkerwijs in een bepaald beheerdomein gelokaliseerd is.
De aan- en afvoer voor een specifiek reservoir verloopt dan natuurlijk ook via … stations. Wanneer reservoirs ‘binnen’ een bepaald beheerdomein ‘liggen,’ geldt hetzelfde voor dergelijke bevoorradingsstations.
Merk ook op dat reservoir, in navolging van station, als een verbijzondering van installatie gemodelleerd staat. Zie figuur 13.

Figuur 13.

Het aardige, althans voor een enthousiaste ontwerper, is dat er meteen allerlei vragen rijzen waarop vroeg of laat inderdaad een antwoord nodig is. Het idee is natuurlijk om reservoirinstallaties pèr beheerdomein vervolgens, indien van toepassing, tot reservoirs op de schaal van het vervoerstelsel te verklaren. Als zodanig (lees ook: in die context) doen ze op die schaal immers pas ‘mee’ in voorraadbeheer. Maar …, leiden reservoirs onder de noemer van vervoer niet ergens tot tegenspraak? Is het niet verstandiger om tevens een voorraadstelsel te veronderstellen? Behoren, strikter genomen, de reservoirs voor algemeen voorraadbeheer dan niet tot dat voorraadstelsel? En zijn zowel vervoer- als voorraadstelsel eigenlijk ook al, in dit geval, aspèctgerichte verbijzonderingen van ‘ iets’ dat nòg omvattender is? Of kunnen vervoer, respectievelijk voorraad beter in nadere contexten tot uitdrukking komen (zodat ‘slechts’ wat tot dusver vervoerstelsel heet een algemener etiket verdient)?
Voor antwoorden op dergelijke vragen kan de ontwerper gestructureerde suggesties doen, dus in de vorm van alternatieve schetsmodellen. Wij kiezen ervoor om hier slechts één alternatief grof uit te werken. Daarvoor erkennen wij dus algemeen dat, bij nader inzien, zelfs vervoer alweer nodeloos beperkend is (gelet op het óók wezenlijke voorraadkarakter van ‘het stelsel’). En dan proberen wij eens zover mogelijk te komen door de vooropgestelde aanduiding vervoer domweg te schrappen. Want zowel het vervoers- als het voorraadaspect zou weleens vanzelfsprekend uit nadere context kunnen blijken. Voor goed begrip van figuur 14 helpt het daarom om allereerst vast te stellen dat daarin vervoerstelsel vervangen is door …, tja, hoe noem je dat? De associatie met een federatief verband lijkt vruchtbaar. Vooruit, voorlopig noemen we ‘het’ maar federatie.

Figuur 14.

Als uitdaging om het expliciete voorraadperspectief op z’n minst wat verder te overwegen, zijn in figuur 14 eveneens eventuele voorraadgerichte meldingen opgenomen die opdrachtgevers kunnen doen. Dat suggereert sterk verband. Een verandering die een opdrachtgever wenst van het totaal van de voorraad die de federatie voor hem beheert, staat deels feitelijk gelijk aan een aan-/afvoermelding. Wat een aan-/afvoermelding tevens is de aanwijzing van een eindstation. Dit werpt dan weer de vraag op, of voorraadmeldingen — let wel, afkomstig van een opdrachtgever — voor afzonderlijke reservoirs gespecificeerd moeten zijn. Wij zouden zeggen, nee. Dergelijke meldingen doet een opdrachtgever aan de federatie-als-geheel (wat simpel in het model valt te wijzigen; dat laten wij graag als oefening aan de lezer).
Het verleggen van die relatie annex ‘ding’ van federatief reservoir naar federatie, betekent echter niet dat federatief reservoir weer uit het model kan verdwijnen. Over — gedrag van — dergelijke reservoirs is specifieke informatie nodig voor het regelen van vervoer-in-combinatie-met-voorraadbeheer (tot en met financiële afrekening).
De nevengeschikte focus op voorraadbeheer bevordert voorts om nogeens na te gaan wat allemaal kan tellen als reservoir. Zodra je beseft dat er wat te halen valt, ga je ook gemotiveerd zoeken. Dat is uiterst productief voor modelkwaliteit. Een schip zoals een olie- of gastanker? Waarom niet? Een olieveld? Een waterbassin? Datahub?
Lòs van politiek correcte antwoorden, is het altijd de moeite waard om te kijken hoe (ook) dergelijke gevallen kunnen passen in het informatiemodel. Via modellering komen zo wellicht èchte strategische kansen voor bedrijfsvoering en/of infrastructuur in beeld.
Tot zover een aanzet voor een concreet informatiemodel. Om er werkelijk hout mee te snijden is het volgens ons noodzakelijk allereerst te verduidelijken hoe 1. de vervoersregeling, 2. de voorraadregeling en, wij zouden zeggen, afgeleid daarvan, 3. de financiële afrekening(en) met opdrachtgevers voor vervoer en/of voorraadbeheer gebeuren. Vooral de vervoersregeling achten wij, nota bene, ònlosmakelijk verbonden met operationeel voorraadbeheer, een vraagstuk van grote formele complexiteit; wij nemen aan dat daarvoor algoritmen/heuristieken uit de — wiskundige — zgn operationele analyse gebruikt worden. Het is dan de vraag of — op enige termijn — het hier geopperde onderscheid tussen beheerdomein, respectievelijk vervoerstelsel en zo door naar federatie aanleiding geeft tot gewijzigde optimalisering van vervoers- annex voorraadregeling met bijbehorende gevolgen voor afrekening enzovoort.
Tenslotte merken wij op dat nog nergens in het tot dusver ontwikkelde informatiemodel de verbijzondering naar een ‘goed’ of ‘stof’ noodzakelijk bleek (zolang hij maar van het ene naar het andere station kan ‘stromen’). Algemene(re) geldigheid is vaak een aanwijzing voor robuustheid. Wellicht dat bedoelde verbijzondering ‘beperkt’ kan blijven tot — het bij voorkeur zo lòs mogelijk gekoppelde gereedschap voor — het ‘uitrekenen’ van de daadwerkelijke vervoers- en voorraadregeling.

Bijlage

Vloeibare of gasvormige stof is een roerend goed.
Een hoeveelheid stof kent een eigenaar, of een groep eigenaren; zo’n groep heet hier voorlopig ook enkelvoudig ‘eigenaar.’
Het eigendom van een hoeveelheid stof is overdraagbaar.
De eigendomsoverdracht staat geregeld in een overeenkomst.
De overdracht betreft 1. een hoeveelheid op 2. een geografische locatie gedurende 3. een tijdvak.
Een overeenkomst kan meerdere overdrachten betreffen.
De overdrachtlocatie is altijd ook een meetpunt.
Voordat de hoeveelheid stof de overdrachtlocatie bereikt, is de leverancier ervoor verantwoordelijk.
De overdrachtlocatie kan verschillen van de locatie(s) waarop de leverancier de hoeveelheid stof verzamelt.
Nadat de hoeveelheid stof de overdrachtlocatie verlaat, is de afnemer ervoor verantwoordelijk.
De overdrachtlocatie kan verschillen van de locatie(s) waarop de afnemer de hoeveelheid stof verspreidt.

De overdrachtlocatie kan ‘verdeeld’ worden door de verantwoordelijkheid voor het stoffelijk vervoer te verbijzonderen: enerzijds beschouwt de leverancier zijn verzamellocatie(s) als overdrachtlocatie(s), anderzijds beschouwt de afnemer zijn verspreidingslocatie(s) als evenzovele overdrachtlocatie(s).
Als verdeelde overdrachtlocatie is zo’n verzamel-, respectievelijk verspreidingslocatie altijd ook een meetpunt.
De partij die de eventueel verbijzonderde verantwoordelijkheid over de hoeveelheid stof draagt tijdens het vervoer van verzamel- naar verspreidingslocatie(s) heet hier een vervoersagent.
Accumulatie van vervoersbehoeften — en, nota bene, onder voorwaarde van uni- en transformeerbaarheid van de stof — ontkoppelt het directe verband tussen eigendomsoverdracht en routering.
De intermediaire overdrachtlocatie ‘virtualiseert.’
Een virtuele locatie hoeft geen meetpunt te zijn.

Stoffelijk vervoer verloopt tussen locaties; gezien vanuit verzamel- en verspreidingslocaties zijn dat al dan niet intermediaire locaties.
Een traject verbindt locaties.

Een traject kan apart in beheer zijn.
De beheerder beheert wat geldt als een netwerk van het perspectief van een enkel traject.
Een enkel traject is het eenvoudigste netwerk.
Vanuit het perspectief van stoffelijk vervoer in het algemeen beheert de netwerkbeheerder een deelnetwerk van trajecten.
Er zijn locaties, al dan niet intermediair, die via diverse trajecten ‘aangesloten’ zijn op diverse andere locaties.
Meervoudige aansluiting betekent — de mogelijkheid van — variabele, flexibele routering.

Daadwerkelijke routering van stoffelijk vervoer door het algemene netwerk kan volgens diverse ‘methoden’ bepaald zijn.
De twee uiterste methoden zijn 1. brede optimalisering: het algemene netwerk is volledig transparant en 2. smalle optimalisering: elke netwerkbeheerder bewaakt eenzijdig de externe toe- en uitgangen van zijn eigen deelnetwerk.

Een (ver)simpel(d) voorbeeld van ‘brede optimalisering:’

— er zijn 2 verzamellocaties, a en z
— er zijn 2 verspreidingslocaties, b en y
— er is de ene handelsovereenkomst voor levering van een hoeveelheid stof van a naar y
— er is de andere handelsovereenkomst voor levering van een hoeveelheid stof van z naar b
— de hoeveelheid/kwaliteit stof en het tijdvak zijn voor beide overeenkomsten gelijk.

Als alternatief voor stoffelijk vervoer van-a-naar-y èn van-z-naar-b geldt stoffelijk vervoer van-a-naar-b en van-z-naar-y.

Het ligt voor de hand dat elke netwerkbeheerder minstens dergelijke vervoersoptimalisering beoefent voor ‘zijn’ deelnetwerk, dus ‘intern.’
Zo ja, dan verschillen — nota bene, hier vooralsnog abstraherend van politiek-bestuurlijke en commerciële aspecten — methoden voor smalle en brede optimalisering niet kwalitatief; door opschaling/verbreding groeit ‘slechts’ het relevante netwerk kwantitatief.

Voor het regime van smalle optimalisering gelden àlle externe toe- en uitgangen van het deelnetwerk in kwestie als verzamel- en/of verspreidingslocaties.
De (deel)netwerkbeheerder beslist zelfstandig — hier blijft reële afhankelijkheid gemakshalve buiten beeld — over in- en uitstroom van de hoeveelheid stof.

Voor het regime van brede optimalisering vervalt — onder voorwaarden van regulier ‘bedrijf’ — de beslissingsautonomie van de afzonderlijke (deel)netwerkbeheerder over vervoersregeling.
Enkele, of wellicht zelfs alle, grenslocaties van een deelnetwerk zijn op de algemene schaal overslaglocaties.
Dan is het overslagvolume enzovoort voor zo’n intermediaire locatie bepaald vanuit algemene(re) overwegingen.

De toekomstvastheid wordt sterk bevorderd door formeel onderscheid aan te houden tussen:

— het netwerk als domein van vervoerscoördinatie
— het netwerk als beschikbare infrastructuur.

Voor smalle optimalisering overlappen beide netwerken elkaar; zo’n één-op-één verhouding kan zo geworteld zijn, dat het nut van bedoeld onderscheid (nog) niet herkend is.
Voor brede optimalisering omvat het ene vervoersdomein diverse infrastructurele (deel)netwerken.

Omgekeerd, informatievoorziening die voor brede optimalisering opgezet is, werkt altijd voor smalle optimalisering.
Dit laatstgenoemde (smal) is immers ‘slechts’ een bepaald geval, te weten het eenvoudigste, van het eerstgenoemde (breed).
Smal is óók breed, zij het minimaal.

Uitwerking van voordelen van brede optimalisering vallen buiten het bestek van deze aanzet.
Het komt erop neer dat, op de schaal van het totale netwerk, met gelijke vervoerscapaciteit méér hoeveelheid stof bij verspreidingslocaties afgeleverd wordt.
Of hetzelfde volume met minder vervoerscapaciteit.
Verder kan beheer/eigendom over (deel)netwerken eenvoudiger veranderen (maar, wie weet, geldt dat juist als nadeel).
Waarom eenvoudiger?
Bij smalle optimalisering verandert de vervoerscoördinatie onherroepelijk, wanneer toe- en uitgangen van beheerder/eigenaar wisselen.
Voor brede optimalisering hebben beheers- resp. eigendomsverhoudingen — toegegeven: idealiter — géén invloed op vervoerscoördinatie.

Aangezien de horizon voor vervoerscoördinatie minstens gelijk òf breder is dan de beheers-/eigendomshorizon, vormt — naar de huidige stand van inzicht — ‘vervoer’ de primaire insteek voor de — nieuwe — opzet van informatievoorziening.
Hoe optimalisering gebeurt, blijft ònbehandeld; er gaat bepaalde informatie de black-box-voor-optimalisering in, en er komt bepaalde informatie uit.
De uitkomst betreft instellingen van alle locaties in het gehele vervoersdomein: hoeveel stof gaat daar gedurende een bepaald tijdvak ‘passeren’?
Daarvoor geldt als uitgangspunt de opgave van overeengekomen hoeveelheden op verspreidingslocaties en geplande hoeveelheden op verzamellocaties.
Door het formele onderscheid tussen vervoers- en beheersdomein ontstaat echter een ànder informatiemodel; kenmerkend daarvoor — althans vergeleken met de huidige opzet — is in eerste aanleg de abstractie van enige specifieke zgn (deel)netwerkbeheerder; dat maakt, als het goed is, het informatiemodel op hoofdlijn zelfs eenvoudiger.