SIG FRIEDA Werkgroepen – v1

SIG FRIEDA Werkgroepen – v1
Als onderdeel van sig FRIEDA worden werkgroepen ingericht. Elke werkgroep richt zich op een deel
van de architectuur van het UWKS.
Voorbereiding door RWS
RWS zorgt ervoor dat de sig Frieda werkgroepen doelgericht aan het werk kunnen. Dit gebeurt door
een deel van de architectuur te maken. Dit is het deel dat beschrijft wat de behoefte van de
architectuur is en hoe de logica van de oplossingsrichting wordt gestructureerd. RWS doet dit aan de
hand van de methode Enterprise Architectuur RWS (EAR). Tijdens de startbijeenkomst van 3 februari
2011 is EAR toegelicht (zie de bijgesloten presentatie).
Sig Frieda completeert de architectuur
Via sig FRIEDA zoekt RWS de samenwerking met de markt om de architectuur verder te
completeren. Het doel daarbij is om breed gedragen keuzes te maken voor de implementatie. In de
architectuur aanpak heet dit de Systeem Implementatie Beschrijving.
Aan de hand van de huidige inzichten voor de onderwerpen van de Systeem Implementatie
Beschrijving is een voorstel gemaakt voor de indeling in werkgroepen. Elk onderscheiden onderwerp
zal worden opgepakt door een werkgroep. Mocht dit niet voldoende blijken dan kan dit in de sessie
van 17 februari 2011 worden ingebracht.
De werkgroepen
Drie van de werkgroepen worden gekoppeld aan verschillende soorten fysieke componenten. In
onderstaand schema is met kaders aangegeven hoe de werkgroepen hier op passen. Werkgroep 3,
de Host, is een complexer component.
Schema twee verduidelijkt werkgroepen 3 en 4. Hier zijn de werkgroepen gedefinieerd op basis van
de software componenten in de Host. Het schema laat zien dat er een scheiding is tussen de fysieke
host waarin ook een deel van de basale software componenten (werkgroep 3) en de hogere lagen
van de software componenten (werkgroep 4).
De vier werkgroepen krijgen de volgende opdrachten
WG1 Actuatoren
De werkgroep WG1 richt zich op de actuatoren die voor het UWKS 2.0 noodzakelijk zijn. Dit omvat
alle actuatoren die nodig zijn voor Verkeerssignalering en Monitoring, zoals hieronder opgesomd:
1. Signaalgever, zowel rijstrook- als rijbaangebonden signaalgevers die een gedefinieerde set
beelden kunnen tonen.
2. Rotatiepaneel. Een signaalgever die zich als bebording manifesteert met drie mogelijke
beelden. Typisch gebruik is voor snelheidsgeboden of bewegwijzering bij spitsstroken.
3. Object, bestaande uit brug en tunnel. Deze actuator representeert de mogelijkheid voor een
object om lokaal in te grijpen op een UWKS. Dit komt overeen met de LIB en BIV
functionaliteit in Verkeerssignalering.
4. MUS, afkorting voor MUlti Sign. Deze actuator representeert een generieke mogelijkheid om
een discreet aantal toestanden aan te sturen (vanuit het UWKS) en een discreet aantal
toestanden te ontvangen (vanuit de MUS).
De opdracht voor deze werkgroep is het opstellen van het relevante deel van de Systeem
Implementatie beschrijving. Dit omvat typisch het kiezen van interfaces op meerdere (OSI) lagen
voor de interactie met deze actuatoren, vaststellen van de betrokken componenten en hun
specifieke functionaliteit (bv de eisen voor het synchroon knipperen van flashers op een
signaalgever) en de eisen die de actuatoren stellen aan het gedrag en werking van de HOST.
WG2 Sensoren
De werkgroep WG2 richt zich op de sensoren die voor het UWKS 2.0 noodzakelijk zijn. Voor de
toepassingen Verkeerssignalering en Monitoring bestaat dat alleen uit de Detector; of meer
nauwkeurig de voertuigpassagedetector.
Vanuit de behoeften van RWS kan onderscheid worden gemaakt in meerdere kwaliteiten
detectoren. RWS wil onderscheid toestaan in detectiekwaliteiten voor Monitoring (hoge
nauwkeurigheid en beschikbaarheid, 5 voertuigcategorieën) , normale verkeerssignalering,
verkeerssignalering voor bijzondere ondergrond (bv stalen fundering zoals bruggen of tunnels) en
Werk In Uitvoering. Hiermee wil RWS het mogelijk maken om gedefinieerd om te gaan met
verschillende situaties waarbij andere technologieën een kans krijgen (bv radardetectie bij Werk In
Uitvoering).
De opdracht voor deze werkgroep is het opstellen van het relevante deel van de Systeem
Implementatie beschrijving. Dit omvat typisch het definiëren van interfaces met de sensoren, het
vaststellen van de betrokken componenten en hun specifieke functionaliteit en de eisen die de
sensoren stellen aan het gedrag en werking van de HOST.
WG3 Platform
De werkgroep WP3 richt zich op het platform dat de faciliteit biedt voor de software, in het schema
aangeduid als UWP en Application Services. Het platform zal bestaan uit één of meer componenten
die aan de ene zijde (fysieke)interfaces biedt aan de overige (fysieke)componenten, via een
processing unit (een computer) tot en met een operating system dat geschikt is om het UWP en
Application Services te laten functioneren.
De werkgroep WP3 richt zich verder op de voedingsvoorziening en de wegkantkast.
De opdracht voor deze werkgroep is het opstellen van het relevante deel van de Systeem
Implementatie beschrijving, waarbij het mogelijk moet zijn dat componenten van het platform door
verschillende leveranciers kunnen worden ingevuld, zonder daarbij Implementatieafhankelijkheden
tussen componenten te creëren (ihb. de UWP en Application Services).
N.B. Het is uitdrukkelijk geen wens van RWS dat dit leidt tot één keuze voor een processor type.
WG4 Software Stack
De werkgroep WP4 richt zich op de software stack die op het platform zal draaien, in het schema
aangeduid als UWP, Application Services en Diagnose. Het zal uitsluitend bestaan uit software. Het
UWP zal daarin de mogelijkheid bieden om Application Services voor Verkeerssignalering en
Monitoring uit te voeren. Voor het vaststellen van de architectuur van het UWP zal gebruik worden
gemaakt van CVIS. Diagnose staat voor een extern systeem dat gevoed moet worden met
diagnostische gegevens over het functioneren van het complete UWKS. Langs dit pad moet
informatie worden ontsloten voor alle beheerpartijen om adequaat beheer mogelijk te maken.
De opdracht voor deze werkgroep is het opstellen van het relevante deel van de Systeem
Implementatie beschrijving, waarbij het mogelijk moet zijn dat componenten van het platform door
verschillende leveranciers kunnen worden ingevuld, zonder daarbij Implementatie afhankelijkheden
tussen componenten te creëren.