Marktverkenning Componenten DVM-systeem

Ministerie van Verkeer en Waterstaat

Directoraat-Generaa] Rijkswaterstaat Adviesdienst Verkeer en Vervoer

Marktverkenning Componenten DVM-systeem Een wereldwijde marktverkenning naar systeemdelen voor een duurzaam Verkeersmanagement systeem 16 September 2002 versie 1.0

Adviesdienst Verkeer en Vervoer Directoraat-Generaal Rijkswaterstaat

Ministerie van Verkeer en Waterstaat

DirectOTaat-Generaal R i j k s w a t e r s t a a t Adviesdienst Verkeer en Vervoer

Marktverkenning Componenten DVM-systeem Een wereldwijde marktverkenning naar systeemdelen voor een duurzaam Verkeersmanagement systeem 16 september 2002 versie 1.0

Colofon Uitgegeven door:

Ministerie van Verkeer en Waterstaat Directoraat-Generaal Rijkswaterstaat Adviesdienst Verkeer en Vervoer Postbus 1031 3000 BA Rotterdam

Informatie: Telefoon: Fax: E-mail:

Service Desk AVV 045 5605200 045 5605 209 [email protected]

Uitgevoerd door:

Dr. T.J. Grant Ir. R. Moerman Dr.ir. B.D. Netten

Onder begeleiding van:

P. Kik G. Mol Ir. W.W. Polman Ing. E.R. van der Ster

Opmaak:

Datum:

Marktverkenning Componenten DVM-systeem

16 september 2002

Inhoudsopgave

Inhoudsopgave

4

Samenvatting

8

Summary

10

1 1.1 1.2 1.3 1.4 1.5

Inleiding Achtergronden van de marktverkenning Doel van de marktverkenning Scope marktverkenning en status rapport Vervolgstappen Doelgroep en leeswijzer

12 12 13 13 14 14

2 2.1 2.1.1 2.1.2 2.1.3 2.1.4 2.1.5 2.2 2.2.1 2.2.2 2.2.3 2.2.4 2.2.5 2.2.6 2.2.7 2.2.8 2.2.9

Gevolgde aanpak Fasering Bepaling aandachtsgebieden Longlist Selectie van producten voor de shortlist Shortlist Eindrapportage Informatiebronnen Uitgangsdocumenten Internet Air Traffic Control beurs Petrotech 2002 lntertraffic2OO2 ITS America Bezochte eindgebruikers Leveranciers bezoeken Bezochte projecten

15 15 15 15 16 16 17 17 17 18 18 19 20 21 22 22 23

3 3.1 3.1.1 3.1.2 3.1.3 3.2 3.2.1 3.2.2 3.2.3 3.2.4 3.2.5 3.3 3.3.1 3.3.2 3.3.3 3.3.4 3.3.5

Markt, matching en ACT Criteria voor productevaluatie Functionele eisen Niet-functionele eisen - Product integratie ACT functionele landkaart Categorieën van producten Lagenmodel: van fysieke apparatuur naar business niveau Scope van de Applicatie Architectuur Lagenmodel in relatie tot ACT Product Categorieën Categorieën afgebeeld op ACT BL toolkits in MES-laag Inleiding Gemeenschappelijk eigenschappen Producten Selectie criteria Afbeelding op ACT

24 24 25 26 28 30 31 34 34 36 37 38 38 39 39 40 43


3.3.6 3.3.7 3.4 3.4.1 3.4.2 3.4.3 3.4.4 3.4.5 3.4.6 3.4.7 3.5 3.5.1 3.5.2 3.5.3 3.5.4 3.5.5 3.6 3.6.1 3.6.2 3.6.3 3.6.4 3.6.5 3.6.6 3.7 3.7.1 3.7.2 3.7.3 3.7.4 3.7.5 3.7.6 3.7.7 3.8 3.8.1 3.8.2 3.8.3 3.8.4 3.8.5 3.8.6 3.8.7 3.9 3.9.1 3.9.2 3.9.3 3.9.4 3.9.5 3.9.6 3.9.7 3.9.8 3.10 3.10.1 3.10.2 3.10.3 3.10.4 3.10.5 3.10.6 3.10.7


Specifieke eigenschappen Conclusies Supervisory Control And Data Acquisition (SCADA) Inleiding Gemeenschappelijke eigenschappen Producten Selectie criteria Afbeelding op ACT Specifieke eigenschappen Bevindingen en Conclusie Device Drivers Inleiding Producten Selectie criteria Afbeelding op ACT Bevindingen en Conclusies Actuator Management Systemen Inleiding Gemeenschappelijke eigenschappen Selectie criteria Afbeelding op ACT Product specifieke eigenschappen Bevindingen en conclusies Toolkits voor de presentatielaag Inleiding Gemeenschappelijke eigenschappen Producten Selectie criteria Afbeelding op ACT Specifieke eigenschappen Conclusies Totaaloplossingen voor DVM Inleiding Gemeenschappelijk eigenschappen Producten Selectie criteria Afbeelding op ACT Specifieke eigenschappen Conclusies VANESSA Inleiding Globaal ontwerp Selectie criteria Afbeelding op ACT Product specifieke eigenschappen Aandachtspunten Stand van zaken Vergelijkbare ontwikkelingen Bevindingen Algemene Bevindingen MES model BL Toolkits SCADA/PLC producten Dedicated device drivers VMS Presentatie toolkits

45 46 47 47 47 49 49 52 53 55 57 57 57 57 59 59 60 60 61 62 64 66 67 69 69 70 71 71 73 74 75 75 75 76 76 78 82 84 86 87 87 88 88 91 93 93 93 94 94 94 95 95 95 96 96 96

3.10.8 4 4.1 4.1.1 4.1.2 4.1.3 4.1.4 4.2 4.2.1 4.2.2 4.2.3 4.2.4

Totaaloplossingen

96

4.2.5 4.2.6 4.2.7 4.2.8

Ontwikkelingen in de markt 97 Systeemontwikkeling door de markt 97 Componenten versus producten 97 Van sensoren en actuatoren naar maatregelen 99 Totaaloplossingen op komst 99 Bevindingen en conclusies 100 Gebruikte standaarden voor koppeling en communicatie van systemen 100 NTCIP - National Transportation Communications for ITS Protocol 101 UTMC - Urban Traffic Management & Control 106 NMCS2 - National Motorway Communication System 2 108 OCIT - Open Communication Interface for Road Traffic Control Systems 109 TLS - Technische Lieferbedingungen für Streckenstationen 110 LCR - Langage de Commande Routier 112 IVERA - Initiatiefgroep VERkeersregeltechnici ASTRIN 112 Data definities in XML - eXtensible Markup Language 113

4.2.9

CORBA naar het wegkantstation

116

4.2.10 4.2.11 4.3 4.3.1 4.3.2 4.3.3 4.3.4 4.3.5 4.3.6 4.3.7 4.4 4.4.1

CORBA in DVM systemen Bevindingen en conclusies Marktverkenning PLC/SCADA/DCS/Industriële computers Inleiding Veldbussen Programmable Logic Controllers (PLC) Supervisory Control And Data Acquisition (SCADA) Distributed Control Systems (DCS) Industriële computers Conclusies Ervaringen in andere branches Rail Infrastructuur

119 119 122 122 122 122 123 123 123 123 124 124

4.4.2

Rail voertuigen

127

4.4.3 4.4.4 4.4.5

Luchtverkeersleiding Petrochemie Utilities

128 129 130

4.4.6

Ruimtevaart

131

4.4.7

Landmacht

133

4.4.8

Marine

136

4.4.9 4.5

Bevindingen en conclusies Bevindingen en conclusies

138 139

5 5.1 5.1.1 5.1.2 5.1.3 5.1.4 5.1.5 5.1.6 5.2 5.2.1 5.2.2 5.2.3 5.3

Bevindingen, conclusies en aanbevelingen Bevindingen Zoekresultaten producten Architectuur Interface standaarden Extra CORBA en XML onderzoeksopdracht Extra PLC/SCADA/DCS/Industriële computers onderzoeksopdracht Projectaanpak Conclusies Gevonden Producten DVM Systeem op basis van VANESSA DVM Systeem zonder VANESSA Aanbevelingen

140 140 140 141 142 143 144 145 146 146 147 147 148

6

Opgedane ervaringen m.b.t. marktverkenning

150


6.1 6.2 6.3 6.4 6.5 6.6 6.7 6.8 6.9 6.10

Karakterisering van het project Gebruik van internet Gebruik van e-mail Telefonische follow-up Reacties van bedrijven op questionnaires Beursbezoeken Bedrijfsbezoeken en presentaties Projectdossier Praktische zaken Conclusie

Referenties Afkortingen

Bijlage A Bijlage B Bijlage C Bijlage D Bijlage E


150 152 152 152 153 155 155 155 156 156

157 160

Lijst van aangeschreven leveranciers Longlist van producten Shortlist productbeschrijvingen Questionnaires Functionele en niet-functionele eisen

Samenvatting

Door een AVV-IBI team is een wereldwijde marktverkenning uitgevoerd. Het doel van de marktverkenning is: Inzicht krijgen in de beschikbaarheid op de markt en de mate van toepasbaarheid van Commercial Off The Shelf (COTS) producten voor generieke delen van een duurzaam dynamisch verkeersmanagement (DVM) systeem. Het resultaat van de marktverkenning is: Er zijn producten gevonden, die binnen de Architectuur voor VerkeersBeheersing (AVB) geplaatst kunnen worden en die tevens voldoen aan de gestelde functionele en niet functionele eisen van de Applicatie Architectuur (AVB-AA). Er zijn echter geen COTS producten gevonden in de vorm van componenten, die voldoen aan het Applicatie Componenten Topologie (ACT) ontwerp. De markt van producten ten behoeve van locale autonome regelingen in combinatie met een centraal management systeem wordt gedomineerd door respectievelijk Programmable Logic Controller (PLC) en Supervisory Control And Data Acquisition (SCADA) producten. De toepassing van een SCADA pakket als uniforme intermediair tussen systemen in de verkeerscentrales en de apparatuur aan de wegkant vormt derhalve mogelijk een goede eerste stap in de toepassing van COTS producten. Het gebruik van PLC's als wegkantplatform sluit hier vervolgens naadloos op aan. Voor de verbinding tussen het wegkantplatform en de sensoren en actuatoren is de Profibus veldbus een geschikte open standaard, die reeds door leveranciers ondersteund wordt. Een DVM systeem op basis van de reeds in ontwikkeling zijnde gebruikersinterface "VANESSA" kan gerealiseerd worden met COTS producten uit de productcategorie SCADA/PLC, voor het inwinnen en distribueren van sensor informatie en het aansturen van actuatoren. Een DVM systeem zonder "VANESSA" kan gerealiseerd worden met COTS producten uit de productcategorie SCADA/PLC, aangevuld met een bedieningsinterface. De marktverkenning resulteerde in ondermeer de volgende aanbevelingen: 1. Implementeer de Applicatie Architectuur uit de Architectuur voor VerkeersBeheersing op basis van (AVB conforme) marktproducten en niet op basis van componenten met de omvang zoals deze is gedefinieerd in de Applicatie Componenten Topologie. 2. Om de volgende generatie verkeersmanagementsystemen conform AVB met COTS producten van verschillende leveranciers te kunnen ontwikkelen


is conformiteit met een internationale standaard voor koppeling van systemen gewenst. De categorie van SCADA en PLC producten is de enige categorie uit de shortlist met COTS producten op basis van zo'n standaard. Het aantal SCADA en PLC producten is echter vele malen groter dan het aantal producten dat in dit project is geëvalueerd, en een aanbeveling voor één specifiek product is dan ook niet opportuun. 3. Gezien de geringe ervaring op het gebied van SCADA/PLC standaarden bij verkeersmanagement systemen is het uitvoeren van een kleinschalige praktijkproef aan te bevelen. 4. Voor de Nederlandse ITS systemen moeten standaarden worden opgesteld, bij voorkeur afgeleid van een of meer bestaande standaarden in een samenwerkingsverband tussen verkeersindustrie en overheid De overige aanbevelingen hebben betrekking op praktische architectuur aspecten van AVB en KAREN, en het omgaan met XML en CORBA. Het uitgangspunt voor de marktverkenning bestaat naast de Architectuur voor Verkeersbeheersing voornamelijk uit de resultaten van het Applicatie Componenten Topologie project. Daar dit beide in feite slechts architectuur ontwerpen zijn en de beschrijving van het operationele concept en de specificaties van het te realiseren DVM systeem ontbreken, is in het kader van het project een beknopte lijst van eisen opgesteld. Deze eisen hebben gefungeerd als evaluatie criteria voor de gevonden producten. De voornaamste onderzoekslijn van het MATCH project is uitgevoerd op basis van de volgende fasering: • Bepaling aandachtsgebieden, resulterend in beschrijvingen van context, sensor en actuator management en applicatie control; • Longlist fase, waarin een questionnaire is verstuurd naar 300 potentiële leveranciers, hetgeen resulteerde in 140 ontvangen product questionnaires; • Selectie van producten voor de shortlist, waarbij de producten werden getoetst aan een aantal basiscriteria, resulterend in een shortlist van 35 producten; • Shortlist fase, waarin nadere informatie is verzameld over shortlïst producten, welke informatie vervolgens is geëvalueerd; • Eindrapportage fase, waarin de resultaten zijn gepubliceerd nadat er bevindingen, conclusies en aanbevelingen aan zijn toegevoerd. Naast de marktverkenning op basis van questionnaires met het doel om COTS producten te identificeren, zijn vier neven onderzoeken uitgevoerd: • Een inventarisatie van systemen die reeds worden toegepast door bedrijven met een vergelijkbare problematiek van geografisch gedistribueerde besturing en bewaking; • Een onderzoek naar trends op het gebied van verkeers management standaarden, waarbij de standaarden welke in de gevonden producten werden toegepast als uitgangspunt genomen zijn; • Een onderzoek naar aspecten van het gebruik van CORBA (Common Object Request Broker Architecture) en XML (eXtended Markup Language) in een Dynamisch Verkeers Management systeem; • Een verkennend onderzoek naar de beschikbare technologie op het gebied van SCADA en PLC. Van de laatste twee onderzoeken zijn separate rapporten opgeleverd Van de door het projectteam opgedane ervaringen op het gebied van marktonderzoek is verslag gedaan in een separaat hoofdstuk.


Summary

An AVV-IBI team has conducted a worldwide market survey. The aim of the market survey was: To obtain insight into the availability and applicability of Commercial Off The Shelf (COTS) products for implementing the generic parts of a modernised dynamic road-traffic management (DVM) system in the Netherlands. The results of the market survey were as follows: Products have been found which conform both to the Ministry's architecture for traffic management - "Architectuur voor Verkeersbeheersing" (AVB) in Dutch - and to the functional and nonfunctional requirements of the AVB Application Architecture (AVBAA). However, no products have been found that comply with the subsequent AVB-AA component-based design - known by its Dutch title as "Applicatie Componenten Topologie" (ACT). The market for products providing local control combined with central supervisory control is dominated by Programmable Logic Controller (PLC) and Supervisory Control And Data Acquisition (SCADA) systems. The application of a SCADA package as a uniform layer between systems in traffic control centers and in road-side equipment would be a good initial step towards the application of COTS products. The use of PLCs as road-side outstations would fit seamlessly into this concept. The Profibus field bus would be suited to connecting the road-side outstations to the physical sensors and actuators, since it is an open standard already supported by the market. A DVM system based on the nearly-completed user interface "VANESSA" could be realized by COTS products from the SCADA/PLC category, to gather and distribute sensor data and to send control instructions to the actuators. A DVM system without "VANESSA" could be realized by COTS products from the SCADA/PLC category, supplemented by a user interface. The market survey resulted in the following recommendations: 1.

The AVB-AA should be implemented on the basis of (AVB-conform) market products, rather than on the basis of components with the granularity assumed in the ACT project.

2.

A COTS-based, AVB-compliant, next-generation traffic management system should be developed so as to conform to an international interfacing standard. Amongst the short-listed COTS products only the SCADA/PLC category is based on such a standard. However, the number of SCADA and PLC products on the market is much larger than the


10

number of products evaluated in this project. Therefore, it is not opportune to make a recommendation for any one specific product. 3.

A small-scale pilot project using a SCADA/PLC system should be performed in order to gain experience in the area of traffic management standards.

4.

Interfacing standards for Dutch ITS systems should be established in collaboration between government and the traffic industry, preferably by derivation from one or more existing standards.

Other conclusions and recommendations have to do with the practical architectural aspects of AVB and KAREN, and with the use of XML and CORBA. The starting point for the market survey was the AVB architecture, together with the ACT project results. As these are essentially architectural designs, the survey team lacked a description of the operational concept and the DVM system specification. For the purposes of this project it was necessary to compile a concise list of requirements. These requirements have served as the evaluation criteria for the surveyed products. The main research activities of MATCH followed this approach: • Determination of the areas of interest, resulting in descriptions of the context for sensor and actuator management and for application control; • Long-list stage, in which a questionnaire was sent to 300 potential suppliers, eliciting the completion and submission of 140 product questionnaires; • Selection of products for the shortlist, in which the products were assessed against the evaluation criteria, resulting in a shortlist of 35 products; • Shortlist stage, in which more detailed information was obtained and assessed about the short-listed products; • Final report stage, in which the results were documented, together with the survey findings, conclusions and recommendations. Supplementary to the questionnaire-based market survey of COTS products, four additional research activities were carried out: • Research into systems in other, non-ITS branches with geographicallydistributed management and control of operations; • Research into trends in the area of traffic management standards. The starting point was the set of standards used in the short-listed products. • Research into aspects concerning the use of CORBA (Common Object Request Broker Architecture) and XML (eXtended Markup Language) in a DVM system; • Research into available technology in the area of SCADA and PLC. The latter two activities were set up as separate projects that delivered their own reports. In a separate chapter the project team reported on their experiences in conducting a market survey.


11

1 Inleiding 1.1

Achtergronden van de marktverkenning

In de achterliggende decennia is voor het Nederlandse HoofdWegenNet een veelheid aan afzonderlijk ontwikkelde, vaak Rijkswaterstaat specifieke, verkeersbeheersingssystemen opgeleverd. Deze zijn deels verouderd en ongeschikt om verder uit te bouwen met nieuwe functies. De belangrijkste knelpunten die zich voordoen zijn: onvoldoende mogelijkheden voor duurzame implementatie van nieuwe verkeersmaatregelen, lange doorlooptijden bij aanpassingen, geen mogelijkheden voor netwerkbreed dynamisch verkeersmanagement en hoge exploitatiekosten. Om aan deze uitdagingen het hoofd te bieden is door de Rijkswaterstaat de Architectuur voor Verkeersbeheersing (AVB) ontwikkeld.

Figuur 1 : Het AVB-architectuurraamwerk Een onderdeel daarvan, de AVB Verkeerskundige Architectuur [AVB_VA], wordt inmiddels al op diverse plaatsen in het land toegepast. Deze toepassingen worden echter nog niet ondersteund door informatie- en/of regelsystemen. De behoefte aan deze systemen (applicaties) en de daarvoor benodigde technische infrastructuur is groeiende. SAVIERA (Standaard Applicaties voor Verkeers-Informatie En Regel Algoritmes) is het systeem dat invulling gaat geven aan de Applicatie Architectuur. De realisatie en ontwikkeling van SAVIERA betreft het gehele traject van uitwerken van de AVB Applicatie Architectuur [AVB_AA] tot en met het realiseren van de applicaties. SAVIERA verzorgt het management van gedistribueerde systemen ten behoeve van Dynamisch Verkeersmanagement, binnen een netwerk.


12

In het kader van SAVIERA is in 2001 door de Adviesdienst Verkeer en Vervoer van de Rijkswaterstaat gewerkt aan het ACT-project (Applicatie Componenten Topologie). In dit project zijn de componenten1 van SAVIERA gedefinieerd en hun onderlinge samenhang. Daarmee zijn de eerste specificaties van het te bouwen SAVIERA systeem opgeleverd, zie [OCD_ACT], [SSS_ACT] en [SSDD_ACT]. Samen met de verkeerskundige logica van de te realiseren maatregelen, is dit de basis voor de bouwfase van het SAVIERA-systeem. Het beschikbaar krijgen van de componenten van SAVIERA kan door middel van het starten van een maatwerk ontwikkelingstraject. Een andere mogelijkheid is het kopen van de componenten of delen daarvan op de markt. In verband met het gebruikmaken van beproefde technologie, extensivering van IT systeemkennis en kostenbeheersing lijkt dit een aantrekkelijke optie. Binnen SAVIERA geldt dit met name voor de "command en control" functies en de generieke functies bij het managen van sensoren en actuatoren.

1.2 Doel van de marktverkenning Het doel van de marktverkenning is: Inzicht krijgen in de beschikbaarheid op de markt en de mate van toepasbaarheid van COTS7 producten voor generieke delen van een duurzaam dynamisch verkeersmanagement systeem. Mede op basis van dit inzicht zal Rijkswaterstaat een keuze maken uit de alternatieven voor het systeemontwerp. Het marktverkenningsonderzoek dient binnen dit kader een advies te leveren voor het eventueel toepassen van COTS producten, met inzage in de alternatieve mogelijkheden en de consequenties. In hoofdstuk 3 is een paragraaf aan VANESSA gewijd, maar onderzoek naar overige niet commerciële producten valt buiten de scope van het project., evenals een mogelijk onderzoek naar de haalbaarheid van ACT.

1.3

Scope marktverkenning en status rapport

De marktverkenning betreft een oriëntatie op de beschikbaarheid en bruikbaarheid van COTS producten. Daarbij gaat het met name om softwareproducten binnen de Applicatie Architectuur. De technische infrastructuur waarop de software draait valt buiten de scope van de verkenning. Hiernaar is alleen gekeken in het geval een marktproduct hierin geen scheiding heeft aangebracht. De COTS producten zijn beoordeeld op hun huidige potenties. Plannen van de leverancier en nog lopende ontwikkelingen ten aanzien van het product zijn buiten beschouwing gelaten. Bij de marktverkenning zijn eisen en wensen gehanteerd zoals geformuleerd in AVB-AA en ACT. Dit zijn voor een groot deel globale functionele eisen. Op basis daarvan kon geen strikte productselectie worden toegepast. Voor deze verkenning was het ook niet wenselijk, om producten met potenties in de

1

Component Een van tevoren gebouwd softwareonderdeel, met een goed gedefinieerde interface en goed gedefinieerd gedrag, dat kan worden gebruikt én hergebruikt in verschillende applicaties. Zie ook: H4.1.1 2 Commercial Off The Shelf producten; daarbij gaat het om duurzame producten of systeemdelen die op de markt beschikbaar zijn.


13

beschouwing mee te nemen. Hoewel gedurende het onderzoek wel een schifting van producten op basis van globale eisen ten aanzien van bruikbaarheid heeft plaats gevonden, is er in het kader van dit onderzoek geen sprake van een officiële productselectie. Nadat Rijkswaterstaat met deze onderzoeksresultaten inzicht heeft gekregen in de mogelijkheden van COTS producten, zal mogelijk aan de markt verzocht worden om (ontwerp)altematieven op basis van nog op te stellen producteisen en selectiecriteria.

1.4 Vervolgstappen Het is inmiddels waarschijnlijk dat VANESSA toegepast gaat worden als gebruikersinterface voor SAVIERA. Omdat hierover bij de start van de marktverkenning maar ook tijdens de uitvoering nog geen formeel besluit is genomen, zijn COTS producten voor de besturing van SAVIERA gewoon meegenomen in de beschouwing. Daarnaast is bij de aanbeveling zowel een variant met VANESSA als een variant zonder VANESSA opgenomen.

1.5 Doelgroep en leeswijzer Dit rapport betreft het verslag van de marktverkenning naar COTS-producten voor generieke delen van het Dynamisch Verkeersmanagement (DVM) systeem van Rijkswaterstaat. Het rapport is bedoeld voor degenen binnen Rijkswaterstaat die verantwoordelijk zijn voor het voorbereiden van de besluitvorming en het maken van ontwerpkeuzes voor het SAVIERA systeem. Het rapport is als volgt opgebouwd: Hoofdstuk 2 geeft inzicht in de gevolgde aanpak en de informatiebronnen die geraadpleegd zijn. Hoofdstuk 3 geeft een overzicht van de gevonden COTS producten die redelijk goed aansluiten bij de gewenste functionaliteit volgens de Architectuur voor Verkeersbeheersing (AVB) en de Applicatie Componenten Topologie (ACT). Per productcategorie zijn de belangrijkste bevindingen en conclusies weergegeven in relatie tot het doel van de marktverkenning. In hoofdstuk 4 is een beeld geschetst hoe de architectuur van DVM-systemen door de markt is opgezet en welke standaarden toegepast worden. Ook zijn ervaringen in andere branches in dit hoofdstuk opgenomen. Hoofdstuk 5 geeft, aansluitend op de meer gedetailleerde bevindingen en conclusies in de eerdere hoofdstukken, algemene bevindingen, conclusies en aanbevelingen voor het gebruikmaken van COTS producten voor DVM toepassingen. Als laatste zijn de opgedane leerervaringen tijdens de marktverkenning weergegeven in hoofdstuk 6.


14

2 Gevolgde aanpak

In dit hoofdstuk wordt de gevolgde aanpak beschreven en welke informatiebronnen geraadpleegd zijn. In sectie 2.1 wordt uiteengezet welke fasering toegepast is. Gewerkt is van grof naar fijn. Aanvankelijk is door het verzamelen van diverse lijsten van leveranciers een basis aangelegd welke na diverse selecties uitgemond is in een shortlist van potentiële producten. In sectie 2.2 worden de belangrijkste geraadpleegde informatiebronnen beschreven, zowel uit de DVM wereld als ook uit andere sectoren. In dit hoofdstuk wordt geen evaluatie van de gevolgde aanpak beschreven, deze is opgenomen in hoofdstuk 6.

2.1 Fasering Het MATCH project is behoudens de normale projectvoorbereiding en afsluiting, uitgevoerd op basis van de volgende fasering: • Bepaling aandachtsgebieden; • Longlist; • Selectie van producten voor de shortlist; • Shortlist; • Eindrapportage. 2.1.1 Bepaling aandachtsgebieden In de fase 'bepaling aandachtsgebieden' zijn de volgende oriënterende activiteiten uitgevoerd: • Inlezen in geselecteerde AVB, ACT en VANESSA documentatie; • Afstemmen van werkwijze en planning met MEDUSA en onderling tussen MATCH subprojecten; • Ontvangen van briefings over AVB, ACT en VANESSA; • Opstellen van beschrijvingen van context, sensor management, actuator management en applicaton control, zowel in het Nederlands als in het Engels. 2.1.2 Longlist In de 'longlist' fase is de nadruk gelegd op het verzamelen en evalueren van informatie over leveranciers van potentiële producten. Streefdoel was zoveel mogelijk potentiële leveranciers van DVM systemen te ontdekken. In de 'longlist' fase zijn de volgende activiteiten uitgevoerd: • Begonnen is met het opstellen van een lijst van potentiële leveranciers (zie Bijlage 1), op basis van lijsten van andere projecten (waaronder MEDUSA en VANESSA), aangevuld met informatie van Internet en eigen ervaringen van de consultants.


15

•

•

•

•

•

Vervolgens is een longlist questionnaire template (Bijlage D3) opgesteld, die samen met een begeleidend schrijven (Bijlage D1) en een beschrijving van de projectcontext, sensor management, actuator management en application control (Bijlage D2) per e-mail is verstuurd aan de bedrijven op de lijst van potentiële leveranciers. Om ervoor te zorgen, dat de e-mails de benodigde aandacht zouden krijgen en zouden terechtkomen bij de juiste persoon is op de mailing een telefonisch contact gevolgd, waarbij tevens eventuele vragen van de kant van de geadresseerden beantwoord werden. Ingevulde longlist questionnaires die retour ontvangen werden en product informatie die daarbij ingesloten was, is geadministreerd en gearchiveerd. Hier is vervolgens eventuele additionele informatie van websites aan toegevoegd. Informatie omtrent potentiële leveranciers die gereageerd hadden en een enkeling die dat nog niet gedaan had, is ingewonnen door middel van bezoeken op beurzen (PetroTech 2002, InterTraffic 2002, en ITS America 2002); De resultaten van de longlist fase zijn vervolgens aan het (IBI) management gepresenteerd.

Van de circa 315 potentiële leveranciers hebben we binnen twee en een halve maand 76 reacties (24%) ontvangen3. Er waren 47 reacties met ingevulde questionnaire(s) resulterend in een totaal van 140 producten. 2.1.3 Selectie van producten voor de shortlist Na de long list fase zijn volgende algemene criteria gehanteerd voor het selecteren van producten voor de shortlist fase. Streefdoel was om hiermee het aantal producten terug te brengen tot ongeveer 20. Na selectie zijn er 35 producten van 24 leveranciers geselecteerd voor de 'shortlist' fase. Deze producten zijn vervolgens in productcategorieën ingedeeld. Bij de selectie van producten voor de 'shortlist' fase zijn de volgende criteria gehanteerd: • Er is voldoende informatie verkregen van een product, middels een volledig ingevulde bedrijfs- en product questionnaire. • Een product moet commercieel leverbaar zijn, of binnen afzienbare tijd leverbaar worden. • Een product moet functionaliteit uit ACT bieden. Producten met alleen functionaliteit voor bijvoorbeeld BOSS of TIAV worden niet beschouwd. • Een product moet een duidelijke modulaire structuur hebben, of bestaan uit 1 of meer componenten. Op dit moment is nog niet relevant of die modulen ook als losse producten leverbaar zijn. • Producten voor verkeersbeheersing worden allen beschouwd indien ze inzetbaar zijn voor beheersing van het hoofdwegennet. Management op regionaal en stedelijk niveau, alsmede verkeerslichtregeling of parkeersystemen, zijn niet beschouwd. 2.1.4 Shortlist In de shortlist fase is de nadruk gelegd op het verzamelen en evalueren van informatie over geselecteerde producten. In de 'shortlist' fase zijn de volgende activiteiten uitgevoerd:

' Ervaring uit de marketing wereld leert dat 5-10% een goede response is


16

•

•

•

Om de producten voor de shortlist te kunnen selecteren, moesten eerst functionele, niet-functionele, en ACT-gerelateerde eisen (zie paragraaf 3.1 en Bijlage E) opgesteld worden. Hier zijn vervolgens twee shortlist questionnaires van afgeleid (Bijlage D4 en D5); De ontvangen shortlist questionnaires werden gearchiveerd, waarbij eventuele onduidelijkheden werden opgelost, door middel van telefonisch of e-mail overleg met - of bezoek aan/van - potentiële leverancier; De producten in iedere categorie werden geanalyseerd, waarbij gemeenschappelijke en specifieke eigenschappen werden geïdentificeerd, op basis waarvan voor iedere categorie conclusies werden getrokken.

In de shortlistfase zijn twee extra onderzoeksopdrachten opgesteld en uitgevoerd, met als onderwerpen: Corba en XML, alsmede SCADA en PLC respectievelijk door TNO TPD in Delft en ICT Solutions in Deventer. Van de rapportages van beide onderzoeksopdrachten is een samenvatting opgenomen in dit rapport (Zie hoofdstuk 4.2.2 en 4.3). 2.1.5

Eindrapportage

In de 'eindrapportage' fase zijn de volgende activiteiten uitgevoerd: • Het opstellen, door projectteamleden reviewen en verbeteren van het eindrapport in meerdere cycli, waarna het rapport in concept werd uitgebracht. • Het conceptrapport is vervolgens gereviewd door medewerkers van de verschillende diensten van Rijkswaterstaat • Het eindrapport is definitief gemaakt na het verwerken van externe review resultaten.

2.2

Informatiebronnen

2.2.1

Uitgangsdocumenten

De volgende documenten zijn als uitgangspunt gehanteerd: •

De AVB documenten: Applicatie Architectuur [AVB_AA], Informatie Architectuur, [AVBJA] en Technische Infrastructuur voor Verkeersbeheersing [AVB_TIAV].

•

De ACT documenten: System/Subsystem Specification (SSS) ACT [SSS_ACT], System/Subsystem Design Description (SSDD) ACT [SSDD_ACT].

De componentbeschrijvingen uit de SSDD van ACT zijn gebruikt als beschrijving van de te zoeken componenten (producten). Op basis van de ACT is een indeling gemaakt in de volgende onderdelen: • Application Control, bestaande uit: o Presentatielaag, o Sessie-, useren taakbeheer; o Business Logic, de verkeerskundige delen zoals regelscenario's en maatregelen; o Alarmhandling; • Sensor management, de sensoren en het beheer ervan; • Actuator management, de actuatoren en het beheer ervan.


17

Op basis van de componentbeschrijving en de SSS-ACT is per onderdeel een kernpakket van eisen geformuleerd. De AVB en ACT documenten leveren samen echter niet de volledige specificatie, ze zijn echter ook nooit zo bedoeld geweest. Dit heeft wel als consequentie dat een aantal criteria ontbreekt dat van belang is bij een productselectie. Deze criteria hebben voornamelijk betrekking op de interface tussen de Applicatie Architectuur en de technische infrastructuur en de wijze waarop de diverse standaarden toegepast moeten worden. Het zoeken naar componenten als bedoeld in ACT is dan ook niet direct mogelijk gebleken. De longlist marktverkenning is derhalve uitgevoerd op basis van de opgestelde kernpakketten, terwijl voor de shortlist door de projectleiding functionele en niet-functionele eisen zijn opgesteld, zoals beschreven in hoofdstuk 3.1. 2.2.2 Internet Het internet is een belangrijke informatiebron voor een brede marktverkenning zoals is uitgevoerd in het MATCH project. Informatie is op twee manieren gezocht: 1. Initieel is gezocht in de publiekelijk beschikbare informatie naar potentieel interessante bedrijven, producten, projecten, publicaties, standaarden en conferenties. Deze exploratie levert veel nieuwe informatie op ter aanvulling op de referenties uit andere projecten en van projectieden. Dit maakt een meer objectieve markt verkenning mogelijk. 2. Bedrijfs- en productinformatie voor meer nauwkeurige evaluatie is voor een deel op het internet beschikbaar. Beperkte en globale informatie is veelal publiekelijk beschikbaar. Er zijn ook bedrijven die hun customer portals ter beschikking stellen voor het ophalen van elektronische product informatie, van product folders tot en met gebruikershandleidingen. Dit laatste is vooral efficiënt in de communicatie met buitenlandse bedrijven, en bij grote hoeveelheden informatie die zo elektronisch doorzocht en verwerkt kunnen worden. Een tweede belangrijke toepassing is de communicatie via e-mail. Via e-mail zijn de questionnaires elektronisch gedistribueerd, ingezameld, en verwerkt. Het vereenvoudigt ook de persoonlijke communicatie met personen; beschikbaarheid is minder tijdsgebonden, tijdszones vormen geen belemmering, uitspraken kunnen gecombineerd worden met aanvullende productinformatie, en correspondentie en informatie kan geregistreerd worden. Een groot deel van de informatie op het internet en de e-mail communicatie is elektronisch verzameld en toegevoegd aan het project dossier. 2.2.3 Air Traffic Control beurs ATC is de beurs voor Air Traffic Control. De beurs werd gehouden in het MECC te Maastricht in begin februari. De volgende categorie systemen zijn te onderscheiden: 1. Radar installaties; 2. Vluchtplanningssystemen; 3. Verkeersleidingssystemen; 4. Test, training en simulatie systemen.


18

Radar installaties Alhoewel deze radarsystemen niets te maken hebben met DVM-systemen is het toch aardig te vermelden dat de interfaces van radars gestandaardiseerd zijn zodat het eenvoudig is om nieuwe systemen te koppelen met reeds geïnstalleerde radars en zo het ontwikkelen van nieuwe functionaliteit ook eenvoudiger wordt. Vluchtplanningssystemen Met behulp van deze systemen wordt een gehele vlucht ingepland, van vertrekpunt tot aankomst met de te volgen route door de lucht en de benodigde radio frequenties voor onderweg. Verkeersleidingsystemen Verkeersleidingsystemen worden gebruikt voor de begeleiding van een vliegtuig van A naar B. Daarbij worden de frequenties uit het vluchtplan gebruikt voor de contacten met de grond. Het werkveld van een verkeersleider is een sector. De verkeersleider beheert één frequentie. Hij behandelt al het verkeer binnen die frequentie. Verdwijnt een vliegtuig uit zijn sector dan wordt dit overgedragen aan een andere verkeersleider, waarna de piloot een andere frequentie kiest. Het automatisch overschakelen op een andere frequentie is nog in een proefstadium. Test, training en simulatie systemen Detestsystemen zijn referentiesystemen voorde productieomgeving. Nieuwe versies worden pas operationeel na grondige testtrajecten. De training en simulatie systemen richten zich voornamelijk op het werk van de verkeersleider. Dit zijn imposante installaties waarbij je echt het gevoel hebt dat je in een toren zit. Relatie met DVM-systemen. Er zijn bedrijven die zowel werkzaam zijn in het wegverkeer als in het luchtverkeer, echter binnen deze bedrijven kennen de divisies elkaar niet of nauwelijks. In de luchtvaart voeren niet zozeer de technische standaarden de boventoon maar wel de procedurele zaken als de gesprekken tussen de luchtverkeersleiding en de gezagvoerders. De werkwijze is dan ook niet te vergelijken met de wegverkeersleider in de RVMC's. Sensor en actuator management komen voor in de grondsystemen voor de routering van vliegtuigen op vliegvelden, de geografische schaal is echter beperkt en door fysieke afscherming minder storingsgevoelig dan onze DVM systemen. De trend is om sensoren en actuatoren uit te rusten met SNMP processoren om het beheer te vereenvoudigen. Op het gebied van Air Traffic Control zijn er geen producten die toepasbaar zijn voor DVM-systemen. Wat wel geleerd kan worden is dat het standaardiseren op interfaces de markt open maakt. Leveranciers zien het als een uitdaging om producten te ontwikkelen welke aansluiten op deze interfaces. 2.2.4 Petrotech 2002 Van 9 t / m 11 april 2002 heeft in Ahoy' Rotterdam de tweejaarlijkse vakbeurs PetroTech 2002 plaatsgevonden. Circa 125 exposanten vertegenwoordigden het aanbod van technologie en diensten voor petrochemie en raffinage en de beurs trok in drie dagen tijd 3.372 vakbezoekers. Deze vakbeurs wordt in Ahoy' Rotterdam gehouden voor de uit 6 landen afkomstige industriële keten in de Rijn-Schelde-delta. Het is de enige beurs in de Benelux voor de (petro)chemie.


19

De beurs omvatte de segmenten: EPC-contracting, Mechanical Construction en Electrical Installation, Maintenance, Health, Safety & Environment, Fluid Handling, Process Control & Equipment en Utilities. PetroTech is een typische relatiebeurs; een relatiemarketing evenement met een belangrijk kennisplatform, een ontmoetingsplaats voor de olie- en (petro)chemische industrie en haar toeleveranciers en heeft vooral als doel een bijdrage te leveren aan goede contacten tussen de industrie en contractors. Process Control bleek slechts een gering onderdeel uit te maken van de beurs. Doordat de techniek, waarin wij als MATCH team in eerste instantie geïnteresseerd waren, ondergeschikt was aan relatiemanagement, hebben we slechts enkele nuttige gesprekken kunnen voeren. Doordat de reisafstand naar de voor ons gunstige gelegen locatie in Ahoy beperkt was, hebben we er echter een zeer renderend bezoek van kunnen maken. De volgende bedrijven zijn op de Petrotech beurs bezocht: • ABB • Imtech Marine & Offshore

•

Bentley

•

MathWorks

•

Croon

•

Yacht

2.2.5 Intertraffic 2002 Van 15 tot en met 18 april heeft in Amsterdam de tweejaarlijkse Intertraffic beurs plaatsgevonden, de grootste internationale beurs op zijn gebied. Er worden ook Intertraffic activiteiten georganiseerd in Azië, Eurazië en Latijns Amerika, waaronder Brazilië en Mexico. Intertraffic is een vakbeurs op het gebied van producten en diensten, waaronder ontwerp, management en onderhoud van de verkeers- en vervoersinfrastructuur, waar leveranciers van deze producten en diensten bestaande en nieuwe klanten kunnen ontmoeten. Intertraffic 2002 werd bezocht door 23.741 bezoekers uit 100 landen en er waren 640 exposanten. 35% van de bezoekers was afkomstig uit de overheids sector en 55% uit het bedrijfsleven. Een derde van de bezoekers kwam in verband met de aanschaf van producten. Onderwerpen waar veel belangstelling voor was, waren parkeren, wegmarkering, verkeersveiligheid en verkeersdetectie. Mede doordat er een groot aantal leveranciers van (intelligente) verkeersmanagementsystemen en apparatuur op de beurs aanwezig was, resulteerde het voor de zeven leden van het MATCH team in een zeer vruchtbaar bezoek, niet alleen in het kader van het MATCH project, maar ook op andere aandachtsgebieden. De volgende bedrijven zijn op de Intertraffic beurs bezocht, waarbij informatie is ingewonnen in het kader van het MATCH project. • • • • • • •


ACISO, Barcelona, Spanje ADDCO, St. Paul, USA ASIM, Uznach, Zwitserland AVE, Aken, Duitsland Barco, Kuune, België Brimos, Hattem Capsys, Crolles, Frankrijk

20

• • • • • • •

Ko Hartog, Heiloo Neuricam, Trento, Italië PAT-Kruger, Den Bosch Peek Traffic, Amersfoort Sainco, Madrid, Spanje Sice, Madrid, Spanje SES, Tours, Frankrijk

• • • • • • • • •

Dambach, Gaggenau, Duitsland Data Display, H.I.Ambacht ECM, Vandoeuvre les Nancy, Fr. Etra, Valencia, Spanje Eurotech, Amaro, Italië Gardner-Siemens, USA Gesig, Wenen, Oostenrijk Gevas, Munchen, Duitsland Iteris, Anaheim, USA

• • • • • • • • •

Siemens, Den Haag Sofrel, Vern sur Seiche, Frankrijk Stork, Son Swarco, Wattens, Oostenrijk TDI, Raamsdonkveer TPA, Arnhem Vialis, Zeist Weiss, Trier, Duitsland Zelisko, Mödling, Oostenrijk

2.2.6 ITS America "ITS America 12th Annual Meeting and Exposition" of kortweg "ITSA 2002" vond plaats van 29 april t/m 2 mei 2002 in Long Beach, California, USA. Het bezoek van de beurs diende meerdere doelen in MATCH: • Het direct persoonlijk benaderen van ca. 15 bedrijven/leveranciers. • Het verkennen van de National ITS Architecture en NTCIP concept (o.a. consult Iteris en "standards session"). • Het opbouwen van marktcontacten en vastleggen van marktgegevens. • Het verkennen van trends in systeemontwikkeling en marktwerking. Voorafgaand aan het bezoek was een aantal leveranciers geselecteerd, die mogelijk een voor MATCH interessant product hadden. De producten waren op basis van de reeds aanwezige documentatie bestudeerd en met de bedrijven waren vervolgens bezoekafspraken gemaakt. Ook was een diapresentatie gemaakt om onze missie en zoekvraag uit te leggen aan de standhouders. Ondanks een grondige scan vooraf bleken leveranciers/producten ons zowel in positieve als negatieve zin te verrassen. De Amerikaanse ITS wereld en markt verschilt aanzienlijk van de onze. De industrie herkent bijvoorbeeld AVB/ACT niet. Omdat ITS in Noord-Amerika een low budget gebeuren is wil een aantal firma's wel graag expanderen. Producten zijn toegesneden op stedelijk verkeersmanagement, NTCIP, centraal dan wel lokaal systeem, et cetera. Een aantal leveranciers is bezig met webbased workstations en communicatie; de trend is standaard tools en technologie. Ook bij dit bezoek bleek weer dat technologie doorgaans minder het probleem is, eerder de organisatie. NTCIP is DE standaard waarop aangesloten wordt die bovendien steeds meer omvattend wordt, sensoren en mogelijk ook het Amerikaanse UWKS equivalent worden binnen enkele jaren ondersteund. CORBA wordt wel gebruikt binnen en tussen verkeerscentrales. XML is een emerging standaard. Overheid en bedrijven ontwikkelen samen standaarden, dit stimuleert ook weer de productontwikkeling. Architecturen die standaarden voor data uitwisseling of protocollen vastleggen zijn meer succesvol. AVB-AA en AVB-TIAV moeten nog uitgewerkt worden tot dit niveau en wordt idealiter ondergebracht in de Europese architectuur KAREN, die overigens weinig verschilt van de National Architecture. Zonder deze standaarden blijkt de markt moeilijk te bevragen te zijn. Filestaartbeveiliging, mistwaarschuwing en dergelijke lijken redelijk eenvoudige regelingen, mits lokaal uitgevoerd met gekoppelde UWKS-en. Het kan een goede oplossing zijn om het UWKS als PLC uit te voeren (advies Transdyn).


21

De volgende bedrijven zijn bezocht, waarbij informatie is ingewonnen in het kader van het MATCH project: • • • • • • • • •

Activu Barco Daktronics International Road Dynamics Iteris Fortran Gardner Open Roads Consulting PD Programming

• • • • • • • •

Peek Traffic RTMS by EIS Scientix Skyline Telcontar Tornar Transcore Transdyn

2.2.7 Bezochte eindgebruikers In het kader van het MATCH project zijn contacten gelegd met een aantal eindgebruikers en organisaties uit andere branches met als doel het zoeken naar oplossingen die wellicht interessant zijn voor toepassingen binnen DVMsystemen. Aanleiding hiervoor zijn twee veronderstellingen: 1. Verkeer is een specifiek werkgebied en vereist dus specifieke oplossingen. 2. In andere branches zijn vergelijkbare werkprocessen en oplossingen te vinden. In dit kader is contact gelegd met Shell, Rail Infra Beheer, Nuon en de Gasunie. In hoofdstuk vier wordt nader ingegaan op de resultaten van deze contacten. 2.2.8 Leveranciers bezoeken In het kader van het project MATCH zijn de volgende bezoeken geweest aan of door potentiële leveranciers. Aan de volgende bedrijven zijn bezoeken gebracht in het kader van het MATCH project: • ABB, Rotterdam, 10 juni 2002 • Brimos, Hattem, 12 april 2002 • Electron Automatisering, 28 mei 2002 • Imtech Marine & Offshore, Rotterdam, 22 mei 2002 • Peek Traffic, Amersfoort, 7 maart 2002 • Trinite, Mijdrecht, 17 juni 2002 • Vialis, Zeist, 29 mei 2002 Door een of meer vertegenwoordigers van een bedrijf is een bezoek aan AVV gebracht in het kader van het MATCH project: • DHV/Delcan, Amerfoort/Toronto, 11 juni 2002 • Schneider-Electric, Haarlem, 31 mei 2002 • Trimation, Chaam, 6 juni 2002 Verder hebben een of meer MATCH teamleden seminars bijgewoond, georganiseerd door potentiële leveranciers: • ILOG en Logica, Amsterdam, 28 maart 2002 • Ferranti, Antwerpen, 24 mei, bezoek in Zeist


22

2.2.9 Bezochte projecten In het kader van het project MATCH is overleg geweest met een aantal projecten of is gebruik gemaakt van reeds afgeronde projecten welke interessant waren voor de marktverkenning. MEDUSA Het project MEDUSA is opgestart om op structurele wijze de ITS markt in kaart te brengen door leveranciersgegevens te verzamelen. In het begin van het MATCH project is gestuurd op een gezamenlijke aanpak, dit is echter in de praktijk niet mogelijk gebleken door gebrek aan middelen aan de kant van MEDUSA en het verschil in focus van de projecten. MEDUSA richtte zich immers op bedrijven, MATCH op producten. Wel zijn de in MEDUSA verzamelde leveranciersgegevens gebruikt om de markt te bevragen. VANESSA (DNH) Het project VANESSA is bedoeld geweest als tussenstap naar AVB-conforme systemen. In de praktijk realiseert het project een meer lange termijn oplossing. Het MATCH-project heeft als opdracht meegekregen om de onderdelen van VANESSA als producten te beschouwen. Daarnaast zijn de gegevens van leveranciers die bij VANESSA informatie hebben opgevraagd in de diverse Europese aanbestedingen, gebruikt om de markt te bevragen. Er is zowel overleg geweest met het projectmanagement van VANESSA als met de diverse (deel)projectleiders. In dit rapport zal in hoofdstuk 3 nader worden ingegaan op de onderdelen van VANESSA. PARADIGMA (AVV) In PARADIGMA wordt het M T M systeem als legacy systeem ontsloten door deze te voorzien van een userinterface gebaseerd op Java technologie en gebruik te maken van universele wegkantsystemen. Het contact met PARADIGMA is voornamelijk gericht op de productontwikkeling door bedrijven en gecombineerde toepassing van COTS-producten en legacy systemen. VICNET+ (MD) Het project VICNET+ realiseert TIAV. Aan het project VICNET+ is gevraagd welke eisen er worden gesteld aan het koppelvlak met sensoren, actuatoren, UBP, UWKS, USP, etc. Gebleken is dat het onderdeel componentbeheer een onderdeel is van het VICNET+ project en daarom is binnen het MATCH project besloten dit onderdeel niet verder te beschouwen. Bouwdienst Een aantal van de aangeboden producten is gebaseerd op PLC en/of SCADA systemen. Daarom is contact gezocht met de Bouwdienst. Bij het projectteam was bekend dat zij de productontwikkeling van PLC en DCS systemen volgen. Derhalve is kennis genomen van hun projecten en hun activiteiten.


23

3 Markt, matching en ACT

In het MATCH project is een brede marktverkenning uitgevoerd van potentieel relevante producten voor AVB en ACT. In dit hoofdstuk wordt een overzicht gegeven van de wijze waarop en de mate waarin producten aansluiten bij de eisen en wensen uit AVB-AA en ACT. De producten worden hierbij enerzijds getoetst aan de functionele en niet-functionele eisen uit AVB-AA, anderzijds wordt de functionaliteit van de producten afgebeeld op de ACT componenten. In dit hoofdstuk worden alleen de relevante producten uit de tweede of shortlist fase behandeld. In paragraaf 3.1 zijn zowel de functionele en niet-functionele eisen uit AVB-AA, als ook een gegeneraliseerde beschrijving van ACT componenten, die dient als 'landschapskaart' voor de functionele decompositie, opgenomen De grote verscheidenheid aan producten maakt evaluatie moeilijk en onoverzichtelijk. Om die reden zijn de producten in verschillende categorieën opgedeeld, en per categorie geëvalueerd. In paragraaf 3.2 is het denkmodel beschreven volgens welke de producten zijn gecategoriseerd. In de daaropvolgende paragrafen 3.3 tot en met 3.8 worden producten per categorie geëvalueerd, op basis van de functionele en niet-functionele eisen uit AVB-AA en de functionele overeenkomst met de ACT landkaart uit paragraaf 3.1. Hierbij is niet gekeken naar de potentiële eigenschappen, maar alleen naar de feitelijke eigenschappen. Paragraaf 3.9 bevat een evaluatie van VANESSA Paragraaf 3.10 bevat de bevindingen en conclusies van hoofdstuk 3. Dit hoofdstuk rapporteert alleen op kwalitatieve wijze over de overeenkomst van de producten met AVB-AA en ACT ten opzichte van de drie genoemde criteria. Hierbij worden geen conclusies of beoordelingen gegeven ten aanzien van de producten zelf, noch over hun geschiktheid voor verkeersbeheersing. De algemene bevindingen, conclusies en aanbevelingen ten aanzien van de onderzoeksopdracht zijn opgenomen in hoofdstuk 5. De questionnaires op basis waarvan de evaluatie heeft plaatsgevonden zijn opgenomen in bijlage D, evenals de volledige lijsten van leveranciers in bijlage B en producten uit de longlist en shortlist fasen in bijlage C.

3.1 Criteria voor productevaluatie Deze sectie geeft een overzicht van de gehanteerde criteria voor het evalueren van producten in de shortlist fase van het project. De functionele en niet-functionele eisen, welke zijn gehanteerd voor productevaluatie in de shortlist fase, zijn bij het ontbreken van bruikbare eisen


24

in de AVB-AA en ACT documentatie, opgesteld door de MATCH project management. De eisen zijn kort beschreven in de volgende subparagrafen en volledig opgenomen in bijlage "Functionele en niet-functionele eisen" ( bijlage E). De nummers en titels van de eisen worden gerefereerd in de tabellen voor productevaluaties later in dit hoofdstuk. De mate waarin de producten voldoen aan de eisen is in de tabellen van hoofdstuk 3 gekwalificeerd als: V = volledig compliant; het product voldoet volledig aan de eis. G = Gedeeltelijk compliant; het product voldoet gedeeltelijk aan de eis, en de mate wordt nader toegelicht. N = Niet compliant; het product voldoet in grote mate of geheel niet aan de eis '-' = eis is niet van toepassing voor dit product. De waardering mag beslist niet worden opgevat als een waardering van de functionele kwaliteit. Zeer fraaie functionaliteit hoeft niet compliant te zijn met de eisen, en functionaliteit die compliant is met de eisen hoeft bijvoorbeeld niet gebruikersvriendelijk te zijn. De questionnaires die zijn gecommuniceerd met de productleveranciers zijn gebaseerd op deze criteria. De questionnaires zijn opgenomen in de bijlage D "Questionnaires". 3.1.1 Functionele eisen Een volledige beschrijving van de eisen is opgenomen als questionnaire in bijlage D4 "Product Compliancy Questionnaire". De volgende functionele eisen zijn gesteld: 1. Verkeersmanagement Het product moet verkeersmanagement mogelijk maken voor de wegverkeersleider. Deze moet volledig inzicht krijgen in de verkeerstoestand en het verkeer kunnen beïnvloeden. Daarnaast moet volledig inzicht worden gegeven in de verkeerskundige en bedrijfstoestand van het DVM systeem, inclusief sensoren, actuatoren, en regelingen (regelscenario's en maatregelen). De wegverkeersleider moet ook geïnformeerd worden over alle relevante afwijkende toestanden. 2. Verkeerskundig configuratiebeheer Het product moet verkeerskundig configuratiebeheer mogelijk maken voor de configuratiebeheerder. Daarvoor moeten alle aangesloten systeemcomponenten, waaronder sensoren, actuatoren en regelingen, geconfigureerd kunnen worden, en beschikbaar gesteld aan de wegverkeersleiders. 3. Technisch systeembeheer Het product moet technisch systeembeheer en onderhoud mogelijk maken voor systeembeheerders. Doorvoor moet volledig inzicht worden gegeven in de technische toestand van het systeem, moeten componenten in- en uitgeschakeld, ingesteld en geconfigureerd kunnen worden. Daarnaast moet het aantal bedrijfsuren van sensoren en actuatoren gegeven worden, en moeten relevante afwijkende technische toestanden, zoals storingen, gemeld worden. 4. Operator taakscheid ing Functietaken moeten gescheiden en toegewezen kunnen worden aan operators.

5. Operator taakoverdracht


25

De taken uit 4 moeten ook overgedragen kunnen worden aan operators op verschillende locaties. 6. Functie taakscheiding De functietaken beschreven in eisen 1 tot en met 3 moeten strikt gescheiden worden. 7. Datalogging Gebeurtenissen (events) en data moeten op event en tijdbases gelogd worden. 8. Beschikbaarheids informatie De beschikbaarheidsduur en -percentages van aangesloten sensoren en actuatoren moeten bepaald worden. 3.1.2 Niet-functionele eisen - Product integratie De niet-functionele eisen zijn verder onderverdeeld in eisen aan de integratie, performance, ondersteuning, en interfaces van het product en eisen aan regelingen. Een volledige beschrijving van de eisen is opgenomen in bijlage D4 "Product Compliancy Questionnaire". Product integratie eisen: 1. Vervangen gebruikersinterface 2. Integratie regelingen

3. Integratie databases 4. Integratie producten Van producten wordt geëist dat modulen vervangen kunnen worden door andere producten, of geïntegreerd kunnen worden met andere producten. Specifiek wordt deze eis gesteld aan modulen voor de gebruikersinterface, verkeersregelingen (regelscenario's en maatregelen), en databases. De integreerbaarheid moet onafhankelijk zijn het gebruikte platform, operating system, software taal en ontwikkelomgeving. Product performance eisen: 1. Modulaire opbouw 2. Uitbreiding functionaliteit 3. Leverancier onafhankelijkheid 4. Schaalgrootte 5. Schaaluitbreiding 6. Verwerkingscapaciteit 7. Verwerkingscapaciteit uitbreiding Van producten wordt geëist dat ze modulair zijn opgebouwd, dat modulen toegevoegd, omgeruild, of verwijderd kunnen worden, en dat de functionaliteit gewijzigd of uitgebreid moet kunnen worden. Functionele aanpassingen moeten een minimale impact op het verkeersmanagementsysteem hebben, en moeten kunnen worden uitgevoerd door andere leveranciers. Het product moet kunnen worden ingezet voor DVM in Nederland, met een gewenste schaal en verwerkingscapaciteit: o Nationale schaalgrootte: 5000 wegkantstations, 20.000 actuatoren en 40.000 sensoren. o Verwerkingscapaciteit in een verkeersmanagement centrale: 100.000 tot 200.000 gegevensitems per 4 sec. Bovendien moeten deze schaal en verwerkingscapaciteit aanzienlijk uitgebreid kunnen worden:


26

o o

Schaalgrootte met een factor 10. Verwerkingscapaciteit met een factor 3.

Product ondersteuningseisen: 1. COTS 2. Grote Installed base 3. Ruime Installed base 4. Product ondersteuning 5. Product service 6. Product lifecycle 7. Onderhoud op afstand Het product is commercieel verkrijgbaar als "Commercial Off The Shelf", en met een grote of ruime installed base. Een installed base is ruim als er 10 of meer installaties zijn, en groot als er meer dan 100 installaties zijn. Het product moet commercieel ondersteund worden door middel van een verkoopafdeling vanuit Europa, en het moet technisch ondersteund kunnen worden door middel van eerstelijns onderhoud vanuit Nederland. Het product moet nog tenminste 10 jaar ondersteund worden. Behoudens mechanische ingrepen, moet het product op afstand kunnen worden onderhouden, onder meer door middel van het instellen van parameters. Product interface eisen: 1. Uitbreiding Interface 2. Pluriforme Interface 3. Meerdere protocollen 4. Redundante I/O 5. Sensor interface voor andere producten 6. Sensor interface door andere producten 7. Actuator interface voor andere producten 8. Actuator interface door andere producten 9. VicNet Communicatie 10. Locale bediening 11. ITS standaarden Eisen 1 tot en met 8 hebben betrekking op producten met een interface naar sensoren of actuatoren. Deze interfaces dienen in aantal flexibel uitbreidbaar te zijn en meerdere typen hardware I/O en meerdere algemeen bekende standaard protocollen te kunnen ondersteunen. De informatie moet redundant ingewonnen en verwerkt kunnen worden. Het product moet als interface tussen sensoren of actuatoren en andere verkeerssystemen kunnen worden gebruikt. Met andere woorden: • Sensor informatie dient ook naar andere systemen uitgevoerd te kunnen worden, of vanuit andere data acquisitie systemen ingelezen te kunnen worden. • Aangesloten actuatoren moeten ook door andere systemen via dit product bediend kunnen worden, en er moeten bedieningscommando's naar andere systemen uitgevoerd kunnen worden. Decentraal geplaatste producten moeten kunnen communiceren via VicNet (TCP/IP), en lokaal bediend kunnen worden via een locale user interface en bedieningsfuncties. Het product moet het gebruik van internationale ITS standaarden ondersteunen, zoals bijvoorbeeld: NTCIP, OCIT, UTMC, en XML (traffic).


27

Product regelingen Verkeersregeling wordt gerealiseerd door middel van regelscenario's en maatregelen. Indien het product verkeerskundige maatregelen kan realiseren, dan moet het voldoen aan volgende eisen: 1. Blokkeren van maatregelen 2. Parameteriseren van maatregelen 3. Scheiding beslissing en uitvoering 4. Locale regelingen

5. Real-time I/O 6. Real-time regelingen Maatregelen moeten van buiten het product bereikbaar zijn. Zo moet een maatregel van buiten het product aan- of uitgezet kunnen worden, en moeten de parameters opgevraagd en gewijzigd kunnen worden. Het beslissingsproces dat leidt tot het inzetten van de maatregel en de uitvoering van de maatregel dienen van elkaar gescheiden te zijn. Vitale verkeerskundige maatregelen moeten decentraal kunnen worden uitgevoerd, waarbij de verbindingen met overige systeemdelen kunnen uitvallen, zonder dat de uitvoering van de verkeerskundige maatregel hierdoor verhinderd wordt. De inwinning en verwerking van verkeerskundige gegevens, de uitvoering van verkeerskundige regelingen, en het aansturen van verkeerskundige signaleringen, moeten in een real-time omgeving worden uitgevoerd, waarin meerdere verkeerskundige applicaties naast elkaar kunnen draaien. 3.1.3 ACT functionele landkaart Marktproducten zijn te vergelijken met de ACT op het niveau van de functionaliteit van de ACT componenten. Van de meeste producten zijn wel de belangrijkste modulen en hun functionaliteit bekend. Verdere decompositie in componenten binnen deze modulen is niet mogelijk, omdat de functionaliteit en de connecties of interfaces van die componenten meestal niet bekend zijn. Om producten met ACT te kunnen vergelijken is de functionaliteit van de ACT componenten geaggregeerd tot een niveau waarop vergelijking met de verzamelde productinformatie mogelijk is. De functionaliteit is ingedeeld voor actuator management, sensor management en application control. Deze sectie beschrijft deze geaggregeerde functionaliteit in hoofdlijnen. Een meer gedetailleerde beschrijving is gegeven in bijlage D5 "ACT Compliancy Questionnaire". Middels deze questionnaire is deze functionaliteit verzameld. Actuator management functionaliteit Voor de bediening en beheer van fysieke actuatoren, zoals signaalgevers, heeft het product de volgende functionaliteit: 1. Actuator control Het product heeft bedieningsobjecten; dit zijn software objecten of componenten voor de bediening van fysieke actuatoren. Bedieningsobjecten hebben basale logica voor prioritering van bedieningsopdrachten vanuit meerdere maatregelen, op basis van een lijst van openstaande verzoeken voor actuatie van DVM toestanden. 2. Actuator groepering Bedieningsobjecten voor logische groepen van actuatoren. 3. Actuator configuratie


28

Configuratie van actuatoren en hun interfaces omvat de definitie van tekst en beelden en hun positie op de actuatoren, en instelling van parameters voor communicatie en hardware. 4. Actuator object beheer Instantiatie, configuratie en beheer van bedieningsobjecten, en de opslag van deze objecten in databases. 5. Actuator toestandsinformatie Het product kan op centraal niveau informatie beschikbaar stellen over de verkeerskundige, bedrijfs-, of configuratietoestand van één of meer actuatoren en/of bedieningsobjecten. 6. Actuator historische informatie Het product kan historische overzichten genereren van getoonde teksten en beelden op actuatoren. Sensor management functionaliteit Voor het inwinnen en beschikbaar maken van verkeerskundige informatie uit sensoren bevat het product de volgende functionaliteit: 1 . Sensor data acquisitie Het product heeft inwinningsobjecten; dit zijn software objecten of componenten voor het inwinnen van data via fysieke sensoren. Het product maakt verkeerskundige basisgrootheden die zijn ingewonnen via een fysieke sensor beschikbaar. 2. Sensor groepering Het product heeft informatieobjecten; dit zijn software objecten of componenten voor het aggregeren van informatie afkomstig van fysieke sensoren en logische groepen van sensoren. Informatieobjecten bevatten algoritmen voor de aggregatie van informatie. 3. Sensor configuratie Configuratie van sensoren en hun interfaces omvat de instelling van parameters voor communicatie en hardware. 4. Sensor object beheer Instantiatie, configuratie en beheer van inwinnings- en informatieobjecten, en de opslag van deze objecten in databases. 5. Sensor toestandsinformatie Het product kan op centraal niveau informatie beschikbaar stellen over de verkeerskundige, bedrijfs-, of configuratietoestand van één of meer sensoren, inwinnings- en/of informatieobjecten. Applicatie besturing: Presentatie laag functionaliteit Voor de presentatie van informatie aan gebruikers, bevat het product een presentatie laag met de volgende functionaliteit". 1 . Visuele representaties Het product biedt een grafische gebruikersinterface voor het DVM systeem. Het presenteert geografische gebieden van het wegennet en beheerbare objecten, zoals bruggen en tunnels. Het systeem presenteert ook onderdelen van het DVM systeem, zoals sensoren, actuatoren, wegkantstations, verkeerscentrales, communicatie netwerken, software componenten, en subsystemen. Het presenteert ook verkeerscentrales met hun ruimtes, werkplekken, taken, apparatuur en netwerken. Deze informatie wordt gepresenteerd in geografische, schematische, iconische, lijst en tekstuele vorm. 2. Geografische en/of schematische presentaties met 4000 objecten in 4 sec. Kaarten moeten worden weergegeven met ca. 4000 objecten die per 4 seconden van nieuwe data voorzien worden.


29

3. GDF formaat Geografische gegevens kunnen in GDF-formaat worden geïmporteerd. 4. Video Video informatie kan worden getoond, bediend en verwijderd.

5. Audio Geluidssignalen ("audio") kunnen worden gegenereerd, bediend en onderdrukt. Applicatie besturing: Business Logic laag functionaliteit In de business logic laag bevat het product verschillende typen software objecten of componenten zoals hieronder worden vermeld. Voor deze objecten biedt het product de functionaliteit voor instantiatie, configuratie en beheer van de objecten, instelling van parameters voor communicatie met de objecten, opslag van objectgegevens in databases, en opvragen van toestandsinformatie over bundels van objecten in de vorm van een abonnement. 1. Verkeersbeheersing (VB) object beheer Het product heeft verkeersbeheersingsobjecten; dit zijn software objecten of componenten voor de verkeersregelingen (regelscenario's en maatregelen). 2. Verkeersbeheersing (VB) object gebruik Verkeersbeheersingsobjecten kunnen worden aan- en uitgezet. Ze worden gebruikt voor identificatie van specifieke verkeerskundige omstandigheden op basis van ingewonnen sensor en verkeersinformatie, inzetten en coördineren van maatregelen, en het activeren van signalen voor verkeersbeïnvloeding. 3. Session, User, en Taak (SUT) beheer Het product heeft sessie-, gebruiker- (user), en taakobjecten. Deze objecten worden gebruikt voor autorisatie van gebruikers voor taken, en het beheren en overdragen van taken. 4. Storingsmelding beheer Het product instantieert en beheert storings- en alarmmeldingen, slaat deze informatie op in databases, en maakt deze informatie beschikbaar voor gebruik, eventueel door bundeling van abonnementen.

3.2

Categorieën van producten

Om de shortlist producten met elkaar te vergelijken hebben we het nuttig gevonden om ze te verdelen over een aantal categorieën. Na verschillende pogingen hebben we categorieën geïdentificeerd om op basis van een functioneel lagenmodel uit de proces controle literatuur. Deze aanpak heeft de volgende voordelen: • Het is gebaseerd op een beproefd lagenmodel; • Het versoepelt de vergelijking tussen producten; en • Het geeft een idee over hoe een DVM systeem zou kunnen worden geïmplementeerd, gebruikmakend van COTS producten uit de proces controle wereld. Het lagenmodel wordt als eerste beschreven. Daarna wordt de scope van de Applicatie Architectuur geïdentificeerd, en wordt de relatie met ACT componenten uitgelegd. Vervolgens kan een set categorieën uit het lagenmodel gedestilleerd worden.


30

3.2.1

Lagenmodel: van fysieke apparatuur naar business niveau

Het lagenmodel is een combinatie van het MESA model [MESA2] [MESA6] (SCADA laag naar boven) met het SCADA/PLC functionele model (SCADA laag naar beneden). De lagen zijn geordend op basis van geografisch gebied en tijdschaal, van groot / lang (boven) tot klein / kort (beneden). Het lagenmodel is afgebeeld in Figuur 2. De reden om het lagen model zo op te zetten is dat veel gevonden producten uit de proces controle wereld en/of uit de industriële automatisering afkomstig zijn.

Strategisch

fc)

ERP Managers

Tactisch

MES

±

Operationeel

ca CO

co o

SCADA

"o.

3:

< o. o

PLC / DCS / controller

o

00

£:

Fysieke sensoren / actuatoren Verkeersproces Figuur 2. Het lagenmodel. Verkeersproces laag Helemaal aan de onderkant van het lagenmodel ligt het verkeersproces. Entiteiten in het verkeersproces zijn weggebruikers, voertuigen, files, en dergelijke. Een DVM systeem heeft als doel het verkeersproces te beïnvloeden, maar het verkeersproces zelf is geen onderdeel van het DVM systeem. Fysieke devices laag

Het verkeersproces wordt bewaakt en beïnvloed door field devices, zoals de fysieke sensoren en actuatoren langs de wegen. Voorbeelden zijn lussen, TV camera's, slagbomen, toeritdosering installaties, matrix borden, en DRIP's. De fysieke sensoren en actuatoren maken wel onderdeel uit van het DVM systeem. PLC laag

De fysieke sensoren en actuatoren worden aangestuurd door middel van Programmable Logic Controllers (PLCs), Distributed Control Systems (DCSs), ofwel controllers. In de DVM wereld worden PLCs, DCSs, en controllers vaak road-side controllers genoemd, en zijn dicht bij de fysieke sensoren en actuatoren in zogenaamde onderstations geïnstalleerd.


31

REMOTE SITES

CENTRAL SITE

Control Program

Remote Terminal Unit

Figuur 3.

Symbolische weergave van een SCADA systeem.

SCADA laag PLCs, DCSs, en controllers worden zelf aangestuurd door middel van software toepassingen in de categorie van Supervisory Control And Data Acquisition (SCADA) systemen. Figuur 3 bevat een symbolische weergave van een SCADA systeem. In de SCADA wereld wordt Remote Terminal Units (RTUs) vaak gebruikt als verzamelnaam voor PLCs, DCSs, en controllers. De twee centrale onderdelen van een SCADA systeem zijn: • De System Controller, d.w.z. de front-end processor die zorgt voor de datastromen tussen de RTUs en het Control Program; • Het Control Program, d.w.z. de real-time database kern met minimaal de volgende omliggende functies: o Status monitoring; o Alarmering; o Rapportage; o Grafische presentatie van data aan de gebruiker (vaak Human-Machine Interface (HMI) genoemd). In de DVM wereld worden deze centrale onderdelen vaak aangeduid als het data management systeem. MES laag Boven het SCADA niveau is er een laag, die in de Industriële Automatisering het "Manufacturing Execution Systems" (MES) wordt genoemd. Een MES is een algemeen toepasbaar software systeem in Industriële Automatisering waarmee het productie proces wordt geoptimaliseerd. Het begeleidt, initieert, reageert op, en rapporteert activiteiten in real-time. In DVM termen komt een MES overeen met een proces management systeem. Omdat het begrip MES tamelijk onbekend is in de DVM wereld, verdient het meer gedetailleerde uitleg. De standaardverzameling van functies in een MES is volgens de 'MES Association' [MESA6]: • Product Tracking & Genealogy; • Operations / Detailed Scheduling;


32

• • • • • • • • •

Resource Allocation & Status; Dispatching Production Units; Process Management; Performance Analysis; Maintenance Management; Labour Management; Document Control; Quality Management; Data Collection & Acquisition.

Een aantal van deze functies is specifiek voor het domein van de Industriële Automatisering. Data Collection & Acquisition is te vinden in de SCADA laag. Maintenance Management, Document Control, en Quality Management zijn beheer functies. Wat overblijft van de MESA-standaard functies is: • Operations / Detailed Scheduling, dat operaties in een sequentie plaatst, gebaseerd op prioriteiten of andere kenmerken. • Resource Allocation & Status, dat de resources bewaakt en bestuurt, die nodig zijn voor het uitvoeren van (sequenties van) operaties. In DVM verband kunnen sensoren en actuatoren gezien worden als resources. • Dispatching Production Units, dat de sequenties van operaties uitvoert, die door Operations / Detailed Scheduling zijn gemaakt. • Process Management, dat het uitvoeringsproces bewaakt, alarmen initieert, en eventueel storingen in het proces corrigeert. • Performance Analysis, dat rapportages in real-time voor hoger management (bijvoorbeeld op ERP niveau) genereert. Vertaald naar het DVM proces, betekent dit, dat functionaliteit nodig is die in DVM operaties in sequenties plaatst, de juiste sequenties initieert op basis van de DVM toestand op de snelweg, deze sequenties uitvoert, en het uitvoeringsproces bewaakt. In de DVM wereld, zijn operaties maatregelen. De logica die de maatregelen afhankelijk van de toestand op de snelweg initieert zijn regelscenario's. Regelscenario's en maatregelen zullen we in dit rapport verder gezamenlijk Business Logic (BL) noemen. Business Logic (BL) brengt binnenkomende informatie, zoals verkeersgegevens, in verbinding met uitgaande informatie, zoals commando's richting actuatoren. De essentie van de intelligentie - de kennis en ervaring over hoe het beste een proces in bepaalde situaties beïnvloed kan worden - ligt in de BL. Betere sensoren resulteren wel in een beter inzicht in het proces, en nieuwe actuatoren maken nieuwe maatregelen mogelijk. Maar verbeteringen in de BL maken het mogelijk om in te spelen op veranderde situaties, ook met bestaande sensoren en actuatoren4. Bij het ontwikkelen van ICT systemen kan BL op verschillende manieren gerepresenteerd worden. Vaak voorkomende representaties zijn: programmeeren scripttalen, (expert systeem) regels, semantisch netwerken, beslisbomen, beslissings- en opzoektabellen, Finite State Machines, neurale netwerken, e.d. Elke representatie heeft zijn eigen voor- en nadelen, en is daardoor min of meer geschikt voor DVM toepassingen. Een belangrijk aspect hierbij is, hoe geschikt een bepaalde representatie voor real-time processen is. Dit gaat niet alleen over hoe snel geredeneerd kan worden met een bepaalde representatie, maar ook welke garantie de representatie geeft, dat binnen een bepaald tijd een antwoord opgeleverd

1


Een overkoepelend architectuur is hierbij een randvoorwaarde. Daarom is AVB zo belangrijk.

33

wordt. Bijvoorbeeld, als een wegverkeersleider binnen één minuut de juiste maatregel nodig heeft, dan is het niet zinvol een representatie te kiezen welke soms een resultaat geeft in 10 seconden, maar er ook wel eens vijf minuten over kan doen. Men praat over een "hard real-time" systeem als een harde garantie gegeven kan worden, een "soft real-time" systeem als het resultaat binnen acceptabele grenzen wat in tijd kan variëren, en "non real-time" systemen als de variatie te groot is om bruikbaar te zijn. BL-achtige functionaliteit kan gevonden worden op elk niveau van het lagenmodel. Het geografisch gebied en de tijdschaal van de logica worden kleiner hoe lager je komt in het lagenmodel. In de ERP-laag gaat het over logica op een strategisch, enterprise niveau met landelijke of regionale werking over perioden van weken of langer. In de MES-laag gaat het over tactische beslissingen, toegesneden op het verkeersproces langs een snelweg, over perioden van een uur. In de SCADA-laag gaat het over operationele, tijd kritische logica met een uitwerking over een paar kilometers en een paar minuten. BL-achtige functionaliteit kan zelfs gevonden worden in de PLC-laag, in de vorm van (controle) regelingen die werken op het niveau van meters en milliseconden. In het MATCH project ligt de nadruk op regelscenario's en maatregelen. Dit is in eerste instantie BL op het tactisch - dus, MES - niveau. ERP-laag Enterprise Resource Planning (ERP) systemen liggen op strategisch of business niveau. Ze liggen boven het niveau van DVM systemen, en hebben inventory management, voorspelling, planning en costing op lange termijn als doel. In de RWS context zouden ERP systemen gebruikt kunnen worden op het organisatorisch niveau van Regionale Directies en AVV, en niet door wegverkeersleiders- en managers of beheerders. In werkelijkheid, is er op dit moment geen RWS-breed ERP systeem, maar wel een aantal management informatie systemen. 3.2.2 Scope van de Applicatie Architectuur De Applicatie Architectuur is aan de onderzijde begrensd door de fysieke sensoren en actuatoren, welke deel uit maken van TIAV. Aan de bovenzijde is er in RWS geen ERP systeem. Dus, de scope van de Applicatie Architectuur is beperkt tot de PLC/ DCS/ Controller, SCADA en MES lagen; zie Figuur 2. Functies op het SCADA niveau en daarboven hebben interactie nodig met menselijk gebruikers. Dit wordt weergegeven in Figuur 2 in de vorm van een presentatie- en sessie-, user-, en taak-laag, ofwel Mens-Machine Interface (MMI). Er wordt onderscheid gemaakt tussen de M M I op ERP niveau en de gecombineerde M M I op MES en SCADA niveau, omdat het ERP niveau buiten de scope van de Applicatie Architectuur ligt. 3.2.3 Lagenmodel in relatie tot ACT In Figuur 4 zijn de ACT componenten gegroepeerd, overeenkomstig de praktijk binnen het MATCH project: • PL componentgroep: CoPresentatieLaag, inclusief GIS functionaliteit; • SUT componentgroep: CoSessie, CoSessieManager, CoUserManager, en CoTaakManager; • Storing componentgroep: CoStoringsMeldingManager;


34

SM componentgroep: CoSensor, CoMonitor, CoSensorManager, en CoMonitorManager; BL componentgroep: CoRegelScenario, CoMaatregel, CoScenarioManager, en CoMaatregelManager; A M componentgroep: CoActuator, CoActuatorDirector, CoActuatorManager, en CoActuatorDirectorManager. WVLs

J

Bchccrdcre

t

Business Logic • Control

o-

êsUTJ-O

CD-

Business Logic - Verkeersbeheersing

7 Technische Infrastructuur Architectuur voor Verkeersbeheersing (TIA V)

1

%

Sensoren

Figuur 4.

l

£

Actuatoren

ACT topologie, met groepering van componenten.

De ordening in ACT is gebaseerd op de afstand van bepaalde functionaliteit tot de menselijk gebruikers (boven) of de technische infrastructuur (beneden). Bijvoorbeeld, de presentatielaag staat dichtbij de gebruikers, en de SM en A M componentengroepen in de Business Logic - Verkeersbeheersinglaag staan dichtbij de infrastructuur. SUT-beheer, storingsmelding, en BL functionaliteit liggen tussenin. BL functionaliteit kan zelfs variëren, afhankelijk van de plaats waar ze in het DVM systeem het moet draaien. In de verkeerscentrale staat de BL redelijk dichtbij de gebruiker, met alleen het PL en SUT-beheer ertussenin. In het UWKS heeft de BL functionaliteit geen PL, en ligt dus op een wat lager niveau, maar wel boven de SM en A M componentgroepen. Het lagenmodel kan als volgt in relatie gebracht worden met de ACT componentgroepen: • BL in MES-laag. De BL functionaliteit in de MES-laag heeft een direct relatie met de BL componentgroep in ACT's Business Logic Verkeersbeheersingslaag. BL functionaliteit heeft een tactische rol gericht op de nabije toekomst. Bijbehorende PL functionaliteit is het tonen van regelscenario's (bijvoorbeeld als beslisbomen) en maatregelen (bijvoorbeeld als sequenties van acties) en het visualiseren van toekomstige en/of hypothetische toestanden (bijvoorbeeld, hoe het verkeer er over een uur zou kunnen uitzien als maatregel X in werking is gezet). •

5


SCADA-laag. SCADA functionaliteit komt overeen met de SUT, Storing, en de "bovenkant" van de SM en A M componentgroepen. Opmerkelijk is dat SCADA meer nadruk legt op verwerking van sensoren en gegevens5 dan op Zoals de naam aangeeft: Supervisory Control And Data Acquisition.

35

•

actuatoren en commando's. Bijbehorende PL functionaliteit is het tonen van gegevens (bijvoorbeeld als een grafiek over tijd) en van de huidige toestand (eventueel in geografische kaart of schematische vorm). BL functionaliteit is optioneel, en dan wel om op een operationeel niveau snel in te spelen op de huidige toestand. PLC-laag. PLC / DCS / controller functionaliteit komt overeen met de "onderkant" van de SM en A M componentgroepen.

3.2.4

Productcategorieën

De product categorieën zijn top-down geïdentificeerd in het lagen model. Het hoogste niveau is Business Logic op het MES niveau. Hier komen producten voor in de vorm van BL toolkits. De verkenning van producten in de BL toolkit categorie is beschreven in sectie 3.3. Het middelste niveau zijn de SCADA systemen met interfaces naar verschillende leveranciers' PLCs. De PLCs bevinden zich op het laagste niveau. De verkenning van SCADA en PLC producten is samengevoegd in sectie 3.4 omdat SCADA systemen en PLC nauw met elkaar verbonden zijn.

Strategisch

ERP Managers öfj

Tactisch

CO CO

C3 O

Operationeel

"5. o. <

Telecontrol (smalband)

u o. o o

Verkeersproces Figuur 5.

Varianten op het lagen model.

Verder is er een aantal variaties te herkennen; zie Figuur 5. Device drivers zitten op het PLC niveau, maar implementeren slechts een technische conversie van data van en naar de fysieke sensoren en actuatoren. Device drivers zijn beschreven in sectie 3.5. Telecontrol systemen zijn SCADA/PLC systemen, ontworpen voor specifieke toepassingen met zeer beperkte bandbreedte. Telecontrolsystemen zijn ook beschreven in sectie 3.4. Verder bestaat een aantal producten uit een combinatie van software en (sensor en/of actuator) hardware. Deze ontwikkelingen in de markt komen niet overeen met de AVB benadering. Actuator Management Systemen (AMS'en) verbinden alle software van fysieke actuatoren tot en met het SCADA niveau. Verder hebben ze de bijbehorende


36

M M I . Enkele AMS'en bieden ook een deel van de MES-niveaufunctionaliteit. Telecontrol en AMS'en hebben een verticale benadering, i.p.v. een horizontale gelaagdheid. AMS'en zijn beschreven in sectie 3.6. Er is een categorie van toolkits welke alle soorten HMI's / MMI's / GUI's kan aanmaken. Voor DVM doeleinden zijn ook GIS-achtig geografische kaarten en schematische representaties een vereiste. PL toolkits zijn beschreven in sectie 3.7. De laatste categorie is voor producten die alle lagen van het lagenmodel kunnen afdekken: totaaloplossingen. Totaaloplossingen zijn beschreven in sectie 3.8. 3.2.5 Categorieën afgebeeld op ACT De productcategorieën kunnen afgebeeld worden op de ACT component topologie. Figuur 6 geeft weer hoe PL toolkits, BL toolkits, AMS'en, en SMS'en afgebeeld zouden kunnen worden op de ACT component topologie. In de praktijk zou iedere categorie ook de database componenten omvatten, maar dit is niet duidelijk in een figuur weer te geven. SMS'en zijn hier wel denkbaar als een spiegelbeeld van AMS'en, maar er zijn geen SMS'en gevonden in de markt. Men zou kunnen verwachten "SUT toolkits" (SUT & PL componentgroepen) en "storingsmelding toolkits" (Storing & PL componentgroepen) te vinden, maar die zijn ook niet aanwezig in de markt. WVL's

Beheerders

PL toolkit AMS /

SMS

BL toolkit

É§Z>

Technische Infrastructuur Architectuur voor Verkeersbeheersing (TJA V)

t Sensoren

Figuur 6.

t Actuatoren

PL & BL toolkits, AMS en SMS in topologie.

Figuur 7 geeft weer hoe SCADA systemen, PLS's/DCS's, en totaaloplossingen geplaatst zouden kunnen worden op de ACT componenttopologie. Hier is het wel mogelijk om de databasefunctionaliteit van SCADA systemen en totaaloplossingen op te nemen. Producten in beide categorieën hebben


37

minstens een real-time database en vaak hebben ze eveneens een niet-realtime, relationele database voor het genereren van rapporten.

WVL's

Beheerders

Totaal oplossing

^

1 Technische Infrastructuur Architectuur voor VerkeeK&ehecrsh 'g(TIAV)

t Sensoren

Figuur 7.

t

PLCs/DCSs

Actuatoren

SCADA, PLC/DCS en Totaaloplossing in topologie.

Behalve PLC's en DCS'en, hebben alle categorieën een scheiding tussen de TIAV en de AA. Bovendien bestrijken deze producten meerdere lagen binnen de AA, omdat ze een eigen PL moeten hebben om als een product op de markt gebracht te kunnen worden. PLC's en DCS'en overlappen de scheiding tussen de TIAV en de AA, omdat deze producten zowel uit software als uit hardware bestaan. Het is belangrijk om op te merken, dat weinig producten in werkelijkheid precies in deze categorieën passen. Vaak biedt een product additionele functionaliteit boven op de kernfuncties van zijn categorie. Soms kan het daardoor moeilijk zijn een product in een bepaalde categorie in te delen. Bijvoorbeeld, een SCADA systeem dat een scripting module biedt, zou als een totaaloplossing beschouwd kunnen worden. De additionele functionaliteit kan zelfs ook buiten de functionele, nietfunctionele, en ACT eisen vallen. Bijvoorbeeld, meerdere producten bieden een webgebaseerde GUI, de mogelijkheid om configuratie beheer op afstand uitte voeren, of een simulatie module.

3.3 BL toolkits in MES-laag 3.3.1 Inleiding Uit de discussie over de MES-laag in paragraaf 3.2 is duidelijk geworden dat functionaliteit nodig is voor het creëren, beheren, selecteren en uitvoeren van regelscenario's en maatregelen. Alle totaaloplossingen hebben een soortgelijke functionaliteit, en sommige SCADA systemen bieden een soortgelijke functionaliteit als een aanvullende module. Voor de andere SCADA systemen of een DVM systeem opgebouwd uit subsystemen of componenten is het nodig


38

om BL functionaliteit toe te voegen. In de markt hebben we BL toolkits gevonden die dit mogelijk zou maken. 3.3.2 Gemeenschappelijk eigenschappen Hoe men regelscenario's en maatregelen moet representeren in het DVM systeem is onduidelijk. Er is een reeks mogelijkheden. In de ACT documentatie [ACT_SSDD] wordt de component CoRegelScenario gezien als een realisatie van het begrip "regelscenario"uit de AVB Verkeerskundige Architectuur. Het bevat een invoergedeelte, een beslissingsgedeelte, en een uitvoergedeelte. Het invoer- of monitoringsgebied van een regelscenario wordt gerepresenteerd door de "som" van de sensoren die via CoMonitor componenten aan het regelscenario zijn gerelateerd. Het uitvoer-, aangrijpings- of beïnvloedingsgebied wordt gerepresenteerd door de "som" van de actuatoren die via CoMaatregel componenten aan het regelscenario zijn gerelateerd. De beslislogica van een regelscenario wordt gerepresenteerd in een "script", dat door component CoRegelScenario wordt uitgevoerd. Het script heeft de grammatica van een eenvoudige programmeertaal, waarmee in ieder geval taaiconstructies zijn te bouwen als ALS ... DAN ... regels. De component CoMaatregel wordt gezien als een realisatie van het begrip "maatregel" uit de Verkeerskundige Architectuur, d.w.z. de component vertegenwoordigt een uit te voeren stap binnen het scenario van een regelscenario. Het beïnvloedingsgebied van CoMaatregel wordt gevormd door de "som" van alle aangestuurde CoActuator en CoActuatorDirector componenten. CoMaatregel kan worden voorzien van maatregel-specifieke logica voor de correcte aansturing van de onderliggende actuatoren. Een voorbeeld is dat CoMaatregel informatie nodig heeft van een of meer sensoren, zoals bij DRIP's waarop filelengtes of reistijdvertragingen worden getoond. Vanuit deze oogpunten zijn producten nodig die een eenvoudige programmeertaal of iets dergelijks aanbieden. Mogelijkheden zijn o.a. scripttalen en regelgebaseerde expertsystemen. 3.3.3 Producten De producten zijn geëvalueerd volgens de criteria en kwalificatie symbolen (V, G, N, -) uit paragraaf 3.1. De volgende producten zijn voor de Shortlist fase als BL toolkits geselecteerd: Leverancier

Product

Interface & Control Systems (ICS) ILOG

SCL/eSCL & RIMS Rules & JRules

Product type BL & PL toolkits BL toolkits

BL functionaliteit is ook te vinden in totaaloplossingen (en sommige SCADA systemen), vaak in de vorm van scripttalen. Sommige systemen bieden de mogelijkheid om third-party expert systeem producten (zoals Gensym's G2) en/of maatwerk toepassingen te gebruiken voor BL doeleinden. In deze paragraaf wordt bovendien een vergelijking gemaakt met de volgende totaaloplossingen:


39

Leverancier

Product

AVE

MAVE

Bentley CCT Delcan Harris IBI M l Services Trinité

GeoTransport ATMS CCTK TCSS OS/Comet ATMS TransActive PDA

BL functionaliteit Conventioneel of fuzzy verkeerssturing (schakeling) model G2 koppeling Koppeling met Tel scripts en/of G2 Decision trees & traffic plans CCL script-taal Traffic response plans Plan subsystem (Perl scripts) Programmable Information Elements (PIEs) (d.w.z. active objects)

In deze paragraaf worden de BL toolkits volledig geëvalueerd. Alleen de BL functionaliteit van de totaaloplossingen wordt hier geëvalueerd (in tabellen Niet Functioneel: Product regelingen en Applicatie besturing: Business logic laag). Zie paragraaf 3.8 voor een volledige evaluatie van de Totaaloplossingen. BL functionaliteit is ook terug te vinden in sommige SCADA systemen en AMS'en. In SCADA systemen is BL functionaliteit een aanvullende optie. De BL functionaliteit in AMS'en is puur gericht op besturen van actuatoren. De locale regelingen in PLC's en DCS'en (b.v. de gestandaardiseerde IEC 61131-3 programmeertaal) kunnen ook beschouwd worden als BL functionaliteit. Onze inschatting is dat de BL functionaliteit in totaaloplossingen ook representatief is voor de BL functionaliteit in SCADA systemen en AMS'en. Aparte vergelijking tussen BL toolkits en SCADA systemen of AMS'en is niet nodig.

ILOG

MAVE

Bentley

CCT

Delcan

Harris

IBI

Ml Services

Trinité

3.3.4 Selectie criteria

?

V V G G G V V G

V V V V V V V V

V V G V N G V N

V V V V V V V V

V V V V V V V V

V V V G V V V V

V V V V V V V G

G G G IM N N V V

Product eigenschap 1. 2. 3. 4. 5. 6. 7. 8.

Verkeersmanagement Verkeerskundig configuratiebeheer Technisch systeembeheer Operator taakscheiding Operator taakoverdracht Functie taakscheiding Datalogging Beschikbaarheids informatie

•es

Functioneel

G G V -

-

Deze tabel maakt de functionele beperking van een (BL) toolkit in vergelijking met totaaloplossingen duidelijk. Specifieke functionaliteit voor het DVM domein wordt niet geboden door toolkits. Zelfs functionaliteit die hoort bij het meer algemeen domein van real-time control systemen, namelijk taakscheiding en -overdracht, wordt niet ondersteund door toolkits.


40

Ad 1: ICS geeft aan dat het regelgebaseerde expert systeem in SCL/eSCL is gebruikt om de procestoestand en fouten te detecteren, en om correctief acties te ondernemen, inclusief het oproepen van mensen. Voor DVM toepassingen is het proces het verkeersproces en zijn fouten incidenten c.q. calamiteiten in het verkeersproces. Om SCL/eSCL toe te passen is het nodig om scripts, regels en sensorconfiguraties toe te voegen.

ICS

ILOG

MAVE

Bentley

CCT

Delcan

Harris

IBI

Ml Services

Trinité

Ad 3: ICS geeft aan dat bedrijfsuren van sensoren en actuatoren niet worden geregistreerd, maar dat daarvoor wel een applicatie programma ontworpen zou kunnen worden.

V N V G

V V V G

V V V G

V V V V

V V V

V V V V

V V

V V V N

V V V V

V G V G

Niet Functioneel: Product integratie Product eigenschap 1. 2. 3. 4.

Vervangen gebruikersinterface Integratie regelingen Integratie databases Integratie producten

Niet functionele eisen m.b.t. productintegratie worden voor een groot deel even goed ondersteund door (BL) toolkits als door Totaaloplossingen. Ad 2: ICS geeft aan dat SCL/eSCL zijn eigen regelen scripttaal kent, maar dat de regels en scripts niet kunnen worden geïntegreerd met andere regels en scripts. Ad 4: ICS's SCL/eSCL draait op Windows NT/2000, Unix, Linux en embedded systemen. SCL/eSCL is grotendeels in C++ geschreven (en er is een compilerlibraries afhankelijkheid), maar er is een standaard API voor C/C++ en Java.

V V G V V V V

G G V V V V V

V V V V V V

V

Niet functionele eisen m.b.t. product performance worden volledig ondersteund door (BL) toolkits. Slechts een paar totaaloplossingen kunnen op hetzelfde niveau komen als een (BL) toolkit.


41

Trinité

?

V V V V V V V

IBI

V V V V V ?

Harris

V V V G G G G

Delcan

V V V V V V V

CCT

V

Bentley

V V V V V V

MAVE

Modulaire opbouw Uitbreiding functionaliteit Leverancier onafhankelijkheid Schaalgrootte Schaaluitbreiding Verwerkingscapaciteit Verwerkingscapaciteit uitbreiding

ILOG

1. 2. 3. 4. 5. 6. 7.

Product eigenschap

ICS

Niet Functioneel: Product performance

Ml Services

Ad 4: ILOG Rules is specifiek aan C++, en JRules aan Java.

V V G V V V G

V V V ? ? ? ?

,cs

ILOG

MAVE

Bentley

CCT

Delcan

Harris

IBI

Ml Services

Trinité

V V V V V V

V V V N G -

G N N V G V V

V G V V V V

V V V V

V N V V V V V

V V N N V V

V V V N V V

V N G V G V V

V G V V V V

Niet Functioneel: Product ondersteuning Product eigenschap 1. 2. 3. 4. 5. 6. 7.

COTS Grote Installed base Ruime Installed base Product ondersteuning Product service Product lifecycle Onderhoud op afstand

De eenvoud en domeinonafhankelijkheid van (BL) toolkits betekent dat ze een installed base in de honderden of zelfs duizenden kunnen hebben. Dit is vrijwel onhaalbaar voor een Totaaloplossing; de best verkochte Totaaloplossing telt maar 30 operationele installaties. Ad 5: ILOG geeft aan dat er geen eerstelijns onderhoud organisatie in Nederland is voor zijn producten. Ondersteuning zou vanuit Frankrijk moeten komen.

IBI

Ml Services

Trinité

Ad 6: Ondersteuning voor ILOG producten is als standaard niet tien jaren lang.

V V V G V V V V V V V

V V V V V V V G G

V V V V V V V V V V N

Product eigenschap

ICS

ILOG

MAVE

Bentley

CCT

Delcan

Harris

Niet Functioneel: Product interface

1. Uitbreiding Interface 2. Pluriforme Interface 3. Meerdere protocollen 4. Redundante l/O 5. Sensor interface voor andere prod. 6. Sensor interface door andere prod. 7. Actuator int. voor andere prod. 8. Actuator int. door andere prod. 9. VicNet Communicatie 10. Locale bediening 11. ITS standaarden

V V V V V V G

V V N V G

V V G G V V V V N G

V V V V V V V V V V G


V V V V V V V V N N V

V V V V V V V V V V

N

Deze tabel maakt de beperking duidelijk van een (BL) toolkit in vergelijking met Totaaloplossingen voor wat betreft (sensor-) interfacing en real-time communicatie protocollen. Ad 5, 7: ILOG geeft aan dat zijn Rules en JRules producten alleen sensor data kunnen inwinnen van andere producten en commando's sturen aan actuatoren, maar niet in de omgekeerde richting(en). Ad 9: ILOG geeft aan dat Rules en JRules geen TCP/IP interface hebben. Ad 11: ICS geeft aan dat SCL/eSCL en RIMS geen ITS standaarden ondersteunen. XML kan ge-embedded worden in SCL regels en scripts.


42

SDI

ILOG

MAVE

Bentley

CCT

Delcan

Harris

IBI

Ml Services

Trinité

I

Ad 11: ILOG geeft aan dat Rules en JRules XML ondersteunen, maar geen ITSspecifieke standaarden.

G V V G V V

V V V G V V

V V V V V V

N N V N V N

G V V V V V

V V V V V V

V V V V V V

V V V V V V

V V G G V V

G G V V V V

Niet Functioneel: Product regelingen Product eigenschap 1. 2. 3. 4. 5. 6.

Blokkeren van maatregelen Parameteriseren van maatregelen Scheiding beslissing en uitvoering Locale regelingen Real-time I/O Real-time regelingen

Voor wat betreft product regelingen bevinden BL toolkits zich op hetzelfde niveau als totaaloplossingen. Er is een grote diversiteit aan representaties van regelscenario's en maatregelen: • Expert systeem regels: ICS en ILOG. • Scripts: ICS en Harris hebben eigen scripttalen, CCT ondersteunt Tel scripts, en Ml Services ondersteunt Perl scripts. • Decision trees: Delcan. • (Fuzzy) FSM's: MAVE. • Active objects: Trinité noemt ze Programmable Information Elements (PIE's). • Traffic response plans (d.w.z. maatregelen): Delcan, IBI. Ad 1: ICS geeft aan dat blokkeren van maatregelen geïmplementeerd zou moeten worden in SCL scripts en regels. Ad 4: ICS geeft aan dat SCL/eSCL en RIMS uit gaan van een gecentraliseerd systeem, d.w.z. op het "centre" in NTCIP terminologie. Decentralisatie, d.w.z. met een of meerdere niveaus tussen "centre" en "field" wordt niet onderkend in SCL/eSCL en RIMS. Ad 4: ILOG geeft aan dat Rules en JRules een Web Rule Builder hebben die het mogelijk maakt om regels te creëren en in te zetten op afstand. Maar decentrale uitvoering wordt niet ondersteund.

CCT

Delcan

Harris

IBI

Ml Services

Trinité

3.3.5 Afbeelding op ACT

G V V V V V

G V V V V G

G V G V V G

V V V G V V

G V G V V G

G V V V V V

Actuator Actuator Actuator Actuator Actuator Actuator

control groepering configuratie object beheer toestandsinformatie historische informatie

G -

Bentley

1. 2. 3. 4. 5. 6.

MAVE

Product eigenschap

ILOG

Actuator Management

-

G V V V V V

? ? V V V V

Vanwege hun domeinonafhankelijkheid hebben (BL) toolkits weinig te bieden v.w.b. actuator management.


43

o

ILOG

MAVE

Bentley

CCT

Delcan

Harris

IBI

Ml Services

Trinité

Ad 1: ICS geeft aan dat SCL's database discrete, analoge, en string data-types voor commando's richting actuatoren ondersteunt, maar geen "basic logic". Scripts en regels zouden hiervoor kunnen worden gebruikt.

G G

-

V V V V V

V V V V V

V V V V V

V V V V V

V V V V V

V V V G V

V V G V V

V V V V V

Sensor Management Product eigenschap 1. 2. 3. 4. 5.

Sensor Sensor Sensor Sensor Sensor

data acquisitie groepering configuratie object beheer toestandsinformatie

Vanwege hun domeinonafhankelijkheid hebben (BL) toolkits weinig te bieden v.w.b. sensor management. Ad 1: ICS geeft aan dat SCL geen sensorobjecten c.q. -componenten kent. Data-acquisitie routines halen sensor data binnen uit SCL's real-time database.

MAVE

Bentley

CCT

Delcan

Harris

IBI

Ml Services

Trinité

Ad 5: ICS geeft aan dat sensordata waarden gebruikt kunnen worden voor initiëren van regels, in scripts, en/of voor presenteren in de GUI.

G G

-

G G

V ?

G V

V V

G V

G V

V G

V V

N -

-

N N N

V ?

N N N

N V V

V N N

V G G

V V V

G V V

1. Visuele representaties 2. Geografische en/of schematische presentaties met 4000 objecten in 4 sec 3. GDF formaat 4. Video 5. Audio

ILOG

Product eigenschap

ICS

Applicatie besturing: Presentatie laag

?

BL toolkits hebben weinig te bieden v.w.b. de ACT presentatielaag. Het SCL product van ICS ondersteunt wel een deel van de presentatielaag functionaliteit dankzij de Remote Intelligent Monitoring System (RIMS) "add-on". Ad 1: ICS geeft aan dat RIMS schematische beelden kan tonen, maar dat een apart product nodig is om kaarten te tonen. In het verleden is ESRI's Arclnfo GIS hiervoor gebruikt. Ad 2: ICS geeft aan dat de snelheid gehaald kan worden voor data-acquisitie, maar de verversing is zichtbaar vanwege de beperkt bandbreedte tussen de web-server en het RIMS GUI. Ad 3: ICS geeft aan dat RIMS GDF formaat niet ondersteunt.


44

MAVE

Bentley

CCT

Delcan

Harris

IBI

Ml Services

| ILOG V

V

V

V

V

V

V

V

G

G

V G V

V -

V G V

V V V

G N V

V V V

V V V

V G V

V V G

G N V

Applicatie besturing: Business logic laag Product eigenschap 1. Verkeersbeheersing (VB)-object beheer 2. VB-object gebruik 3. SUT beheer 4. Storingsmelding beheer

Voor wat betreft verkeersbeheersingsobjecten (d.w.z. regelscenario's en maatregelen) bevinden BL toolkits zich op hetzelfde niveau als totaaloplossingen. Andere aspecten van de ACT's BL-laag (m.n. sessie-, useren taakbeheer, en beheer van storingsmeldingen) horen niet perse tot de functionaliteit van een BL toolkit. Ad 3: 3.3.6

ICS geeft aan dat RIMS taak- en werkplekoverdracht niet ondersteunt Specifieke eigenschappen

Een vergelijking van de regelingen te vinden in BL toolkits en totaaloplossingen heeft aangetoond dat er een grote diversiteit is van representaties van regelscenario's en maatregelen: • Expert systeem regels: ICS en ILOG. • Scripts: ICS en Harris hebben eigen scripttalen, CCT ondersteunt Tel scripts, en Ml Services ondersteunt Perl scripts. • Decision trees: Delcan. • (Fuzzy) FSM's: MAVE. • Active objects: Trinité. • Traffic response plans (d.w.z. maatregelen): Delcan, IBI. Een representatie welke niet voorkomt in deze producten maar wel in andere markten (b.v. aerospace en defensie) is Standard Operating Procedures (SOPs). Verder, is de veelgebruikte scripttaal Visual Basic niet aangetroffen in de BL toolkits en totaaloplossingen. Visual Basic is wel gebruikt als scripttaal in Ferranti's RTAP SCADA systemen, evenals in niet-DVM producten zoals de Microsoft Office suite en in een aantal andere software ontwikkelomgevingen. Naast zijn eigen kennisrepresentaties ondersteunt een aantal van de producten een of meerdere alternatieve mechanismen voor de implementatie van regelingen: • Externe expert systeem: Bentley, CCT en M l Services, allemaal Gensym's G2. • Externe maatwerk toepassingen koppelen via een API: ICS, Bentley, CCT, Harris, en Ml Services (via CORBA). Onderzoek van de volgende onderwerpen ligt buiten de scope van het huidige project: • De gedetailleerde capabiliteiten van elke representatie; • Een vergelijking tussen elke representatie en een standaard programmeertaal, zoals C++ of Java; • De voor- en nadelen van de verschillende representaties onderling; • De mate van dekking die elke representatie geeft voor DVM scenario's en maatregelen zoals ze worden gebruikt in Nederland.


45

3.3.7 Conclusies In deze paragraaf is een vergelijking gemaakt tussen BL toolkits en de BL functionaliteit in totaaloplossingen. Het is duidelijk dat het meest belangrijke voordeel van een totaaloplossing is, dat het een veel omvangrijkere functionaliteit biedt. Een BL toolkit heeft ook voordelen: • De BL functionaliteit in een BL toolkit is vaak meer expressief en/of sneller dan de BL functionaliteit van een totaaloplossing; • Een BL toolkit kan aanvullend zijn op andere producten waarin geen BL functionaliteit voorkomt, zoals een SCADA/PLC systeem zonder additionele BL module. Een brede diversiteit van representaties is te vinden in BL toolkits en de BL functionaliteit in totaaloplossingen. Sommige SCADA systemen en een enkele AMS hebben ook aanvullende modules welke BL functionaliteit aanbieden. Zelfs de locale regelingen in PLC's en DCS'en kunnen als BL functionaliteit gezien worden. De reden voor deze diversiteit is onduidelijk. Een evaluatie van de voor- en nadelen van de verschillende representaties en hoe geschikt ze zijn voor DVM doeleinden valt buiten de scope van het MATCH project. De mate waarin deze representaties voldoen aan de verkeerskundige regelscenario's en maatregelen kan niet geëvalueerd worden. Het is niet helder of de representaties gekozen in ACT de enige mogelijke zijn of dat ze het resultaat zijn van een ontwerpkeus. Andere conclusies zijn: • DVM-specifieke functionaliteit wordt niet aangeboden door BL toolkits. • BL toolkits tonen functionele beperkingen in vergelijking met totaaloplossingen. • In ACT termen hebben BL toolkits weinig te bieden v.w.b. sensoren actuator-management en v.w.b. DVM-gerelateerde visuele presentaties (d.w.z. geografische kaarten en schematische beelden). • BL toolkits zijn beperkt v.w.b. (sensor-) interfacing en real-time communicatieprotocollen. • SUT- en storingsmelding-beheer ontbreekt in BL toolkits. • BL toolkits hebben een grotere installed base dan totaaloplossingen. • Slechts een paar totaaloplossingen kunnen op hetzelfde niveau komen als BL toolkits v.w.b. de niet-functionele eisen van productprestaties en regelingen. Verdergaande studie is aanbevolen om: • Helderheid te creëren over de mogelijk representaties van regelscenario's en maatregelen zoals deze worden gebruikt voor DVM doeleinden in Nederland; • Een brede inventarisatie uit te voeren van de BL functionaliteit in SCADA systemen en andere producten op de Match shortlist; • De representaties geïdentificeerd in deze inventarisatie verdergaand te bestuderen voor wat betreft hun expressiviteit, de mate van dekking van de behoeften van regelscenario's en maatregelen, en de voor- en nadelen voor toepassing in DVM systemen.


46

3.4 Supervisory Control And Data Acquisition (SCADA) 3.4.1 Inleiding Een SCADA systeem kan worden gekarakteriseerd als: een algemeen toepasbaar Supervisory Control en Data Acquisition software systeem, ten behoeve van productie- en procesautomatisering. Met deze systemen kunnen productie- en procesgegevens verzameld worden, afkomstig van een breed scala aan productie- en procesbesturingssystemen. Deze gegevens kunnen beschikbaar gesteld worden aan de gehele organisatie. Tevens kan de gebruiker hiermee het onderliggende (productie) proces besturen. Een SCADA systeem bevat in vrijwel alle gevallen een Human Machine Interface (HMI), waarmee een gebruiker directe bediening en bewaking van het onderliggende proces kan uitvoeren. Een SCADA systeem maakt doorgaans van PLC's gebruik voor het fysiek inwinnen van gegevens en het fysiek aansturen van actuatoren. Een PLC kan worden gekarakteriseerd als een algemeen toepasbaar besturingsapparaat, dat kan worden gebruikt voor het besturen en bewaken van een industrieel proces. Een PLC kan zowel 'stand-alone' toegepast worden als ook in combinatie met een SCADA systeem. 3.4.2 Gemeenschappelijke eigenschappen Supervisory Control and Data Acquisition software (SCADA) wordt gedefinieerd door de volgende eigenschappen: • Computer based: een SCADA systeem moet beschikken over een hoge connectiviteit en een grote integreerbaarheid. Dit betekent, dat een SCADA pakket kan communiceren via meerdere hardware interfaces, zoals serieel, Profibus en Ethernet. • Data acquisition: een SCADA systeem moet in staat zijn data op te halen uit en te leveren aan meerdere PLC's en andere hardware, zoals bijvoorbeeld het Philips Allegeant Video schakelsysteem (VC Utrecht) en verkeerslicht regelaars. • Database: De meeste applicaties maken gebruik van regel scenario's, maatregelen , data-logging en andere toepassingen die in een database moeten worden opgeslagen. SCADA systemen kunnen daartoe grote hoeveelheden data opslaan. De opslag van data kan worden onderverdeeld in 'real-time' data ten behoeve van de uitvoering van het proces en 'nietreal-time' data voor bijvoorbeeld off-line statistische verwerking en het genereren van rapportages. De opslag van 'real-time' data gebeurt binnen het SCADA pakket zelf in wat ook wel de 'Tag' database genoemd wordt, de opslag van niet 'real-time' data (b.v. voor het genereren van rapporten) gebeurt buiten het SCADA pakket in bijvoorbeeld een relationele database (RDB). In bijna ieder geval is het RDB Oracle. • Alarmering: een SCADA systeem moet in staat zijn om alarmen te detecteren, te tonen en te loggen. Dit opdat gebruikers in geval van problemen gewaarschuwd kunnen worden en op basis daarvan correctieve maatregelen kunnen nemen en herhaling kunnen voorkomen. • Operator interface: Een SCADA systeem verzamelt gegevens over een proces. Deze gegevens moeten aan een gebruiker worden weergegeven, dit kan onder meer gebeuren via de Human Machine Interface (HMI). • Besturing: een SCADA systeem kan besturingstaken uitvoeren, welke door de PLC worden gerealiseerd. Hierbij is het tevens mogelijk dat de besturing door het SCADA systeem en door de PLC met elkaar worden geïntegreerd.


47

Daar SCADA systemen vooral gebruikt worden in de technische procesbesturing, beschikken de meeste SCADA systemen over een grafische gebruikersinterface waarmee uitstekend processchema's kunnen worden weergegeven. Het weergeven van geografische kaarten is bij de SCADA systemen zelf in veel gevallen aan beperkingen onderhevig. Om verkeersinformatie geografisch te kunnen weergeven, wordt het SCADA systeem gecombineerd met een GIS applicatie. GIS is derhalve een additionele functionaliteit.

SCADA systemen worden vaak in combinatie met Programmable Logic Controllers (PLC's) gebruikt. Een PLC wordt gekenmerkt door de volgende eigenschappen: • SCADA koppeling: Een PLC fungeert als 'concentrator' van proces data, zowel direct ingewonnen data als ook door een applicatie in de PLC afgeleide data. Het SCADA systeem kan besturingsinformatie via een driver en een netwerkverbinding naar de PLC 'downloaden'. De informatie uit de PLC kan vervolgens op omgekeerde wijze ook worden 'ge-upload' door een SCADA systeem. Een PLC kan ook gekoppeld worden aan andere systemen. Hiervoor moet zo'n systeem wel beschikken over een driver (bijv. TCP/IP of OPC) waarmee data gelezen of geschreven kan worden. • I/O: Een PLC heeft de beschikking over een groot aantal (evt. galvanisch) gescheiden standaard in- en uitgangsmodules voorde meest uiteenlopende elektrische signalen, waarbij gebruik gemaakt kan worden van een grote verscheidenheid aan bedrading. Dit kan direct op de PLC zelf gerealiseerd worden, of in de vorm van een "I/O blok" dat los van de PLC kan worden opgesteld en wat verbonden is met de PLC via een fieldbus, waarop ook andere apparatuur kan worden aangesloten; • Real-time regelingen (maatregelen en regelscenario's): de PLC kan applicaties bevatten, die parallel real-time regelingen uitvoeren, waarbij de PLC de infrastructuur hiervoor biedt. • Programmeer standaard: de PLC applicaties kunnen modulair worden geprogrammeerd, op basis van de IEC 61131-3 standaard. • Robuuste uitvoering: Een PLC is geschikt voor gebruik in een industriële omgeving Alhoewel alle SCADA en PLC systemen in principe "Real-time" systemen zijn, moet worden opgemerkt dat niet alle systemen aan dezelfde eisen op dit gebied voldoen. In het algemeen kan worden gesteld, dat PLC's een beter "real-time" gedrag hebben dan SCADA pakketten, waarbij het real-time gedrag ook nog afhankelijk is van het gebruikte communicatiekanaal tussen PLC en het SCADA

pakket.


48

3.4.3 Producten De volgende producten zijn in de Shortlist fase geselecteerd: SCADA producten: Leverancier

Product

Ferranti OSI Software

RTAP PI System

SCADA/PLC producten: Leverancier Product ABB

Industrial IT Sattline SAT 200 SAT 1703 Unimacs Dynac-ATMS Modicon PLC UZ2000

Electron Imtech Marine Transdyn Weiss

Product type SCADA SCADA

Product type SCADA/PLC SCADA/PLC SCADA PLC-achtig MES/PLC/SCADA SCADA PLC Unter Zentrale

NB: ABB had in eerste instantie ook het Sattline systeem als product opgevoerd. In de Shortlist fase heeft ABB aangegeven, dat van de twee systemen: Industrial IT en Sattline, het Industrial IT systeem het beste aan de gestelde criteria voldeed, onder meer met betrekking tot de continuïteit. Het Sattline systeem, dat door de Bouwdienst voor objectbeheer toegepast wordt, is vervolgens, mede gezien het grote aantal producten op de shortlist, niet meer in het onderzoek betrokken. De producten Operate IT en de AC800 maken deel uit van het Industrial IT systeem. Wegens gebrek aan informatie kon het op TLS (en dus op Telecontrol, zie Electron) gebaseerde UZ2000 systeem niet volledig worden beoordeeld. 3.4.4 Selectie criteria

Imtech

Transdyn


Electron

1. 2. 3. 4. 5. 6. 7. 8.

ABB

Product eigenschap

OSI Soft.

Functioneel

Ferranti

De producten zijn geëvalueerd volgens de criteria en kwalificatie symbolen (V, G, N, -) uit paragraaf 3.1.

V V V V V V V V

V V G

V V V N N V V G

V G V V G V V G

V V V V V V V G

V V V V V V V V

Ad 2: Electron geeft aan, dat het gebruik van de standaarden IEC 60870-5 en IEC 61850 enige beperkingen oplegt aan de informatie die kan worden overgebracht (o.a. geen tekst)


49

Product eigenschap

Ferranti

OSI Soft.

ABB

Electron

Imtech

Transdyn

Ad 8: ABB geeft aan dat dit geen standaard functie is, maar dat dit wel als applicatie gerealiseerd kan worden. Electron geeft aan dat dit geen standaard functiels, maar dat dit wel als applicatie gerealiseerd kan worden. Imtech geeft aan dat dit geen standaard functie is, maar dat dit wel als applicatie gerealiseerd kan worden. OSI software geeft aan dat dit geen standaard functie is, maar dat dit wel als applicatie gerealiseerd kan worden.


V G N V

V G N V

V V V V

N V G G

V V V V

G V V V

Niet Functioneel: Product integratie

1. 2. 3. 4.

Ad 1: Transdyn geeft aan dat de huidige GUI zowel geografische- als kaartpresentaties kan weergeven en dat de huidige versie van Dynac volledig geïntegreerd is met DataViews en Motif. Het vervangen van de gebruikersinterface is technisch mogelijk, maar volgens Transdyn volkomen overbodig en derhalve is Dynac volgens hen "Partial Compliant" op dit punt. OSI-Software biedt rond de kern aanvullende modules. Enkele daarvan vervullen de rol van gebruikersinterface. Deze modules zijn ingedeeld naar de taak van de gebruikers. Ad 2: Ferranti geeft aan dat RTAP drie mogelijkheden kent om regelingen te integreren: (1) data-structuren voor regelscenario's en maatregelen toekennen aan de RTAP (real-time) Database en gebruik maken van RTAP's Calculation Engine; (2) regelscenario's en maatregelen in een externe toepassing representeren en de toepassing koppelen via RTAP's API; (3) gebruik maken van VBA scripting binnen RTAP. In ieder geval moeten data-structuren voor regelscenario's en maatregelen worden ontworpen. Daarom is de codering G(edeeltelijk). De uitleg voor Ferranti is eveneens van toepassing op OSI-software. Ad 3: Ferranti geeft aan dat RTAP een eigen real-time database heeft, die niet te vervangen is. OSI-software heeft eveneens een eigen real-time database maar kent wel diverse toegangsmogelijkheden gebaseerd op ODBCtechnieken. Ad 3 en 4: Electron geeft aan, dat het gebruik van de standaarden IEC 60870-5 en IEC 61850 enige beperkingen oplegt aan de koppelbaarheid. Ad 4: Integratie producten: Transdyn geeft aan dat Dynac is ontwikkeld gebaseerd op open standaarden waaronder TCP/IP, Motif/Xwindows, SQL/ODBC en Netscape / Microsoft browsers ten behoeve van documentatie. Osi-software heeft zich gecommitteerd aan de Microsoft lijn en maakt gebruik van COM.


50

Electron

Imtech

Transdyn


ABB

1. 2. 3. 4. 5. 6. 7.

OSI Soft.

Product eigenschap

Ferranti


V V V V V V V

V V V V V V V

V V V V N V V

V V G V G G G

V V V V V V V

V V V V V V V

Ad 4 en 5: ABB: schaalgrootte zit tegen het maximum aan. Uitbreiding met factor 3 is voorzien, maar nog niet met factor 10. Ad 5, 6, 7: Electron: Kan geen bevestigend antwoord geven, gevraagde schaalgrootte komt bij energie voorziening niet voor.

V V V V V V

V V V V V V V

V V V V V V

V V V V V V

V V V

V V V V

Transdyn

Imtech


Electron

1. 2. 3. 4. 5. 6. 7.

ABB

Product eigenschap

OSI Soft.

Niet Functioneel: Product ondersteuining

Ferranti

Ad 5, 6, 7: Imtech: Kan geen bevestigend antwoord geven, gevraagde schaalgrootte komt op schepen niet voor. Volgens de betreffende onderleveranciers (Cimplicity/Trimation en Modicon/Schneider) is gevraagde schaalgrootte en performance geen probleem.

V V N N V V

Ad 2 en 3: Imtech heeft slechts een ruime installed base. De onderleveranciers (o.a. Cimplicity/Trimation en Modicon/Schneider) hebben een grote installed base. OSI-software kent een grote installed base maar niet op ITS gebied. Ad 4 en 5: Transdyn zet samen met haar klanten een technisch ondersteuningsprogramma op, toegespitst op de specifieke eisen van de klant. Voor internationale klanten kan dit resulteren in het lokaal stationeren van een werknemer ofwel het gebruikmaken van de diensten van een gekwalificeerd lokaal bedrijf, dat door Transdyn wordt opgeleid om eerstelijns onderhoud te verrichten. Voor klanten met een eigen technische onderhoudsdienst, kan Transdyn, 24 uur per dag en zeven dagen per week telefonische on-line ondersteuning leveren in combinatie met periodieke preventieve onderhoudsbezoeken. OSI-Software is werkzaam in diverse industrieën en ondersteuning staat centraal. Door eindgebruikers wordt met name de compatibiliteit tussen oude en nieuwe versies als goed ervaren alsmede de ondersteuning van specifieke interfaces ook bij de nieuwe versies.


51

V V V V V V V V V V -


V V V G V V V V V V G

V V V V V V V V

V V N

Transdyn

Electron


Imtech

ABB

1. Uitbreiding Interface 2. Pluriforme Interface 3. Meerdere protocollen 4. Redundante I/O 5. Sensor interface voor andere producten 6. Sensor interface door andere producten 7. Actuator interface voor andere producten 8. Actuator interface door andere producten 9. VicNet Communicatie 10. Locale bediening 11. ITS standaarden

OSI Soft.

Product eigenschap

Ferranti


V V V V V V V V V V V

Ad 11: Ferranti geeft aan dat RTAP XML ondersteunt, maar geen ITS standaard. Ad 11: Alhoewel het standaard product van Electron als zodanig geen ITS standaarden ondersteunt, is SAT in Oostenrijk marktleider op het gebied van wegverkeerssystemen, omdat zowel de SAT producten, als de ook in Oostenrijk en Zwitserland gehanteerde Duitse TLS standaard op dezelfde IEC 60870-5 en IEC 61850 standaarden gebaseerd zijn.

V G

Transdyn

V V V V

Imtech


Electron

1. 2. 3. 4. 5. 6.

ABB

Product eigenschap

OSI Soft.

Niet Functioneel: Product regelingen

Ferranti

Ad. 11: Transdyn ondersteunt de NTCIP standaard.

V V V V

V V V V V V

V V V V V V

V V V V V V

V V V V V V

Ad 6: Ferranti geeft aan dat RTAP een multi-proces systeem is, dat er van uit gaat dat de processen onafhankelijk van elkaar zijn. Dit is een stapje minder dan vol-parallele regelingen met interacties (zoals nodig voor maatregelcoördinatie).


52

Transdyn

control groepering configuratie object beheer

Imtech

Actuator Actuator Actuator Actuator

Electron

1. 2. 3. 4.

ABB

Product eigenschap

OSI Soft.

Actuator Management

Ferranti


V V V V

V V V V

V V V V

V V V V

V V V V

V V V V

V V V

Transdyn

V

Imtech

Electron

ABB

V

V V V V V

V V V V V

Transdyn


V V V V V

V V

Imtech

Product eigenschap

V V V V V

V V

Electron


V V V V V

V V

ABB

Sensor data acquisitie Sensor^roepering Sensor configuratie Sensor object beheer Sensor toestandsinformatie

OSI Soft.

1. 2. 3. 4. 5.

V V

OSI Soft.

Product eigenschap

V V

Ferranti <

Sensor Management

V V

Ferranti

5. Actuator toestandsinformatie 6. Actuator historische informatie

V V

V V

G G

G G

V V

V V

N V V

N V V

N V V

N N N

V V V

V V V

Ad 1, 2, 3: ABB: Weergave Geografische data, anders dan bitmap, (vermoedelijk) niet ondersteund. Ad 1, 2, 3: Imtech: Weergave Geografische data, zowel vector- als bitmapkaarten, wordt ondersteund. Toepassing wordt momenteel echter alleen gebruikt voor zeekaarten.

G V

V V N V

Transdyn

V V G V

Imtech

Verkeersbeheersing (VB)-object beheer VB-object gebruik SUT beheer Storingsmelding beheer

Electron

1. 2. 3. 4.

OSI Soft.

Product eigenschap

aav

Applicatie besturing: Business logic laag

Ferranti

Ad 3: Ferranti geeft aan dat RTAP GDF niet ondersteunt.

V V G V

V V V V

V V V V

Ad 3: Ferranti geeft aan dat RTAP taak- en werkplekoverdracht nietondersteunt Ad 3: ABB: Taakbeheer op basis van standaard Windows (inlog) functies 3.4.6

Specifieke eigenschappen

Ferranti

Het SCADA systeem Real-Time Application Platform (RTAP) is een suite van producten. De kern van het systeem is het RTAP Real-time Database, ontworpen door de Canadese firma Verano. De Real-time Database bevat


53

RTAP's Calculation Engine, Data Historian, en Alarm Detector. PLC's, DCS'en en RTU's worden bewaakt en bestuurd door de RTAP Scan System, hetgeen ook een Verano product is. Het Scan System is een verzameling van scan-tasks, dat verbindingen kan maken met PLC's via de Allen-Bradley DH+, Modbus, AbNetScan, OPC, HP 3852A, Siemens H1, en VXI standaarden. Andere delen van het RTAP suite zijn afkomstig van Ferranti Computer Systems uit Antwerpen. Deze houden in een Event Manager, de RTAP API, Distribution Services (via ActiveX of OBDC), en de RTAP Configurator en Scripting Tools. De HMI (RTAP Visualiser) biedt de mogelijkheden om schematics, alarm notification, trend displays, een report builder, en control panels te maken en te gebruiken. Naast Ferranti en Verano, is de RTAP suite te krijgen van Hewlett Packard voor de Unix en Windows NT platforms. In Nederland is RTAP veel gebruikt voor Utilities. Voorbeelden van klanten zijn o.a. Amsterdam Airport Schiphol (voor pijpleidingen), Rotterdam Rijn Pijpleidingmaatschappij, Nuon (electriciteit, gas en water), ENECO Energie Delfland, Westland Energie, Defensie Pijplijn Organisatie, Amylum, VDAB, Essent, BASF, Vandemoortele, en Rotterdam Antwerpen Pijpleiding. Momenteel zijn er weinig ITS voorbeelden. RTAP is operationeel binnen MONICA, maar in verband met een verhoging van de licentiekosten bij upgrading wordt nagedacht over een vervanging van RTAP door een maatwerk database functie. De RTAP Visualiser is gebruikt om GIS-achtige beelden te maken op regionaal en stedelijk niveau, zoals in het Nuon SCADA systeem voor de gasdistributie. Verano is druk bezig met het lanceren van een Internet-enabled versie, RTAP//, met web services en ondersteuning voor Java en web browsers. Ferranti's en Verano's vertegenwoordiger in Nederland is Nijkerk. OSI software De kern van de producten van OSI-software is een real-time database die gebruikt wordt voor de representatie van de actuele situatie. De gegevens kunnen van een groot aantal soorten bronnen ingewonnen worden: PLC's, DCS-en, andere SCADA pakketten, handmatige invoer en klantspecifieke interfaces. De database is schaalbaar. Andere kernfuncties zijn validatie, opslag en distributie op basis van publish-subscribe of push mechanisme. De andere modules zijn gericht op het verstrekken van informatie, hetzij aan gebruikers hetzij aan andere toepassingen. Het product is nog niet toegepast in de ITS-markt, maar het heeft wel de potentie om daar gebruikt te kunnen worden.

Transdyn Dynac is een SCADA systeem, dat een redelijke installed base heeft in de Amerikaanse industrie ( > 150) en reeds is aangepast voor gebruik in (Amerikaanse) ITS toepassingen. ABB Industrial IT is een compleet pakket van industriële besturingscomponenten. Deze kunnen separaat worden gebruikt, maar doordat ze als integraal pakket ontwikkeld en op de markt gebracht worden, ontstaat een zekere afhankelijkheid, waarbij de aangeboden functies alleen optimaal tot hun recht komen als van het gehele pakket gebruik gemaakt wordt en niet slechts van een deel. Electron Electron richt zich voornamelijk op de energievoorziening en distributie. De besturing van energieproductie en distributiesystemen wordt gerealiseerd middels specifieke systemen. Deze systemen zijn gebaseerd op de standaarden


54

van de IEC werkgroep TC-57 (o.a. IEC 60870-5 en IEC 61850): Power System control and associated Communications, voorheen: Telecontrol, Teleprotection and Associated Telecommunications for Electric Power Systems. De systemen worden derhalve momenteel vaak nog aangeduid als Telecontrol systemen. Imtech Marine Unimacs bestrijkt drie lagen: MES, SCADA en PLC, die redelijk onafhankelijk van elkaar zijn, omdat ze van drie verschillende producenten afkomstig zijn. Het MES deel is een eigen Imtech product, gericht op het integrale scheepsmanagement (platform, navigatie en payload); Voor het SCADA deel wordt het product Cimplicity van Trimation toegepast Voor het PLC deel wordt onder andere Modicon van Schneider Electric gebruikt. Modicon heeft als opvallende eigenschappen: • Alle communicatie op basis van TCP/IP en ethernet, alhoewel ook nog veldbussen ondersteund worden; • De PLC bevat een (HTML) webserverten behoeve van onderhoud, waarmee alle onderhoudsgegevens vanaf elke locatie op het netwerk (of lokaal zelfs draadloos) bereikbaar zijn via een standaard webserver met login account. Imtech Marine heeft in tweede instantie (kort voor het uitbrengen van dit rapport) aangegeven, dat ze bij nader inzien geen activiteiten buiten hun 'corebusiness area' (scheepvaart en offshore) willen ondernemen. Voor verkeerssystemen verwijzen ze nu naar Imtech Industrie. 3.4.7

Bevindingen en Conclusie

SCADA/PLC combinaties hebben voldoende functionaliteit om het management van actuatoren en sensoren als onderdeel van een verkeerskundig management systeem te kunnen realiseren. SCADA en PLC's hebben bovendien een zeer grote 'installed' base en zijn volwassen producten. De toepassing van SCADA/PLC combinaties is een goede eerste stap van het migratietraject naar volledige COTS DVM systemen. Ten gevolge van het feit dat de markt vanuit softwarecomponenten ten behoeve van verkeersmanagement benaderd is, vormen de gevonden SCADA/PLC producten slechts een subset van de op de markt aanwezige SCADA/PLC systemen. Derhalve zijn de conclusies niet algemeen geldend voor alle SCADA pakketten en PLC's. Voor een dergelijke conclusie is verder onderzoek nodig, hetgeen ook reeds wordt uitgevoerd. SCADA/PLC combinaties voldoen in het algemeen aan vrijwel alle selectie criteria. Echter: • Niet alle SCADA systemen hebben GIS presentatie; • Niet alle SCADA systemen bieden SUT beheer en taak en werkplek overdracht in het bijzonder Mogelijk ondersteunen niet alle SCADA systemen regelscenario's en maatregelen. Daarentegen hebben veel SCADA systemen een scripttaal, wat zou kunnen dienen om regelscenario's en maatregelen te representeren, maar hier is meer onderzoek voor nodig.


55

ITS standaarden zijn niet standaard aanwezig in SCADA/PLC producten, maar door het generieke karakter van SCADA/PLC producten zijn ze daarin wel eenvoudig te implementeren. Telecontrol systemen zijn primair bedoeld voor de energievoorziening of zijn hiervan afgeleid. Daar een van de uitgangspunten van deze systemen is geweest: het veilig kunnen aansturen over slechte communicatielijnen, is de communicatie traag en beperkt, waardoor bijvoorbeeld het op afstand configureren van VMS actuatoren niet mogelijk is. Hierdoor zijn ze derhalve niet toepasbaar in de Nederlandse AVB situatie. De afbeelding van SCADA/PLC systemen op ACT, ziet er voor de onderzochte systemen als volgt uit:

WVL's

J

Beheerders

t

SCADA /

Presentatie

Business Logic - Control

ISUT

Sensoren

£

PLCs / DCSs

Figuur 8 : Afbeelding SCADA/PLC op ACT Bij de afbeelding zijn de volgende opmerkingen te maken: • Kenmerk van een SCADA/PLC combinatie is, dat deze nadrukkelijk uit twee delen meteen verschillend karakter bestaat, waartussen een kleine functionele overlap aanwezig kan zijn; • De dekking is niet voor alle producten hetzelfde. Zo heeft Imtech (Cimplicity/Modicon) de volledige gewenste functionaliteit van de SUT component, terwijl ABB wel vergelijkbare functionaliteit heeft, maar deze sluit niet aan bij het gewenste gebruik; • De Business Logic functionaliteit kan bij enkele SCADA pakketten worden ingevuld middels scripttalen, of dit voldoet aan de gebruikerswensen moet middels verder onderzoek nog worden vastgesteld.


56

3.5 Device Drivers 3.5.1

Inleiding

In het kader van de werkgroep Convenant UniversaI Roadside System, is een systeem met een aantal losse "device drivers" ontwikkeld, welke zouden kunnen worden gezien als de implementatie van CoSensor en CoActuator. Conform het ontwerpuitgangspunt van ACT, zijn dit geen generieke componenten, maar zijn ze sensor of actuator specifiek. De werkroep Convenant UniversaI Roadside System is echter tijdens de looptijd van het Match project ontbonden en deze product categorie is dus in feite achterhaald. 3.5.2 Producten De volgende systemen zijn in voor de Shortlist fase geselecteerd. Leverancier

Product

Product type

Peek Traffic Peek Traffic

ITMS Traffic Box Sensor Traffic Box Actuator

DVM systeem Driver Driver

Wegens gebrek aan informatie kon het ITMS systeem van PeekTraffic niet volledig worden beoordeeld.

Product eigenschap 1. 2. 3. 4. 5. 6. 7. 8.


Ad 3: De functie van het bijhouden van de bedrijfsuren van een actuator is niet standaard voorzien. Deze functie kan echter wel worden. Ad 7: De TB AMS kent twee soorten van beheer die gescheiden Verkeerskundig (verkeersdata) en technisch (SNMP) Ad 8: De functie van het bijhouden van de beschikbaarheid van actuator is niet standaard voorzien. Deze functie kan echter wel worden.


57

TB-SS

Functioneel

TB- AMS

3.5.3 Selectiecriteria

V G G V G

V G G V G

sensor of toegevoegd zijn: een sensor of toegevoegd

1. 2. 3. 4.


TB-SS

Product eigenschap

TB-AMS


V G

V G



Niet Functioneel: Product interface Product eigenschap 1. Uitbreiding Interface 2. Pluriforme Interface 3. Meerdere protocollen 4. Redundante I/O 5. Sensor interface voor andere producten 6. Sensor interface door andere producten 7. Actuator interface voor andere producten 8. Actuator interface door andere producten 9. VicNet Communicatie 10. Locale bediening^ 11. ITS standaarden


58

TB-SS

V V G V V V V

V V G V V V V

TB-SS

Modulaire opbouw Uitbreiding functionaliteit Leverancier onafhankelijkheid Schaalgrootte Schaaluitbreiding Verwerkingscapaciteit Verwerkingscapaciteit uitbreiding 3: in overleg met de leverancier

V V V V V V

V V V V V V

TB-SS

1. 2. 3. 4. 5. 6. 7. Ad

TB-AMS

Product eigenschap

TB - AMS


TB - AMS

Ad 4: Indien gebruik gemaakt wordt van een standaard netwerk of protocol koppeling. Hierin is echter nog niet voorzien

V V V V V V V V V

V V V V V V V V V

1. 2. 3. 4. 5. 6.

TB-SS

Product eigenschap

TB - AMS


V V V V V V

V V



Product eigenschap Sensor Sensor Sensor Sensor Sensor

V V V V V V

-

-

V V V V V


Sensor Management

1. 2. 3. 4. 5.

TB-SS

1. 2. 3. 4. 5. 6.

TB-SS

Product eigenschap

TB - AMS

Actuator Management

TB- AMS



Applicatie besturing: Presentatielaag en Business logic-laag: niet van toepassing 3.5.5 Bevindingen en Conclusies Bij de in het onderzoek gevonden Device Drivers ontbreekt een gemeenschappelijke interface definitie voor de interface naar de applicaties, in de vorm van een formele of defacto interface standaard. Tevens is de interface naar de hardware niet open, omdat het hier een proprietary hardware platform betreft. De gevonden 'Device Driver' producten zijn derhalve niet geschikt voor toepassing in de Nederlandse AVB situatie.


59

De afbeelding van de Device Drivers op ACT, ziet er voor de onderzochte producten als volgt uit: WVL's

Beheerders

TB-SS

Sensoren

Actuatoren

3.6 Actuator Management Systemen 3.6.1 Inleiding In deze paragraaf is een categorie van producten opgenomen voor het beheren van actuatoren voor verkeersbeheersing op snelwegen. De term actuator wordt hier als verzamelterm gebruikt voor DVM signaalgevers, zoals matrixborden, DRIPs, VRIs, slagbomen, kantelwalsen, gordijnborden, bruglichten, verschijnborden, dwangborden, geleidingslichten en in-car systemen. Een deel van de actuatoren kunnen slechts een beperkt en vooraf vast gedefinieerd aantal signalen aan weggebruikers geven. Configuratiebeheer van deze systemen vanuit een verkeerscentrale is beperkt. In de markt zien we een sterke opkomst van variable message sign (VMS) systemen. Een onderscheid met dynamic message signs (DMS) wordt hier niet gemaakt. Van een aantal VMS systemen zijn de tekst en grafische beelden op de schermen vrij programmeerbaar. Configuratiebeheer van deze systemen is uitgebreider dan voor vooraf gedefinieerde borden, bijvoorbeeld met functionaliteit om de beelden vanuit de centrale te modificeren. In ACT wordt deze uitgebreide configuratiebeheerfunctionaliteit in zijn algemeenheid vereist. Daarom is het marktonderzoek naar actuator management systemen voornamelijk gericht op de vrij programmeerbare dynamische borden zoals DRIP's. De meeste systemen voor beheer en bediening van actuator systemen worden projectmatig ontwikkeld op directe specificaties van opdrachtgevers. Voorbeelden van bedrijven die op deze wijze alleen maatoplossingen ontwikkelen zijn Dambach en Daktronics. Deze projecten of producten zijn geen COTS producten en zijn hier niet verder beschouwd.


60

Er zijn vier bedrijven gevonden die wel een COTS product ontwikkeld hebben voor het beheren van actuatoren, zoals DRIPs, matrixborden en kantelwalsen: • TRAffic Managment System TRAMS van Variable Message Signs UK Ltd. (VMS UK). MIDAS en RIGEL (zie appendix) worden beschouwd als modulen gekoppeld aan TRAMS in deze evaluatie. • Mercure van Securité & Signalisation (SES). De data monitoring en inwinsystemen van SIAT worden beschouwd als module gekoppeld aan Mercure in deze evaluatie. • Brimos Traffic Information System (BTIS) van Brimos, • Variable Message Signs (VMS) van Solari di Udine. TRAMS en Mercure kunnen ook verkeerskundige informatie inwinnen van diverse sensoren van de respectievelijke leveranciers zelf. Ook zijn er maatoplossingen beschikbaar uit eerdere projecten voor koppeling met producten van enkele andere leveranciers. TRAMS heeft ook een beperkte beheersfunctionaliteit voor het aanpassen van configuratieparameters van de sensoren. Een belangrijke reden om deze producten te groeperen is dat ze een gelijkaardige systeemarchitectuur kennen. Ze bestaan uit een front-endprocessor (FEP) in de verkeerscentrale, een controller langs de weg bij de VMS, en een communicatieverbinding. Een aantal leveranciers, zoals Swarco en Zelisko, levert wel de panelen en controllers maar geen management software, en die zijn hier eveneens niet beschouwd. 3.6.2 Gemeenschappelijke eigenschappen De geëvalueerde producten hebben een gemeenschappelijke systeem architectuur met een front-end-processor in de verkeerscentrale, een controller langs de wegkant, een paneel, en een communicatiesysteem. Deze architectuur is ontstaan doordat deze systemen veelal als add-on aan bestaande DVM systemen zijn toegevoegd, waarbij de systeemkoppeling in de centrale wordt gerealiseerd. De systemen zijn zowel stand-alone als in een netwerk in de verkeerscentrale inzetbaar. De netwerkinfrastructuur tussen verkeerscentrale en wegkantsystemen is niet overal geschikt voor het versturen van de tekstuele en grafische informatie voor een actuator. Dit probleem wordt vermeden door een aparte modem verbinding te gebruiken tussen FEP en controller. De controller draait daarbij onafhankelijk van het wegkantstation. Vanuit deze achtergrond gebruiken de leveranciers veelal eigen communicatieprotocollen, maar standaard protocollen zijn ook leverbaar (zie opmerkingen bij niet-functionele eisen: product interface). De systemen zijn daardoor wel geschikt om gebruik te kunnen maken van een vaste infrastructuur met wegkantstations. De functionaliteit van de producten voor actuator management is in grote lijnen vergelijkbaar. In alle systemen kunnen actuatoren manueel worden bediend en op afstand worden geconfigureerd en onderhouden. De gebruikersinterfaces zijn relatief eenvoudig en bieden weinig of geen functionaliteit voor andere verkeersbeheersingstaken. Sessie en taakbeheer worden niet ondersteund. De systemen zijn niet toegepast voor DVM op nationale schaal, en het is niet bekend of de producten voldoende schaalbaar zijn en voldoende verwerkingscapaciteit hebben.


61

Alle producten hebben een vergelijkbare functionaliteit voor storingsbeheer. De actuatoren en controllers genereren foutmeldingen voor bijvoorbeeld transmissie- en communicatiefouten, fouten in de displaysystemen (zoals pixel, led, paneel of lampfouten), stroomstoringen en -verbruik, en bedrijfstemperatuur. De status van de wegkantsystemen kan opgevraagd worden. Geen van de systemen kan echter statische informatie over de beschikbaarheid van de actuatoren leveren. Geen van de systemen kan ook historische informatie over werkelijk getoonde beelden rapporteren. Alleen van BTIS is bekend dat deze informatie wel wordt gelogd.


Verkeersmanagement Verkeerskundig configuratiebeheer Technisch systeembeheer Operator taakscheiding Operator taakoverdracht Functie taakscheiding Datalogging Beschikbaarheidsinformatie

Solari

1. 2. 3. 4. 5. 6. 7. 8.

BTIS

Product eigenschap

Mercure

Functioneel

TRAMS

De producten zijn geëvalueerd volgens de criteria en kwalificatiesymbolen (V, G, N, -) uit paragraaf 3.1. Van SES is geen ingevulde short list questionnaire terug ontvangen. Van BRIMOS is alleen de confirmatie van de questionnaire over ACT functionaliteit ontvangen. De questionnaires voor TRAMS, Solari en Brimos zijn bijgesteld voor de gemeenschappelijke interpretatie van de eisen met die in andere product categorieën.

G G G N N N G N

G G G N N N G N

G G G N N G G N

G G G N N N G N

Bij alle producten is de 'compliance' voor de functionaliteit beperkt tot de sensoren en actuatoren, en eenvoudige maatregelen voor het bedienen van actuatoren. In alle producten kunnen eenvoudige tijdplannen worden opgesteld en automatisch uitgevoerd voor actuator bediening. Een generiek mechanisme voor regelscenario's is in geen van de producten geïmplementeerd. TRAMS bevat een beperkt regelscenario mechanisme om bijvoorbeeld actuatoren te activeren bij een alarm van een detector. Mercure bevat een expert systeem om scenario's te definiëren voor locale 'events', of gebeurtenissen, maar hierover zijn geen verdere details bekend. Geen van de producten heeft taakbeheer waarin expliciete operator taken zijn gedefinieerd. Wel bieden ze gebruikersregistratie en autorisatie. ad 1. BTIS en Solari verwerken geen informatie uit sensoren en monitoren, en kunnen geen verkeersbeeld genereren, ad 3. Geen van de systemen kunnen informatie over de branduren van sensoren en actuatoren genereren, ad 6. BTIS implementeert een duidelijke functie scheiding tussen gebruik voor verkeersleiding en beheer. Dit is echter niet gekoppeld aan een taakbeheer.


62


N N V N

N N V N

V N V N

Solari

BTIS

1. 2. 3. 4.

Mercure

Product eigenschap

TRAMS


N V N


Solari

1. 2. 3. 4. 5. 6. 7.

BTIS

Product eigenschap

Mercure


TRAMS

Alle producten zijn alleen ontwikkeld voor PC's en Windows OS en niet integreerbaar als bedoeld in 4, anders dan via een netwerk verbinding en maatwerk interfaces. Alle producten gebruiken standaard databases en database koppelingen die wel integreerbaar zijn met andere producten. Voor zover er regelingen in de producten zijn, kunnen die niet extern worden benaderd of gekoppeld met regelingen uit andere producten. Het kunnen toevoegen van regelingen of maatregelen in het product wordt niet als integreerbaar beschouwd.

N V N N N N N

N V N N N N N

G V N N N N N

N V N N N N N



63

Solari

1. 2. 3. 4. 5. 6. 7.

BTIS

Product eigenschap

Mercure

Niet Functioneel: Product ondersteuining

TRAMS

ad 1. Alleen BTIS maakt enkele grote softwaremodulen beschikbaar. De andere producten maken de softwaremodulen niet beschikbaar voor verdere ontwikkeling. Geen van de producten is ontwikkeld voor toepassing op nationale schaal. Het is niet bekend of de producten voldoende schaalbaar zijn en of de verwerkingscapaciteit voldoende is.

V N V V N V V

V N V V N N V

V N V V V N V

V V V V N V V

1. Uitbreiding Interface 2. Pluriforme Interface 3. Meerdere protocollen 4. Redundante I/O 5. Sensor interface voor andere producten 6. Sensor interface door andere producten 7. Actuator interface voor andere producten 8. Actuator interface door andere producten 9. VicNet Communicatie 10. Locale bediening 11. ITS standaarden

N N V N V V V V V V

V V

G N V V G V N

Solari

V V V N V V V V V V

BTIS

Mercure

Product eigenschap

TRAMS


N N N N N N V V N

BTIS

Solari

N N V V V V

N N V V N N

V V V V N N

N N N N

BTIS

Solari


Mercure

1. 2. 3. 4. 5. 6.

Mercure

Product eigenschap

TRAMS


TRAMS

ad 9. BTIS wordt standaard met eigen BopNet protocol geleverd, maar andere protocollen zijn ook mogelijk. Communicatie via TCP/IP en VicNet is mogelijk, maar nog niet eerder geïnstalleerd. De andere producten zijn of worden ontwikkeld voor TCP/IP, maar toepassing op VicNet is niet geïnstalleerd. ad 11. Niet alle ITS standaarden worden ondersteund: • TRAMS: NTCIP, UTMC, NCMS2 .Mercure: NTCIP, TEDI/LCR, ATM, LONWORKS

G N V V V N

G N V V V N

G V V V V V

V V V V V N


Actuator Management Product eigenschap 1. 2. 3. 4. 5. 6.



ad 1. TRAMS heeft wel elementaire logica voor prioritering van bedieningscommando's voor actuatoren, maar deze is alleen aanwezig in de verkeerscentrale en niet als beveiliging op de wegkantsystemen. Mercure en BTIS hebben deze elementaire logica niet.


64


V V V V V

Solari


BTIS

1. 2. 3. 4. 5.

Mercure

Product eigenschap

TRAMS

Sensor Management

-

-

Solari


BTIS

Product eigenschap

Mercure


TRAMS

Sensor management functionaliteit van Mercure is niet ingevuld.

G N

G N

G N

N N

N N V

N N N

N N N

N N N


Solari

1. 2. 3. 4.

BTIS

Product eigenschap

Mercure


TRAMS

ad 1. Interne beelden van verkeerscentrales kunnen in geen van de producten getoond worden. BTIS kan alleen de fysische actuatoren tonen op geografische kaarten.

G G G G

G G G G

G G G G

G G

ad 1. BTIS biedt alleen functionaliteit voor de beperkte maatregelen en de plannen voor maatregelen. TRAMS biedt daarnaast ook beperkte regelscenario functionaliteit. Mercure biedt iets meer functionaliteit voor scenario's dan TRAMS middels een ingebouwd expertsysteem. Solari biedt geen functionaliteit voor het definiëren van maatregelen zoals tijdplannen, maar biedt alleen functionaliteit voor het manueel bedienen van actuatoren. ad 2. TRAMS en BTIS kunnen geen verkeerstoestanden detecteren uit sensor en monitoring informatie, en kunnen daaruit ook geen gecoördineerde maatregelen genereren. Functionaliteit van Mercure is onvoldoende bekend. ad 3. TRAMS, BTIS en Solari hebben alleen gebruikersbeheer en autorisatie, maar hebben geen sessie- en taakbeheer. Formele taakoverdracht is daardoor ook niet mogelijk. Voor Mercure is dit waarschijnlijk hetzelfde. BTIS onderscheidt wel duidelijk de gebruikers naar functies van verkeersleiding en beheer.


65

ad 4. Storingsmeldingen zijn beperkt tot de regelingen, actuator en/of sensor functionaliteit van de producten. 3.6.5 Product specifieke eigenschappen De koppeling van de vier producten met overige DVM systemen ligt in de verkeerscentrale. Deze koppeling is echter niet volledig in de zin van de AVBAA. Bij systemen zoals BTIS en Solari wordt geen externe informatie ingewonnen en zijn er geen regelscenario's. De verkeersleider maakt de koppeling tussen monitoring en actuatorbediening. Wel kunnen vooraf gedefinieerde schema's voor actuatorbediening worden geëxecuteerd. TRAMS en Mercure daarentegen voeren wel informatie in van sensoren en monitoren om via eenvoudige scenario's en maatregelen actuatoren te kunnen bedienen. Voor de inwinning van verkeersinformatie kunnen beide producten worden gecombineerd met andere producten van zowel de leveranciers als van derden. Koppeling met sensoren of actuatoren van andere leveranciers vereisen Maatwerk made koppelingen die door de leveranciers van het management systemen moet worden ontwikkeld. Alleen systemen met standaard interfaces, zoals NTCIP, NMCS2, UTMC zijn in principe te koppelen met TRAMS of Mercure zonder maatwerk koppelingen. Alleen van BTIS en Solari is bekend dat logische groepen van actuatoren gedefinieerd en collectief bediend kunnen worden. In BTIS is een beheersfilosofie ontwikkeld met een duidelijke scheiding tussen bediening en configuratiebeheer. Nieuwe beelden worden door de configuratie beheerder geïnstalleerd op zowel het wegkantsysteem als in de verkeerscentrale, en gevalideerd met een unieke elektronische handtekening. Deze handtekening maakt het onmogelijk voor een verkeersleider om een nietgevalideerd beeld dat niet overeenkomt met de werkelijke beelden op de panelen te activeren. Alleen BTIS heeft een modulaire structuur die toegankelijk gemaakt wordt voor andere applicaties. De software van de andere producten is wel modulair maar er is geen public interface of API beschikbaar om deze modulen extern te koppelen. In BTIS wordt dit niet gerealiseerd door API's of een open communicatiestandaard tussen de modulen zoals gekozen in AVB-AA en ACT. De belangrijkste softwarecomponenten in de verkeerscentrale en langs de wegkant communiceren via databases. Een bericht tussen centrale en wegkantsysteem wordt verstuurd via het BopNet protocol. Lokaal wordt de inhoud van dit bericht weggeschreven in de locale database. Een locale applicatie 'pollt' de database op nieuwe relevante data, leest deze uit en verwerkt deze nieuwe data. Op deze wijze wordt integratie van software georganiseerd door standaard data base management systemen. Indien verschillende applicaties toegang hebben tot de gemeenschappelijke database, dan is geen directe communicatie tussen die applicaties zelf nodig. De ontwikkeling van een gemeenschappelijk communicatie protocol lijkt daardoor ook overbodig. Er is geen analyse gemaakt van de voor- en nadelen van deze benadering t.o.v. AVB-AA en een Corba middleware communicatie. Indien wordt uitgegaan van een landelijk gedistribueerde database, waarvan alle componenten gebruik kunnen maken, lijkt een gestandaardiseerde definitie voor de database structuur voldoende te zijn om informatie uit te kunnen wisselen tussen


66

softwarecomponenten van verschillende leveranciers. Indien XML wordt gebruikt voor data definitie en data-base toegang, dan kunnen transport, opslag, en communicatie transparant worden geïntegreerd. Een potentieel nadeel is dat iedere applicatie de databases moet pollen om nieuwe informatie uit andere applicaties te ontvangen. De frequentie van pollen wordt dan in grote mate bepalend voor de reactietijd van de component op veranderende data. Daarmee wordt de poll-frequentie potentieel een kritische en extra vertragende factor op het tijdsgedrag van het verkeersmanagement systeem. Een ander potentieel probleem kan zijn dat de betrouwbaarheid kritisch afhankelijk kan worden van de betrouwbaarheid van data base management systemen en de hardware voor data opslag. Hoewel een landelijk gedistribueerde database een schaalbare oplossing lijkt, is dit voor het BTIS systeem nog niet aangetoond. Nader onderzoek is dan ook aan te bevelen. 3.6.6

Bevindingen en conclusies

De marktverkenning naar actuator management systemen is vooral gericht op management systemen van vrij programmeerbare dynamische borden, omdat het configuratie beheer op afstand hiervoor essentieel is. De beschouwde producten kunnen echter ook gebruikt worden voor de bediening en het beheer van andere typen dynamische borden. De dekking van de vier producten met de ACT is weergegeven in onderstaande figuur. De functionaliteit van de producten is voornamelijk beperkt tot het beheer van actuatoren. Maatregelen bijvoorbeeld zijn beperkt tot de bediening van actuatoren. Alleen TRAMS en Mercure bieden ook enige functionaliteit voor het beheer van sensoren en definitie regelscenario's voor bediening van actuatoren. De architectuur van de producten is eenvoudig met een module in de verkeerscentrale die direct communiceert met de actuator controller langs de weg. Dit is in onderstaande figuur aangegeven door een scheiding (zwarte balk) van de componenten in de laag van de Business Logic - Verkeersbeheersing. De systemen kunnen echter ook geïntegreerd worden in complexere DVM architecturen met wegkantstations en een vast communicatie netwerk zoals VicNet. Nader onderzocht moet worden in hoeverre de functionaliteit van TRAMS, Mercure en Solari beperkt zijn door de gebruikte communicatie protocollen en wegkantstations, zoals TEDI en NMCS2.


67

WVL's

Beheerders

Technische Infrastructuur Architectuur vaor Yerkeersbeheertiég (TIAV)

1

71

% ,'£i

Sensoren

Figuur 9: AMS in ACT De functionaliteit van de software modulen in de verkeerscentrale is van alle vier producten zeer beperkt. TRAMS, Mercure en Solari zijn bovendien niet open en niet goed integreerbaar met andere producten in de verkeerscentrale. Waarschijnlijk is het eenvoudiger om de beperkte maatregelen en regelscenario's over te nemen in andere producten. Daardoor zijn deze producten onvoldoende geschikt voor AVB. Ook van BTIS is de DVM functionaliteit zeer beperkt. Door de modulaire structuur is het echter wel mogelijk om de GridServer en ScenarioServer te hergebruiken om de actuatoren vanuit de verkeerscentrale te bedienen en te beheren. De ScenarioServer leest en executeert tijdplannen voor actuator bediening via de GridServer, die de directe communicatie met de actuatoren verzorgt. Er zijn echter wel twee beperkingen op de integreerbaarheid in AVB: • BTIS gebruikt een eigen protocol om met de controller langs de weg (SchermPC) te communiceren. Dit zal vervangen moeten worden aan het communicatie protocol op VicNet+. • GridServer en ScenarioServer ontvangen informatie voor bediening en beheer vanuit de BTIS database en niet direct via een API. Via de database kunnen deze modulen eenvoudig met andere producten geïntegreerd worden maar niet via Corba zoals voorzien is in AVB. BTIS is ontwikkeld op basis van een architectuur waarin modulen met elkaar communiceren door gegevens uit te wisselen via gemeenschappelijke databases. Deze manier van communiceren is een alternatief voor communicatie via Corba zoals in AVB-AA. Standaardisatie van communicatie tussen componenten van verschillende leveranciers kan met de BTIS benadering in principe vereenvoudigd worden. Er zijn echter ook potentiële nadelen aan deze benadering. In dit project is geen verdere evaluatie en vergelijking met AVB gemaakt van deze benadering. Voor toepassing en integratie van BTIS


68

componenten met andere producten in AVB is nader onderzoek wel noodzakelijk. BTIS en Solari hebben geen softwarecomponenten op een wegkantstation. Aansluiting van de actuator controllers op wegkantstations en de TIAV valt buiten dit project. 3.7 Toolkits voor de presentatielaag 3.7.1 Inleiding ACT bevat een presentatielaag (PL). Ook al zijn er weinig details uit het ACT project bekend over de presentatielaag, de huidige praktijk leert dat een DVM systeem een sterk grafisch-georiënteerde gebruikersinterface moet hebben. Daarbij staan dynamisch kaarten en schematisch diagrammen van regionale gebieden en complex objecten zoals bruggen en tunnels centraal. Voor de gebruiker van een real-time systeem voor het bewaken van een geografisch-gedistribueerd proces - zoals in DVM - is het voor de algemene begripsvorming6 van de gebruiker bevorderlijk, om dynamisch gebeurtenissen symbolisch te tonen binnen het kader van een kaart of schematisch diagram. Nog belangrijker is het om de besturingsaangrijpingspunten van de gebruiker ook in te brengen binnen het kader van een kaart of schematisch diagram: men praat in dat geval over "direct manipulation" schermen. Om "cognitive overload" en "screen clutter" te voorkomen, wordt het aanbevolen om de gebruiker de mogelijkheid te geven om symbolen te verstoppen als ze op een bepaald moment niet belangrijk zijn. Bijvoorbeeld, als een wegverkeersleider een nieuwe boodschap op een DRIP wil plaatsen, dan is het handig als de gebruiker alle andere symbolen die andere soorten sensoren en actuatoren representeren tijdelijk onzichtbaar kan maken.

ire^ffireffiMBHïïi

Figuur 10.

6


Geografisch kaart opbouwen uit oleaten.

Ofwel zijn/haar "situation awareness", in militaire-operationeel terminologie.

69

Vanuit een ICT oogpunt, kan 'direct manipulation' en het aan- en uitzetten van soorten symbolen geïmplementeerd worden door middel van "oleaten". Elke oleaat is een doorzichtig beeld waarop symbolen voor één soort verkeerskundig object getoond kunnen worden, bijvoorbeeld alle lussen, alle DRIP's of alle tunnels. Een geografisch kaart of schematische presentatie wordt dan opgebouwd uit een stapel oleaten boven een geografische achtergrond (zie Figuur 10).

zji-î^r JMi

" " 'Wj.B

"""" =

Figuur 1 1 .

29

30 :

"

^îmwm* 32 33

35 36

~~

32U PO 4091 £470

38 _ 4 J

~

: 41

42

44 ; «5

4?

48

50

rs~T?~ö

; 6P5 FBIN BiUIT

51

"

'M]

'

03 14342 NOV00

Voorbeeld GIS-achtige presentatie met oleaten.

Geographical Information System (GIS) en Computer-Aided Design / Computer-Aided Manufacturing (CAD/CAM) systemen hebben de stapel van oleaten als centraal begrip. GIS systemen zijn speciaal ontworpen voor geografische en schematische toepassingen, zoals DVM. Een voorbeeld van een GIS-achtige presentatie met oleaten is te zien in Figuur 11. In dit geval gaat het om het Battlefield Management System (BMS) van de Koninklijke Landmacht. De BMS gebruiker kan oleaten aan- en uitzetten door middel van het klikken op de knopjes rechts boven. In Figuur 11 zijn de Situation Awareness (SA), Operations (Ops) en hindernissen (Hind) oleaten aan (blauwe stip binnen de knop), en de andere uit (witte stip). 3.7.2

Gemeenschappelijke eigenschappen

PL producten moeten een moderne GUI kunnen ondersteunen, met de bekende visuele schermobjecten zoals vensters, iconen, menu's en opties. Voor DVM doeleinden moeten ook grafieken getoond kunnen worden, zoals snelheid afgezet tegen afstand, intensiteit tegen tijd, e.d. Daarnaast moet een Geographical Information System (GlS)-achtige functionaliteit gemaakt kunnen worden. Moderne PL producten kunnen exact op maat worden gesneden om invulling te geven aan GIS presentaties, in tegenstelling tot oudere PL toolkits zoals DataViews en SL-GMS.


70

3.7.3 Producten De volgende producten zijn voor de Shortlist fase als PL toolkits geselecteerd: Leverancier

Product

ILOG Engenuity

Views & JViews JLOOX & JLOOXGIS

Product type PL toolkit PL toolkit

Kenmerken van de producten zijn als volgt: • ILOG Views is een set van C++ grafische software bibliotheken. Ze ondersteunen 2D grafische objecten en controls. Add-ons geven de mogelijkheid om charts en kaarten te presenteren, naast koppelen aan databronnen zoals databases en XML. ILOG JViews is de equivalente bibliotheek voor Java, en voegt mogelijkheden toe om workflowdiagrammen en Gantt charts te creëren. ILOG Views en JViews worden veel gebruikt voor wegen spoorwegverkeer, alsmede in luchtvaart, scheepvaart en ruimtevaart. ILOG JViews is gebruikt voor de implementatie van de VANESSA presentatielaag. • Engenuity's JLOOX is een grafische toolkit voor Java programmeurs. Het wordt gebruikt voor het visualiseren van datagrafieken, charting, topologieën en diagrammen. JLOOX ontwikkelt 100% Java softwarecomponenten volgens het Swing standaard en ondersteunt Scalable Vector Graphics (SVG). Alle JLOOX-gebaseerde toepassingen kunnen geïnstalleerd worden als stand-alone applicaties, applets of servlets. JLOOX is gebruikt in het PARADIGMA project. JLOOXGis is een JLOOX componenten set voor interactieve kaarten en schematische diagrammen, met raster- en vectordata volgens de Arclnfo, DTED, TeleAtlas, Navtech, en Shape formaten. De beoordelingen in deze paragraaf over ILOG Views & JViews zijn in overleg met ILOG tot stand gekomen, zoals voor alle shortlist producten. Van JLOOXGis is geen reactie ontvangen van Engenuity voor de opleveringsdatum van dit rapport. De lezer moet er rekening mee houden dat ons oordeel over JLOOXGis niet geverifieerd is bij de leverancier, er kunnen derhalve onjuistheden in staan. De punten waarover onvoldoende duidelijkheid bestaat zijn aangegeven m e t " ? " . 3.7.4 Selectie criteria

1. 2. 3. 4. 5. 6. 7. 8.


Engenuity

Product eigenschap

ILOG

Functioneel

-

-

De functionele eisen zijn niet van toepassing voor PL toolkits.


71

1. 2. 3. 4.


Engenuity

Product eigenschap

ILOG


V G

V G

PL toolkits zijn makkelijk te vervangen. Regelingen en database toegang zijn niet van toepassing.

Product eigenschap 1. 2. 3. 4. 5. 6. 7.


ILOG


V V V V V V V

Engenuity

Ad 4. ILOG geeft aan dat Views beperkt is tot C++ en Jviews tot Java toepassingen. Ad 4. Analoog aan ILOG zal JLOOX beperkt zijn tot Java toepassingen.

V V V V V ? ?

Product eigenschap 1. 2. 3. 4. 5. 6. 7.


ILOG

Niet Functioneel: Product ondersteuning

V V V N G -

Engenuity

Beide PL toolkits zijn modulair opgebouwd, gemakkelijk uit te breiden en kunnen de schaalgrootte aan. Het is onduidelijk hoe groot de verwerkingscapaciteit van JLOOX is.

V ? V ? ? -

Beide PL toolkits zijn COTS producten met ondersteuning in Europa. ILOG (J)Views heeft een grote installed base, maar het is onduidelijk hoe groot de installed base van JLOOX is. Ad 5. ILOG geeft aan dat er geen 1 e lijns ondersteuning voor (J)Views in Nederland is.


72

Product eigenschap

ILOG

Engenuity

Ad 6. ILOG geeft aan dat het mogelijk geen 10 jaar ondersteuning voor Views kan geven omdat de C++ taal in die periode misschien achterhaald wordt door Java.

1. Uitbreiding Interface 2. Pluriforme Interface 3. Meerdere protocollen 4. Redundante l/O 5. Sensor interface voor andere producten 6. Sensor interface door andere producten 7. Actuator interface voor andere producten 8. Actuator interface door andere producten 9. VicNet Communicatie 10. Locale bediening 11. ITS standaarden

G

G


Product eigenschap 1. 2. 3. 4. 5. 6.

Blokkeren van maatregelen Parameteriseren van maatregelen Scheiding beslissing en uitvoering Locale regelingen Real-time l/O Real-time regelingen

ILOG


V -

Engenuity

Sensor- en actuator-interface standaarden zijn niet van toepassing voor PL toolkits. Beide producten hebben een XML interface, maar ondersteunen geen ITS standaard (zoals NTCIP).

? -

Regelingen zijn niet van toepassing voor PL toolkits. ILOG (J)Views kan realtime inputs en outputs verwerken. Het is onduidelijk of JLOOX dat ook kan.

Product eigenschap

ILOG

Engenuity



-

-

Actuator Management

1. 2. 3. 4. 5. 6.


Actuator management is niet van toepassing voor PL toolkits.


73

1. 2. 3. 4. 5.



Engenuity

Product eigenschap

ILOG

Sensor Management

-

-

ILOG

Engenuity

Sensor management is niet van toepassing voor PL toolkits.

V V

V V

?

? ?

Applicatie besturing: Presentatie laag Product eigenschap 1. Visuele representaties 2. Geografische en/of schematische presentaties met 4000 objecten in 4 sec 3. GDF formaat 4. Video 5. Audio

G G

7

Beide PL toolkits kunnen kaarten en schematische diagrammen weergeven met voldoende snelheid. Het ziet er naar uit dat geen van beide data in GDF formaat kan importeren. ILOG (J)Views kan video en audio data gedeeltelijk verwerken. Voor JLOOXG is het onduidelijk of dit mogelijk is.

Product eigenschap

ILOG

Engenuity

Ad 5. ILOG geeft aan dat (J)Views beperkt is in het presenteren van video en audio data.


-

-


1. 2. 3. 4.

Business logic is niet van toepassing voor PL toolkits. 3.7.6


Logica heeft ILOG Views gebruikt voor prototyping van de VANESSA gebruikersinterface; zie Figuur 12.


74

m KOE».

"-,,,&

,•'.••'

W W M M U M K M «QMt- 1

:

Schiphol tunnel a *—

tJiïiX!l.f

~"

'** *•>

— •

«]„

Figuur 12.

1

WntÉ

*9

CO

|_— •£-__;.

"•"" O

•••#

•€

"O

uk

_

\,f

Screendump van VANESSA PL prototype.

3.7.7 Conclusies Alle SCADA systemen en totaaloplossingen bieden Human-Machine Interfaces (HMI's) waarmee schematisch diagrammen, grafieken, en andere GUI functionaliteit weergegeven kan worden. Enkele SCADA systemen (b.v. Trimation, Electron, en Transdyn) bieden ook GIS-achtige functionaliteiten in de vorm van een additioneel product van een third-party leverancier. Van Transdyn is het bekend dat de GIS functionaliteit een ESRI product is. De meerderheid van de totaaloplossingen bieden GIS-achtig functionaliteiten. Bentley en Trinité bieden hun eigen GIS. IBI Group en M l Services bieden GIS producten van ESRI. Alleen CCT en Harris bieden geen GIS-achtige presentatiemogelijkheden. In een situatie waar een DVM systeem wordt geïmplementeerd op basis van een SCADA systeem of een totaaloplossing dat geen GIS-achtige functionaliteit biedt, is een PL toolkit een mogelijke oplossing. Het blijkt dat beide PL toolkits op de shortlist aan alle PL-gerelateerde eisen kunnen voldoen. Verder zijn beide toolkits gebruikt voor prototyping van PL'en van Nederlands DVM systemen.

3.8 Totaaloplossingen voor DVM 3.8.1 Inleiding Totaaloplossingen zijn producten die als uitgangspunt hebben dat ze het gehele scala van functionaliteiten uit de Applicatie Architectuur implementeren. Met andere woorden, een totaaloplossing vult de basis SCADA functionaliteit aan met BL, AMS en PL functionaliteit. Het streefdoel van de leverancier is, dat de gebruikersorganisatie de totaaloplossing niet hoeft te combineren met andere producten. De klant hoeft maar één product te kiezen. Het voordeel voor de klant is dat het systeemintegratieprobleem gedelegeerd wordt aan de leverancier. Nadelen zijn:


75

•

•

De klant kan niet de optimale implementatie van iedere functionaliteit in een DVM systeem kiezen, maar moet één product kiezen dat sterke maar vooral ook zwakke plekken kent; en Eén leverancier heeft een grote invloed op het soepel opereren van de gebruikers organisatie. De organisatie heeft bijvoorbeeld een groot probleem als de leverancier failliet gaat

3.8.2 Gemeenschappelijk eigenschappen Van een totaaloplossing mag in principe verwacht worden dat deze volledige DVM functionaliteit biedt, niet alleen binnen verkeerscentrales, maar ook langs de weg en alles daartussen, ln de praktijk, hebben totaaloplossingen een ontwerpgeschiedenis doorgemaakt, waardoor de nadruk op een bepaald deel van de totale functionaliteit ligt. Vaak ligt de nadruk op functionaliteit binnen de verkeerscentrale. Bijvoorbeeld, de leverancier Bentley is sterk in het management van geografisch-gedistribueerde resources (of - in DVM termen - objecten), zoals (militaire) vliegvelden en kazernes. Van oorsprong is de kernfunctionaliteit van Bentley's producten een database van configuratie- en toestand-gegevens voor resources en onderdelen daarvan, gekoppeld met een GIS presentatielaag. In de loop der tijd is Bentley's productlijn ontwikkeld tot (o.a.) een Advanced Trafffic Management System (ATMS), maarte verwachten valt dat de resource database en GIS presentatie het sterkste onderdeel daarvan vormen. Vergelijkbare processen zijn te vinden bij andere producten. Bijvoorbeeld, de oorsprong van de producten Command & Control Toolkit (CCTK) en OS/Comet als een BL toolkit is merkbaar. Alleen Delcan's TCSS, IBI Group's ATMS, AVE's MAVE®-Sys en Ml Services' TransActive kunnen van begin af aan worden gezien als "echte" totaaloplossingen. 3.8.3 Producten De producten zijn geëvalueerd volgens de criteria en kwalificatiesymbolen (V, G, N,-) uit paragraaf 3.1. De volgende producten zijn voor de Shortlist fase als totaaloplossingen geselecteerd: Leverancier

Product

AVE Bentley CCT Delcan Harris IBI M l Services Open Roads Inc. Trinité

MAVE®-Sys GeoTransport ATMS CCTK TCSS OS/Comet ATMS & ADCS TransActive Open TMS PDA

Product type Totaaloplossing Totaaloplossing Totaaloplossing Totaaloplossing Totaaloplossing Totaaloplossing Totaaloplossing Totaaloplossing Totaaloplossing

Kenmerken van de producten zijn als volgt: • MAVE®-Sys is een op CORBA gebaseerd gedistribueerd verkeersmanagementsysteem in een verkeerscentrale en (Duitse) onderstations, dat is gekoppeld aan wegkantsystemen via de Duitse standaarden MARZ en TLS. Het product is nog in ontwikkeling en de


76

beoogde afronding is medio 2003. De eisen zijn ingevuld voor het beoogde eindproduct. Eisen die momenteel nog niet zijn gepland zijn niet meegenomen, ook al zou de functionaliteit gedurende de ontwikkeling eventueel toegevoegd kunnen worden. Bentley's GeoTransport ATMS is een verzameling'modules die onderling communiceren via een kernmodule: de Message Server. De Operator Client biedt GUI faciliteiten aan de gebruikers. Verder zijn er Maintainer, Plug-ins, Device Drivers, Incident Management, Schedule Server, en Archiver Server modules en een Developer's Kit. CCT's Command & Control Toolkit (CCTK) is afkomstig van het aerospace domein, en tot nu toe zijn er geen operationele ITS installaties. CCTK heeft een aantal ingebouwde hulpmiddelen, namelijk de Display Editor, Data Monitor, Data Retrieval, en een verzameling Utilities (voor configuratie, data opslag, remote data server, en simulatie). Verder is er een aantal "addo n " producten, namelijk de Developer's Kit, API's, en External Interfaces. Delcan's Traffic Control and Surveillance System (TCSS) is een complete ATMS oplossing, met daarin (o.a.) AID, incident management, en sensor management functionaliteit. De kern is een Real-Time Database (RTDB), waaraan worden gekoppeld GUI, AID, Alarm/Event Management, Traffic Response Plan Management, Equipment Interface Management, en System Management modules. Harris' OS/Comet is afkomstig uit de aerospace, defensie en telecommunicatie netwerk management domeinen. Tot nu toe zijn er geen operationele ITS installaties. De kern is OS/Comet's Data Distribution module, waaraan worden gekoppeld de User Interface, (scripting) Language Processing, Recording & Logging, Command & Telemetry, Operations Automation, en Simulation modules. IBI Group's Advanced Traffic Management Software (ATMS) en Advanced Device Control Software (ADCS) vormen een geheel. ATMS is een suite van modules voor diverse ITS functionaliteiten die zorgen voor event, file en reistijd management. ADCS is een verzameling van modules voor bewaking en besturing van sensoren en actuatoren. ADCS is bedoeld als een integraal onderdeel van ATMS, maar kan ook apart geleverd worden. De ATMS/ADCS modules zijn de SCADA, GUI, Remote Weather Information System (RWIS), Vehicle Detection Station (VDS), Emergency Roadside Telephone (ERT), Camera Control (CC), Dynamic Message Signs (DMS), Lane Control Signs / Variable Speed Limit Signs (LCS / VSLS), Incident and Queue Detection (IQ), Travel Time (TT), Event Manager (EM), Response Manager (RM), Centre-to-Centre (C2C), en Broadcast. M l Services' TransActive is een suite van modules van diverse ITS technologieën door middel van een open systems architectuur. Alle modules interacteren via een Core module gebaseerd op CORBA. Een Facilities Viewer geeft SCADA schematisch displays, en een Map Viewer gebaseerd op ESRI producten (Arclnfo en Spatial Display Engine) geeft een GIS presentatie voor kaarten. Sensoren en actuatoren worden bewaakt en bestuurd door middel van de CCTV Control, Video Control, Traffic Detection, Emergency Telephone, en Traffic Signal Control modules. Alarm Management, Incident Detection Integration, Traffic Statistics, Message Communication, Network Monitor, en Region Manager modules bieden beslissingondersteuning. Een Incident Management Plan Module zorgt voor de business logic. Open Roads Open TMS bestaat uit een user interface met een aantal server subsystemen, elk met een eigen specifieke functionaliteit, zoals VMS of Highway Advisory Radio (HAR). De communicatie tussen clients en servers is gebaseerd op CORBA.


77

•

Trinité's Programmable Distributed Architecture (PDA) is in ontwikkeling voor Verkeerscentrale Noord Holland. De kern van het PDA is de Dynamic Subscription Software (DSS) middleware laag. Business logic wordt ondersteund door het Integrated Management Concept (IMC), dat Programmable Information Elements (PIE's) implementeert. Een presentatielaag is geïmplementeerd als het Event presentatie & Logging System (ELTRIS) en het Visualisatie System (V-TRIS).

1. 2. 3. 4. 5. 6. 7. 8.

Verkeersmanagement Verkeerskundig configuratiebeh. Technisch systeembeheer Operator taakscheiding Operator taakoverdracht Functie taakscheiding Datalogging Beschikbaarheids informatie

V V G G G V V G

V V V V V V

V V

V V G V N G V N

V V V V V V V V

V V V V V V V V

V V V G V V V V

V V V V V V V G

V V G V V V V G

Trinité

Open Roads

IBI

Harris

Delcan

CCT

Bentley

Product eigenschap

MAVE

Functioneel

Ml Services


G G G N N N V V

Deze tabel laat zien dat alle totaaloplossingen een aantal functionele eigenschappen gemeen hebben. Alle totaaloplossingen bieden volledig verkeersmanagement, verkeerskundig configuratiebeheer, en data logging. Ad 1, 2 & 3. Trinité geeft aan dat PDA sterk leunt op bestaande DVM systemen, zoals MONICA. Ad 3. MAVE heeft geen informatie over de bedrijfsuren van sensoren en actuatoren. Ad 3. CCTK is een product uit het aerospace domein. Daarom is het niet optimaal voor technisch systeembeheer in het DVM domein. Ad 4. MAVE kan wel taken scheiden naar gebruikers en gebruikersgroepen, maar dat wordt niet expliciet geregistreerd of toegewezen per gebruiker. Ad 4. IBI Group geeft aan dat slechts één ATMS gebruiker tegelijk een taak kan uitvoeren. Meekijken is niet mogelijk. Ad 4, 5 & 6. Trinité heeft geen documentatie of demonstratie gegeven waarin SUT-beheer functionaliteit te zien is. Ad 5. MAVE kan geen taken expliciet overdragen naar andere gebruikers. Ad 5. CCT geeft aan dat CCTK taak- en werkplekoverdracht niet ondersteunt. Ad 6. CCT geeft aan dat CCTK de scheiding tussen verkeersmanagement en configuratiebeheer ondersteunt, maarniet het technisch systeem beheer. Ad 8. MAVE biedt alleen de beschikbaarheidsinformatie op basis van informatie uit TLS. Ad 8. CCT geeft aan dat CCTK geen functionaliteit biedt voor beschikbaarheids informatie. Ad 8. Ml Services geeft aan dat TransActive beperkte functionaliteit biedt voor beschikbaarheids informatie. Ad 8. Open Roads biedt alleen de beschikbaarheids informatie op basis van

analyse van logging data.


78

MAVE

Bentley

CCT

Delcan

Harris

IBI

Ml Services

Open Roads

Trinité

\ Product eigenschap Vervangen gebruikersinterface Integratie regelingen Integratie databases Integratie producten

V V V G

V V V V

V V V

V V V V

V V

V V V N

V V V V

V V V V

V G V G


1. 2. 3. 4.

Deze tabel geeft aan dat alle totaaloplossingen het mogelijk maken om de gebruikersinterface te vervangen. Alle totaaloplossingen behalve Harris' OS/Comet kunnen ook samenwerken met andere databases. Het komt weinig voor dat de regelscenario's en maatregelen vervangen kunnen worden.

Bentley

CCT

Delcan

Harris

IBI

Ml Services

Open Roads

8. Modulaire opbouw 9. Uitbreiding functionaliteit 10. Leverancier onafhankelijkheid 11. Schaalgrootte 12. Schaaluitbreiding 13. Verwerkingscapaciteit 14. Verwerkingscapaciteit uitbreiding

V V V G G G G

V V V V V ? ?

V V V V V V V

V V G V V V V

G G V V V V V

V V V V V V V

V V G V V V G

V V V V V V V


Behalve Harris' OS/Comet kennen alle totaaloplossingen een modulaire opbouw, wat uitbreiding van hun functionaliteit mogelijk maakt. Minstens drie leveranciers hebben opgemerkt dat schaalgrootte, verwerkingscapaciteit en mogelijkheid tot uitbreiding afhankelijk zijn van hardware, netwerk en load balancing. Ad 1, 2. Harris geeft aan dat OS/Comet niet volledig modulair is, maar niet waarom. Ad 3. Delcan geeft aan dat TCSS deels leverancier afhankelijk is. Ad 3. M l Services geeft aan dat TransActive deels leverancier afhankelijk is. Ad 4 t/m 8. Trinité heeft tot nu toe maar twee installaties van PDA geïmplementeerd. Het is te vroeg om te kunnen bepalen of PDA de


79

Trinité

Product eigenschap

MAVE

Ad 2. Trinité geeft aan dat PDA sterk leunt op bestaande DVM systemen, zoals MONICA. Het PIE concept is beperkt v.w.b. het representeren van sequenties van acties, zoals maatregelen en traffic plans. Terwijl regelscenario's als PIE's gerepresenteerd kunnen worden, zijn maatregelen in MONICA opgenomen. Ad 4. MAVE is voor een groot deel ontwikkeld in C++ en integratie is als zodanig gebonden aan deze taal en ontwikkelomgeving. De GUI's zijn ontwikkeld in JAVA. Ad 4. IBI Group geeft aan dat ATMS platform-, operating system-, en programmeertaal afhankelijk is. Ad 4. Trinité geeft aan dat PDA volledig in C++ geschreven is (en draait op Unix systemen). Dit betekent dat integratie van andere producten via C++ code plaats moet vinden.

V V V ? 7 7 7

CCT

Delcan

Harris

IBI

Ml Services

Open Roads

Trinité

schaalgrootte, verwerkingscapaciteit en uitbreidingsmogelijkheden aan kan om het hele snelwegennette kunnen bewaken en besturen. Ad 7. M l Services geeft aan dat TransActive wel de verwerkingscapaciteit ondersteunen kan, maar de uitbreiding slechts gedeeltelijk.

V V V V

V N V V V V V

V V N N V V

V V V N V V

V N G V G V V

V N N N V V

V G V V V V

Product eigenschap COTS Grote Installed base Ruime Installed base Product ondersteuning Product service Product lifecycle Onderhoud op afstand

Bentley

1. 2. 3. 4. 5. 6. 7.

MAVE

Niet Functioneel: Product ondersteuning

G N N V G V V

V G V V V V

Geen van de totaaloplossingen heeft een grote installed base. De best verkochte totaaloplossing telt maar 30 operationele installaties. Alle totaaloplossingen ondersteunen een product lifecycle vani O-jaar en bieden de mogelijkheid om onderhoud op afstand te doen. Ad 3. Bentley geeft aan dat GeoTransport ATMS zes operationele installaties

heeft.

Product eigenschap

MAVE

Bentley

CCT

Delcan

Harris

IBI

Ml Services

Open Roads

Trinité

Ad 3. M l Services geeft aan dat TransActive een ruime installed base zou hebben voor eind 2002. Ad 3. Open Roads geeft aan dat Open TMS twee operationele installaties heeft. Ad 3. Trinité geeft aan dat er maar twee operationele PDA installaties zijn. Ad 4, 5. Harris geeft aan dat ze, op dit moment, geen Europese partner hebben, maar dat ze dit zouden regelen als het tot een opdracht zou komen. Ad 5. IBI Group geeft aan dat er, op dit moment, geen 1e lijns ondersteuning in Nederland is voor ATMS. Ad 5. M l Services geeft aan dat TransActive's 1e lijns onderhoud in Nederland op dit moment beperkt is.

1. Uitbreiding Interface 2. Pluriforme Interface 3. Meerdere protocollen 4. Redundante I/O 5. Sensor interface voor andere prod. 6. Sensor interface door andere prod 7. Actuator int. voor andere prod. 8. Actuator int. door andere prod. 9. VicNet Communicatie 10. Locale bediening 11. ITS standaarden

V V G G V V V V N G



V V V V V V V V N N V


V V V G V V V V V V V

V V V V V V V G G

V V V G V V V V V N V




80

Alle totaaloplossingen bieden de mogelijkheid om sensor data en actuator commando's te sturen naar en inwinnen van andere producten. Een ruime meerderheid heeft een range van protocollen beschikbaar, en ondersteunt meerdere types hardware input/output. De meeste totaaloplossingen kunnen communiceren via TCP/IP, maar slechts een paar voldoen aan ITS standaarden, zoals NTCIP, OCIT en UTMC.

IBI

Ml Services

Open Roads

Trinité

Ad 3 , 1 1 . MAVE ondersteunt alleen Duitse standaarden MARZ en TLS. Ad 4. Dit is gedeeltelijk beschikbaar in MAVE, afhankelijk van de kenmerken en eisen. Ad 4. IBI Group geeft aan dat in de verkeerscentrale ATMS redundant kan zijn en ook dat sensoren redundant kunnen zijn, maar er is geen ondersteuning voor redundante communicatie tussen sensoren en de verkeerscentrale. Ad 9, 10. Delcan geeft aan dat TCSS geen TCP/IP verbindingen heeft en gedecentraliseerde operaties niet kan ondersteunen. Ad 10. M l Services geeft aan dat TransActive ontworpen is voor verkeerscentrales, en niet voor gedecentraliseerde operaties. Ad 10. Open Roads geeft aan dat Open TMS ontworpen is voor verkeerscentrales, en niet voor gedecentraliseerde operaties. Ad 11. Bentley geeft aan dat GeoTransport ATMS een deel van de NTCIP standaarden ondersteunt. Ad 11. CCT geeft aan dat CCTK puur XML ondersteunt, maar geen ITS standaarden (ook niet Traffic XML). Ad 11. Harris geeft aan dat OS/Comet geen ITS standaarden ondersteunt, ook puur XML niet. Ad 11. M l Services geeft aan dat TransActive ITS standaarden gedeeltelijk ondersteunt. Ad 11. Trinité geeft aan, dat PDA ITS standaarden niet ondersteunt, en ook puur XML niet.

V V V V V V

V V G G V V

G V V V V V

G G V V V V

N N V N V N

G V V V V V

Harris

V V V V V V

Delcan


CCT

1. 2. 3. 4. 5. 6.

Bentley

Product eigenschap

MAVE


V V V V V

V V V V V

v v

Alle totaaloplossingen ondersteunen real-time input/output, en alle behalve Bentley's GeoTransport ATMS ondersteunen real-time regelingen. Ad 1, 2, 4 & 6. Bentley geeft aan dat het GeoTransport ATMS product regelscenario's en maatregelen niet ondersteunt, maar Gensym's G2 expert systeem kan gekoppeld worden voor deze doeleinden. Ad 1. CCT geeft aan dat andere onderdelen van CCTK scripts kunnen initiëren, maar niet kunnen blokkeren. Ad 1. Open Roads geeft aan dat andere onderdelen Open TMS maatregelen

kunnen blokkeren op basis van prioriteit. Ad 1 & 2. Trinité geeft aan dat maatregelen in MONICA zijn opgenomen. Ad 3, 4. Ml Services geeft aan dat TransActive ontworpen is voor verkeerscentrales, en niet voor gedecentraliseerde operaties. Beslissing en uitvoering gebeuren in de verkeerscentrale, en er zijn geen locale regelingen.


81

V V V V

G V V V V G

G V G V V G

V V V G V V

G V G V

V G

V V V V V V

Trinité

G V V V V V

Open Roads

? ?

IBI

G V V V V V

Harris


Delcan


CCT

1. 2. 3. 4. 5. 6.

Bentley

Product eigenschap

MAVE

Actuator Management

Ml Services


G V V V V V

Alle totaaloplossingen kennen beperkingen in het managen van actuatoren. Vooral maatregel coördinatie op actuatorniveau wordt niet ondersteund. Ad 1. MAVE heeft geen basis logica voor prioritering van actuator commando's in de actuator componenten. Ad 1, 2. Bentley moet nog intern informeren over coördinatie en groepering op actuatorniveau. Ad 1. CCT geeft aan dat CCTK geen basis logica voor maatregel coördinatie biedt op actuatorniveau. Ad 1. Delcan geeft aan dat TCSS geen basis logica voor maatregel coördinatie biedt op actuatorniveau. Ad 1. Harris geeft aan dat OS/Comet geen basis logica voor maatregel coördinatie biedt op actuatorniveau. Ad 1. M l Services geeft aan dat TransActive wel een safety interlock checker heeft, maar geen basis logica voor maatregel coördinatie op actuatorniveau biedt. Ad 1. Trinité geeft aan dat zijn BL is gebaseerd op PIE's dat moeilijk lijsten kan representeren. Dus is het minder geschikt voor maatregelcoördinatie, zowel op maatregel niveau als op actuatorniveau. Ad 3. Harris geeft aan dat OS/Comet geen functionaliteit voor het definiëren van teksten en beelden op DRIPS panelen biedt. Ad 3. M l Services geeft aan dat TransActive beperkte functionaliteit biedt voor het definiëren van teksten en beelden op DRIPS panelen. Ad 4. IBI Group geeft aan dat Windows NT's Cluster Manager gebruikt is voor het managen van softwareobjecten, niet voor ATMS zelf. Ad 6. Delcan geeft aan dat TCSS wel historisch event rapporten kan archiveren, maar geen bit-mapped grafische elementen, foto's, of video. Ad 6. Harris geeft aan dat OS/Comet historische informatie over commando's presenteren kan, maar geen informatie over teksten en beelden op DRIPS panelen. Ad 6. M l Services geeft aan dat TransActive geen historische informatie over teksten en beelden op DRIPS panelen presenteren kan.

1. Sensor data acquisitie


82

V

V

I—

arris

CO

slcan

>ntley

AVE

Product eigenschap

u

o

X

CQ

V

V

V

V

"O (Ö

o cc c 0) n.

: >

O

V

V

inité

I Serv ce

t/l

Sensor Management

V

2. 3. 4. 5.

Sensor Sensor Sensor Sensor

groepering configuratie object beheer toestandsinformatie

V V V V

V V V V

V V V V

V V V V

V V V V

V V G V

V G V V

V V V V

V V V V

Alle totaaloplossingen kunnen sensordata inwinnen en toestandsinformatie beschikbaar maken. Een ruime meerderheid kan sensordata aggregeren en configuratie en sensorobject beheer ondersteunen.

Delcan

Harris

IBI

Open Roads

Trinité

G V

V V

G V

G V

v G

V V

V V

N N N

N V V

V N N

V G G

V V V

V V V

G V V


Bentley

Product eigenschap

MAVE


G G

V

N N N

V

7

7 7

Ml Services

CCT

Ad 3. M l Services geeft aan dat de functionaliteit van TransActive voor het zetten van sensor hardware parameters beperkt is, maar volledig voor andere soorten sensor parameters. Ad 4. IBI Group geeft aan dat Windows NT's Cluster Manager is gebruikt voor het managen van software objecten, niet ATMS zelf.

Alle totaaloplossingen bieden een visuele representatie van een geografisch gebied, in kaartvorm of in schematische vorm. Representeren van objecten en de taakverdeling binnen een verkeerscentrale wordt minder ondersteund. Er is geen totaaloplossing die aan alle eisen voldoet. Ad 1. MAVE kan geen verkeerscentrales e.d. presenteren. Ad 1. CCT geeft aan dat CCTK beperkt is tot bit-maps, en geen vectordiagrammen kan representeren. Ad 1. Harris geeft aan dat OS/Comet geografische presentaties maar gedeeltelijk kan ondersteunen. Ad 1. IBI Group geeft aan dat ATMS alle visuele representaties kan ondersteunen, behalve representatie van de configuratie binnen een verkeerscentrale. Ad 2. MAVE presentaties zijn afhankelijk van hardware en complexiteit van de objecten. Ad 2. Ml Services geeft aan dat TransActive's Map Viewer gebaseerd is op ESRI's Arclnfo GIS database en Spatial Data Engine een beperkte prestatie heeft. Ad 3. CCT geeft aan dat CCTK het GDF formaat niet ondersteunt. Ad 3. Delcan geeft aan dat TCSS het GDF formaat niet ondersteunt. Ad 3. Trinité geeft aan dat PDA het GDF formaat maar gedeeltelijk kan ondersteunen. Het is onduidelijk wat ontbreekt. Ad 4, 5. Bentley moet nog intern informeren over presenteren van video en audio data. Ad 4, 5. CCT geeft aan dat CCTK geen video of audio data kan presenteren. Ad 4, 5. Harris geeft aan dat OS/Comet geen video of audio data kan presenteren.


83

MAVE

Bentley

CCT

Delcan

Harris

IBI

Ml Services

Open Roads

Trinité

Ad 4, 5. IBI Group geeft aan dat ATMS geen video of audio data kan presenteren, maar er zijn wel producten van derden beschikbaar.

V

V

V

V

V

V

G

V

G

V G V

V V V

G N V

V V V

V V V

V G V

V V G

V N N

G N V

Applicatie besturing: Business logic laag Product eigenschap 1. Verkeersbeheersing (VB)-object beheer 2. VB-object gebruik 3. SUT beheer 4. Storingsmelding beheer

Alle totaaloplossingen ondersteunen storingsmelding beheer, en een ruime meerderheid ondersteunt VB-objectbeheer. Weinig totaaloplossingen kunnen SUT beheer volledig ondersteunen. Vooral taak- en werkplekoverdracht is een gebrek. Ad 1. Ml Services geeft aan dat TransActive's Plan Subsystem regelscenario's en maatregelen maar gedeeltelijk in een database kan opslaan. Ad 1 & 2. Trinité geeft aan dat in MONICA maatregelen worden gerepresenteerd. Ad 2. CCT geeft aan dat de Tcl-gebaseerde scripts in CCTK aan en uit gezet kunnen worden. Ze kunnen echter niet geïnitieerd worden door verkeerssituaties en ze kunnen ook geen maatregelen initiëren. Maatregelcoördinatie wordt ook niet ondersteund. Ad 3. MAVE kent geen sessies, maar wel gebruikers, gebruikersgroepen en taken. Taakoverdracht is momenteel nog niet voorzien. Ad 3. CCT geeft aan dat SUT-beheer in zijn geheel ontbreekt. Ad 3. IBI Group geeft aan dat ATMS taak- en werkplekoverdracht niet kan ondersteunen. Ad 3. Trinité heeft geen documentatie of demonstratie gegeven waarin SUTbeheer functionaliteit te zien is. Ad 4. Ml Services geeft aan dat TransActive een beperkte functionaliteit voor storingsmelding beheer heeft. 3.8.6


Bepaalde totaaloplossingen hebben sterke delen vanwege hun geschiedenis. Bentley's GeoTransport ATMS is sterk in de GIS presentatie en resourcemanagement. CCT's Command & Control Toolkit en Harris' OS/Comet zijn sterk in BL functionaliteit. Slechts één totaaloplossing is volledig gebaseerd op CORBA: M l Services' TransActive ATMS. Ml Services merkt op, dat CORBA niet zo snel is als een native protocol, maar dat het wel acceptabel is. Voordelen van CORBA zijn volgens MI Services: een vereenvoudiging van de softwarearchitectuur en redundante input/output. Verder maakt CORBA "plug-and-play" makkelijker te implementeren. MAVE gebruikt CORBA alleen in de verkeerscentrale en onderstations. CCT en Open Roads gebruiken CORBA alleen in de verkeerscentrale. In dit verband is het wel interessant te noemen dat de BL toolkit SCL/eSCL + RIMS van ICS gebruik maakt van CORBA binnen de centrale, maar dat er een gebruiker is die wil dat CORBA verwijderd wordt omdat de licentiekosten te hoog zijn. Trinité vindt dat er een gebrek in


84

ondersteuning van CORBA is voor het publish-subscribe-notify mechanisme, maar het kan zijn dat Trinité een wat verouderd beeld van CORBA heeft. MAVE is gebaseerd op de Duitse standaarden (MARZ, TLS) en infrastructuur. De communicatie naarde wegkantstations (Streckenstationen), sensoren en actuatoren is beperkt (zie hoofdstuk 4.2.4), waardoor de CORBA softwarelaag niet doorgetrokken kan worden en alle complexe verkeersregelingen in de verkeerscentrales en onderstations (in Duitsland, niet vergelijkbaar met de Nederlandse onderstations) moeten draaien. In discussie met de leveranciers van de totaaloplossingen hebben we geïdentificeerd dat verschillende landen een verschillend aantal niveaus in hun nationale DVM systeem kennen. Bijvoorbeeld, in de VS is het National ITS Architecture gebaseerd op slechts twee niveaus: "center" en "field". Zie meestlinkse beeld in Figuur 13. Daarom praat men over "center-to-center" en "center-to-field" protocollen in de NTCIP standaard. De meerderheid van de totaaloplossingen ondersteunt alleen een tweeniveau DVM systeem, en biedt daarom geen functionaliteit voor decentralisatie en locale regelingen (apart van de locale regelingen in de sensoren en actuatoren). De nieuwe AVB architectuur is gebaseerd op drie niveaus: verkeerscentrales, Universele Wegkant Stations (UWKS), en leverancierspecifieke detectorstations en actuatoren7. Zie de tweede afbeelding van links in Figuur 13. M l Services' TransActive ATMS kan een tweeniveau DVM systeem ondersteunen.

"Center"

"Field" USA

Figuur 13.

Nederland (& rest Australia)

Duitsland

New South Wales, Australia

Verschillende niveaus in nationale D V M systemen.

In Duitsland is het landelijk DVM systeem gebaseerd op vier niveaus: een verkeerscentrale niveau, een "field" niveau, en twee niveaus daartussenin met Unterzentralen en Streckenstationen. Zie de tweede afbeelding van rechts in Figuur 13. AVE's MAVE product is ontworpen voor installatie in

7

Het Landelijk Verkeers Management Centrum (TIC) is niet betrokken bij operationele

wegverkeersleiding.


85

verkeerscentrales en Unterzentralen, van waaruit de sensoren en actuatoren via Streckenstationen worden bewaakt en bestuurd. In New South Wales in Australië is er ook een vierniveau DVM systeem. Het verschil met Duitsland is dat er geen twee tussennivéaus zijn, maar twee niveaus in verkeerscentrales. Zie de meest rechtse afbeelding in Figuur 13. Tactische verkeerscentrales richten zich op incidentmanagement op de locatie van de gebeurtenis, en de strategische verkeerscentrale houdt zich bezig met het oplossen van congestie over een breed gebied. Ml Services' TransActive ATMS kan ook dit vierniveau DVM systeem implementeren. Een aantal totaaloplossingen biedt additionele functionaliteit boven hetgeen geëist door AVB-AA en ACT. Bijvoorbeeld CCT, Delcan en Harris bieden een simulatiemodule als standaard onderdeel van hun product. Webgebaseerde toegang is sterk in opkomst, meestal voorlopig geïmplementeerd in aparte applicaties gekoppeld via bestaande API's. Volledig webgebaseerde bewaking en besturing is verder ontwikkeld in aerospace en defensietoepassingen. Alarmering van mobiele mensen (meestal beheerders) door middel van SMS berichten of paging ("piepers") is ook een interessante mogelijkheid. 3.8.7 Conclusies Er is geen allerbeste totaaloplossing, ledere totaaloplossing kent een of meerdere ontbrekende functionaliteiten. M l Services' TransActive, IBI Group's ATMS (inclusief ADCS), en Delcan's TCSS bieden de meeste functionaliteit. Alle totaaloplossingen hebben een kernfunctionaliteit, waaraan (eventueel additionele) modules gekoppeld kunnen worden. De kernfunctionaliteit heeft de kenmerken van een real-time database met een bijbehorend protocol voor input en output van data. De kern kan Real-Time Database, Dynamic Subscription Software, of Message Server genoemd worden, afhankelijk van de benadering van de leverancier. Alle totaaloplossingen zijn breed qua functionele ondersteuning. Een uitzondering is Trinité's PDA, wat nog steeds in ontwikkeling is. Weinig totaaloplossingen kunnen een volledig SUT-beheer bieden, zoals in de selectie criteria en eisen. Vaak ontbreekt taak- en werkplekoverdracht in totaaloplossingen, zoals voor sommige SCADA/PLC systemen Drie producten zijn gebaseerd op CORBA, waarvan alleen M l Services' TransActive ATMS CORBA doortrekt naar de wegkantstations. In vergelijking met SCADA/PLC systemen, zijn totaaloplossingen minder open voor wat betreft interfacing naar sensoren en actuatoren. De device-driver aanpak komt vaker voor. Dit zou additionele beheerskosten betekenen, want iedere keer dat een nieuwe type sensor of actuator gekoppeld moet worden, moet een nieuwe device driver ontwikkeld worden. Voor SCADA/PLC systemen met zijn defacto (alhoewel proprietary) interfacing standaarden is dit vaak niet nodig. Ml Services' TransActive kan wel OPC ondersteunen. Sommige totaaloplossingen bieden additioneel functionaliteit, zoals simulatie. Totaaloplossingen hebben als voordeel dat de gebruikersorganisatie niet belast hoeft te worden met het integratie probleem. "One-stop shopping" kan hier toegepast worden. Bijbehorende nadelen zijn dat de gebruikersorganisatie niet


86

de meest optimaal implementatie van iedere functionaliteit kan kiezen en afhankelijk van één grote leverancier is. 3.9 VANESSA 3.9.1 Inleiding In deze wordt ingegaan op VANESSA (Verkeerscentrale Algemeen Nieuw Eenvoudig Sturing Systeem Aanpassing). Het systeem wordt ontwikkeld door Directie Noord-Holiand in opdracht van het Hoofdkantoor van RWS. In deze paragraaf wordt zowel de aanduiding VANESSA 1.0 en VANESSA gebruikt. VANESSA 1.0 wordt gebruikt voor de versie die nu in ontwikkeling is. VANESSA wordt gebruikt als het eigenschappen van het systeem betreft die versieonafhankelijk zijn. In een enkel geval wordt gerefereerd aan het project VANESSA. Dit project realiseert VANESSA 1.0. Historie Het project VANESSA is eind '98 begin '99 ontstaan. De consequenties van DVM voor de verkeerscentrales zijn voor het eerst via het project Blauwdruk RVMC gedocumenteerd. Voortbouwend op de resultaten van de Blauwdruk is, na een aantal voorstudies, besloten het systeem VANESSA 1.0 te ontwikkelen. De ingezette ontwikkeling wordt gekenmerkt door het vervangen van de bestaande architectuur van de huidige individuele DVM-systeemapplicaties door een lagenarchitectuur waarin bewaking en bediening (presentatie), datacommunicatie (distributie) en de verkeersmanagement applicatie ieder hun eigen systeemlaag gaan krijgen. Met VANESSA 1.0 worden de presentatie- en de distributielaag in hun eerste versie ontwikkeld. Daarnaast worden de nodige aanpassingen uitgevoerd in de bestaande systemen (in de verkeersmanagementlaag) om deze in te passen in de nieuwe architectuur. Consequentie van dit ingeslagen pad is dat RWS niet langer een individuele verkeersmanagement applicatie kan (laten) ontwikkelen, maar dat de verkeersmanagement functionaliteit als passende bouwblokken in de op dat moment beschikbare architectuur moet worden ingepast. Hiermee stelt RWS zich actief op als Systeem Integrator van het DVM -systemen complex. Met deze verandering zullen ook de relaties met de industrieën die actief zijn op het gebied van DVM (ontwikkelende ICT-industrie, bouwende industrie en installateurs) aan veranderingen onderhevig zijn. Vervolgtraject DVM is in Nederland nog volop in ontwikkeling. Met projecten als "Top Level Integratie" en Architectuur voor VerkeersBeheersing is een toekomstperspectief van de systeemarchitectuur neergezet dat daar op middellange en lange termijn invulling aan moet geven. VANESSA 1.0 is een eerste stap naar een invoering van integraal DVM zoals dat voor de lange termijn gezien wordt. Hoofddoelstellingen van het systeem Het project VANESSA is aangevangen vanuit drie primaire doelstellingen, te weten: 1. Verbeteren van de bedienbaarheid van de systemen in de Regionale Verkeersmanagementcentrales; 2. Verbeteren van de beheerbaarheid van de systemen in de Regionale Verkeersmanagementcentrales; 3. Het definiëren van een architectuur die de migratie naar toekomstige architectuurvormen van DVM faciliteert.


87

3.9.2 Globaal ontwerp VANESSA is opgedeeld in clusters. De volgende clusters worden onderkend: 1. PL : Presentatielaag 2. 3. 4. 5. 6. 7. 8. 9.

DML: Distributie Management Laag CMC: Centrale Management en Coördinatie CBO : Centrale Bediening Objecten VMM : Verkeersmanagement A U D : Audiocommunicatie V I D : Videodistributie B E H : Beheer INF: Informatiesystemen VANESSA 1.0 PL

OC

Presentatielaaq |INF | Distributie Laag

DML

Voor de aansluiting van een cluster op de distributielaag is, is een (1) interface definitie ontwikkeld. De communicatie in een cluster wordt overgelaten aan het cluster. Als in het vervolg van deze paragraaf de term presentatielaag gebruikt wordt dan wordt het cluster PL bedoeld.

3.9.3 Selectiecriteria VANESSA is opgebouwd uit clusters. Deze clusters zijn niet zonder meer in te zetten als aparte producten, hetgeen niet betekent dat zij niet vervangbaar zijn. De reden hierachter is dat VANESSA het begrip Informatie Element heeft geïntroduceerd dat in elke laag bekend moet zijn. De betekenis van het IE ligt vast in het cluster. De bedienmogelijkheden en de representatie ervan in de Presentatielaag, de koppeling met autorisaties e.d. in de Distributie Laag, de configuratie ervan ligt in handen van het cluster Beheer. Op deze manier zijn de lagen op zo'n manier met elkaar verbonden dat zij niet los van elkaar gezien kunnen worden. Een uitzondering hierop is het cluster PL, dat met relatief eenvoudige aanpassingen apart inzetbaar. Derhalve is VANESSA als geheel beoordeeld. Er is wel een minimale configuratie denkbaar bestaande uit de clusters : PL, CMC, DML en BEH.


VANESSA 1.0 is nog in ontwikkeling. Hierdoor is het niet mogelijk gebleken om alle punten te beoordelen.

Functioneel Product eigenschap 1. 2. 3. 4. 5. 6. 7. 8.

Verkeersmanagement Verkeerskundig configuratiebeheer Technisch systeembeheer Operator taakscheiding Operator taakoverdracht Functie taakscheiding Datalogging Beschikbaarheidsinformatie

G G V V V V V N

In VANESSA 1.0 bevat het cluster V M M slechts drie systemen: SPS , CDMS en MONICA. Van het laatste systeem worden de gegevens wel in de DML opgenomen maar niet gepresenteerd. In VANESSA wordt beheer en verkeer gescheiden, mits de aangesloten systemen dat ondersteunen. Verkeerkeerskundig configuratiebeheer is beperkt opgenomen en heeft alleen betrekking op alarmen. VANESSA 1.0 biedt geen configuratiebeheer voor de systemen in het VMM-cluster omdat verondersteld wordt dat dit behoort tot het cluster.

Niet Functioneel: Product integratie Product eigenschap 1. 2. 3. 4.


G ? 7

In VANESSA 1.0 zijn een aantal operating systems en middleware producten voorgeschreven. Ook om een vermindering van de beheerslast te bereiken. Er is geen harde garantie dat productspecifieke eigenschappen niet gebruikt worden. Als gevolg hiervan zijn deze producten niet zonder meer vervangbaar. Als RDBMS wordt Oracle voorgeschreven. Voor middleware wordt Corba 2.3 met als implementatie lona voorgeschreven.

Niet Functioneel: Product performance Product eigenschap 1. 2. 3. 4. 5. 6. 7.



V 7 7 7 7 7

ad 1, VANESSA 1.0 is modulair opgebouwd maar de modules zijn dermate grote delen dat cluster het juiste woord is. VANESSA zegt niets over de wijze waarop clusters opgebouwd moeten worden. Ad 2, VANESSA is een infrastructurele basis. Het krijgt de functionaliteit door de Informatie Elementen, de bedienmogelijkheden en de autorisatiefaciliteiten. Ad 3, De clusters zijn in opdracht van RWS ontwikkeld. RWS is eveneens eigenaar van de clusters en daarmee verantwoordelijk voor het beheer en onderhoud. Hoe onafhankelijk RWS is van de partijen die de clusters hebben ontwikkeld kan pas beoordeeld worden wanneer het onderhoud geregeld is. Vanuit het project en de toekomstig operationeel beheerder wordt wel op onafhankelijkheid gestuurd. Ad 4, VANESSA 1.0 is bedoeld voor centrales met minimaal 2 en maximaal 12 lessenaars. Ad 5, De distributielaag is configureerbaar en schaalbaar opgezet. Er zijn geen maximale eisen gesteld. Ad 6, De verwerkingscapaciteit in VANESSA 1.0 is te meten aan de performance eisen t.a.v. hoeveelheden en grootte van de Informatie-elementen en de verwerkingssnelheden ervan. VANESSA 1.0 is gericht op de verwerking van 50.000 dynamische en 50.000 statische informatie-elementen. Dynamische informatie-elementen zijn gerelateerd aan zaken die snel van waarde kunnen wisselen. Statische informatie elementen worden meer gebruikt voor configuratieaspecten.



7

N N 7 7 7 7

VANESSA 1.0 is in ontwikkeling. Het operationeel beheer is belegd bij RWSMD. Het functioneel beheer is nog niet belegd. Er zijn minimaal zes implementaties gepland. Er zijn nog geen onderhoudscontracten afgesloten, het project VANESSA levert de voorlopige productondersteuning.


90

Niet Functioneel: Product interface Product eigenschap 1. Uitbreiding Interface 2. Pluriforme Interface 3. Meerdere protocollen 4. Redundante I/O 5. Sensor interface voor andere producten 6. Sensor interface door andere producten 7. Actuator interface voor andere producten 8. Actuator interface door andere producten 9. VicNet Communicatie 10. Locale bediening 11. ITS standaarden

V D N V -

VANESSA is niet bedoeld om de communicatie met sensoren en actuatoren te verzorgen, dit wordt overgelaten aan de systemen binnen het cluster CBO en V M M . VANESSA kent de volgende soorten interfaces: • Interface met andere VANESSA systemen, beoogd om centrale - centrale communicatie te bewerkstelligen, echter niet in VANESSA 1.0 gerealiseerd; • Een interface met niet VANESSA systemen, beoogd om niet VANESSA systemen aan te kunnen sluiten t.b.v. uitwisseling gegevens, onbekend of dit in VANESSA 1.0 wordt gerealiseerd; • Een SNMP interface voor het cluster beheer, beoogd om SNMP te ondersteunen wordt gerealiseerd in VANESSA 1.0.

Niet Functioneel: Product regelingen Product eigenschap 1. 2. 3. 4. 5. 6.


-

VANESSA is in beginsel verkeersarm en biedt alleen infrastructurele faciliteiten. 3.9.4 Afbeelding op ACT

Actuator Management Product eigenschap 1. 2. 3. 4. 5. 6.




91

G G G

VANESSA kent het begrip actuator niet. Door de juiste configuratie van VANESSA kunnen wel actuatoren gerepresenteerd worden door de definitie in informatie-elementen. Door in de definitie de eigenschappen van een actuator vast te leggen zijn bovengenoemde zaken wel beschikbaar.

Sensor Management Product eigenschap 1. 2. 3. 4. 5.



G G G

Zie uitleg bij Actuator Management.

Applicatie besturing: Presentatie laag Product eigenschap 1. Visuele representaties 2. Geografische en/of schematische presentaties met 4000 objecten in 4 sec 3. GDF formaat 4. Video 5. Audio

V G ? G G

Voor de PL is een styleguide en een bibliotheek van iconen aangelegd. Deze is voldoende voor VANESSA 1.0. VANESSA 1.0 kent mogelijkheden voor grafische en schematische presentaties, deze dienen echter per implementatie te worden opgebouwd. Bedienen van audio- en videokanalen kan wel via de presentatielaag maar de daadwerkelijke communicatie en presentatie gaat buiten de presentatielaag om. Overigens kunnen er aanvullende technieken voor videobesturing gebruikt worden waarbij het wel lijkt alsof deze geïntegreerd zijn. Ondersteuning van GDF is niet geëist, evenmin als het aantal informatie elelementen dat getoond moet kunnen worden. Wel zijn er performance eisen opgenomen t.a.v. de snelheid van presentatie en response.

Applicatie besturing: Business logic laag Product eigenschap 1. 2. 3. 4.


N N V V

VANESSA 1.0 levert naast storingbeheer, ook faciliteiten voor alarmafhandeling. Het functioneel gedrag van verkeersmanagementsystemen bevat echter veelal een degradatiemechanisme gebaseerd op


92

storingsmeldingen. VANESSA 1.0 is er op gericht om de storingen en alarmen te splitsen en te routeren. Dit betekent dat storingsmeldingen die van belang zijn voor andere verkeersmanagementsystemen onderling gedeeld moeten kunnen worden en dat de storingsmeldingen aangeboden worden aan het clusterbeheer. Sessie, user en taakbeheer is ver uitgewerkt in VANESSA 1.0. De Sessiecomponent welke onderkend is in ACT is in VANESSA 1.0 ondergebracht in het cluster CMC. 3.9.5 Product specifieke eigenschappen VANESSA 1.0 biedt faciliteiten die het product onderscheidt van veel van de op de markt verkrijgbare oplossingen: 1. Taakbeheer; 2. Taakoverdracht;

3. Werkplekoverdracht; 4. Aansluitmogelijkheden voor nieuwe en bestaande systemen.

3.9.6 Aandachtspunten VANESSA is bedoeld voor invulling van de 'hogere lagen' van de applicaties. VANESSA is een ontwikkeling van RWS en is gebaseerd op de wensen en de verschillende manieren waarop de werkprocessen in de centrales zijn ingericht. VANESSA 1.0 is in ontwikkeling en heeft zich dus nog niet bewezen. Aandachtspunten voor de verdere ontwikkeling en aansluiting van systemen op VANESSA 1.0 zijn: •

• •

•

• • •

De performance eisen t.a.v. aantallen informatie-elementen zijn beperkt. Voor het aansluiten van een nieuw systeem dient zorgvuldig te worden nagedacht over het aantal informatie-elementen en de grootte daarvan. De eerste performance tests laten zien dat er nog ruimte is t.a.v. de eisen. Verkeerskundige configuratie van de systemen is niet opgenomen. Het kan zinvol zijn om de huidige user-interfaces naast de VANESSA interface te laten bestaan als fallback-scenario maar dit brengt meer onderhoud met zich mee. De beschikbaarheidseisen komen in een aantal gevallen niet overeen met hetgeen wat men nu gewend is. In een aantal wijzigingsvoorstellen wordt dit rechtgetrokken. Een nieuw aan te sluiten systeem kan de keten echter even sterk houden of verzwakken. VANESSA 1.0 biedt geen faciliteiten voor het overdragen van de bediening aan andere centrales. Voor de beheerinterface van een systeem kan worden gekozen om deze niet onder de presentatielaag te plaatsen. De backup-restore functionaliteit van VANESSA is niet geschikt voor de backup-restore faciliteiten van de aangesloten systemen.

3.9.7 Stand van zaken Het systeem VANESSA 1.0 is in ontwikkeling. Afronding van het project wordt verwacht in de eerste helft van 2003. Daarop zijn de beoogde implementaties in de diverse centrales gepland. Het systeem VANESSA 1.0 zal, in tegenstelling tot de eerste ambitie, een beperkt aantal DVM-systemen aansluiten. Er zijn wel wensen geuit bij de RD's om ook andere DVM-systemen aan te sluiten, wil VANESSA 1.0 een toegevoegde waarde bieden.


93

De DVM-systemen gebaseerd op AVB zullen eveneens aangesloten worden op VANESSA. 3.9.8 Vergelijkbare ontwikkelingen Nederland is niet het enige land waar een dergelijke ontwikkeling plaatsvindt. Voor de verkeerscentrale voor Antwerpen wordt een vergelijkbare oplossing gerealiseerd voor (Nederlandse begrippen) een kleinere verkeerscentrale.

3.10 Bevindingen 3.10.1 Algemene Bevindingen

Benamingen Alhoewel er wel een aantal producten is gevonden in de categorie "Actuator Management Systeem", welke worden aangeduid als 'VMS systeem', zijn geen overeenkomstige producten gevonden voor het "Sensor Management Systeem". De benamingen "Actuator Management Systeem" en "Sensor Management Systeem" zijn tijdens het onderzoek niet als product aangetroffen, met een uitzondering: het Sensor Management Systeem van Imtech. Dit betrof echter slechts een protocol converter tussen de (maritieme) NMEA en MITS protocollen. Ook zijn er op overeenkomstige wijze geen producten gevonden die door de leverancier zijn ingedeeld in de categorie: Application Control.

Corba Slechts een kleine minderheid van de gevonden producten maakt gebruik van Corba en dan nog slechts alleen binnen de verkeerscentrale. Doorgaans wordt gebruik gemaakt van alternatieve technologieën (zoals: messaging, shared dataspaces, datapool en shared database). Uit de contacten met de marktpartijen blijkt dat er weinig ervaringen zijn met het gebruik van middleware in I.T.S.-systemen. De ervaringen die er zijn met Corba zijn niet overtuigend. Om diverse redenen is terughoudendheid geboden voor het toepassen van deze toch relatief nieuwe technologie. De aanbeveling is om vanuit de behoefte te bepalen of dit middel werkelijk nodig is.

Databases Bijna alle non-real time relationele databases maken gebruik van Oracle. Systeem integratie Zeker bij de leveranciers, die voornamelijk aan de industriële markt leveren, is een trend waar te nemen naar een integrale levering van producten. Onder meer van leveranciers op de Petrotech beurs werd vernomen, dat hun afnemers steeds meer overgaan op "One stop shopping", met als doel de systeemintegratie problematiek uit te besteden, door een leverancier eindverantwoordelijk te maken voor de integratie van producten uit een multivendor omgeving. Binnen Rijkswaterstaat daarentegen is momenteel een trend waar te nemen in tegengestelde richting, waarbij Rijkswaterstaat zich juist zelf gaat profileren als systeemintegrator.


94

3.10.2 MES model De in de markt aangetroffen producten hebben een harde koppeling tussen hard- en software. Deze situatie is niet compliant met de AVB architectuur, waarbij het scheidingsvlak tussen TIAV en AA ergens in de PLC laag ligt. 3.10.3 BL Toolkits Bij deze producten moet (nog steeds) erg veel zelf gedefinieerd worden. Dit is eveneens nodig omdat er informatie uit verschillende geografische gebieden moet worden ingebracht (PL toolkits) of een verschillende verkeerskundige aanpak (BL toolkits). In feite is dit min of meer waar voor alle categorieën van producten. De functiescheiding die in ACT is ingevoerd in de BL (Business Logic), wordt ook door de markt herkend. De invulling daarvan gebeurt op verschillende manieren. Het is zinvol om deze functiescheiding te gebruiken als toetscriteria bij productselectie Het is onvoldoende duidelijk welke maatregelen en regelscenario's er zijn en hoe en in welke datastructuur deze beschreven dan wel gepresenteerd worden 3.10.4 SCADA/PLC producten SCADA en PLC producten, voldoen niet aan een bepaalde algemene standaard, maar vormen door hun ontwikkeling en grote wereldwijde 'installed base' van een beperkt aantal PLC leveranciers, een defacto standaard, waarbij voor elk SCADA pakket drivers te verkrijgen zijn voor vrijwel elk type PLC. Doordat de meeste PLC's tevens ook programmeerbaar zijn volgens dezelfde standaard (IEC 61131-3) ontstaat er een uitwisselbaarheid op hardware en applicatieniveau. PLC/SCADA combinaties voldoen in het algemeen aan vrijwel alle selectie criteria. Echter: • Niet alle SCADA systemen hebben GIS presentatie; • Niet alle SCADA systemen ondersteunen regelscenario's en maatregelen. Daarentegen hebben veel SCADA systemen een scripttaal, wat zou kunnen dienen om regelscenario's en maatregelen te representeren, maar hier is meer onderzoek voor nodig. • Niet alle SCADA systemen bieden SUT beheer en taak en werkplekoverdracht in het bijzonder SCADA/PLC als totaaloplossing is niet haalbaar, op SCADA/PLC gebaseerde oplossingen kunnen echter zorg dragen voor lokale toepassingen, inwinning, validatie en distributie van gegevens en commando's. Opgemerkt moet worden dat bij toepassing van SCADA en PLC systemen de verkeerskundige functionaliteit voor een groot deel geïmplementeerd dient te worden. Telecontrolsystemen zijn bedoeld voor de Energievoorziening of zijn hiervan afgeleid. Daar een van de uitgangspunten van deze systemen is geweest: het veilig kunnen aansturen over slechte communicatielijnen, is de communicatie traag en beperkt, waardoor bijvoorbeeld het op afstand configureren van VMS


95

actuatoren niet mogelijk is. Hierdoor zijn ze derhalve niet toepasbaar in de Nederlandse AVB situatie 3.10.5 Dedicated device drivers Slechts een leverancier levert een tweetal producten die qua omvang als ACT componenten zouden kunnen worden opgevat. Het gaat hier om 'device drivers', die tussen sensor of actuator en applicaties kunnen worden toegepast op een specifiek wegkantplatform; de Traffic Box, waardoor de interface naar de hardware proprietary is. De componenten zijn echter ook niet voorzien van een gestandaardiseerde interface naar de applicaties. 3.10.6 VMS De VMS systemen vormen een ontwikkeling als toevoeging op (bestaande) DVM systemen, waarbij de koppeling tussen het DVM systeem en het VMS systeem in de centrale wordt gerealiseerd, in de meeste gevallen via de verkeersleider. De VMS systemen zijn onderling vergelijkbaar en bestaan doorgaans uit twee delen, een besturings applicatie ('controller') langs de weg en een beheerapplicatie in de centrale, waarbij de toegepaste interface tussen deze twee systemen veelal custom-made is. Bij het onderzoek is alleen gekeken naar de aansturing van VMS'sen. Doorgaans kunnen deze producten eveneens minder geavanceerde actuatoren besturen, waaronder bijvoorbeeld kantelwalsen. 3.10.7 Presentatie toolkits Bij presentatielaag producten is een toenemend gebruik te constateren van echte GIS tools. Door toepassing van moderne technieken is het real-time gedrag hiervan sterk verbeterd in verhouding met enkele jaren terug.

3.10.8 Totaaloplossingen Totaaloplossingen kunnen doorgaans alleen onderhouden worden door derden als de softwarecode in de leveringsomvang is inbegrepen. Dit is bij twee leveranciers (DHV/Delcan en Open Roads) het geval.


96

4 Ontwikkelingen in de markt

ln dit hoofdstuk wordt een overzicht gegeven van een aantal waarnemingen, tijdens het onderzoek over ontwikkelingen in de markt, die van belang kunnen zijn voor de ontwikkeling van een nieuwe generatie verkeersmanagementsystemen. De individuele waarnemingen zijn in onafhankelijke secties verzameld: 1. In sectie 4.1 worden enkele waarnemingen over systeemontwikkeling door de DVM markt gegeven; ontwikkeling van producten versus componenten, ontwikkeling van software voor verkeerskundige maatregelen, en over koppeling met totaaloplossingen. 2. In sectie 4.2 wordt een overzicht gegeven van een aantal standaarden voor communicatie en koppelingen van verkeerskundige systemen die zijn toegepast in shortlist producten uit hoofdstuk 3: • NTCIP (National Transportation Communications for ITS Protocol) • UTMC (Urban Traffic Management and Control) • NMCS2 (National Motorway Communications Protocol 2) • OCIT (Offene Schnittstelle für Gerate der StraBenverkehrstechnik) • TLS (Technische Lieferbedingungen für Streckenstationen) • LCR (Language de Commande Routier) • IVERA (Initiatiefgroep VERkeersregeltechnici ASTRIN) In een aanvullend onderzoek is de toepasbaarheid van XML beschouwd als specificatie taal voor data definities in DVM, en zijn enkele aspecten beschouwd bij het doortrekken van de CORBA vanuit de centrale naar wegkantstations. Tot slot zijn enkele praktijk ervaringen verzameld over standaardisatie van communicatie met CORBA. 3. In sectie 4.3 worden enkele bevindingen samengevat uit een aanvullend onderzoek naar de toepasbaarheid van PLC, SCADA, DCS en industriële PCs voor verkeersmanagement systemen. 4. In sectie 4.4 wordt kort verslag gedaan over de ervaringen van eindgebruikers in andere branches; rail infrastructuur, luchtverkeersleiding, petrochemie, utilities, ruimtevaart, landmacht en marine. 5. Bevindingen en conclusies

4.1 Systeemontwikkeling door de markt In deze paragraaf wordt ingegaan op de wijze waarop marktpartijen systemen ontwikkelen en wat daarbij hun 'leit-motiv' is. 4.1.1 Componenten versus producten De redenen voor RWS om systemen op te delen in componenten zijn gerelateerd aan de beheersbaarheid. Vanuit de wens om nieuwe functionaliteit toe te kunnen voegen en huidige functionaliteit te kunnen wijzigen is er een


97

globaal ontwerp gemaakt, gebaseerd op componenten. De volgende definitie van een component wordt gehanteerd: Een van tevoren gebouwd softwareonderdeel, met een goed gedefinieerde interface en goed gedefinieerd gedrag, dat kan worden gebruikt én hergebruikt in verschillende applicaties. Zulke componenten worden ook wel "Black Box components" genoemd. Eén component op zich is geen volledig zelfstandige eenheid, maar is een onderdeel van een groter 'componentgebaseerde' systeem. Commercieel verkrijgbare componenten Door het CBDi Forum [CBDi] is een analyse gemaakt van op de markt verkrijgbare componenten. Daarbij wordt uitgegaan van een indeling van componenten in drie categorieën van functies; branche specifieke functies, branche generieke functies en branche onafhankelijke functies. Het aanbod van componenten is het grootst in de laatste categorie. De productontwikkeling door marktpartijen kan op twee manieren plaatsvinden: vanuit projecten en vanuit marketing. Productontwikkeling als het gevolg van projecten Vaak worden projecten uitgevoerd waarbij het eindresultaat, of delen daarvan, hergebruikt kunnen worden in vervolgprojecten. Dit is veelal ook mogelijk omdat eigendomsrechten tussen opdrachtnemer en opdrachtgever niet goed zijn vastgelegd. Door meerdere malen projecten van dezelfde aard uit te voeren ontstaat op termijn een 'gereedschapskist' met producten of tools. De producten uit zo'n gereedschapskist kunnen vaak niet zonder meer op de markt worden gezet. De projectmedewerkers kennen de gereedschapskist met alle ins- en outs en hebben door ervaring kennis opgedaan hoe deze producten het beste ingezet kunnen worden. Vaak wordt ook alleen de hoogst noodzakelijke documentatie aangelegd. Een gebruiker aan de kant van de opdrachtgever mist deze ervaring en heeft een ander werkproces dan de projectmedewerker. Een koper van zo'n product mist zelfs de ervaring van de opdrachtgever. Het resultaat van een projectgebaseerde ontwikkeling is dat opgeleverde producten geen echte verkoopbare producten zijn, wat overigens niet afdoet aan de kwaliteit van de uitgevoerde projecten. Typerend voor deze werkwijze is dat een leverancier vaak geen prijslijst van de producten heeft. Er zijn leveranciers die dergelijke producten willen beschermen. Het is tenslotte voor hen een middel om nieuwe projecten concurrerend aan te kunnen bieden. Daartegenover staat dat leveranciers een omschakeling moeten maken in hun werkwijze wanneer zij gevraagd worden om ook het onderhoud op de gerealiseerde producten uit te voeren. Productontwikkeling vanuit marketing Door marktonderzoek wordt bekeken waar kansen liggen. Productspecificaties worden opgesteld gericht op een brede inzetbaarheid van het product waarbij de productontwikkelaar ook verantwoordelijk zal zijn voor het beheer en onderhoud. Dit leidt tot producten die meer gericht zijn op een branche of werkproces dan op een specifieke klant en die beter onderhoudbaar zijn. Het nadeel van deze vorm is de investering die gedaan moet worden met een hoog uitval risico. Afnamegarantie is er immers niet. Leveranciers zijn gericht op overleven. Dit betekent dat er gezocht wordt naar een afhankelijkheidsrelatie tussen klant en leverancier, zodat er voor leveranciers een lange termijn perspectief ontstaat. Dit behoeft echter zeker


98

nietten nadele van de opdrachtgever te zijn, maar heeft wel gevolgen voor het product wat op de markt gezet wordt. Componenten, zoals ontworpen binnen RWS, zijn derhalve niet op de markt te verkrijgen. Leveranciers worden vaak gevraagd geen deelzorgen uit de hand te nemen maar een compleet product te bieden. Dergelijke producten, al dan niet met onderhoud, is per definitie geen component als geschetst in het globaal ontwerp. Een ander belang van de leverancier is niet afhankelijk te willen zijn van andere leveranciers. Leveranciers leveren daarom producten die groter zijn dan de componenten in de huidige topologie. Nadelen van componentgebaseerde ontwikkeling komen voort uit de technische en organisatorische problemen rond de integratie en interoperabiliteit van componenten. Dit kan worden geïllustreerd aan de hand van een vereenvoudigd rekenvoorbeeld. Er zijn in totaal 24 componenten geïdentificeerd in ACT met 122 onderlinge koppelvlakken. In het meest extreme geval moeten 24 verschillende producten van 24 verschillende leveranciers met elkaar geïntegreerd worden. Als er voor elk product jaarlijks een nieuwe release wordt uitgebracht, dan zal een component gebaseerd DVM systeem gemiddeld twee aanpassingen per maand moeten ondergaan, waarbij meer dan 10 interfaces betrokken zijn. In zo'n situatie zou RWS moeten overwegen om de rol van systeem integrator uitte besteden, en een "one-stop shopping" inkoopbeleid te adopteren. Gebleken is dat de huidige componentindeling te fijn is. Producten op de markt dekken vaak meerdere componenten met een andere insteek. Bij het verwerven van marktproducten is het noodzakelijk om de producten te beoordelen op hun openheid en op functiescheiding zoals gewenst is in de verkeerskundige architectuur van AVB. 4.1.2 Van sensoren en actuatoren naar maatregelen Er is een verschuiving waar te nemen t o . v . een aantal jaren geleden over de aard van de producten. Er is een toenemend aantal leveranciers dat complete maatregelen levert. Het grootste deel van de beschikbare producten betreft echter niet-autonome maatregelen (afgezien van de VRI-achtige systemen). Voor een geïntegreerd DVM zullen deze maatregelen gecoördineerd moeten worden. Het probleem is echter dat veel van deze oplossingen vanuit een project gerealiseerd zijn. Koppelingen tussen maatregelen komen dan ook nauwelijks voor. Er is pas een belang voor de leverancier om hiervoor een oplossing te bieden, als een klant hem vraagt meerdere maatregelen te leveren die interactie met elkaar hebben. Daarmee wordt een basis gelegd voor producten met een uniforme bedieninterface. 4.1.3 Totaaloplossingen op komst Er zijn leveranciers die totaaloplossingen bieden. Deze oplossingen zijn echter vaak nog niet rijp als COTS product. De totaaloplossingen zijn veelal alleen ontwikkeld voor hun eigen sensoren en actuatoren. Koppelingen met 'externe' systemen worden wel gemaakt maar zijn maatwerk oplossingen. Wanneer standaarden meer draagvlak krijgen en verder ontwikkeld worden is het beter mogelijk om totaaloplossingen samen te stellen uit afzonderlijke en complementaire producten van verschillende leveranciers. Dit zal echter nog enige tijd vergen.


99

4.1.4 Bevindingen en conclusies Er zijn drie belangrijke waarnemingen gedaan over systeemontwikkeling in de markt: • De componentindeling van ACT is te fijn om als producten van de marktte kunnen kopen. Leveranciers leveren complete producten op (sub)systeem grootte. • Een toenemend aantal leveranciers levert complete maatregelen met detectie en signalering als een zelfstandig systeem. Koppelingen en coördinatie tussen maatregelen van verschillende leveranciers is nog niet mogelijk. • Totaaloplossingen zijn leverancierspecifiek en bieden geen industriebrede standaard interfaces. Koppeling met producten van andere leveranciers vereist maatwerk.

4.2 Gebruikte standaarden voor koppeling en communicatie van systemen Tijdens de marktverkenning is het gebruik van een aantal nationale standaarden voor ITS Applicaties vastgesteld. In een aantal landen, zoals het Verenigd Koninkrijk en Duitsland zijn de standaarden voorgeschreven. Daarnaast is er ook een tendens dat steeds meer leveranciers deze nationale standaarden gaan gebruiken in plaats van, of naast, eigen of locale standaarden. Deze sectie vermeldt een aantal standaarden die gebruikt worden in de shortlist van producten in hoofdstuk 3. De relevante kenmerken van de standaarden worden kort beschreven. De standaarden zelf zijn echter niet geëvalueerd op hun geschiktheid voor de Applicatie Architectuur. Wel kunnen andere relevante aspecten van de standaarden worden vermeld, zoals het proces van standaardisatie, en de onderliggende architecturen. Nationale standaarden voor koppeling en communicatie van systemen zijn op verschillende wijzen ontwikkeld. Een communicatie standaard kan worden ontwikkeld op basis van een functionele en systeem architectuur, zoals [KAREN] of de National ITS Architecture [Nat ITS Aren]. Het NTCIP is ontwikkeld op basis van de National ITS Architecture. UTMC en OCIT zijn afgeleid van NTCIP. Het TLS daarentegen is ontwikkeld vanuit een bestaande telecontrol communicatie standaard. NMCS2 is ontwikkeld in combinatie met een technische infrastructuur. Standaardisatie van data definities is een belangrijk onderdeel van deze communicatie standaarden. XML (eXtensible Markup Language) is een generieke taal voor het definiëren en communiceren van data die sterke opgang vindt in bepaalde branches. Ook in een aantal shortlist producten en in ITS projecten wordt XML al toegepast. In paragraaf 4.2.8 wordt een korte beschrijving van XML en de toepassingsmogelijkheden voor DVM geschetst. In de ACT wordt aangenomen dat software componenten in verkeerscentrales én op de wegkantstations kunnen draaien en onderling via CORBA communiceren. Daarvoor moet de Corba middleware zowel in de verkeerscentrale als op de wegkantstations en het tussenliggende netwerk beschikbaar zijn. Dit heeft grote consequenties op de producten die op de wegkantstations moeten draaien. In paragraaf 4.2.9 worden enkele technische aspecten beschouwd van het doortrekken van Corba naar de wegkantstations vanuit het perspectief van de Applicatie Architectuur.


100

Tot slot worden ook enkele waarnemingen uit de markt over ervaringen met Corba in verkeerscentrales gemeld. 4.2.1 NTCIP - National Transportation Communications for ITS Protocol Een communicatie protocol bestaat uit een set van regels die voorschrijven hoe berichten gecodeerd en verzonden moeten worden tussen elektronische apparaten. De apparatuur aan elk einde van het data transmissie traject moet hetzelfde protocol gebruiken om een succesvolle communicatie tot stand te kunnen brengen. De situatie is vergelijkbaar met verschillende mensen die dezelfde taal gebruiken; ze hebben een gemeenschappelijk alfabet, vocabulaire en grammatica regels. Historisch gezien ontwikkelde iedere leverancier een bedrijfseigen communicatie protocol voor haar apparatuur en software. Dit vereiste uitgebreide systeemintegratie projecten, om apparatuur en software van verschillende leveranciers te laten samenwerken als een geïntegreerd systeem. Het "National Transportation Communications for ITS Protocol" (NTCIP) [NTCIP] biedt gemeenschappelijke protocolstandaarden welke gebruikt kunnen worden door alle verkopers en systeemontwikkelaars teneinde de verschillen tussen de producten te overbruggen. Familie van communicatie standaarden NTCIP bestaat uit een familie van communicatie standaarden voor het versturen van voornamelijk informatie en berichten tussen processor-gestuurde apparatuur die wordt toegepast in "Intelligent Transportation Systems" (ITS). Een voorbeeld van een dergelijk systeem is de centrale computer van de verkeersdienst van een stad, die de werking van de microprocessor gestuurde verkeerslichtregelaars in de gehele stad bedient en bewaakt. De centrale computer kan instructies sturen aan de verkeerslichtregelaars, teneinde de cyclustijden van verkeerslichten te wijzigen naar gelang het algemene verkeersbeeld wijzigt. De verkeerslichtregelaars sturen op hun beurt informatie omtrent status en verkeersstroom naar de centrale computer. In een ander voorbeeld kunnen twee verkeersmanagementsystemen die realtime informatie met elkaar moeten uitwisselen over de locatie van bussen die op weg zijn naar een gemeenschappelijk busstation. Dit maakt het mogelijk, dat elk systeem direct weet wanneer een bepaalde bus dusdanig op zijn schema achter ligt, dat hij niet in staat is de noodzakelijke overstaptijd te realiseren. Passagiers kunnen hiervan dan automatisch op de hoogte gebracht worden en de locale verkeersleiding kan verzocht worden het vertraagde voertuig voorrang te geven bij verkeerslichten. NTCIP is bedoeld voor gebruik door alle managementsystemen die betrekking hebben op vervoer, inclusief de systemen voor snelwegen, verkeerslichten, openbaar vervoer, calamiteiten afhandeling, reizigers informatie en informatie opslag. NTCIP is bedoeld om toegepast te worden tussen computers in verschillende systemen of in verschillende verkeerscentrales en tussen een computer en apparatuur aan de kant van de weg. De huidige NTCIP standaarden zijn niet bedoeld voor gebruik in apparatuur van individuele reizigers. Hiervoor bestaan andere standaarden ofwel deze zijn in ontwikkeling. NTCIP Overzicht NTCIP biedt standaarden voor twee fundamenteel verschillende typen van ITS communicatie protocollen.


101

Het eerste type is de communicatie tussen een verkeersmanagementsysteem of een verkeerscentrale en de van daar uit beheerde actuatoren en sensoren. Voorbeelden van dit type van communicatie zijn: • Een verkeerslichtregelsysteem dat communiceert met locale verkeerslichtregelaars op kruispunten. • Een openbaar vervoer informatiesysteem, dat communiceert met sensoren en passagier informatie panelen in bussen, in busstations en op bushaltes. • Een snelweginformatiesysteem, dat communiceert met detectoren en snelheidssensoren. • Een verkeersmanagementsysteem, dat CCTV camera's, DRIPs, radio zenders, weersensoren en verkeersmeetapparatuur langs de weg bestuurt. Communicatie vanuit een centrale met een grote verscheidenheid aan apparatuur langs de weg of op dienstvoertuigen, wordt aangeduid als "Centerto-Field" communicatie. De centrale bevraagt de apparatuur in het veld meestal routine matig en via een enkel gemeenschappelijk communicatie kanaal. Dit wordt aangeduid als een ongebalanceerd "one-to many" netwerk. Het tweede communicatie type heeft betrekking op berichten die worden uitgewisseld door twee of meer verkeersmanagementcentrales. Voorbeelden van dit type van communicatie zijn onder meer: • Uitwisseling van informatie tussen verkeerscentrales, zoals real-time status veranderingen, voor coördinatie van verkeerslichtregelingen vanuit verschillende centrales, of voor bediening vanuit een andere centrale. • Een openbaar vervoer informatiesysteem dat afwijkingen van de dienstregeling rapporteert aan een OV informatie punt, een reizigers informatie systeem, of een regionaal informatie systeem, en een verzoek stuurt aan het verkeersmanagementsysteem om vertraagde voertuigen prioriteit te geven. • Een "incident management" systeem, dat gegevens over een ongeluk doorgeeft aan een snelweginformatiesysteem, verkeerslichtregelsysteem, reizigers informatie systeem en een openbaar vervoer informatie systeem. • Een snelweg informatie systeem, dat een "incident management" systeem informeert omtrent een waarschuwing die geplaatst is op een dynamisch route informatie paneel als reactie op een incident melding door het "incident management" systeem. Dit type communicatie wordt aangeduid als "Center-to-Center". Het omvat "peer-to-peer" communicatie tussen een willekeurig aantal computer systemen. Dit wordt ook wel aangeduid als een gebalanceerd "one-to many" netwerk. Deze wijze van communiceren is vergelijkbaar met het internet, in die zin, dat elke verkeerscentrale informatie kan aanvragen van, of verstrekken aan, een willekeurig aantal andere centrales. Het is mogelijk, echter nog niet gebruikelijk, om deze protocollen naast communicatie tussen computers, ook te gebruiken voor de communicatie naar en tussen apparatuur langs de weg. Een van de kenmerken van NTCIP protocollen ("Center-to-Center" en "Center-to-Field") is de ondersteuning van continue geautomatiseerde informatie overdracht zonder menselijke inmenging, alhoewel deze communicatie ook een informatie verzoek of een besturingsopdracht van een verkeersleider kan omvatten. Wat is NTCIP NTCIP is een suite van communicatie protocollen en gegevensdefinities, die zijn ontworpen om te voorzien in de diverse behoeften van de verschillende


102

subsystemen en gebruikersfuncties van de "National ITS Architecture" 8 [Nat ITS Arch]. Het is in eerste instantie de bedoeling dit te realiseren voor Center-toCenter en Center-to-Field communicatie. NTCIP verschilt van toepassingen uit het verleden door het definiëren van communicatie protocollen voor managementsystemen, waarbij het niet een enkel protocol is, ontworpen voor een enkele specifieke toepassing. Het bestaat juist uit een hele suite van protocollen die het gehele spectrum bestrijken, van een eenvoudig punt naar punt opdracht/antwoord protocol, tot zeer veelzijdige object georiënteerde technieken. Dit wordt veroorzaakt door de diversiteit van applicaties waarbinnen NTCIP wordt gebruikt en de daaruit voortkomende diversiteit aan applicatie specifieke karakteristieken, zoals onder andere: type en hoeveelheid data die moet worden overgezonden, de benodigde snelheid van de data overdracht, de toelaatbare infrastructuur kosten, de behoefte aan informatiebeveiliging en data integriteit. De grens ligt echter bij de gegevens definities. NTCIP definieert precies welke gegevens overgedragen moeten worden, bijvoorbeeld tussen verkeerslichtregelaars en verkeerscentrales. NTCIP definieert de functionele aspecten, bijvoorbeeld dat aan het object faseGeelVerandering gerefereerd moet worden voor de tijdsduur van de geelfase. NTCIP definieert niet hoe een verkeerslichtregelaar in detail moet werken; het definieert bijvoorbeeld niet de volgorde van de signalen groengeel-rood. Waarom is een protocol als NTCIP nodig Een standaard als NTCIP biedt een oplossing voor een aantal problemen in het gebruik van verkeersmanagementsystemen. Voordat hierop ingegaan wordt, zullen eerst twee termen gedefinieerd worden. De term uitwisselbaarheid ("interchangability") geeft de mogelijkheid weer om meerdere uitvoeringen van een apparaat onderling uit te wisselen. De mogelijkheid om elke uitvoering van een NTCIP compliant verkeerslichtbesturing op een systeem aan te sluiten is een voorbeeld van uitwisselbaarheid. De term interoperabiliteit ("interoperability") geeft het mogelijkheid weer om verschillende apparaten te gebruiken op hetzelfde communicatie kanaal. Het gebruik van hetzelfde communicatie kanaal om een besturingssysteem te verbinden met dynamische route informatie panelen, video surveillance besturing en andere apparaten, is een voorbeeld van interoperabiliteit. Een algemeen probleem is het gebruik van bedrijfseigen protocollen in verkeersmanagementsystemen. Deze protocollen zijn vaak specifiek ontwikkeld voor het project als ook voor de producenten die bij het project betrokken zijn. De producten die zijn ontwikkeld voor deze protocollen zijn niet uitwisselbaar. Nadat een systeem in gebruik genomen is, kan het veelal alleen worden uitgebreid met apparatuur van hetzelfde type en van dezelfde leverancier. Er is eveneens geen gelegenheid om additionele typen van wegkant apparatuur aan het systeem toe te voegen. Er is derhalve geen mogelijkheid voor een realistisch open concurrentierijk aanbestedingstraject als additionele apparatuur aan het systeem moet worden toegevoegd. De correcte toepassing van de NTCIP standaard in een verkeersmanagementsysteem maakt het mogelijk, dat bij toekomstige uitbreidingen van het systeem

8

De "National ITS Architecture" is vergelijkbaar met de Europeese Karen architectuur, maar beslist

niet met de AVB-Architectuur.


103

de voordelen van concurrerende aanbesteding genoten kunnen worden, en dat andere typen wegkantapparatuur aan het systeem kunnen worden toegevoegd. De "Transportation Equity Act for the 21 st century" [TEA-21] (ook bekend als "TEA-21") vereist dat in de Verenigde Staten, federaal bekostigde ITS projecten worden uitgevoerd conform de "National ITS Architecture". Zoals in TEA-21 is gedefinieerd, wordt met de term "intelligent transport system" bedoeld: Het gebruik van elektronica, communicatie of informatie verwerking, alleen of in combinatie, met als doel het verbeteren van de efficiëntie of de veiligheid van een oppervlakte transport systeem. De "National ITS Architecture" definieert zowel de functies die worden uitgevoerd door de ITS implementatie, als ook de informatiestromen tussen de vervoerssubsystemen. In het rapport van het US Department of Transport: "Interim Guidance on Conformity with the National ITS Architecture", van 2 oktober 1998 wordt gesteld, dat 'Ontvangers van geld uit het Highway Trust Fund de noodzakelijke acties zullen ondernemen om zeker te stellen, dat bij de ontwikkeling van projecten: a. Een groot aantal belanghebbenden betrokken is. b. Het gebruik van een elektronische informatie uitwisseling tussen betrokkenen mogelijk gemaakt wordt. c. Toekomstige uitbreidingen worden mogelijk gemaakt. d. Het gebruik van de van toepassing zijnde ITS standaarden wordt overwogen. De termen "uitwisselbaarheid" en "interoperabiliteit" zijn verweven met de TEA-21 wetgeving, waarbij vooral het begrip "interoperabiliteit" veelvuldig wordt gebruikt. Waar een eenvoudige beschouwing van NTCIP zich vaak richt op uitwisselbaarheid, is interoperabiliteit daadwerkelijk veel belangrijker, en wel om twee redenen: Ten eerste omdat de communicatie infrastructuur normaliter het meest dure element is van een nieuw systeem, verlaagt de toepassing van deze infrastructuur voor meerdere doeleinden de totale kosten van het systeem. Ten tweede en belangrijker in termen van de TEA-21 wetgeving, interoperabiliteit stimuleert de uitwisseling van informatie, waardoor de mogelijkheden voor de gebruikers van het verkeersmanagement-systeem vergroot worden om hun systeem efficiënt te beheren, waarbij zelfs informatie uitwisseling over de grenzen van organisaties heen kan plaatsvinden. Lessen uit de praktijk Het belangrijkste aspect van het gebruik van NTCIP is dat het een in opkomst zijnde technologie is. Zoals bij de meeste technologieën die in opkomst zijn hebben de eerste ontwikkelaars meegewerkt aan de totstandkoming van de NTCIP specificatie. Deze ontwikkelaars ontbeerden vaak voldoende opleidingsmateriaal omtrent de beste manier waarop deze systemen gespecificeerd, aanbesteed, ingezet, geïntegreerd en getest konden worden. Voornamelijk als reactie op het gedetecteerde gebrek aan informatie over deze onderwerpen is het document 'NTCIP Guide' [NTCIP Guide] opgesteld. Dit biedt toekomstige ontwikkelaars een mogelijkheid om problemen bij het implementeren van deze nieuwe technologieën te omzeilen. Onder de auteurs van dit document zijn zowel product leveranciers als systeem integrators van de eerste NTCIP toepassingen en dit document bevat derhalve een weergave van de tijdens de ontwikkeling van deze toepassingen in de praktijk opgedane ervaringen. Daarnaast is dit document nagezien door een team van reviewers uit de publieke sector om zeker te stellen dat de behoeften


104

zijn afgedekt van de belanghebbenden die toekomstige toepassingen zullen gaan uitvoeren. Het NTCIP is ontwikkeld op basis van bestaande industriële standaarden met een breed draagvlak. Hierbij is zoveel mogelijk gebruik gemaakt van algemeen gangbare internet communicatie protocol standaarden om het risico dat verbonden is met het gebruik van deze protocollen zo veel mogelijk te beperken. Diensten die het gebruik van NTCIP overwegen, moeten zorgvuldig hun functionele specificaties beoordelen en vervolgens bepalen van welke objecten het gebruik voorgeschreven moet worden en van welke objecten optioneel toegepast kunnen worden. Als voorbeeld kan in bepaalde toepassingen gekozen worden voor een strikte hantering van de standaard teneinde een optimale uitwisselbaarheid van wegkantapparatuur te garanderen, terwijl voor andere toepassingen genoegen kan worden genomen met een beperkte uitwisselbaarheid, waarbij optimaal gebruik gemaakt kan worden van leverancier specifieke functies. De behoefte om een combinatie van verschillende apparatuur toe te passen in de communicatie infrastructuur is eveneens een factor die afgewogen moet worden. Al deze onderwerpen zullen een aanzienlijke invloed hebben op de inhoud van het bestek, en diensten moeten zich derhalve in een vroegtijdig stadium van de systeemontwerp- en uitbestedingsfasen over hun doelstellingen beraden. Daarnaast is het waarschijnlijk niet mogelijk of praktisch om het NTCIP protocol voor bestaande systemen te implementeren, omdat deze niet beschikken over de benodigde processor en geheugen capaciteit. Door NTCIP ondersteunde communicatie

NTCIP definieert een familie van algemeen toepasbare protocollen, die de communicatie tussen computers en alle typen van wegkantapparatuur die gebruikt worden voor verkeersmanagement ondersteunt. De toepassingen van NTCIP zijn opgedeeld in twee categorieën: "center-tofield" en "center-to-center". De eerste categorie betreft apparaten aan de wegkant of op dienstvoertuigen die met management software op een centrale computer communiceren. De tweede categorie betreft communicatie tussen computers in verkeerscentrales. NTCIP lagenmodel NTCIP communicatie is opgebouwd uit lagen die vergelijkbaar zijn met die van het Internet Protocol en het OSI model. NTCIP communicatie omvat de volgende lagen (zie ook Figuur 14): • Informatie laag; deze laag definieert de standaarden voor de data elementen, objecten en berichten die verstuurd worden. Dit zijn onder meer: TCIP, TS3.5, MS/ETMCC. • Applicatie laag, deze laag definieert de standaarden voor de data pakket structuur en sessie management. Dit zijn onder meer: SNMP, STMP, DATEX, CORBA, FTP. • Transport laag: deze laag definieert de standaarden voor de data pakket opsplitsing, samenvoeging en routering. Dit zijn onder meer: TCP, UDP, IP. • Subnetwerk laag, deze laag definieert de standaarden voor de fysieke interfaces. Dit zijn onder meer: HDLC, PPP, Ethernet, ATM. • Fysiek niveau, deze laag definieert de standaarden voor de fysieke verbinding. Dit zijn onder meer: koperdraad, coaxiaal kabel, glasvezel, draadloos (radio/GSM).


105

Center-te- Field

Center-to-Center ITS Data Model

L_J

Reference Model

I [ « — ] ITS Message Sefe

Data Object;

ITS Data Didionary

|

| Files

Figuur 14: Opbouw NTCIP Standaard [NTCIP Framework]

Conclusie Teneinde 'interoperabiliteit' en 'interconnectiviteit' van verkeerssystemen te realiseren heeft de Amerikaanse overheid in een succesvol samenwerkingsverband met de industrie de NTCIP standaard gedefinieerd, die bestaat uit een familie van protocollen voor gebruik tussen een centrale en wegkantapparatuur en tussen centrales onderling. 4.2.2 UTMC - Urban Traffic Management & Control UTMC is een raamwerk voor een open en modulair communicatie netwerk voor intelligente transport systemen in het Verenigd Koninkrijk [UTMC]. Uiteindelijk zal UTMC tot een nationale standaard moeten worden doorontwikkeld in een samenwerkingsverband van overheid en industrie. De doelstellingen van UTMC zijn enigszins vergelijkbaar met die in de Applicatie Architectuur. UTMC voorziet in de uitwisseling van informatie tussen ITS systemen en ondersteunt zowel gecentraliseerde als gedistribueerde intelligentie - dit maximaliseert de ontwerp vrijheid. UTMC richt zich uiteraard voornamelijk op stedelijke en regionale verkeersbeheersing, verkeersregelinstallaties (VRI) en parkeerbeheer. Architectuur Het netwerk verbindt verkeerskundige applicaties en apparatuur in verkeerscentrales en wegkantsystemen ("outstations" en "controlled units"), een gemeenschappelijke database (in de centrale) en externe systemen. Het programma omvat ook onderzoek naar monitoring, analyse functies en regelstrategieën. UTMC kent een logische architectuur van systemen (nodes) op 5 hiërarchische niveaus; externe systemen voor bijvoorbeeld verkeersinformatie (TIC),


106

systemen in de verkeerscentrale, outstations (een soort wegkantstations), UTMC gecontroleerde wegkantsystemen, en systemen in voertuigen. Communicatie protocollen Op het transport niveau van communicatie is IP voorgeschreven in de centrales en met wegkantsystemen. Daarop is UDP het geprefereerde transport protocol. TCP wordt toegestaan in plaats van UDP indien communicatie tijd geen belangrijke eis is. Op het applicatie niveau van communicatie wordt CORBA toegestaan in en tussen centrales voor intensieve interactieve communicatie. SNMP wordt toegepast voor communicatie met apparatuur en wegkantsystemen waarvoor response tijd en beheersbaarheid belangrijke criteria zijn. IP mag ook zonder transport protocol toegepast worden indien geen open standaard communicatie vereist is. UTMC hanteert geen gecentraliseerde en normatieve data definities, omdat dit beheersmechanisme niet snel genoeg op specifiek wensen en eisen kan inspelen. Wel wordt een "Data Object Registry" voorgeschreven waarin toevoegingen via een acceptatie proces gepubliceerd worden. Hierin staan CORBA objecten, database tabellen, internet objecten, MIBs voor SNMP, en berichten naar legacy software naast elkaar opgenomen. De verschillende representaties moeten zo goed mogelijk compatibel zijn met DATEX. Redundantie tussen de verschillende representaties wordt zoveel mogelijk in het acceptatie proces geverifieerd. Onderzoeksprogramma UTMC is een vijfjarig onderzoeksprogramma (1997-2002) van het DTLR (Department for Transport, Local Governement and the Regions). DTLR heeft het management van het programma uitbesteed aan een consultancy firma. Het programma omvat een groot aantal projecten die moeten leiden tot technische specificaties van de infrastructuur, communicatie standaarden, data definities, NTCIP compliance, netwerk model, gemeenschappelijke database, migratie plannen, en performance evaluatie. Daarnaast zijn ook een aantal pilot projecten gedefinieerd waarin de praktische realiseerbaarheid wordt geëvalueerd aan de hand van diverse ITS applicaties. Deze pilot projecten worden uitgevoerd met locale overheden en commerciële partners. Enkele relevante projectresultaten zullen kort worden besproken. Relatie met NTCIP In het algemeen accepteert UTMC het NTCIP standaard raamwerk. In een project [UTMC08] is de bruikbaarheid van NTCIP voor UTMC geëvalueerd. Hierin is ook een voorlopige specificatie voor SUPS (Simple UTC Protocol) ontwikkeld voor een open data communicatie en interface standaard tussen front-end-processors en andere systemen op het netwerk in verkeerscentrales. Deze zijn in de praktijk getoetst in pilot projecten in Leeds en Nottingham. In [UTMC09] is de bruikbaarheid van de NTCIP messaging standaarden (SNMP) voor UTMC onderzocht voor met name verkeersregelinstallaties. Uit beide projecten is een specificatie opgesteld voor de inhoud, de structuur (MIB) en de kwaliteit van in- en uitvoer data naar UTMC systemen. De specificatie is opgesteld volgens de DATEX standaard. Twee significante verschillen met NTCIP worden aangegeven: • NTCIP informatie standaarden zijn nog in ontwikkeling en zijn sterk georiënteerd naar operationele en technische eisen in de VS. In afwachting van een Europese of wereld standaard prefereert UTMC een eigen UTMC standaard te definiëren. De UTMC standaard verschilt vooral in de


107

•

verzameling van protocollen. De gebruikte protocollen zelf verschillen weinig van die van NTCIP. UTMC verkiest geen STMP maar schrijft de standaard SNMP voor.

Pilot projecten

De laatste twee jaren zijn vooral een demonstratie fase met enkele pilot projecten, waarin de technische oplossingen in de praktijk van stedelijk verkeersmanagement worden geëvalueerd [UTMC29]. In Preston (UTMC29A) en York (UTMC29D) is de systeemarchitectuur van KAREN gecombineerd met UTMC. In Reading (UTMC29B) en York is CORBA in de verkeerscentrale toegepast voor real-time communicatie met de gemeenschappelijke database, en SNMP voor communicatie naar wegkantsystemen. Transformatie van informatie tussen CORBA en SNMP MIBs wordt verzorgd door speciale adapters. XML wordt in Reading gebruikt voor communicatie van verkeersinformatie naar externe partijen vanuit de database. Stedelijk verkeersmanagement

UTMC is niet direct ontwikkeld voor verkeersbeheersing op snelwegen, maar enkele koppelingen vanuit stedelijk naar regionale verkeersbeheersing zijn wel onderzocht. Voor communicatie van en naar wegkantsystemen (outstations en transponders) is NMCS2 als standaard gedefinieerd in het Verenigd Koninkrijk. In UTMC is SNMP geprefereerd voor communicatie naar wegkantsystemen. Koppeling van SNMP en NMCS2 is niet triviaal (UTMC09). In UTMC wordt geadviseerd om NMCS2 aan te passen aan SNMP voor het aansturen van VMS systemen. In het project UTMC04 is bewaking en voorspelling van verkeerscondities bestudeert voor beslissingsondersteuning bij verkeersmanagement op netwerk niveau. Hieruit zijn aanbevelingen geformuleerd voor kosteneffectieve detectie en bewaking van netwerk data, data synthese opslag van historische data. Ook is een evaluatie gemaakt van netwerk modellering en management in pilot projecten in Birmingham en Leicester. 4.2.3

NMCS2 - National Motorway Communication System 2

Het National Motorway Communication System (NMCS) is een systeem dat is geïmplementeerd door de "National Highways Agency" in Engeland, om snelweg apparatuur te verbinden met computers en besturingssystemen die zijn geïnstalleerd in centrale posten. De "National Highways Agency" is bezig het oude analoge NMCS1 uitte faseren, ten behoeve van de invoering van het nieuwe digitale NMCS2 [NMCS2] systeem, gedefinieerd in 1997. Er bestaan vier versies van het NMCS2: Voor Engeland, Wales, Schotland en Noord Ierland, mede omdat er ook verschillende systeemeigenaren zijn, respectievelijk The Highway Agency, The Welsh Office, The Scottish Office en The Department of Environment. Architectuur

Het Engelse snelwegennet is verdeeld over 39 verschillende "Control Office Areas" (COA). Elk COA heeft een bedienpost, de "Control Office" (CO), welke door de politie gebruikt wordt om het verkeer op de snelweg te regelen. Communicatie

Het NMCS is een communicatie systeem, waarmee in de CO gecommuniceerd kan worden via twee onafhankelijke netwerken:


108

•

Het telefoonsysteem, waarop de telefoons voor noodgevallen langs de snelweg zijn aangesloten, is toegankelijk via de "Operator Interface" (OIF) van het "Control Office Base System" (COBS) in de CO; • Het datanetwerk waarop alle aangesloten wegkantapparatuur door een NMCS subsysteem bedient en bewaakt kan worden. Er zijn onder andere subsystemen voor de bediening en bewaking van verlichting, tunnels, "Variable Message Signs" (VMS) en Motorway Incident Detection and Automatic Signalling (MIDAS). Ook het NMCS2 systeem is gebaseerd op bestaande industriële standaarden met een breed draagvlak, te weten: het X25, het HDLC en het RS485 protocol. Het NMCS datanetwerk verbindt de centrale apparatuur in de CO met; • een "Local Communications Controller" (LCC) in het veld, over een X25 level 2 9600 bits/s point to point vierdraadsverbinding, • de Regional Communication Controllers in het land, via een X25 level 3 WAN. • onderhoudsterminals via een X25 level 2 verbinding. De CO bestaat uit het "Control Office Base System" (COBS) met de bijbehorende "Operator Interfaces" (OIF), voor de bediening en bewaking van subsystemen. Een "Operator Interface" (OIF) bestaat doorgaans uit: een bedienpaneel, een QWERTY toetsenbord en een monitor. De LCC is een NMCS2 data system message switching unit, die High-level Data Link Control (HDLC) protocol berichten doorgeeft via een multidrop verbinding. Op de LCC zijn "Standard Transponders" (ST) aangesloten, waarop de wegkant apparatuur via een half-duplex verbinding is aangesloten. Een LCC kan in master-slave configuratie maximaal vierX25 multidrop verbindingen aansturen, waarop elk maximaal 58 STs zijn aangesloten. De ST functioneert als postbus, multiplexer en als monitor voor verschillende subsystemen, waarbij statuswijzigingen worden doorgegeven. Op een ST kunnen maximaal 120 wegkantapparaten worden aangesloten via een halfduplex 2400 bits/s RS485 tweedraadsverbinding. Een ST kan maximaal vier RS485 verbindingen aansturen, waarop elk maximaal 30 wegkantapparaten zijn aangesloten. 4.2.4

OCIT - Open Communication Interface for Road Traffic Control Systems

OCIT [OCIT] is een samenwerkingsverband van enkele Duitse ontwikkelaars en organisaties. De industriële ontwikkelaars zijn Dambach, Siemens, Signalbau Huber, Stoye, en Stuehrenberg. Daarnaast zijn het BASt (Bundewanstaltfuer Strassenwesen) en organisaties voor Duitse steden, verkeerstechniek en ingenieursbureaus betrokken. OCIT is opgericht in 1999. Het doel van OCIT is een open communicatie interface te definiëren waarmee apparatuur voor verkeersregelinstallaties (VRI) van verschillende leveranciers geïntegreerd kan worden. OCIT is echter niet open voor andere partijen. Relatie met NTCIP

De ontwikkeling van OCIT is gebaseerd op het harmoniseringsvoorstel ISO TC204, dat op zich weer is afgeleid van NTCIP. OCIT is bewust niet een volledig nieuwe ontwikkeling. OCIT beoogt juist de enorme financiële en tijdsinspanningen die zijn gemaakt bij NTCIP te kunnen besparen en de ervaringen met NTCIP te kunnen hergebruiken. Wel wordt onderkend dat de systeemtechniek in Duitsland op enkele punten essentieel verschilt met die in de VS. OCIT zal op die punten verder ontwikkeld worden, in het bijzonder op


109

transport protocollen, flexibiliteit in systemen, communicatie verbindingen, en netwerk beveiliging. Programma OCIT wordt gefaseerd ontwikkeld. Versie 1 definieert een functionele en een systeem architectuur, infrastructuur, communicatie interface en protocollen voor bediening van verkeersregelinstallaties vanuit centrales. De interface voorziet in communicatie voor inwinnen van verkeerskundige informatie en bedrijfstoestanden, bediening, bewaking, visualisatie en onderhoud op afstand. Het netwerk bestaat uit point-to-point verbindingen tussen een centrale en VRIs. Medio 2001 is een pilot project opgezet in Frankfurt. Versie 2 voorziet ook in statische beheersinformatie en is gepland voor eind 2002. Toekomstige versies zullen ook communicatie tussen centrales, netwerktoegang vanaf locale systemen, DVM voor het hoofdwegennet, en parkeerbeheer omvatten. Architectuur De OCIT architectuur onderscheidt wegkantapparatuur en systemen in verkeerscentrales. OCIT onderkent twee typen koppelvlakken: instation outstation

koppelvlakken tussen systemen en applicaties in 1 of meerdere verkeerscentrales. koppelvlakken tussen een systeem of applicatie in een verkeerscentrale en een wegkantsysteem.

Communicatie Data transport op in- en outstation koppelvlakken is gebaseerd op TCP/IP of UDP/IP en PPP. Het data model is object-georiënteerd. Data definities zijn opgesteld in XML en worden ook voorgeschreven voor data uitwisseling. Voor instation communicatie zal daar een eigen OCIT communicatie protocol bovenop gedefinieerd worden (niet in versiei). Voor communicatie over outstation koppelvlakken is een ander OCIT protocol BTPPL (Basis Transport Paket Protokoll Layer) voorgeschreven boven op TCP en UDP. BTPPL is speciaal ontwikkeld om de data overhead te minimaliseren, waardoor geheugen capaciteit en netwerk belasting kunnen worden beperkt. OCIT beoogt een decentrale besturing en schrijft onder andere voor dat het communicatie netwerk niet met tijd kritische data mag worden belast. Tijdkritische processen moeten daarom in het veld uitgevoerd worden en niet via de centrale. 4.2.5 TLS - Technische Lieferbedingungen für Streckenstationen De verkeersbeheersingssystemen op snelwegen in Duitsland hebben een hiërarchische systeem architectuur. Het nationale hoofdwegennet is verdeeld in afzonderlijke regionale netwerken, leder regionaal netwerk heeft een verkeerscentrale van waaruit Unterzentralen (UZ) worden aangestuurd. Een UZ bestuurt een eigen netwerk van Streckenstationen (SS). Een Streckenstation bevat een Stueuermodul en controllers voor detectoren en actuatoren. Een UZ heeft twee functies; • communicatie tussen een verkeerscentrale en de SSen, inclusief transformatie tussen de communicatie protocollen, aggregatie van data, en optimalisatie van communicatie, en • (manuele en locale) bediening van actuatoren. Een UZ staat fysiek in de verkeerscentrale zelf of in een dependance in de regio.


110

Er zijn twee communicatie standaarden opgelegd; MARZ (Merkblattfürdie Ausstattung von Verkehrsrechnerzentralen und Unterzentralen) tussen verkeerscentrale en UZ, en TLS tussen UZ en SS. TLS [TLS] is een Duitse standaard voor data inwinning, communicatie, functies en koppelvlakken voor wegkantsystemen langs snelwegen. TLS dateert van 1993, en is dwingend voorgeschreven voor alle nieuwe wegkantsystemen. Communicatie

Tussen een UZ en een SS ligt een vaste lijn verbinding voor half-duplex communicatie met 1200 bps. De communicatie over deze verbinding is beperkt, en ook het aantal SSen is beperkt. Het SS heeft een locale bus met een RS 485 interface en een snelheid van 9600 bps. Ook kan een modem V24/V28 in het SS worden opgenomen. In TLS worden begrippen en data gedefinieerd voor het communiceren van; • het inwinnen en aggregeren (monitoring) van actuele verkeerskundige, statistische en omgevingsgegevens, • bewaken van apparatuur, • bediening van actuatoren, bevestiging van bedieningsopdrachten, terugmelding van verkeerskundige, beeld, en bed rijfsstatus. Het kleinste interval voor uitwisseling van verkeersgegevens is 1 minuut. TLS schrijft voor dat bedieningsopdrachten gecontroleerd worden op uitvoerbaarheid, en dat een bevestiging bij uitvoering, of een melding van een storing in beeld, communicatie of apparatuur, naar de centrale gegeven moet worden. TLS definieert de optie voor een "Dirigent" in een SS. Dit is een entiteit die de bediening van actuatoren overneemt indien de communicatie met de UZ verbroken wordt. TLS is gebaseerd op de standaarden IEC 60870-5-101 en IEC 61850 van het Technical Comittee IEC-TC 57 voor "telecontrol, teleprotection and associated telecommunications for electric power systems". Dit zijn standaarden voor bitseriële communicatie over netwerken met lage snelheid en grote geografische spreiding. In TLS wordt alleen de asymmetrische (unbalanced) transportmode toegestaan. Gegevens worden doorgestuurd als berichten (telegrammen) met een vooraf gedefinieerde byte structuur. Een bericht kan maximaal 255 byte (inclusief header informatie) lang zijn. Een standaard als TLS zou enige beperkingen impliceren voor de gewenste functionaliteit in de Applicatie Architectuur. Vrij programmeerbare tekstberichten bijvoorbeeld zijn beperkt tot 220 karakters. Grafische beelden kunnen niet worden doorgestuurd voor bijvoorbeeld configuratie van dynamische borden. Waarschijnlijk wordt er momenteel gewerkt aan de revisie van TLS gebaseerd op het IEC 60870-5-104 protocol dat gebruik maakt van TCP/IP9.

9


Mededeling uit persoonlijke communicatie met ASIM en AVE op Intertraffic.

111

4.2.6 LCR - Langage de Commande Routier Frankrijk heeft een wegennet dat sterk convergeert rondom Parijs. In en om Parijs alleen al zijn er meer dan 10 autoriteiten voor verkeersregeling van stedelijke regio's, snelwegen met een eigen (regionale) verkeerscentrale, en het Sirius systeem [Susanne]. Sirius beheert een deel van het netwerk en coördineert de overige centrales. Het communicatienetwerk tussen centrales en wegkantsystemen bestaat uit vaste (koper) verbindingen over grote afstanden met lage communicatie snelheden. Er zijn een aantal applicatie en communicatie protocollen in gebruik in de verschillende regio's en systemen, naast twee nationale standaarden LCR en TEDI. Standaard normen Langage de Commande Routier (LCR) is een informatie en applicatie protocol voor het beheren van ITS systemen. LCR definieert communicatie op ISO lagen 6 en 7. Naast verkeersbeheersing op hoofdwegen, vallen hier bijvoorbeeld ook TIC, parkeer, tol en betalingssystemen onder [LCR NORM]. Verkeersregelinstallaties zijn uitgesloten. LCR is vastgelegd in vier normen van AFNOR[AFNOR]: •

NF P99-340: Algemene regels en bibliotheken voor het versturen van ruwe sensor data en basale verkeersinformatie (snelheid, intensiteit) naar instations en berichten naar actuatoren. De norm definieert onder andere de programmeertaal, remote control, telecontrol, verkeersleiding, signalering en signaalgevers, camera's, remote supervision, open systems interconnection, informatie uitwisseling, datatransmissie en karakters, maatregelen, dynamische borden, en video surveillance.

•

NF P99-341: Uitbreiding van de norm voor toepassing voor bediening van dynamische borden met een lijst van commando's en parameters.

•

NF P99-342: Uitbreiding van de norm voor toepassing voor bediening van camera's.

•

NF P99-344: Uitbreiding van de norm voor toepassing van LCR op meetsystemen met een lijst van commando's en parameters.

Communicatie De meeste communicatie verloopt nog asynchroon. LCR wordt echter op TCP/IP gebruikt. TEDI10 is een Franse standaard voor telecommunicatie en informatie uitwisseling gedefinieerd in de [AFNOR] normen ZZ 66-010 en NF P 99-302. ZZ 66-010 definieert basic mode controle procedures voor data communicatie, inclusief data verwerking, uitwisseling en transmissie, en gecodeerde karakter sets. NF P 99-302 is een uitbreiding op ZZ 66-010 voor onder andere een adresseringsstructuur voor enkel- en meervoudige schakelingen, aanpassing aan verbindingen met lage snelheid en veel verstoringen (radio half duplex). De norm is vooral gericht op het inwinnen van verkeersgegevens en beperkt tot alfanumerieke berichten. 4.2.7 IVERA - Initiatiefgroep VERkeersregeltechnici ASTRIN Het IVERA-protocol is een Nederlands datacommunicatiestandaard voor verkeersregeltoestellen en de daarmee verbonden centrale computersystemen.

10

Deze afkorting wordt gehanteerd door o.a. SES voor deze norm, maar is in de documentatie van

[AFNOR] niet genoemd.


112

Door het implementeren van het IVERA-protocol zijn verkeersregelinstallaties en centrales van verschillende fabrikanten met elkaar te verbinden. Standaardisatie proces Het IVERA-protocol wordt breed gedragen. Het is opgesteld door vertegenwoordigers van het Rijk, de provincies (verzameld in het overlegplatform IVER), de gemeenten en de vier leveranciers van verkeersregelinstallaties (PeekTraffic, Siemens Nederland, TPA Traffic en Parking Automation en Vialis Verkeer en Mobiliteit) verenigd in de brancheorganisatie ASTRIN. De protocolspecificatie is overgedragen aan de Stichting Beheer IVERA Protocol, gevestigd te Zoetermeer. Om voor alle fabrikanten tot een acceptabele specificatie te komen zijn de afgelopen jaren al vele hindernissen genomen. Na het gereedkomen van de versie 1.30, in januari 1999, zijn de fabrikanten hun software gaan aanpassen. Kort daarna werden de regeltoestellen door de Stichting IVERA gecertificeerd. Een aantal fabrikanten ontwikkelde een IVERA module voor hun centrale. Bij het onderling testen van diverse merken regeltoestellen op andere centrales werden een aantal problemen geconstateerd die voortkwamen uit verschillen in interpretatie van het protocol. Ook werd de beveiliging tegen ongewenst inbellen op de regeltoestellen nog eens bekeken, wat resulteerde in een geheel nieuwe beveiliging. De onvolkomenheden in de versie 1.30 en de eisen betreffende de beveiliging zijn inmiddels vastgelegd in een addendum. Het IVERA-protocol wordt nu door de deelnemende partijen als stabiel, geloofwaardig en als goede basis voor de toekomst gezien, maar daarvoor hebben zij veel moeten investeren. 4.2.8 Data definities in XML - eXtensible Markup Language In een aantal producten en communicatie standaarden wordt XML (eXtensible Markup Language) toegepast voor data definities en berichten vanwege de flexibiliteit en generieke expressiviteit van deze taal. Deze sectie beschrijft enkele mogelijkheden van XML als taal voor de specificatie van DVM data definities. XML wordt in vele applicatie domeinen ook toegepast in de communicatie van berichten, maar dit aspect wordt hier niet beschouwd. De informatie in deze sectie is gebaseerd op een studie naar toepassingsmogelijkheden van XML voor data definities [TPD 020750]. Toepassingen van XML XML wordt in veel applicatie domeinen toegepast als standaard taal voor data definities en het uitwisselen van informatie tussen markt partijen. Domein specifieke XML data definities kunnen worden geregistreerd bij OASIS [XML Registry], bijvoorbeeld voorde automobiel industrie (SAE J2008), uitwisseling van logistieke informatie (TranXML), inter-systeem en inter-company product data integratie (PDTnet), financiële diensten (ebXML, BizTalk), energie (PIPE), utilities (BAML), petrochemie (POSC), scheepvaart (MTML). Voor uitwisseling van verkeersinformatie tussen het TIC en reizigers wordt XML ook toegepast in bijvoorbeeld het UTMC29B project in Reading, en zijn ook standaarden in ontwikkeling, bijvoorbeeld in Nederland (XML for Traffic Data Exchange [XML TRAIL]) en Ontario [TDML]. DATEX is een veel gebruikte standaard in ITS. DATEX is afgeleid van EDIFACT; een standaard uit de financiële sector die wordt vervangen door onder andere de genoemde XML standaards. In [Pond] wordt XML vergeleken met DATEX, en gesuggereerd als alternatief vanwege de grote flexibiliteit en toepasbaarheid van XML. In bijvoorbeeld het Courier project [TIH-DATEX] wordt XML in


113

combinatie met CORBA toegepast als alternatief voor DATEX en voor transformatie en representatie van DATEX informatie voor TIC. Communicatie - syntax en semantiek van berichten In de Applicatie Architectuur moeten software componenten communiceren met elkaar, maar ook met wegkantsystemen, externe applicaties en databases. Componenten communiceren door het aanroepen van eikaars services of procedures, of door het uitwisselen van berichten. Wanneer de gecommuniceerde informatie op verschillende wijzen wordt geïnterpreteerd en verwerkt, ontstaan communicatie storingen of wordt foutieve informatie gegenereerd. Deze problemen zijn niet altijd (direct) te detecteren of te diagnosticeren. Eenduidige specificatie van de syntax en de semantiek van de te communiceren informatie is daarom essentieel. Syntax is de definitie van data elementen en hun structuur in een bericht. Semantiek is de betekenis van de gecommuniceerde informatie. Data definitie in XML Een bericht is een gestructureerde verzameling van data elementen. De structuur van berichten kan worden gespecificeerd met XML. Hiertoe worden in XML data elementen geclassificeerd met etiketten (tags), de zogenaamde "markup". XML biedt de generieke mogelijkheid om deze tags voor specifieke toepassingsdomeinen te definiëren. XML is een taal voor formele definitie van data elementen en de hiërarchische structuur van deze elementen in een bericht. XML definieert een bericht in een standaard ASCII (Unicode) bestand of string (niet als binaire gegevens) en is daarmee zeer goed leesbaar voor personen en uitwisselbaar tussen software componenten, ln XML terminologie wordt de inhoud van een bericht beschouwd als een document. Een maatregel om een verkeerssymbool te tonen kan gezien worden als een domein specifiek concept. Dit concept kan nader worden beschreven door kenmerken voor de verkeerskundige toestand en het grafisch beeld met kleur, dimensies, en eventuele karakters. Zo'n verkeerskundig concept wordt gedefinieerd in een samengestelde datastructuur met deze kenmerken. Concepten worden veelvuldig toegepast in verschillende typen XML berichten, en kunnen eenmalig en eenduidig worden gedefinieerd in een DTD (Document Type Definition) of een XML Schema. In een DTD worden beperkingen op de structuur van data elementen en een vocabulaire van de toegestane tags gedefinieerd. Op basis van deze beperkingen kan de integriteit van een XML bericht automatisch worden geverifieerd. Een XML Schema is een uitbreiding op de DTD en maakt het mogelijk eigen data types te definiëren en beperkingen op de inhoud van data elementen vast te leggen, zoals een domein van mogelijke waarden. Transformatie tussen data definities In XML is de data en de structuur onafhankelijk gedefinieerd van de uiteindelijke wijze van presentatie. In een zogenaamde stylesheet wordt presentatie-specifieke informatie over het type XML bericht gedefinieerd. Een XML document wordt getransformeerd volgens de stylesheet om de inhoud van een bericht in het gewenste formaat te tonen. Deze techniek kan ook toegepast worden om de inhoud van een bericht naar een representatie van een andere leverancier of type actuator te transformeren. Stylesheets worden met de eXtensible Stylesheet Language (XSL) beschreven. Transformatie van XML documenten naar vele andere representaties, zoals CORBA IDL, is een generiek proces waarvoor standaard tools beschikbaar zijn, zoals het K2 Web Services Platform.


114

XML Tools Er zijn vele standaard producten voor het genereren, editten, parsen, en transformeren van XML documenten te verkrijgen, zowel gratis als commercieel. XMLSpy is een voorbeeld van een editor. Xerces en Xalan van Apache kunnen vanuit Java of C++ programma's XML documenten genereren, parsen, bewerken, en transformeren. Voor de integratie van XML met bestaande databases bestaan er ook al een reeks producten, zoals Tamino (Software AG). Met de XML Query taal kunnen aanvragen aan XML documenten gespecificeerd worden. Daardoor kunnen ze net als databases behandeld worden, zonder aan een bepaalde database implementatie vast te zitten. XML berichten en gegevens uit databases kunnen zo naadloos met elkaar worden gecombineerd. Betekenis en interpretatie van berichten Data elementen in berichten representeren domein specifieke concepten, zoals een maatregel, actuator en een verkeerssymbool. Achter de term maatregel schuilt een concept met een verkeerskundige betekenis, een motivatie (doel, prioriteit) en een procedure waarop ze uitgevoerd zou moeten worden. Deze aspecten zijn kenmerken van de maatregel zelf, of weer concepten op zich (recursie). De maatregel kan een beeld op verschillende typen actuatoren plaatsen. Het uiteindelijke beeld dat wordt gepresenteerd op een bord is een interpretatie van (een deel van) de maatregel, en is afhankelijk van de leverancier en de implementatie in de hard- en software. Concepten en kenmerken moeten eenduidig gedefinieerd worden om interpretatie fouten bij de uitvoering of implementatie van de maatregel te voorkomen. Een concept wordt niet alleen gedefinieerd door zijn kenmerken (zoals in een data definitie), maar ook door de relaties tussen, en kwalificaties van, deze kenmerken. Een voorbeeld van zo'n relatie is de vertaling (interpretatie) van een maatregel in een specifiek actuator beeld. Een definitie van domein specifieke concepten heet een ontologie, en wordt gedefinieerd in zogenaamde ontologie 'editors' zoals Protégé-2000. Ontologiën kunnen in verschillende formaten gerepresenteerd worden. Gebruikelijk zijn het Resource Description Framework (RDF) en de Ontology Web Language (OWL). Ze zijn gebaseerd op XML maar voegen een aantal abstracties toe aan DTD's en schema's, zoals uitgebreide beschrijving van relaties tussen concepten en beperkingen daarop. De semantiek van concepten en termen uit een specifiek domein kan daardoor eenduidig vastgelegd worden. Voor eenduidige communicatie moeten componenten berichten uitwisselen die zijn opgesteld volgens een wederzijds overeengekomen ontologie. De data definitie die gebruikt wordt in de berichten maakt deel uit van deze ontologie, en kan zonodig vanuit de ontologie apart worden gespecificeerd. Wat is de relatie tussen XML en MIB's? SNMP wordt toegepast in een aantal ITS communicatie standaarden. Hierin worden Management Information Bases (MIBs) toegepast om de data elementen te definiëren die gecommuniceerd kunnen worden via SNMP. MIBs zijn ook hiërarchisch gestructureerd voor objecten waarvan de data elementen gedefinieerd worden, evenals in XML. De semantiek van de definities en concepten (ontologie) zijn echter niet in de MIB te definiëren, terwijl XML wel gekoppeld kan worden met een ontologie definitie. Een tweede potentieel nadeel is dat de data typen en elementen in een MIB gebaseerd zijn op de internet netwerk management ontologie; het oorspronkelijke domein van SNMP. Deze terminologie verschilt van het domein van verkeerskunde. In XML


115

kan de terminologie wel specifiek voor het AVB, DVM of ITS domein gedefinieerd worden, waardoor de kans op interpretatie fouten reduceert. Een derde verschil is dat een MIB een representatie vorm van data definities is die intrinsiek verbonden is aan SNMP, terwijl XML als tekst in vele protocollen direct leesbaar en (her)bruikbaar is. Communicatie van XML berichten

Behalve voor het specificeren van data definities kunnen berichten ook direct in XML worden verstuurd en opgeslagen. Dit kan zowel over gestandaardiseerde protocollen, zoals HTTP, als ook bij het versturen van berichten tussen CORBA componenten, of met SOAP [SOAP] dat speciaal is ontwikkeld voor XML communicatie. De consequenties van het gebruik van XML op de communicatie aspecten voor DVM zijn echter niet nader onderzocht in dit project, en aanvullend onderzoek is aan te bevelen. Betekenis voor D V M systemen

XML is een breed toegepaste taal om data definities te specificeren, en wordt ook voor verkeersmanagement- en verkeersinformatiesystemen toegepast. XML is zowel voor de mens als elektronisch eenduidig en goed leesbaar en kan daardoor in vele producten, programmeertalen en communicatie protocollen geïntegreerd worden. Een groot voordeel is dat het begrippenkader en verkeerskundige concepten ook gedefinieerd kunnen worden en daarmee direct gekoppeld zijn aan de (interpretatie van) data definities en berichten. Daarnaast kunnen berichten direct in XML gecommuniceerd worden en in standaard databases worden opgeslagen. Er is een brede keuze van tools en veel support van vele software bedrijven. 4.2.9

CORBA naar het wegkantstation

In de ACT is geen restrictie aan de locatie van software componenten gesteld, en kunnen deze zowel in een verkeerscentrale als in wegkantstations draaien. Hiertoe moet een transparante software bus, de CORBA middleware laag, vanuit de verkeerscentrale naar de wegkantstations doorgetrokken zijn. CORBA wordt al toegepast in de verkeerscentrale in verschillende producten uit de shortlist en DVM projecten, zoals VANESSA, UTMC29C en OCIT. In deze systemen is de CORBA bus niet doorgetrokken naar de wegkantstations en kunnen de componenten ook niet daar naartoe gedistribueerd worden. ER zijn slechts 2 producten als totaaloplossingen gevonden die de CORBA bus doortrekken buiten de verkeerscentrale (zie 3.8). Stel nu dat de CORBA bus op VicNet(+) wordt doorgetrokken naar de wegkantstations, dan worden een aantal aspecten relevant voor de applicaties en software componenten. Een aantal relevante aspecten worden hier samengevat uiteen aanvullende studie in [TPD 020738]. Technische aspecten en implicaties voor de TIAV worden hier niet beschouwd. interoperabilitieit op het wegkantstation

Het hoofdpunt in wegkantstation interfacing is standaardisatie: een voldoende generiek wegkantstation interface levert zowel flexibiliteit als een leverancier/fabrikant neutrale oplossing. Dit resulteert in een lagere cost-ofownership, grotere onafhankelijkheid van leveranciers, betere onderhoudbaarheid en daarmee ook een grotere beschikbaarheid, etc. Er zijn verschillende benaderingen mogelijk om een wegkantstation interface te standaardiseren, bijvoorbeeld een http protocol gebaseerde cliënt-server benadering, synchroon of asynchroon messaging, of procedurele abstractie.


116

De CORBA (interoperabiliteit) standaard is gebaseerd op een gedistribueerd object PARADIGMA, een krachtig raamwerk waarbij interacties worden vastgelegd en geïmplementeerd in een gedistribueerd computernetwerk. CORBA biedt enerzijds verscheidene interactiemogelijkheden en services aan de applicatieontwerpers en -ontwikkelaars. Anderzijds stelt de CORBA runtime infrastructuur relatief hoge eisen en genereert onvermijdelijk operationele overhead, zowel op de locale computer als op het netwerk. Potentiële voordelen van CORBA

CORBA heeft met name voordelen als; • er een component gebaseerd systeemontwerp en ontwikkeling wordt gevolgd, en/of • de applicatie gestructureerd is volgens een zekere "gedistribueerde intelligentie", en/of • het gedistribueerd object gebaseerd rekenmodel volledig wordt benut door de applicatiearchitectuur. Hierbij biedt CORBA ondersteuning voor betrouwbaarheid, robuustheid, load balancing, fout tolerantie, e.d. Het herontwerp van de applicatiearchitectuur van het verkeersmanagementsysteem zal vermoedelijk volgens bovenstaande elementen plaats vinden. Communicatie overhead en netwerk belasting

De meeste CORBA implementaties gebruiken NOP (internet inter-ORB protocol) voor object interacties. Typisch is HOP op TCP/IP gebaseerd en derhalve kan CORBA worden geïmplementeerd op TCP/IP netwerken zoals het VicNet. Zoals ieder protocol en servicelaag, introduceert ook CORBA extra data handling en processing en dus genereert CORBA overhead. Deze overhead kan worden toegerekend aan het processen op het locale CORBA runtime platform en de extra communicatie over het netwerk. Zelfs wanneer de CORBA gebaseerde communicatie wordt geoptimaliseerd kan dit niet zo effectief worden als voor een zuiver message-gebaseerd systeem. Niettemin kan de overhead worden gekwantificeerd en als ontwerpparameter voor het systeem worden meegenomen. De netwerk gerelateerde overhead is onder andere afhankelijk van de grootte, aantal en frequentie van berichten tussen de CORBA componenten. CORBA wordt veelal toegepast en in benchmarks vergeleken op high-speed netwerken (typisch 10Mbps of meer), waarop deze overhead geen serieuze factor op de communicatie zal zijn (behalve wellicht in extreme gevallen). Het huidige VicNet, met 64kbps TBMS segmenten, die elk gedeeld worden door maximaal 14 wegkantstations, is daarmee vergeleken een relatief langzaam netwerk, waarop de overhead wel relatief groot kan worden. Het lijkt echter mogelijk om de huidige MTM functionaliteiten te implementeren in een CORBA gebaseerde API. Anderzijds zal de huidige VicNet infrastructuur een "full-blown"gebruik van CORBA faciliteiten en services, zoals voorzien in de AA, beperken, en wellicht is het huidige netwerk ontoereikend. Deze inschattingen van de netwerkbelastingen op het VicNet zijn echter kwalitatief en gebaseerd op globale schattingen van het huidige MTM systeem. Het is echter wel een belangrijk punt van aandacht. Nader onderzoek naar de kwantitatieve gegevens en eisen voor de AA en VicNet(+), zoals de netwerkbelasting, responsetijd en quality of service, is dan ook aan te bevelen om hier een duidelijke uitspraak over te kunnen doen. Real-Time aspecten


117

Real-Time CORBA (RT-CORBA) garandeert end-to-end quality of service (QoS) aan bepaalde CORBA services en biedt ondersteuning voor real-time gerelateerde concepten in het gedistribueerde object domein, bijvoorbeeld scheduling, thread-pools, of prioritering. Het is belangrijk om te realiseren dat RT-CORBA geen wonderolie is. In het bijzonder is het zo dat RT-CORBA niet een non-real-time operating system of communicatie infrastructuur kan transformeren in een platform met een compleet deterministisch gedrag. Mits in de correcte setting toegepast kan RT-CORBA functionaliteit bieden om heterogene systemen zodanig te configureren dat end-to-end prioriteit zeker gesteld wordt. Het zal significante kosten met zich meebrengen om een dergelijke infrastructuur met RT-CORBA services in te richten. De huidige M T M verkeersmanagement applicatie is geen hard real-time systeem. De tijdeisen zijn relatief laag en de computationele processing eisen op het wegkantstation lijken matig. Onder deze omstandigheden beantwoord een zorgvuldig ontworpen best-effort service op het wegkantstation (gegeven een mainstream pre-emptive multitasking operating system zoals Linux of Windows NT) aan de applicatie eisen als computer knooppunt. De huidige infrastructuur (VicNet(+)) biedt volgens de huidige inzichten geen QoS faciliteiten. Daarom zal zelfs een RT-CORBA op VicNet geen end-to-end QoS kunnen garanderen. Als de bandbreedte sterk kan worden verhoogd tot een "relaxed sustained load" operationele mode dan zal de end-to-end QoS geen kritische factor meer zijn. Wanneer deze toename niet haalbaar is en/of een strikt resource gebruik gehandhaafd moet worden, dan moet de hele netwerk infrastructuur opgewaardeerd worden met QoS-"aware" componenten en alle computerknooppunten dienen ook QoS-"aware" te zijn. Een alternatief zou kunnen zijn om de netwerkinfrastructuur te voorzien van QoS-"aware" componenten waarbij het mogelijk is om virtuele netwerken te parameteriseren. Op deze wijze is het mogelijk om voor bepaalde applicaties (componenten) vrijwel hard real-time response tijden te garanderen terwijl op andere virtuele netwerken een best effort service beschikbaar is. CORBA Standaard(en) Real-time CORBA is nu opgenomen in de specificatie van CORBA 2.4 en daarmee is real-time CORBA nu door de OMG opgenomen in de standaard. De CORBA 2.4 specificatie verschilt met 2.3 vooral op de Quality of Service aspecten zoals asynchroon messaging met quality of service control, minimum CORBA met name voorembedded systemen, en Real-Time CORBA met prioritering van threads, protocollen en connecties. Er zijn een aantal object request brokers (ORBs) op de markt, of als open source verkrijgbaar, die real-time CORBA functionaliteit bieden, zoals Borland Visibroker, ORB Express, TAO, e*ORB en Orbix. Het is de verwachting dat de komende CORBA specificaties nog flinke uitbreidingen zullen brengen ten aanzien van Real-Time CORBA. De huidige en aan veranderingen onderhevige CORBA 3.0 specificatie geeft zicht op de voorgenomen nieuwe functionaliteit. Voor Real-time CORBA is dit op het gebied van dynamische scheduling en distribueerbare threads. Verder op de horizon wordt functionaliteit voorzien voor real-time notification, ondersteuning voor de Unified Modelling Language (UML), transactions, security en fout tolerantie. Betekenis voor AVB en ACT


118

Het doortrekken van een CORBA middleware naar de wegkantstations biedt met name voordelen wanneer de applicaties op de wegkantstations integraal deel moeten zijn van een geografische gedistribueerd platform van (intelligente) software componenten. Daarnaast is ook de relevantie van realtime CORBA op het wegkantstation kwalitatief beschouwd en lijkt een besteffort service op het wegkantstation voldoende voor de momenteel beoogde verkeerskundige applicaties. 4.2.10 CORBA in DVM systemen In meer algemene zin kunnen nog enkele waarnemingen worden gemaakt over toepassing van CORBA in DVM systemen, onafhankelijk van toepassing in wegkantsystemen zoals hiervoor is behandeld. CORBA is geen communicatie standaard, zoals NTCIP, maar een hoog niveau communicatie kanaal (software bus) waarover gecommuniceerd kan worden. Hierop moet nog een applicatie standaard gedefinieerd worden in de vorm van data en interface definities. Zonder deze definities biedt CORBA geen basis voor product ontwikkeling en integratie door leveranciers. In de VS wordt in het kader van NTCIP ook CORBA toegepast. De ervaring daar is dat de ontwikkeling van componenten rondom CORBA middleware niet ongeregiseerd overgelaten kan worden aan marktpartijen. Dat resulteert in interpretatie en integratie problemen. Een goede beheersing van het ontwikkelingsproces van de Applicatie Architectuur, in combinatie met de ontwikkeling van CORBA interfaces en de technische infrastructuur is essentieel. Met andere woorden; een eenduidige definitie van componenten en interfaces op de middleware vereist een integraal ontwerp van de onderliggende infrastructuur (zoals transport protocollen) en de bovenliggende applicatie componenten. Een tweede ervaring uit NTCIP is dat in een gedistribueerd systeem aanpassingen aan componenten, de bijhorende data en interface definities, en de successievelijk aanpassingen aan communicerende componenten, een complex, recursief en moeilijk te onderhouden probleem blijkt te zijn. Versiebeheer is vooral een organisatorisch probleem. Het is niet duidelijk in hoeverre hierbij gebruik is gemaakt van technische oplossingen zoals dynamic invocations. De CORBA standaard is nog relatief jong en in ontwikkeling. Er bestaan nog interpretatie en implementatie verschillen tussen de verschillende ORBs en ontwikkeltools, waardoor de bedoelde voordelen voor interoperabiliteit worden beperkt. Wederom is een goede regie in de ontwikkeling en onderhoud van een gedistribueerd systeem essentieel. 4.2.11 Bevindingen en conclusies In Sectie 4.2 zijn een aantal waarnemingen vermeld over standaardisatie van communicatie in DVM systemen die worden toegepast in een aantal shortlist producten in hoofdstuk 3. In deze sectie, en in dit project, is dan ook geen objectieve evaluatie gemaakt van communicatie standaarden, en wordt dan ook geen conclusie of aanbeveling gedaan over een geschikte standaard voor de AA. Allereerst zijn een aantal DVM communicatie standaarden uit verschillende landen beschreven. Daarna is XML beschreven als een sterk opkomende trend


119

als specificatie en communicatie taal. In de AA en ACT is CORBA gekozen als middleware communicatie bus. In de laatste secties zijn enkele aspecten beschouwd voor toepassing buiten verkeerscentrales en meer algemene ervaringen bij toepassing voor DVM. Tot slot is de betekenis van deze waarnemingen voor de Applicatie Architectuur geïntegreerd. DVM Communicatie standaarden In Nederland is geen nationale standaard voor informatie of data communicatie voor verkeersbeheersing op het hoofdwegennet. Hiertoe zijn wel initiatieven ontplooit maar dat heeft nog niet tot standaarden geleid. Wel is er een standaard voor verkeersregelinstallatie IVERA. In naburige landen zoals Duitsland, Frankrijk en Engeland zijn wel nationale standaarden ontwikkeld voor applicatie en communicatie protocollen voor verkeersbeheersing op het hoofdwegennet. In Engeland en Duitsland zijn respectievelijk de standaarden NMCS2 en TLS voorgeschreven. Dit zijn standaarden voor communicatie en transport protocollen met wegkantsystemen en die sterk zijn gebaseerd op de gebruikte verbindingen en hardware. De infrastructuur is te typeren als een geografisch wijd verspreid netwerk met lage transportsnelheden en van mindere kwaliteit (o.a. telecontrol). De protocollen zijn vooral ontwikkeld op minimale bericht grootte, robuustheid en betrouwbaarheid. Door de beperking van de infrastructuur en de protocollen worden ook significante beperkingen op de te communiceren informatie opgelegd (OSI lagen 6 en 7). Deze beperkingen zijn zowel kwalitatief (expressiviteit van informatie en grafische informatie) als kwantitatief (transport snelheid en bandbreedte). Gezien deze beperkingen lijken deze standaarden niet geschikt voor een nieuwe DVM benadering in Nederland. In Frankrijk is een breder scala van protocollen in gebruik naast de nationale standaarden zoals LCR. LCR is een uitgebreide standaard voor het applicatie protocol voor definitie en communicatie van ITS informatie. De relevantie en toepasbaarheid van deze standaarden voor de AA zijn echter onvoldoende diep onderzocht. In Spanje is begonnen met een nieuwe glasvezel communicatie netwerk met het SDH protocol. Met SDH zijn snelheden van 155 Mbps tot 600 Mbps mogelijk. Daarmee kan multimedia informatie worden getransporteerd, waaronder video beelden van surveillance camera's en grafische beelden naar actuatoren. Teneinde interoperabiliteit ('interoperability') en uitwisselbaarheid ('interchangability') van verkeerssystemen te realiseren heeft de Amerikaanse overheid in een succesvol samenwerkingsverband met de industrie de NTCIP standaard gedefinieerd. NTCIP bestaat uit een familie van protocollen voor communicatie tussen centrales onderling en met wegkantapparatuur. NTCIP is een standaard in ontwikkeling. Een aantal protocollen zijn al gedefinieerd en operationeel, andere protocollen uit de familie zijn nog in ontwikkeling. In het Verenigd Koninkrijk en Duitsland zijn gelijkaardige initiatieven opgestart met UTMC en OCIT. Deze programma's zijn echter nog volledig in de ontwikkelings- en prototype fasen. UTMC en OCIT beperken zich voorlopig tot verkeersregeling in stedelijke gebieden, maar uitbreiding voor het hoofdwegennet is wel voorzien op termijn. NTCIP is echter primair gebaseerd op de Amerikaanse situatie, waarin bijvoorbeeld geen


120

wegkantstations worden gebruikt11. Dit is een probleem voor Nederland, maar ook voor Engeland en Duitsland. Vanwege die verschillen is het in UTMC en OCIT noodzakelijk bevonden om nationale specialisaties van, en uitbreidingen op, de NTCIP standaard door te voeren. • UTMC gebruikt alleen SNMP en geen STMP. XML wordt in een pilot toegepast voor communicatie. • OCIT maakt geen gebruik van SNMP of STMP, maar definieert eigen protocollen. Data definities worden ontwikkeld in XML vanwege de flexibiliteit en bredere verspreiding van deze standaard dan SNMP en MIBs. In tegenstelling tot NTCIP en UTMC lijkt OCIT vooral door de industrie gecoördineerd en ontwikkeld en te worden en lijkt de rol van de overheid beperkter te zijn. Daar waar standaard protocollen succesvol worden toegepast, zijn deze standaarden ontwikkeld in een samenwerkingsverband van overheid en industrie. XML Data definities kunnen eenvoudig en eenduidig gespecificeerd worden in XML. Ook domein specifiek concepten, beperkingen en andere relaties op data elementen kunnen gerepresenteerd worden. XML is generiek toepasbaar en wordt in een groot aantal producten en communicatie standaarden al gebruikt. XML wordt ook in een aantal DVM producten en projecten toegepast ter voorbereiding op DVM communicatie standaarden. Vele software ontwikkel tools en database interfaces zijn hiervoor beschikbaar. CORBA Een aantal aspecten van het doortrekken van CORBA van de verkeerscentrale naar de wegkantstations zijn beschouwd. CORBA biedt met name voordelen als communicatie platform indien het wegkantstation essentieel onderdeel wordt van een gedistribueerde architectuur waarin ook (intelligente) software componenten op het wegkantstation draaien. De communicatie overhead die wordt geïntroduceerd door CORBA, en de gewenste quality-of-service, zou een probleem met de capaciteit van VicNet kunnen opleveren voor een Applicatie Architectuur implementatie. Enkele relevante aspecten voor real-time CORBA op het wegkantstation zijn beschouwd; een best-effort service op het wegkantstation lijkt voldoende te zijn voor de momenteel beoogde verkeerskundige applicaties. Nader onderzoek is nodig om deze kwalitatieve inschattingen te kunnen kwantificeren. Betekenis voor communicatie in Applicatie Architectuur Door verschillende marktpartijen is de wens voor een communicatie standaard kenbaar gemaakt, waarop producten ontwikkeld kunnen worden, waarbij RWS wordt aangezien als de partij die hiervoor het initiatief zou moeten nemen. In analogie met bovenstaande bevindingen lijkt de volgende benadering voor standaardisatie in Nederland aangewezen": • Benut de grote inspanningen en ervaringen van standaardisatie processen in andere landen door een bestaande standaard als uitgangspunt te nemen en die voor de nationale situatie aan te passen.

11

Uit persoonlijke communicatie met Amerikaanse bedrijven blijkt dat wel wordt overwogen om een

wegkantsysteem in de architectuur en NTCIP te introduceren. 12

Hierbij moet expliciet worden opgemerkt dat standaardisatie geen onderdeel uitmaakt van dit

project en dat nader onderzoek naar de realiseerbaarheid en wenselijkheid van de benadering vereist is


121

•

In analogie met het Engeland en Duitsland lijkt NTCIP een goed uitgangspunt voor een standaard die moet worden aangepast aan onze architectuur en bestaande infrastructuur. Ook de relatie met de Europese architectuur standaard [KAREN] zou daarbij behouden moeten blijven (zie bijvoorbeeld [UTMC29 A en D]). Het in de AA gekozen concept van (geografisch) gedistribueerde software componenten langs de wegkant is nog niet of beperkt opgepakt in de standaardisatie initiatieven en onderliggende architecturen die in dit hoofdstuk zijn beschouwd. De keuze voor dit concept is mede bepalend voor de keuze van een communicatie standaard op basis van CORBA of bijvoorbeeld SNMP. • Een component gebaseerd systeem met een CORBA middleware biedt technische voordelen, zoals een hoge graad van interoperabiliteit en flexibiliteit in de communicatie tussen componenten en verkeerskundige applicaties. Het stelt echter ook hogere eisen aan de producten en communicatie standaard, en aan de organisatie van systeembeheer en het standaardisatie proces. • CORBA kan over een TCP/IP netwerk, zoals het VicNet, naar de wegkantstations worden doorgetrokken. De capaciteit en de quality of service van het huidige VicNet moeten waarschijnlijk worden verbeterd voor de eisen van de AA. Nader onderzoek is echter noodzakelijk voor een nauwkeurige kwantificering hiervan. Voor de specificatie van data definities, berichten uitwisseling, en de betekenis van data in de communicatie en verwerking is XML een geschikte taal. XML is niet gebonden aan een communicatie standaard, en wordt in vele branches als standaard gebruikt voor specificatie, communicatie en database koppelingen.

4.3 Marktverkenning PLC/SCADA/DCS/ Industriële computers 4.3.1 Inleiding Een aanvullende marktverkenning [ICT] is uitgevoerd naar PLC, SCADA, DCS en Industriële Computer systemen die geschikt zijn voor het Universele Weg Kant Station (UWKS). De componenten van een UWKS bestaan uit; processing unit, actuatoren en sensoren. Voor de connecties van deze is er ook een verkenning gedaan naar communicatiesystemen en veldbussen. 4.3.2 Veldbussen Communicatiesystemen hebben reeds een lange historie in de kantoorautomatisering waar ze veelvuldig zijn toegepast. Dit zijn echter geen realtime communicatiesystemen, daar er geen gegarandeerde transport- en update-tijd is van het berichtenverkeer. Daarentegen hebben de industriële veldbussen wel een gegarandeerde transport- en update-tijd en deze zijn meer geschikt voor realtime systemen. Daarnaast bieden de veldbussystemen een grote diversiteit aan koppelingsmogelijkheden naar de actuatoren en sensoren. Er zijn duidelijke standaarden gedefinieerd voor de veldbussystemen, hetgeen een grote compatibiliteit garandeert. 4.3.3 Programmable Logic Controllers (PLC) PLC systemen hebben hun oorsprong als vervanger van de relais besturingstechniek en hedendaagse PLC systemen zijn krachtige besturingscomputers voor de besturing en registratie van industriële processen


122

met sterke realtime eigenschappen. PLC systemen worden op een eenvoudige wijze gekoppeld met veldbussystemen, waarbij slechts configuratie noodzakelijk is om de veldsignalen in te lezen in het PLC geheugen of de uitgangssignalen naar het veld te versturen. Ook voor de koppeling van de PLC naar de bovenliggende systemen als SCADA of industriële computers biedt de PLC goede interfaces d.m.v. seriële lijnen of communicatiebussen als veldbussen of ethernet. Daarnaast is de PLC uitermate geschikt voor realtime besturingen en de registratie van procesdata; hiertoe kan men de gestandaardiseerde programmeertaal (IEC 61131 -3) gebruiken die door PLC leveranciers wordt ondersteund. 4.3.4 Supervisory Control And Data Acquisition (SCADA) SCADA systemen worden gebruikt voor het verzamelen, beheren en uitwisselen van procesgegevens en voor procesvisualisatie. Ze zijn opgebouwd uit een SCADA server en één of meerdere SCADA clients voor visualisatie en bediening. De SCADA server is een uniforme intermediair tussen de besturingssystemen en bovenliggende systemen, daarnaast kan de SCADA server verschillende signalen bewaken op grenswaarden en alarmen genereren bij het onder- of overschrijden van de grenswaarden. 4.3.5 Distributed Control Systems (DCS) DCS systemen hebben hun oorsprong in de chemische en petrochemische industrie en zijn ontworpen voor het besturen en beheersen van grote continue processen met veel signalen van en naar het veld (actuatoren en sensoren). DCS-en zijn gedistribueerde besturingssystemen waarbij de bediening en visualisatie op het centrale systeem plaats vinden en de besturingsmodules, inclusief de koppeling naar het veld, decentraal in het veld zijn opgesteld. Kenmerken van DCS systemen zijn: veel I/O (veldsignalen), korte responsetijden, grafische interface, dedicated hardware en software. Het laatste kernmerk maakt dat de DCS systemen niet zo open en uitwisselbaar zijn als de overige systemen en duurder. 4.3.6 Industriële computers "Industriële computers" is een verzamelnaam voor computers die geschikt zijn voor een industriële omgeving, waar computers onder zwaardere condities moeten functioneren dan in een kantooromgeving. Daarnaast worden ook hogere eisen gesteld aan de betrouwbaarheid van een industriële computer t.o.v. een kantoor PC. In de verkenning zijn de CompactPCi, VME en industriële PC's van de industriële computersystemen beschouwd. Alle systemen zijn zeer open en kunnen flexibel worden opgezet, zowel softwareals hardwarematig. Dit brengt echter met zich mee dat er meer inspanning nodig is voor de koppeling naar het veld waar de actuatoren en sensoren zich bevinden. 4.3.7 Conclusies Uitgaande van het palet aan systemen die binnen deze verkenning onder de loep zijn genomen en op grond van kosten, flexibiliteit en betrouwbaarheid is het advies voor de opbouw van het wegkantstation in drie delen opgezet. 1. De veldbus wordt gebruikt voor de koppeling van de actuatoren en sensoren. Voor veldbussen als b.v. Profibus of CANbus zijn vele


123

componenten op de markt verkrijgbaar. In de toekomst kan men de leverancier van de actuatoren en sensoren vragen deze te voorzien van een veldbus-interface, hetgeen vermindering van hardware componenten geeft. 2. Deze veldbus sluit men dan aan op PLC's voor het inlezen van de sensoren en het sturen van actuatoren. De veldbus en zijn componenten13 worden eenvoudigweg geconfigureerd voor de koppeling naar actuatoren en sensoren met digitale, seriële en veldbus interfaces. In de PLC wordt de benodigde functionaliteit geprogrammeerd voor het uitvoeren van maatregelen e.d. 3. De PLC's worden wederom aangesloten op een SCADA of OPC server zodat er een uniforme intermediair ontstaat vanuit de boven liggende systemen naar de wegkantstations. Dit geeft een eenduidig interface ongeacht hoe de verschillende wegkant systemen zijn opgebouwd.

4.4 Ervaringen in andere branches Een aantal branches kent systemen en processen die vergelijkbaar zijn met DVM. In het kader van dit project zijn beurzen en bedrijven uit enkele branches bezocht. Daarnaast is informatie opgenomen van gesprekken met bedrijven, websites en eigen ervaringen. De bevindingen worden hier per branche beschreven. 4.4.1 Rail Infrastructuur Inleiding Bij de NS wordt het treinverkeer gestuurd en begeleid vanuit centrale en lokale posten. Daarbij wordt een groot aantal systemen gebruikt. In deze paragraaf wordt voornamelijk ingegaan op het primaire proces: het laten rijden van treinen. Werkwijze en toegepaste systemen De procesleiding concentreert zich op de aankomst en het vertrek van treinen op stations. De trajecten tussen de stations worden automatisch bewaakt en bestuurd. De procesleiders zorgen voor een vrij perron voor aankomst en een vrije baan voor vertrek. Er wordt gewerkt vanuit een centrale planning die opgesteld wordt door verkeersleiders. Elke trein heeft een identificatie die overeenkomt met de planning. Een trein mag pas binnenlopen als de rijweg naar het perron vrij is. Het werkproces is voor de vertrekkende treinen in principe niet anders dan vroeger. In het verleden (zonder automatische hulpmiddelen) werden de treinen letterlijk begeleidt. De procesleider zette op een centraal paneel voor de trein de wissels in de juiste stand. Nu gaat dat hetzelfde met geautomatiseerde systemen. De procesleider blijft echter op z'n plek zitten. Het systeem bewaakt ook mogelijke fouten. De verkeersleider geeft het teken voor vertrek aan de trein nadat de trein een vrije rijweg toegewezen heeft gekregen en het systeem zorgt ervoor dat de wissels in de juiste stand staan. Naast verkeersleiding kent men ook objectbediening en bewaking (tunnels en bruggen).

13


Dit zijn geen software componenten in de zin van ACT en 4.1.1

124

Verkeersleider Ten eerste dient de verkeersleider bij een verstoring maatregelen te nemen om de treindienst toch zo veel mogelijk volgens plan te laten verlopen. Verder stelt hij de prioriteiten in het vervoer en bepaalt hij welke aansluitingen gehandhaafd moeten blijven. Bovendien neemt de verkeersleider maatregelen bij pieken in het reizigersaanbod en besluit hij of er meer of minder materieel per trein moet worden ingezet. Elke dag ontvangt de verkeersleider het plan voor de komende twee dagen. Hij kan dus pas twee dagen van tevoren een trein inplannen. We noemen dat 'een trein inleggen'. Het komt ook voor dat treinen al langer van tevoren bekend zijn. Deze treinen worden centraal in de planning opgenomen. De verkeersleider vergelijkt voortdurend het plan met de werkelijkheid. Zodoende weet hij waar hij moet bijsturen. Dat bijsturen gebeurt tegenwoordig volledig met de computer Als de verkeersleider het plan aanpast dan geeft de computer dit door aan zijn collega-verkeersleiders. Zo is elke verkeersleider voortdurend op de hoogte van de actuele situatie in het hele land. Een verkeersleider mag dan een eigen werkgebied hebben: de vervoersstromen beperken zich natuurlijk niet tot zijn eigen gebied. Daarom is de verkeersleider ook verantwoordelijk voor de aangrenzende gebieden. Tezamen sturen de verkeersleiders de totale vervoerstroom. Het Landelijk Coördinatiecentrum Verkeersleiding het LCVL speelt bij dit alles een coördinerende en adviserende rol. Het LCVL is verantwoordelijk voor de uitvoering van centraal gemaakte tijdelijke regelingen en buitendienststellingen. Procesleider Samengevat heeft de procesleider de volgende taken: Ten eerste een planningstaak. De procesleider plant rangeerbewegingen en bepaalt het spoorgebruik op het emplacement. Hij plant de rijwegen voor extra treinen en verwijdert geplande rijwegen voor opgeheven treinen. Hij zorgt ervoor dat het procesplan up to date is en vrij van conflicten. Op de tweede plaats heeft de procesleider een bedientaak. Hij stelt rijwegen in en binnen afgesproken grenzen bewaakt hij de aansluitingen voor de reizigers en de samenstelling van het materieel. De derde taak van de procesleider is een communicatietaak. De procesleider informeert belanghebbenden over afwijkingen en geeft daarnaast standaardmeldingen en veiligheidsberichten door. Hij overlegt met verkeersleiders, de materieelregelaar, machinisten, rangeerders, de perronopzichter en andere betrokkenen. Ten vierde heeft de procesleider een veiligheidstaak. Bij storingen roept hij de storingsdienst op. Hij maakt afspraken met de werkers aan de infrastructuur en legt deze afspraken vast. Vervolgens voert hij ze door in de beveiliging zodat op het betreffende baanvak geen treinen kunnen rijden. De procesleider bevestigt de buitendienststelling via de zogenaamde lastgeving. Coördinator Voor alle door procesleiding te bedienen gebieden moet er een verantwoordelijke procesleider aanwezig zijn. De coördinator, ook wel teamleider of werkverdeler genoemd, zorgt er voor dat al deze gebieden zijn toegewezen aan de aanwezige procesleiders. Hij gebruikt hiervoor het


125

werkverdelingsscherm van VPT-procesleiding. Zodra er een procesleider uitlogt en er geen nieuwe procesleider voor in de plaats komt wordt dit gemeld op zijn scherm. Als er nieuwe procesleiders op een post komen werken zorgt de coördinator er voor dat deze toegang krijgen tot VPT-procesleiding. Mocht het nodig zijn dan kan hij de gebruikersrechten wijzigen van gebruikers bijvoorbeeld omdat de gebruiker na een opleiding ook veiligheidstaken mag uitvoeren. Tevens zorgt de coördinator er voor dat er een vervanger komt bij ziekte van een postmedewerker. Procesleiding moet iedere dag voorzien worden van een nieuw procesplan rijwegen. Dit plan komt van LokaalPlan en moet worden overgehaald, gecontroleerd en in het systemen worden geladen. Hiervoor is ook de coördinator verantwoordelijk. Als een procesleider problemen heeft bij de uitvoering van zijn taak kan de coördinator hem hierbij helpen, hetzij door zijn ervaring of hij kan het opzoeken of navragen. Hiervoor heeft de procesleider zelf minder of geen tijd omdat de rest van het treinproces moet doorgaan. Grote knooppunten kunnen door meer dan één procesleider tegelijk worden bediend. Dit kan echter tot conflicten tussen deze procesleiders leiden. De coördinator lost deze problemen op en heeft het laatste woord hierin. Als er met één van de systemen een technische probleem is zal de coördinator proberen de gevolgen hiervan te minimaliseren door bijvoorbeeld een reserve systeem te laten gebruiken. En hij zal het probleem bij de storingsorganisatie aanmelden en het verloop hiervan volgen. Systemen Productplanning Verkeers-

Icidcr

iVKÖ!

>

VPT

Dag procesplan systeem

Proccsleidcr rijwegen

Post 21 BEPAC-i plan |

öPRÜi

'sINV;:

;

BEF»ACJ

.. +

CTA-bakken en ha [aanwijzer

J.

t

8KEV.':

laaul EBS

bestiirirsg beveiliging

i

VPf

B-relais

Elementen

Figuur 15: Systemen voor rail infrastructuur In Figuur 15 wordt een overzicht gegeven van de diverse systemen. De genoemde systemen hebben de volgende hoofdfuncties: BEPAC CTA EBP EBS


BEdiening Paletten Centrale aanwijzers Centraal gestuurde TreinAanwijzer Elektronische BedienPost voor VPT Elektronische Bedienpost Siemens

126

KEV PRL TNV(V) VKL

Koppeling EBS VPT ProcesLeiding TreinNummer Volgsysteem VerKeersLeiding systeem

Naast het hierboven beschreven systeem wordt nog een aantal systemen ingezet. Kenmerkend is dat gestandaardiseerd is op hard- en software producten van DEC. De applicatie architectuur van rail infrastructuur systemen is onlosmakelijk verbonden met de technische infrastructuur. Voor de bedienposten worden 'traditionele' terminals gebruikt. Betekenis voor DVM systemen De systemen bij de NS zijn in opdracht van de NS ontwikkeld waarbij intensief gebruik wordt gemaakt van de hard- en software producten van DEC met uitgebreide middleware faciliteiten. Van de NS kan geleerd worden dat sterkere standaardisatie een goede basis is voor de samenwerking tussen systemen. Ook zijn er verschillende communicatiemiddelen in gebruik, er wordt onderscheidt gemaakt tussen communicatie binnen een toepassing op een hardware systemen, proces communicatie binnen één hardware systeem, en communicatie tussen toepassingen over meerdere hardware systemen. De systemen en het werkproces zijn anders, maar van de NS kan wei geleerd worden dat een solide basis voor de TIAV noodzakelijk is en dat het goed mogelijk is om deze bij één leverancier te betrekken, uiteraard met de nodige nadelen en voordelen. 4.4.2 Railvoertuigen Situatie Er wordt doorgaans onderscheid gemaakt tussen twee soorten railvoertuigen: • Getrokken materieel, waarbij een locomotief een aantal wagons voorttrekt of -duwt; • Zelfaangedreven materieel (ook wel EMU: Electrical Multipe Units) waarbij (vrijwel) elk voertuig beschikt over een eigen aandrijving. In het kader van de management systemen voor gedistribueerde toepassingen is vooral de tweede groep relevant De besturing van zelfaangedreven treinen werd tot een aantal jaren geleden gerealiseerd middels relais, die werden aangestuurd vanuit de voorste cabine middels 'treindraden', binaire 110 V stuurdraden die door alle treinstellen heen liepen en ook over de koppelingen, waardoor de besturingscommando's over de gehele lengte van de gehele trein beschikbaar waren. Uitval van een tractie installatie en het niet sluiten van deuren werd ook middels een treindraad aan de machinist in de voorste cabine gemeld. Met de komst van draaistroom motoren begin jaren 90, inclusief de daarbij behorende intelligente besturing, alsmede processorbestuurde deuren, verlichting en airconditioning, nam ook de behoefte toe om systemen te koppelen en de bestuurder/machinist en het onderhoudspersoneel van meer informatie te kunnen voorzien. Nederlands EMU materieel 1975 - heden Trein


127

1977 1981 1992 1994 1996 2002

ICM DH SM90 IRM DM90 VIRM

Koploper Wadloper Railhopper RegioRunner Buffel RegioRunner

Chopper aandrijving Diesel Hydraulische aandrijving Draaistroom aandrijving Draaistroom aandrijving Diesel Hydraulische aandrijving Draaistroom aandrijving

Metro 1990 1997 1999 2002

GVBA GVBA RET RET

Sneltram Amstelveen Ringlijn Erasmuslijn Callandlijn

Ontwikkeling SM90, IRM, DM90 en de GVBA metro's zijn gebouwd door Holec Ridderkerk, later Traxis, thans Alsthom. Het voertuig management systeem dat op deze voertuigen is geïnstalleerd is het HOVIS (Holec Vehicle Information System) systeem, een eigen ontwikkeling van Holec Ridderkerk, met proprietary en maatwerk interfaces. De behoefte aan standaardisatie in de multi-vendor omgeving van het rollend materieel van de spoorwegen had reeds in 1989 geleid tot het starten van een standaardisatie programma door het IEC (International Electrotechnical Organisation) in samenwerking met het UIC (Union Internationale des Chemins de Fer) met als doel een TCN (Train Communication Network) communicatie netwerk specificatie te produceren. In 1996 kwamen de eerste COTS producten op basis van de nieuwe IEC standaard 61375; Train Communication Network, beschikbaar. Deze standaard heeft tot doel: het verzenden van informatie tussen voertuigen van een passagiers trein op basis van de "Wired Train Bus" en binnen voertuigen op basis van de "Multifunction Vehicle Bus" communicatie standaarden. Momenteel worden door Alsthom voertuig management systemen geleverd, onder andere voor NS en RET, op basis van gestandaardiseerde COTS producten, onder meer van Schneider. Betekenis voor DVM systemen De internationale branche van spoorvoertuigen heeft een vergelijkbaar probleem met multi-vendor systeem integratie. Dit probleem is aangepakt door gezamenlijk een specifieke IEC interface standaard (IEC 61375) te ontwikkelen. De standaard zelf is niet bruikbaar voor DVM. 4.4.3

Luchtverkeersleiding

Inleiding In de luchtverkeersleiding wordt ervoor gezorgd dat vliegtuigen worden begeleidt van vertrek tot aankomst. Werkwijze en toegepaste systemen De luchtverkeersleiding wordt gekenmerkt door hoge veiligheidseisen en uitgewerkte en gestandaardiseerde communicatieprotocollen tussen luchtverkeersleiders en piloten. Radar installaties Alhoewel deze radarsystemen niets te maken hebben met DVM-systemen is het toch aardig te vermelden dat de interfaces van radars gestandaardiseerd


128

zijn zodat het eenvoudig is om nieuwe systemen te koppelen met reeds geïnstalleerde radars en zo het ontwikkelen van nieuwe functionaliteit ook eenvoudiger wordt Vluchtplanningssystemen; Met behulp van deze systemen wordt een gehele vlucht ingepland. Van vertrekpunt tot aankomst met de te volgen route door de lucht en de benodigde frequenties voor onderweg. Verkeersleidingsystem en; Het werkveld van een verkeersleider is een sector. De verkeersleider beheert één frequentie. Hij behandelt al het verkeer binnen die frequentie. Verdwijnt een toestel uit zijn sector dan gaat deze over naar een andere verkeersleider doordat vanuit het toestel de piloot een andere frequentie kiest. Het automatisch overschakelen op een andere frequentie is nog in een proefstadium. Grondbegeleiding Op de grond wordt het vliegtuig begeleidt door de verlichting. De begeleider bepaald de route naar de gate en zet deze voor het vliegtuig u i t Vanuit het vliegtuig wordt de route zichtbaar door een soort dynamische markering. Training en simulatie systemen; De training en simulatie systemen richt zich voornamelijk op het werk van de verkeersleider. Dit zijn imposante installaties waarbij je echt het gevoel hebt dat je in een toren zit. Betekenis voor DVM systemen De markt voor luchtverkeersleiding is een specifieke markt. Op hoog conceptueel niveau zijn er overeenkomsten te vinden in het werkproces, echter op detailniveau verschilt de uitwerking substantieel. Enige praktische bruikbaarheid van betekenis is er niet. Men kiest in het algemeen voor bewezen technieken. Unix is een veel gebruikt platform. Applicaties op Microsoft besturingssystemen komen geleidelijk in opmars en veelal voor een deel van de presentatie. Actuatoren en sensoren komen uiteraard ook voor op een vliegveld. Sensoren zijn gericht op het verzamelen van bewegingen d.m.v. grondradars en het verzamelen van lokale meteo-gegevens. De actuatoren zijn de landingslichten, lichten gebruikt voor de begeleiding van het vliegtuig van gate naar startbaan en van landingsbaan naar gate en de barriers om het verkeer op de grond te scheiden. Deze systemen zijn echter fabrikant specifiek. Wel is een toename waar te nemen van het gebruik van SNMP voor het beheer van de actuatoren. 4.4.4 Petrochemie Inleiding De petrochemische industrie is ouder en wordt vaak vergeleken met het bedrijfsproces van verkeersbeheersing. In dit kader is contact gezocht met de Shell om te bepalen of er overeenkomsten zijn en wat de verschillen zijn. Werkwijze en toegepaste systemen Een fabriek wordt voor een periode van dertig jaar geplaatst. Het uitgangspunt is dat een fabriek zelfstandig en automatisch opereert. Alleen in geval van alarmen zal een operator ingrijpen. Het sturingssysteem is een DCS systeem dat


129

connecties heeft met sensoren als drukopnemers, thermometers, etc. De actuatoren als kleppen e.d. zijn aangesloten op lokale regelinstallaties gebaseerd op PLC's. Het DCS systeem is vanwege veiligheid en beveiligingsoogpunt een monolithisch systeem. De DCS houdt alleen die gegevens bij die van belang zijn voor het proces. Het zijn met name de grote leveranciers zoals Honeywell die in deze markt actief zijn. Daarnaast is een Proces Informatie Systeem actief welke gegevens inwint van o.a. de DCS en andere systemen en bevat archiverings- en rapportagefuncties. Hiertoe wordt bij Shell producten van OSI-software [OSI Soft] gebruikt. De kern van dit product is een real-time database. Dit product verzorgt ook de distributie van gegevens. Deze leverancier is met name sterk in het maken van specifieke interfaces. Werkplekoverdracht kent men ook als een onderdeel van shiftwissel. Belangrijk hierbij is het Wachtverslag, een zelfontwikkeld systeem, wat als logboek fungeert. Uit bronnen op internet blijkt dat deze pakketten op de markt komen en ondersteunend zijn aan de procedures in het werkproces. Autorisatie wordt anders toegepast. Als men toegang heeft tot het systeem dan is er geen onderscheid in bevoegdheden van taken. In de bediening worden eveneens procedures e.d. toegepast. Alarmafhandeling vindt plaats door een operator. Hij neemt actie en meld storingen en alarmen aan de betreffende diensten/onderhoudsaannemers. Betekenis voor DVM systemen Aan systemen in de petrochemische industrie worden andere en strengere eisen gesteld t.a.v. veiligheid en betrouwbaarheid dan aan DVM systemen. De systemen zijn ook minder aan veranderingen onderhevig. Wat gemeenschappelijk is, is de rol van de centrale en decentrale systemen. Er wordt met standaard producten een basisinfrastructuur gelegd waarop maatwerktoepassingen worden aangesloten. Deze benadering is interessant omdat het een deel van de TIAV en AA verzorgt d.m.v. COTS-producten. 4.4.5 Utilities Inleiding Er is contact gelegd met twee partijen, te weten de Gasunie en Nuon. Gezocht is naar bedrijven die naar verwachting te maken hebben met op grotere afstand geografisch verspreide systemen die vanuit een centrale bediend kunnen worden, zoals in DVM systemen. In deze paragraaf wordt ingegaan op de situatie bij Nuon. De Gasunie kent een vergelijkbaar bedrijfsproces en systemen, echter het gastransportproces is 'trager' dan de elektriciteitsvoorziening. Werkwijze en toegepaste systemen Op de diverse locaties (Hoogspanningsstations) worden de procesgegevens (metingen, alarmen en meldingen) verzameld in z.g.n. RTU's (Remote Terminal Unit's) en onderstations. Deze onderstations zijn er in twee types: het traditionele type en de nieuwere generatie. Het oude type is een PLC met een statisch gedrag. De nieuwere types zijn gebaseerd op industriële PC's en voeren decentraal ook een deel van de procesbesturing uit, dat voorheen in de centrale gelokaliseerd was. De gebruikte besturingssystemen zijn Unix en Windows NT. Beide types hebben faciliteiten voor het inwinnen van analoge en digitale gegevens. Er zijn ca. 200 - 250 RTU's aangesloten op de centrale in Arnhem.


130

De hoogspannings- en middensspanningsinstallaties zijn natuurlijk ook lokaal bedienbaar. De RTU's worden geleverd door meerdere leveranciers. In deze RTU's worden de signalen in telegramvorm gezet (fabrikantspecifieke en IEC 60870-5-101 protocollen). Bij optreden van een gebeurtenis, zoals een melding of alarm, wordt dit direct verzonden. Metingen worden cyclisch verzonden. Vanuit het bedrijfsvoeringcentrum in Arnhem worden ook sturingen gepleegd in de aangesloten onderstations. Het overbrengen van de standmeldingen en sturingen geschiedt "dubbelpolig", waarbij ingeval van sturing ook het achterliggend "stuurcircuit" vanuit de RTU wordt gecontroleerd. Deze RTU's zijn via analoge verbindingen (punt-punt en redundant) verbonden met front-end computers in het bedrijfsvoeringcentrum te Arnhem. Het centrale systeem is een door Siemens geleverd systeem met een Unix besturingssysteem. Hier zijn drie bedienposten op aangesloten die continu worden bemand. Autorisaties zijn gericht op het werkgebied (o.a. een verdeling in spanningniveaus). Er zijn geen faciliteiten voor werkplekoverdracht in het systeem. Men dient de bedienapplicatie af te sluiten, uit te loggen en daarna opnieuw in te loggen. Taakoverdracht heeft men nog niet gerealiseerd, maar men denkt aan een uitwijkcentrum waarnaar de bediening kan worden overgeschakeld. Deze front-end computers zijn verbonden met een LAN waarop de diverse servers draaien van het SCADA/EMS systeem. Nuon streeft er na om binnen afzienbare tijd de analoge verbindingen (dit zijn koper verbindingen) te vervangen door breedband verbindingen in een ring configuratie en de RTU's te laten communiceren met Arnhem d.m.v. het IEC 60870-5-104 en TCP/IP-protocol. De toegepaste overdracht technieken zijn standaard in de E-wereld (leveranciers zijn o.m. Siemens, ABB en SAT-Electron) Het SCADA/EMS systeem is van leverancier Siemens (Sinaut Spectrum) en wordt veel toegepast in de E-wereld (De standaardversie is aangevuld met gebruikerspecifieke oplossingen). Het SCADA systeem wordt gebruikt voor het inwinnen van gegevens vanuit de RTU's maar ook voor het verzenden van opdrachten vanuit de centrale naar de RTU's. Uit performance overwegingen wordt een real-time database van Siemens gebruikt voor het beschikbaar stellen van de tijdkritische gegevens. Voor analyse doeleinden wordt een Oracle database gebruikt. RDBMS-en worden niet geschikt geacht voor tijdkritische processen. Betekenis voor DVM systemen

Een aantal ontwikkelingen zijn vergelijkbaar met DVM, echter is het werkproces in de centrale anders. Verkeer laat zich in tegenstelling tot afname van elektriciteit niet plannen. Over de geschiktheid van RDBMS-en voor toepassing in DVM systemen wordt binnen RWS verschillend gedacht. Om te bepalen of dit aspect werkelijk een probleem is zou een grondige analyse op zijn plaats zijn. Pas dan kan overwogen worden of de ervaring van Nuon gedeeld kan worden. Dit staat overigens los van de keuze om wel of geen COTS-producten toe te passen. 4.4.6 Ruimtevaart Inleiding

Spacecraft mission control systemen (MCS'en) zorgen ervoor dat satellieten en raketten 24 uur per dag en zeven dagen per week worden bewaakt en bestuurd. In Europa zijn er verschillende centrales, waaronder het European Space Operations Centre (ESOC, Darmstadt, Duitsland), het EUMETSAT Operations Centre (ook Darmstadt, Duitsland), het German Space Operations


131

Centre (GSOC, Oberpfaffenhofen, Duitsland), en New Skies Satellites' Spacecraft Operations Centre (SOC, Den Haag, Nederland). Werkwijze en toegepaste systemen

Ruimtevaart operaties worden gekenmerkt door hoge veiligheidseisen en gestandaardiseerde communicatieprotocollen tussen het MCS en een satelliet. De communicatieverbinding van het MCS naar een satelliet heeft een zeer beperkte bandbreedte, vergelijkbaar aan een analoge telefoonlijn. Er bestaan defacto internationale standaarden voor zowel "telecommanding" (TC) of "uplink" (d.w.z. van grond naar de satelliet) als "telemetry" (TM) of "downlink" (d.w.z. van satelliet naar de grond). De meest gebruikte standaarden zijn de packetised TM/TC standaarden van het Consultative Committee for Space Data Systems [CCSDS]. De CCSDS standaarden zijn operationeel gebruikt in meerdere projecten over een periode van minstens 10 jaar. De meest recente is het International Space Station (ISS).

Space Data System Functional Model © © 0 0 Fonward Data Hmdling

k

Ê

Forward Data $ Handling Data Archives

o u n d

è Ohboard è *+*Co ntrol Return £ Hmdling Data \*

Operations Control

I n t e r f

A

è

Project Space Data Acqui-

©

Project Formafon and Op«ations

CorTelatixe Iniestigstions

ê Return

k

Data Directories

è>

Data £ & Handling

Space Segiiment-

-Ground Segment •

Figuur 16. CCSDS architectuur. De CCSDS architectuur (zie Figuur 16) is sterk georiënteerd op communicatie. Een satelliet kan een of meerdere "payloads" 14 of instrumenten dragen, ledere payload kunnen meerdere sensoren en/of actuatoren bevatten. Naast eenvoudige sensoren zoals in proces controle toepassingen, kan een sensor een meer complex subsysteem zijn, zoals een sun tracker, een telescoop, of een magnetometer. Voorbeelden van actuatoren zijn momentum wheels, thrusters, en explosive bolts. Het uitgangspuntvan de CCSDS standaarden is het "Application Process" (AP). Een sensor en/of een actuator kan een AP zijn. Een TC is gedefinieerd als een boodschap richting een AP, en een TM is een boodschappen afkomstig van een AP. Betekenis voor D V M systemen 14

Letterlijke betekenis is de "lading" van de satelliet die geld oplevert; de terminologie komt uit de

luchtvaart. De structuur en technische systemen van een satelliet zijn daarentegen vaak het "platform" ofwel de "(sub)systems" genoemd.


132

De markt voor ruimtevaart MCS'en is een specifieke markt. Er zijn overeenkomsten te vinden in het werkproces van DVM op hoog niveau. Echter op detailniveau verschilt de uitwerking substantieel. Opmerkelijk is de commercialisering van MCS'en in de afgelopen 10 jaren. Een voorbeeld is het SCOS-2000 MCS van het European Space Agency dat 30 gebruikers kent [Kaufeler et al.], net zoveel als de best verkochte Totaal oplossing uit hoofdstuk 3. Andere voorbeelden zijn Harris' OS/Comet, de Command & Control Toolkit (CCTK) van CCT, en Integral Systems Inc.'s Epoch 2000. OS/Comet en CCTK zijn opgenomen in de shortlist. In de ruimtevaart kiest men voor bewezen technieken. Er is een voorkeur voor Unix, vaak in een real-time versie (b.v. VxWorks), maar Windows NT voor gebruikers' workstations is sterk in opkomst. Er is een trend voor het gebruik van COTS producten, maar dit is minder ontwikkeld dan in de defensie markt. 4.4.7 Landmacht Inleiding De Koninklijke Landmacht (KL) zorgt voor de verdediging van Nederland en het bondgenootschappelijk grondgebied [KL]. Daarnaast levert zij wereldwijd een bijdrage aan vrede, veiligheid en stabiliteit, die kan bestaan uit crisisbeheersing, humanitaire hulp en rampenbestrijding. Deze activiteiten zijn geografisch verspreid en hebben zeer sterk real-time en levenskritische karakteristieken. Commandovoering (ofwel "Command, Control, Communications and Intelligence" (C3I) in het engels) is hierbij essentieel. Werkwijze en toegepaste systemen Commandovoering wordt gekenmerkt door onzekerheidsbestendigheid, hoge tolerantie voor communicatie fouten en beperkt bandbreedte, en communicatieprotocollen gestandaardiseerd op internationaal niveau. Belangrijke maatregelen tegen onzekerheid zijn een hiërarchische organisatie en het creëren en beheren van "situation awareness". Op ieder organisatorisch niveau introduceert de KL ICT ondersteuning: van het Soldier's Digital Assistant (SDA) voor individuele soldaten en zijn peleton, via het Battlefield Management System (BMS) op compagnie, bataljon en brigade niveaus, tot het Integrated Staff Information System (ISIS) van divisie en hogere niveaus. De KL heeft een overkoepelend software architectuur gedefinieerd, gebaseerd op de Army Tactical Command and Control Information System (ATCCIS) data-uitwisseling standaard van de NAVO. Deze KL C3I architectuur is afgebeeld in Figuur 17. Zoals in AVB, is het KL C3I een gelaagde architectuur. ISIS (operationeel) en BMS (wordt geëvalueerd in grootschalige internationale oefeningen) maken gebruik van de KL C3I architectuur.


133

è

•••C2 C3I Generic ••GISï Functions

;;

:

C2 ORBAT

Office Suite

Formal MAIL ADatP3

Other

Functions

C3I Specific Functions

i

Figuur 17. Koninklijke Landmacht's C3I architectuur. Met de oplevering halverwege 1999 van de conceptuele en logische beschrijving van de C3I architectuur is begonnen met het definiëren van de fysieke C3I architectuur. De fysieke architectuur dient standaarden en richtlijnen op te leveren voor alle systemen in het C3I domein, met de bedoeling interoperabiliteit te garanderen, kosten te besparen en te beheersen en snellere ontwikkeling van nieuwe systemen mogelijk te maken. Op het gebied van systeem architectuur dient het Command and Control WorkStation (C2WS) deze standaarden en richtlijnen te definiëren. Hoewel de naam van het C2WS wellicht anders doet vermoeden gaat het hierbij om software. Het C2WS is de software die de fysieke systeem architectuur definieert en implementeert. Het C2WS zal gebruik maken van de technische infrastructuur zoals die nu wordt ontworpen in het Theatre Independent Tactical Army and Airforce Network (TITAAN) project. Het C2WS zal in de toekomst het platform zijn waarop systemen voor de ondersteuning van de commandovoering op alle niveaus zullen worden gerealiseerd. Dit betekent dat de functionaliteit zoals die nu door ISIS en BMS wordt aangeboden in de toekomst door het C2WS zal worden aangeboden. Daarnaast zal het mogelijk zijn, toekomstige applicaties voor specifieke ondersteuning van commandovoering ook te realiseren op het C2WS (denk bijvoorbeeld aan logistieke-, vuursteun- of luchtverdedigingapplicaties). Bij het ontwerp en de ontwikkeling van het C2WS is gekozen voor het min of meer gelijktijdig uitvoeren van het ontwerp en de ontwikkelingswerkzaamheden. Het ontwerp is gericht op het vaststellen van een software architectuur vanuit de gebruikerseisen zoals die bekend zijn uit de architectuur studie, ISIS, BMS en overige projecten. Het ontwikkelwerk is gericht op het migreren in drie stappen van het huidige ISIS en BMS naar het C2WS. Op deze manier bepaalt het ontwerp de ontwikkelwerkzaamheden, en de ervaring uit de ontwikkeling valideren en sturen het ontwerp bij. Op een zeker niveau van abstractie beschouwd, zijn ISIS en BMS op een vergelijkbare manier opgebouwd.


134

Beide systemen hebben een informatie uitwisselingscomponent, een gedeelte waar zich de informatie bevindt en een deel voor de interactie met de gebruiker. Echter beide systemen zijn niet of nauwelijks geschikt als platform voor andere applicaties. Voor de ontwikkeling van het C2WS zijn de volgende drie stappen onderkend: • Een generieke informatie uitwisselingscomponent. • Het creëren van de mechanismen die nodig zijn en bepalen hoe met informatie wordt omgegaan. • Het creëren van een generieke component voor de ondersteuning van de gebruikers interface. Stap 1: Informatie uitwisseling Een van de concepten uit de architectuur studie is het 'zero-dependency' concept, d.w.z. dat systemen niet afhankelijk mogen zijn van elkaar. Voor de informatie uitwisseling is daarom voor een informatiebus gekozen. De informatiebus ontkoppelt de component die informatie verzendt van de component die de informatie wil ontvangen. In een experiment is een commercieel "middleware" product getest dat voorziet in een zogenaamd publish/subscribe mechanisme. Uit dit experiment bleek dat het goed mogelijk was om een COTS product te gebruiken om een generieke component voor informatie-uitwisseling te creëren voor de ISIS en BMS omgeving. Daarnaast bleek het een efficiënte manier van informatie uitwisseling. Na dit experiment is een volwassen implementatie gemaakt waarmee het eerste deel van het C2WS is gerealiseerd. Stap 2: Omgaan met informatie De tweede stap betrof het deel van het systeem waar wordt bepaald hoe met informatie wordt omgegaan. Door informatie te delen in een operationeel netwerk heeft iedereen de beschikking over dezelfde "Common Operational Picture" (COP) wat zorgt voor situation awareness. COP betekent echter niet dat iedereen ook daadwerkelijk overal in het netwerk over exact dezelfde informatie beschikt. Dit zou immers betekenen dat alle informatie altijd door het gehele netwerk gedistribueerd moet worden, en gegeven de beperkingen van operationele communicatie netwerken zou dit onmogelijk zijn. Het betekent wel dat iedereen in staat moet zijn, zijn eigen informatie behoefte vast te stellen en dat die informatie indien gewenst beschikbaar is. De COP zorgt ervoor dat wanneer op twee plaatsen in het netwerk men dezelfde informatiebehoefte heeft, bijvoorbeeld men wil een plan van een bepaalde eenheid inzien, men op beide plaatsen precies hetzelfde plan bekijkt. De geografisch referentie is hierbij centraal. Het C2WS moet de mechanismen realiseren die de COP mogelijk moeten maken. Stap 3: Generiek gebruikersinterface De derde stap is het creëren van een generieke gebruikersinterface. Het C2WS biedt de gebruiker de generieke functionaliteit zoals die nu door ISIS en BMS wordt ingevuld. Daarnaast is het C2WS een software raamwerk waarop nieuwe applicaties zullen kunnen worden ontwikkeld. De applicaties zullen, omdat ze gebruik maken van hetzelfde software raamwerk, naadloos met elkaar samenwerken. Hierdoor wordt de interoperabiliteit tussen commandovoering ondersteunende systemen gewaarborgd. Om de verschillende applicaties als een coherente set van functionaliteit aan te beiden is de C2 console ontworpen. De C2 console is de toegang tot alle C2 functionaliteit maar kan ook applicaties uit het kantoordomein in zich hebben. De integratie van het mobiele en statisch domein wordt daarmee expliciet gemaakt. In de kazerne situatie zul je operationele systemen ter beschikking hebben, en in het mobiele domein is het


135

mogelijk om ook gebruik te maken van het Intranet of systemen uit de vredesbedrijfsvoering. De verschillende applicaties zijn o.a. een operationeel 2D GIS, logistiek, vuursteun en video-conferencing, vanuit het kantoor domein een MIS (management informatie systeem), intranet en internet weer- en nieuwspagina's. Verder wordt een COP catalogus zichtbaar en een window met alerts. De wijze waarop deze gebruikers interface wordt ontwikkeld maakt het bovendien mogelijk om dezelfde functionaliteit op een andere manier te presenteren, bijvoorbeeld in kantoor, staf te velde, en voertuig omgevingen. Verder, in het EUCLID RTP 6.14 project wordt gewerkt door een NederlandsDeens-ltaliaans-Grieks consortium onder leiding van het Nederlandse Ministerie van Defensie aan een 3D GIS gekoppeld aan BMS. Betekenis voor DVM systemen De markt voor commandovoering systemen is een specifieke markt, maar bezuinigingen hebben er toe geleidt dat in toenemende mate gebruik wordt gemaakt van COTS producten. ISIS, BMS, en C2WS maken gebruik van een GIS product, het Microsoft Office suite, en een web-browser. Op hoog conceptueel niveau zijn er overeenkomsten te vinden in het werkproces. Op detailniveau zijn er verschillen, zoals het belang van "peer-topeer" communicatie (vergelijkbaar aan "center-to-center") voor "situation awareness" en de geneste rapportage structuur die nodig is voor een hiërarchische organisatie. Opmerkelijk zijn de overeenkomsten, niettemin de sterke werking van de menselijk factor in het proces. Zelfs de sensoren en actuatoren kunnen mensen zijn. Ook het ontwikkelproces toont overeenkomsten. Het C2WS is momenteel in ontwikkeling onder de verantwoordelijkheid van het Ministerie van Defensie met veel inbreng vanuit het Nederlandse bedrijfsleven. Volgens plannen, zal de huidige overheidsindustrie relatie veranderen in een Publiek-PrivateSamenwerking (PPS). 4.4.8 Marine Inleiding De bedrijfsvoering aan boord van (marine) schepen bestaat uit twee delen: platform en payload. Het platform omvat het schip, de voortstuwing, de energie voorziening en de algemene installaties voor verlichting, ventilatie, drinkwater en riolering. Payload omvat het gebruik van het platform voor nautische en militaire doeleinden. Werkwijze en toegepaste systemen De Nederlandse Koninklijke Marine (RNLN) heeft derhalve, evenals andere rederijen, aan boord van haar schepen twee soorten real-time informatie verwerkende systemen; voor het scheepstechnische management (platform) en voor militaire management (payload). De bediening en bewaking van het platform vindt plaats vanuit de "Technische Centrale", en voor de payload vanuit de Commando Centrale. Tussen de systemen bestaat een koppeling op "MES" niveau. Van de twee systemen, heeft het scheepstechnische management systeem de meeste verwantschap met een verkeersmanagement systeem. Bij beide systemen wordt relatief eenvoudige informatie verkregen van en gestuurd naar grote hoeveelheden transducenten: sensoren en actuatoren. Het operationele informatiesysteem verwerkt grote hoeveelheden informatie


136

(radar/sonarbeelden, landkaarten, EOV) van en naar een klein aantal relatief zeer complexe sensoren en andere veelal zelfstandige systemen. In het algemeen is er binnen de marines van de diverse zeevarende landen een trend waar te nemen om zoveel mogelijk over te stappen van specifieke " M i l standard" "ruggedized" producten, die voldoen aan hoge omgevingseisen, op commerciële COTS producten, die met behulp van klimaatregeling en een schok- en trillingabsorberende montage bruikbaar gemaakt worden. De Nederlandse Koninklijke Marine beschikt, naast een aantal relatief eenvoudige schepen, over een aantal vaartuigen met een scheepstechnisch management systeem. De ontwikkeling hiervan door de jaren heen, kan voor dit onderzoek mogelijk relevante aspecten bevatten. • De "Kortenaar" klasse van Standaard en Luchtverdedigingsfregatten (respectievelijk: S-class en L-class) • De "Walrus" klasse onderzeeboot; • Het "Karel Doorman" klasse (M-class), Multi purpose fregat • De BOZ tanker "Amsterdam" • Het Landing Doek Platform "Rotterdam" • Het "De Zeven Provinciën" klasse luchtverdedigings en commando fregatten (LC-class) en nieuwe luchtverdedigings fregatten (NL-class) Op het standaard fregat (kiellegging 1975/81, indienststelling 1979/83) bestaat het scheepstechnisch management systeem in de Technische Centrale uit de voorstuwingsregelautomatiek (de "Fokkerkast") en een groot wandpaneel met (binaire) alarm indicatoren en een enkel de-multiplexer met display ten behoeve van het weergeven van een enkelvoudige analoge waarde. De platform bewaking kan hierdoor gecentraliseerd worden in de Technische Centrale. Bediening van het platform, met uitzondering van voortstuwing en stuurinrichting vindt hier voornamelijk lokaal in de machinekamers plaats. De Walrus onderzeeboot (kiellegging: 1979/88, indienststelling 1990/94) is het eerste vaartuig met een Geïntegreerd Bedienings- en Bewakingssysteem (GBB), het IMCS (Integrated Monitoring and Control System), bestaande uit een aantal automatieken (locale regelingen, vergelijkbaar met wegkantstations), locale verwerkingseenheden (remote I/O) en een centraal systeem met twee bedienposities. Dit is geheel projectmatig gebouwd door Van Rietschoten en Houwens, het huidige Imtech Marine & Offshore. Hiermee kan het gehele platform centraal bediend en bewaakt worden vanuit de "Centrale" (Central Control Room). De machinekamer is in principe onbemand. Het M-Fregat (Multipurpose) is uitgerust met een vergelijkbaar maar moderner systeem gebaseerd op hetzelfde concept, en is eveneens projectmatig gebouwd. Dit systeem heeft echter zeven bedienposities, met een vergelijkbare taak en werkplekoverdracht als gedefinieerd in ACT. Omdat dit systeem tijdens proefvaart nog niet geheel gereed was, is kort voor de proeftocht tijdelijk een aantal April PLC's geïnstalleerd die de ontbrekende functionaliteit verzorgden. Het IMCS systeem kent een functiescheiding en taakoverdracht vergelijkbaar met die van een verkeerscentrale. De machinekamers zijn in principe onbemand. Het bevoorradingsschip Amsterdam (BOZ tanker) is gebouwd als onderdeel van een samenwerkingsverband tussen Nederland en Spanje, en is voorzien van een scheepstechnisch managementsysteem gebaseerd op commerciële (Modicon) PLC producten.


137

Het LPD (Landing Platform Doek) Rotterdam is gebouwd als onderdeel van een samenwerkingsverband tussen Nederland en Spanje, en is eveneens voorzien van een scheepstechnisch management systeem gebaseerd op commerciële (Modicon) PLC producten. Het LC-Fregat De Zeven Provinciën is gebouwd als onderdeel van een samenwerkingsverband tussen Nederland, Duitsland en Spanje, en heeft ten behoeve van de scheepstechnische bedrijfsvoering een "Integrated Platform Management System" gebaseerd op standaardproducten van CAE (Canada) die worden geïntegreerd door Imtech Marine & Offshore. Betekenis voor DVM systemen Bij de marine kunnen we een trend waarnemen van projectmatige oplossingen naar het werken met standaard producten. Hierbij is echter wel een scheiding tussen de applicaties en technische infrastructuur, maar de systeemontwikkeling wordt integraal uitgevoerd. 4.4.9 Bevindingen en conclusies Een aantal branches zijn onderzocht die op het eerste gezicht soortgelijke problemen kennen als in DVM, namelijk het beheren van een controle proces, een gedecentraliseerde systeem architectuur, en het integreren van systemen van meerdere leveranciers. In het bijzonder zijn de werkwijzen, systeemarchitecturen en standaardisatie initiatieven beschouwd. Bij nader onderzoek blijken de werkprocessen en systemen uit andere branches in meer of mindere mate te verschillen van DVM. De oplossingen uit die branches zijn niet direct herbruikbaar. Er zijn ook enkele interessante bevindingen te noteren: • Bij de rail infrastructuur van de NS wordt de ICT infrastructuur bij één leverancier ingekocht. • De branche van railvoertuigen heeft een eigen standaard opgesteld voor multi-vendor systeemintegratie. • Voor luchtverkeersleiding wordt veelal gekozen voor bewezen techniek en maatwerk integratie. • De petrochemische industrie is (bijna) volledig gestandaardiseerd op SCADA en PLC systemen. Bij Shell wordt een basis infrastructuur aangelegd met COTS producten waarop maatwerktoepassingen worden aangesloten. • Bij Nuon is het SCADA/EMS systeem in de centrale van één leverancier. De telecontrol communicatie toegepast met systemen in het veld. Dit is enigszins vergelijkbaar met TLS in Duitsland. • Voor mission control centers in de ruimtevaart worden bewezen technieken toegepast. Veelal wordt gekozen voor Unix met RT operating systemen. Er is een sterke commercialisering in de ontwikkeling van systemen en COTS producten. De schaalgrootte is vergelijkbaar met de DVM industrie. Een aantal producten zijn ook op onze shortlist. • Bezuinigingen in de defensie hebben geleid tot een toename van COTS producten in commandovoering systemen bij de landmacht. Het Ministerie van Defensie is verantwoordelijk voor deze ontwikkelingen en samenwerking met de industrie en de overgang naar Publiek-PrivateSamenwerking.. • Ook de marine kent een sterke toename van het gebruik van COTS producten. Bij de Marine is wel een scheiding tussen de applicaties en technische infrastructuur, maar de systeemontwikkeling wordt integraal uitgevoerd.


138

4.5 Bevindingen en conclusies Hoofdstuk 4 is opgebouwd uit vier onafhankelijke secties over waarnemingen over ontwikkelingen in de markt. Voor de duidelijkheid zijn de bevindingen en conclusies aan het einde van iedere sectie opgenomen.


139

5 Bevindingen, conclusies en aanbevelingen

ln dit hoofdstuk worden de algemene bevindingen, conclusies en aanbevelingen opgesomd, ten aanzien van de onderzoeksvraag zoals deze is geformuleerd in Hoofdstuk 1. Detailbevindingen en conclusies staan vermeld in de hoofdstukken 3 en 4. In sectie 5.1 worden de gedane bevindingen beschreven. In sectie 5.2 worden de conclusies beschreven, welke op basis van het MATCH onderzoek konden worden getrokken. In sectie 5.3 is voor het vervolgtraject een aantal aanbevelingen opgenomen. Van de opgedane ervaringen in het marktverkenningproces wordt verslag gedaan in hoofdstuk 6. 5.1 Bevindingen De in het kader van het MATCH project opgedane bevindingen zijn vastgelegd in de volgende structuur: • Zoekresultaten producten • Architectuur • Interface standaarden • Extra CORBA en XML onderzoeksopdracht • Extra PLC/SCADA/DCS/Industriële computers onderzoeksopdracht • Project aanpak 5.1.1 Zoekresultaten producten Er zijn producten gevonden, die binnen de AVB architectuur geplaatst kunnen worden en die tevens voldoen aan de gestelde AVB-AA functionele en niet functionele eisen voor (zoals beschreven in hoofdstuk 3.3 t / m 3.8 en bijlage E), maar deze zijn niet ACT compatibel in strikte zin. De scheiding tussen de verschillende lagen ligt bij de gevonden producten op een andere plaats dan bij AVB het geval is. De gevonden producten zijn beschreven in hoofdstuk 3 en de conclusies en aanbevelingen zijn opgenomen onder respectievelijk paragraaf 5.1.2 en 5.1.3 van dit hoofdstuk. Naast bovenstaande COTS producten kan VANESSA als een vergelijkbaar product beschouwd worden. VANESSA is beschreven in hoofdstuk 3.9. De AVB-AA functionaliteit wordt door de meeste gevonden producten afgedekt. Er zijn echter DVM producten die meer functionaliteit bieden, zoals: Web functionaliteit (GUI en XML), mobile communicatie (o.a. alarming) en simulatie. Het marktonderzoek heeft echter geen producten opgeleverd in de vorm van componenten, die voldoen aan het ACT ontwerp. Gezien de intensiteit van de door het MATCH project uitgevoerde zoektocht is ook niet te verwachten dat deze er zullen zijn.


140

In het algemeen blijkt dat de modulen van de gevonden producten veel groter zijn dan de componenten uit ACT. De gevonden modulen verenigen functionaliteit uit meerdere ACT componenten. Daarnaast blijkt ook dat de functionele decompositie verschilt met ACT, want een module is veelal geen vereniging van enkele ACT componenten. De opdeling ligt derhalve op een aanzienlijk hoger aggregatieniveau dan bij ACT, d.w.z. op het niveau van subsystemen of zelfs totaaloplossingen. ACT is een ontwerp, waarbij nog geen gebruik gemaakt is van standaarden of dat nog niet heeft geresulteerd in standaarden. Anders dan bij een specificatie, waarin vastgelegd wordt wat een systeem moet doen, wordt in een ontwerp vastgelegd hoe de functies gerealiseerd worden. Een ontwerp bevat bepaalde ontwerpkeuzes, die door elke ontwerper op een eigen wijze ingevuld kunnen worden, zonder dat dit afbreuk doet aan de gewenste functionaliteit en aan andere randvoorwaarden. Het zou derhalve wel heel toevallig zijn als iemand anders precies hetzelfde ontwerp gemaakt zou hebben als de ontwerpers van ACT. Dit is vermoedelijk de belangrijkste reden van het feit, dat er geen ACT componenten in de vorm van COTS producten gevonden zijn. Het diepgaand en volledig evalueren van producten is moeilijk, omdat de specificaties van het totale verkeersmanagement systeem onvolledig zijn. De specificaties die er zijn, zijn bovendien gebaseerd op de werking van de huidige systemen. SCADA en PLC systemen vormen een industrie standaard voor gedistribueerde bediening, bewaking en regeling. Omdat ze zijn ontwikkeld als algemeen toepasbare producten en niet op basis van een functionele applicatie specificatie, kunnen ze ook worden ingezet in situaties waar de applicatie eisen nog niet geheel zijn uitgekristalliseerd. 5.1.2 Architectuur De in de markt aangetroffen producten hebben een harde koppeling tussen hard- en software, terwijl AVB hier juist een scheiding heeft aangebracht, alhoewel het vooralsnog onduidelijk is waar deze precies ligt. Als deze koppeling niet in het architectuurmodel is opgenomen dan kan er geen systeem gebouwd worden waarbij gebruik gemaakt wordt van COTS producten. In de AVB architectuur zijn wel de horizontale lagen: Technische Infrastructuur Verkeers Beheersing (TIAV), Applicatie Architectuur (AA) en Verkeerskundige Architectuur (VA) gedefinieerd, maar ook hier ontbreekt de afstemming daartussen. KAREN is een bekend Europees 'framework' terwijl AVB relatief onbekend is. Omdat de beschrijving van de koppeling tussen KAREN en AVB ontbreekt, vragen de marktpartijen zich af wat de relatie is tussen AVB en bekende 'Architectuur Frameworks' zoals KAREN in Europa en de Amerikaanse National ITS Architecture. Doordat in de huidige AVB architectuur, de verbinding met een hoger niveau van architectuur zoals KAREN of de Amerikaanse National ITS Architecture ontbreekt, kan de verkeersindustrie AVB niet goed plaatsen. De functionele scope van KAREN is breder dan die van AVB; DVM zoals in Nederland dekt overigens slechts drie van de 31 "user services" in de National


141

ITS Architecture (voornamelijk En-route Driver Information, Traffic Control en Incident Management). Mede als gevolg van het ontbreken van een expliciete koppeling tussen AVB en KAREN, zijn er binnen AVB geen (verticale) koppelvlakken gedefinieerd tussen zowel functies in de logische architectuur 'view' als ook tussen units in de fysieke architectuur 'view' [Klijnhout], [IEEE 1471]. Derhalve ontbreken ook de beschrijvingen van de interfaces tussen functies en units aan beide zijden van het koppelvlak. De Amerikaanse markt draagt op basis van de National ITS Architecture andere oplossingen aan om te komen tot een systeemopdeling, dan bij ACT is uitgevoerd. De National ITS Architecture deelt systemen op in subsystemen, bestaande uit een (harde) combinatie van hard- en software, gekoppeld door (volledig) vastgelegde interfaces. De categorie van SCADA en PLC producten onderscheidt zich van de andere categorieën uit deze marktverkenning doordat zij ontwikkeld zijn op industriële standaarden die deze harde koppeling in hard- en software definieert, en vele toepassingsgebieden en leveranciers kent. 5.1.3 Interface standaarden Door het ontbreken van producten interfacestandaarden, worden verkeersmanagement systemen voornamelijk projectmatig gerealiseerd. Pas op het moment dat er standaarden gedefinieerd zijn, kan geïnvesteerd worden in het ontwikkelen van producten die op deze standaarden gebaseerd zijn. In andere landen (o.a. VS, UK, Duitsland, Frankrijk, Spanje) wordt succes geboekt met het door overheid en bedrijven gezamenlijk ontwikkelen van producten interfacestandaarden, waarbij veelal bestaande standaarden worden hergebruikt. Als voorbeeld kunnen worden genoemd de op NTCIP gebaseerde OCIT en UTMC standaarden en de op 'Telecontrol' gebaseerde TLS standaard. Hierbij kan het doorgaans geruime tijd duren, voordat de standaard daadwerkelijk stabiel geworden is. Bij het toepassen van 'emerging standards' blijken in de praktijk interpretatieverschillen, implementatieproblemen en 'feature creep' op te treden. Tijdens het uitgevoerde marktonderzoek is door het bedrijfsleven regelmatig aangegeven, dat men zit te wachten tot Rijkswaterstaat komt met een voorstel voor een interface standaard. Dat er binnen AVV gewerkt is aan een actuator interface standaard in de vorm van een NTCIP extensie, bleek slechts in beperkte kring bekend. Ondanks het bestaan van twee AVB websites, is de algemene beschikbaarheid en vooral de verspreiding van AVB documentatie gering, bij betrokkenen in de markt. De Nederlandse ITS markt is, met uitzondering van verkeerslichtregelaars, een dusdanig marginale markt, dat het vermoedelijk niet loont om daar specifieke product en interface standaarden voor te ontwikkelen en te onderhouden. Dit werd zowel vernomen uit de DVM markt, als ook van leveranciers en gebruikers uit andere sectoren. De vraag uit de markt is om aansluiting te zoeken bij bestaande producten interface standaarden en deze, of een variant daarop, als standaard voor het Nederlandse verkeersmanagement te implementeren.


142

Mogelijke alternatieven hiervoor zijn de Amerikaanse (NTCIP), Duitse (gereviseerde TLS op basis van TCP/IP) en Engelse (UTMS) ITS standaarden, en de defacto interface standaarden die wereldwijd in de PLC/SCADA techniek gebruikt worden. 5.1.4 Extra CORBA en XML onderzoeksopdracht Tijdens het marktonderzoek werd vanuit de markt weinig positief gereageerd op het feit dat binnen ACT het gebruik van CORBA zich uitstrekt van de centrale tot en met het wegkantstation. Daar er bovendien geen toepassingen van CORBA werden aangetroffen, die zich uitstrekken tot het wegkantstation in een multi-vendor omgeving, is aanvullende onderzoek uitgevoerd naar enkele aspecten van toepassing van CORBA op wegkantstations (4.2.9), en naar toepassing van XML (4.2.8) voor DVM. Uit de MATCH marktverkenning en deze opdracht zijn enkele bevinding te melden. De Applicatie Architectuur bevat geografisch gedistribueerde softwarecomponenten. Voor de communicatie tussen deze componenten is gekozen voor een CORBA middleware communicatiebus in de verkeerscentrale, zoals in VANESSA, die mogelijk doorgetrokken wordt naar de wegkantstations. Uitgaande van deze keuzen zijn enkele bevindingen te noteren: •

CORBA wordt toegepast in verschillende DVM totaaloplossingen met een gedistribueerde componentenarchitectuur in de verkeerscentrale. MAVE van AVE en TransActive ATMS van M l Services bieden totaaloplossingen waarin de CORBA componenten ook geografisch gedistribueerd zijn naar respectievelijk de Unterzentralen en wegkantstations. Hierbij moet worden opgemerkt dat het in geen van de gevallen een multi-vendor omgeving betreft, en dat individuele CORBA componenten niet als producten te verkrijgen zijn.

•

CORBA is een standaard voor een communicatie middleware laag. CORBA biedt geen applicatie en transportstandaard voor communicatie, zoals in andere communicatie protocollen. De interfaces tussen CORBA componenten moeten apart worden gespecificeerd in een IDL. CORBA is een relatief complexe technologie in vergelijking met communicatiemechanismen die in DVM applicaties meer gangbaar zijn zoals SNMP. Ervaring in NTCIP leert dat de ontwikkeling van een communicatiestandaard in samenwerking met vele publieke en marktpartijen voor CORBA veel grotere organisatorische problemen met zich meebrengt dan voor bijvoorbeeld SNMP. Voor een CORBA standaardisatieproces zijn extra inspanningen voor een goede regie en organisatie vereist. In sectie 4.2.9 is een beperkte kwalitatieve analyse gemaakt van enkele consequenties bij de uitbreiding van een CORBA bus naar wegkantstations. Hieruit volgt dat de capaciteit van het huidige VicNet mogelijk een beperking kan zijn op de vereiste communicatie voor AVB. Uitbreiding van de capaciteit lijkt dan ook gewenst naar een best-effort quality of service voor AVB componenten op wegkantstations, waarbij kleine overschrijdingen op de gewenste communicatiekwaliteit worden toegestaan. Real-time quality of service, waarbij de vereiste kwaliteit van de communicatie kan worden gegarandeerd, vereist grotere investeringen in de infrastructuur en lijkt niet strikt noodzakelijk te zijn voor AVB. Opgemerkt moet worden dat informatie die beschikbaar is voor deze analyse onvoldoende is voor een kwantitatieve analyse, en dat nader onderzoek nodig is om conclusies hierover te kunnen trekken.

•

•


143

XML wordt in een aantal shortlistproducten en ITS projecten al toegepast als één van de standaarden voor communicatie; in het bijzonder voor communicatie van verkeersinformatie en koppeling met databases. XML vindt in vele branches sterk opgang als taal voor de specificatie en communicatie van applicatie informatie. Een belangrijk voordeel van XML is de grote flexibiliteit voor de definitie van DVM specifieke data elementen, de onderlinge hiërarchische structuur en relaties, en de betekenis (of interpretatie) van de data elementen. Deze definities zijn generiek te specificeren voor het DVM applicatie domein in Data Type Definitions (DTD) en XML Schema's. XML is niet gebonden aan een specifieke communicatie standaard op een lager niveau in het OSI model en kan worden toegepast in combinatie met vele andere communicatie protocollen. XML wordt ondersteund door een breed scala aan tools en standaard databases. 5.1.5 Extra PLC/SCADA/DCS/Industriële computers onderzoeksopdracht Gedurende de marktverkenning is gebleken dat wegkantsystemen veelal gebaseerd zijn op PLC-achtige technieken. Ook kreeg het team regelmatig vragen van leveranciers hoe het Universeel Wegkant Platform van RWS eruit zou komen te zien. Tot nu waren diverse projecten binnen RWS uitgegaan van een oplossing gebaseerd op industriële PC's. PLC's als mogelijk alternatief zijn in die projecten niet meegenomen. Redenen hiervoor kunnen zijn de onbekendheid met PLC's ofwel het feit de PLC's in de tijd dat die projecten werden uitgevoerd nog niet zover ontwikkeld waren om een alternatief te kunnen vormen. Aangezien het feit dat binnen het team beperkt kennis aanwezig was over PLC's is contact gezocht met de Bouwdienst. O.a. op basis van die gesprekken is besloten dat nadere kennis gewenst was. Vervolgens is contact gezocht met de Meetkundige Dienst omdat binnen het project VICNET+ gewerkt wordt aan een Universeel Wegkant Platform. Ook bij dat project was behoefte aan meer kennis op dat terrein. Vervolgens is vanuit praktische overwegingen een opdracht vanuit AVV verstrekt om inzicht te geven in de techniek en functionaliteit van PLC's, DCS, industriële PC's en SCADA systemen. Vanuit de MD en AVV zijn hiervoor de, nog niet volledige, eisen ingebracht. Het resultaat van het onderzoek heeft geleid tot meer inzicht in de genoemde systemen. Ook is gebleken dat PLC's al dan niet gecombineerd met SCADA toepassingen een alternatief kunnen vormen voor de tot nu bedachte oplossingen. Op het gebied van PLC's is een programmeerstandaard (IEC 61131-3) ontwikkeld waaraan de vooraanstaande leveranciers zich gecommitteerd hebben. Daarmee wordt aan twee basiseisen voldaan: er zijn meerdere leveranciers die de systemen kunnen leveren en er zijn meerdere leveranciers die voor deze systemen software kunnen ontwikkelen. PLC's worden toegepast in industriële omgevingen en voldoen per definitie aan normen op het gebied van veiligheid en betrouwbaarheid. Voor de communicatie met het veld (sensoren en actuatoren) zijn diverse bussen ontwikkeld. Voor veldbussen zoals Profibus of CANbus zijn vele componenten op de markt verkrijgbaar. Tijdens de marktverkenning zijn reeds sensoren en actuatoren met een Profibus aansluiting gevonden. Het voordeel is


144

dat er geen aparte drivers behoeven te worden ontwikkeld. Deze zijn reeds voorhanden. PLC's kunnen op twee manieren worden gekoppeld met het centrale systeem. Via een SCADA pakket of OPC. Koppelingen via een SCADA pakket leiden tot een uniforme interface in de centrale. Ook kennen de meeste SCADA pakketten de mogelijkheid om d.m.v. script- of programmeertalen gegevensbewerkingen uitte voeren. De standaard userinterfaces van SCADA pakketten zijn over het algemeen snel maar voldoen niet als userinterface naar de wegverkeersleider. De meeste SCADA pakketten bieden de optie om een eigen userinterface te ontwikkelen of aan te sluiten. De OPC oplossing is een API-achtige oplossing zodat applicaties direct met de PLC kunnen communiceren. In beide gevallen kan een eenduidige interface gerealiseerd worden, ongeacht hoe de verschillende wegkant systemen zijn opgebouwd. 5.1.6 Projectaanpak De 'MATCH' marktverkenning is opgestart als drie afzonderlijke projecten, met drie separate projectplannen en drie verschillende vraagstellingen. De indeling van verkeersmanagementsystemen in SMS, AMS en AC bleek niet overeen te komen met het beeld dat productleveranciers van verkeersmanagementsystemen hebben, waardoor ze soms drie keer hetzelfde verhaal moesten vertellen. In de aanloopfase van het project zijn de drie projecten samengevoegd. Hierbij is echter geen duidelijk gemeenschappelijk projectplan geformuleerd. In latere fasen heeft dit relatief veel inspanning gekost. De onzekerheden in de formulering van wensen en eisen in de Applicatie Architectuur en ACT van waaruit producten componenteisen afgeleid dienden te worden voor de marktverkenning hebben eveneens relatief veel inspanning gekost. De bekendheid van AVB in het algemeen en ACT in het bijzonder is tijdens het onderzoek als bijzonder beperkt ervaren. Het feit, dat er drie architecturen naast elkaar bestaan (KAREN, AVB, ACT), zonder dat voor de buitenwereld de onderlinge relaties duidelijk zijn, bemoeilijkte gesprekken met leveranciers.


145

5.2 Conclusies De hier opgenomen conclusies hebben uitsluitend betrekking op de onderzoeksvraag zoals deze is geformuleerd in hoofdstuk 1: inzicht krijgen in de beschikbaarheid op de markt en de mate van toepasbaarheid van COTS15 producten voor generieke delen van een duurzaam dynamisch verkeersmanagement systeem.. 5.2.1 Gevonden Producten Er zijn producten gevonden, die binnen de AVB architectuur geplaatst kunnen worden en die tevens voldoen aan de gestelde functionele en niet functionele AVB-AA eisen (zoals beschreven in hoofdstuk 3 en bijlage E). Daar de grote verscheidenheid aan producten de evaluatie moeilijk en onoverzichtelijk maakte, zijn de producten in de volgende categorieën opgedeeld, en per categorie geëvalueerd. Toolkits voor de business logic, SCADA/PLC, Device Drivers, Actuator Management Systemen, Toolkits voor de presentatielaag en DVM Totaaloplossingen Behalve PL toolkits, zijn er geen COTS producten in de vorm van componenten, die voldoen aan het ACT ontwerp. Op zichzelf biedt een PL toolkit echter te weinig functionaliteit om er een DVM systeem van te maken. De markt van producten ten behoeve van locale autonome regelingen in combinatie met een centraal management systeem wordt gedomineerd door respectievelijk PLC en SCADA producten. De toepassing van een SCADA pakket als uniforme intermediair tussen systemen in de verkeerscentrales en de apparatuur aan de wegkant vormt derhalve mogelijk een goede eerste stap in de toepassing van COTS producten. Het gebruik van PLC's als wegkantplatform sluit hier vervolgens naadloos op aan. Voor de verbinding tussen het wegkantplatform en de sensoren en actuatoren is de Profibus veldbus een geschikte open standaard, die reeds door leveranciers ondersteund wordt. De producten konden niet volledig getoetst worden, omdat delen van het AVB-AA en ACT eisenpakket nog ontbreken. Wil een productselectie uitgevoerd kunnen worden dan zijn uitgebreidere en meer gedetailleerde specificaties noodzakelijk. De producten zijn beoordeeld binnen een categorie. Er kan echter geen uitspraak gedaan worden over koppelbaarheid tussen systemen uit verschillende categorieën. Dit onderzoek was niet haalbaar binnen de scope van het project en er is dus geen specifiek informatie voor ingewonnen. Er zijn wel COTS producten gevonden, die goed aan de gestelde (AVB-AA) eisen voldoen, maar waarvoor een ander DVM architectuurontwerp moet worden gemaakt (dan hetgeen beschreven is in [ACT_SSDD]), alvorens ze kunnen worden toegepast. Vanuit het huidige AVV perspectief met betrekking tot VANESSA, zijn er in dat geval twee opties: • Een DVM systeem, waarbij delen worden ingevuld door VANESSA; • Een DVM systeem, waarbij geen gebruik gemaakt wordt van VANESSA.

15

Commercial Off The Shelf producten; daarbij gaat het om duurzame producten of systeemdelen

die op de markt beschikbaar zijn.


146

5.2.2 DVM Systeem op basis van VANESSA Een DVM systeem op basis van VANESSA kan gerealiseerd worden met COTS producten uit de productcategorie SCADA/PLC, voor het inwinnen en distribueren van sensor informatie en het aansturen van actuatoren. Er kan op basis van het uitgevoerde marktonderzoek geen keuze gemaakt worden voor een bepaalde SCADA/PLC oplossing, ledere SCADA oplossing voldoet niet volledig aan alle selectie criteria, ook al worden de presentatielaag en het sessie- user- en taakbeheer buiten beschouwing gelaten. De meeste functionaliteit van de beschouwde producten wordt echter geboden door: OSISoft PI System, Imtech's Unimacs (in casu: SCADA: Cimplicity van Trimation en PLC: Modicon van Schneider-Electric), en Transdyn's Dynac ATMS. Daar in VANESSA de Business Logic functionaliteit ontbreekt, kan het SCADA pakket worden aangevuld met een Business Logic toolkit, indien het betreffende SCADA pakket onvoldoende Business Logic functionaliteit bevat. Ten gevolge van het feit dat de markt benaderd is vanuit software componenten ten behoeve van verkeersmanagement, vormen de onderzochte SCADA/PLC producten slechts een subset van de op de markt aanwezige SCADA/PLC systemen. Er zijn derhalve vermoedelijk meer geschikte systemen dan in dit rapport worden genoemd. 5.2.3 DVM Systeem zonder VANESSA Een DVM systeem kan zonder VANESSA op twee manieren gerealiseerd worden: •

Met COTS producten uit de productcategorie totaaloplossing; door een enkele leverancier. Er kan op basis van het uitgevoerde marktonderzoek geen keuze gemaakt worden voor een bepaalde totaaloplossing. Geen enkele totaaloplossing voldoet aan alle selectie criteria. Ml Services' TransActive, IBI Group's ATMS (inclusief ADCS), en Delcan's TCSS bieden echter de meeste functionaliteit.

•

Met een combinatie van COTS producten: Een SCADA/PLC systeem, aangevuld met GIS pakket en eventueel BL toolkit. Hierbij komen dezelfde producten in aanmerking als bij toepassing van VANESSA, zoals beschreven in 5.2.2


147

5.3 Aanbevelingen


1.

Implementeer AVB-AA op basis van (AVB conforme) marktproducten en niet op basis van componenten met de omvang zoals deze is gedefinieerd in ACT.

2.

Om de volgende generatie verkeersmanagementsystemen conform AVB met COTS producten van verschillende leveranciers te kunnen ontwikkelen is conformiteit met een internationale standaard voor koppeling van systemen gewenst. De categorie van SCADA en PLC producten is de enige categorie uit de shortlist met COTS producten op basis van zo'n standaard. Het aantal SCADA en PLC producten is echter vele malen groter dan het aantal producten dat in dit project is geëvalueerd, en een aanbeveling voor één specifiek product is dan ook niet opportuun. Van de SCADA/PLC producten die wel zijn beschouwd, hebben OSISoft PI System, Imtech's Unimacs (in casu: SCADA: Cimplicity van Trimation en PLC: Modicon van SchneiderElectric), en Transdyn's Dynac ATMS de meeste functionaliteit.

3.

Gezien de geringe ervaring op het gebied van SCADA/PLC standaarden is het uitvoeren van een kleinschalige praktijkproef aan te bevelen, met de volgende uitgangspunten: • Voor de keuze van het hiervoor te gebruiken SCADA pakket kan naast de informatie uit dit rapport, eveneens informatie uit het separate SCADA/PLC onderzoek [ICT 2002.17.0049] worden gebruikt. • Voor de keuze van de hiervoor te gebruiken PLC, moet een keuze gemaakt worden uit PLC's met een embedded webserver, waardoor tevens onderzocht kan worden of de hierdoor geboden onderhoudsfaciliteit een oplossing biedt voor de wensen op het gebied van technisch systeembeheer en onderhoud. • Het aanbrengen van één-richting verbinding met het bestaande MONICA systeem om gegevens uit MONICA naar een SCADA systeem over te brengen, zou parallel hieraan kunnen worden uitgevoerd. • Gebruik van de huidige actuatoren, waarbij een interface ontwikkeld wordt om de bestaande actuatoren op een PLC aan te kunnen sluiten.

4.

Indien gekozen wordt voor toepassing van CORBA tussen de centrale en het wegkantstation, vereist dit een goede organisatie en strakke regie van het standaardisatie proces van componentinterfaces. Hierbij moeten ook de leveranciers van software en van wegkantsystemen betrokken worden. Daarnaast zullen enkele technische aspecten nader uitgewerkt moeten worden (4.2.9), zoals de benodigde capaciteit en quality-of-service van VicNet. In de marktverkenning zijn alleen totaaloplossingen met CORBA componenten gevonden, maar individuele componenten worden niet als product geleverd. In de onderzoeksfase is het ontbreken van interface standaarden nog geen groot probleem, evenals voor toepassing binnen een verkeerscentrale. Om de totale Applicatie Architectuur echter leverancier onafhankelijk met COTS componenten te kunnen implementeren, is verdere standaardisatie van de CORBA middleware voor DVM nodig, zoals in NTCIP en UTMC.

148

5.

Het opnemen in de AVB documentatie van de bij het MATCH project gebruikte functionele en niet functionele specificaties, die zijn opgenomen als bijlage van dit rapport. Om verwarring te voorkomen is het raadzaam de oude AVB website te verwijderen.

6.

Om een daadwerkelijk AVB conform dynamisch verkeersmanagementsysteem te kunnen ontwikkelen, moeten vooraleerst de specificaties van dit verkeersmanagementsysteem opgesteld worden. Hierbij moet gewerkt worden vanuit de behoefte van de eindgebruikers. Voor het vastleggingsproces van de specificaties en het ontwerp dient gebruik gemaakt te worden van een gestructureerde methode.

7.

Om meer begrip te kweken voor AVB kan het verhelderend werken om de relatie tussen KAREN en AVB te verduidelijken, alsmede om de lagen van de AVB architectuur onderling af te stemmen, met name de interface tussen Applicatie Architectuur (AA) en de Technische Infrastructuur (TIAV).

8.

De ontwikkeling van de Applicatie Architectuur en de Architectuur van de Technische Infrastructuur dient in onderlinge afstemming te worden uitgevoerd. De voorkeur gaat ernaar uit om dit zelfs binnen één team te realiseren.

9.

Het in samenwerkingsverband tussen verkeersindustrie en overheid opstellen van standaarden voor de Nederlandse ITS systemen, bij voorkeur als afgeleide van een of meer bestaande standaarden. Als interface standaard tussen sensoren, actuatoren en wegkantsystemen kan hiervoor gebruik gemaakt worden van de Profibus veldbus.

10. Specificatie van een standaard begrippenkader (ontologie), data definities en berichten voor een communicatie standaard in Nederland, conform aanbeveling 9. Voor deze ontwikkeling en distributie van de specificatie wordt het gebruik van XML aangeraden zoals beschreven is in 4.2.9. Het specificatie proces bevat volgende stappen: • Specificatie van een begrippenkader (ontologie) voor de juiste betekenis en interpretatie van te gebruiken DVM concepten. • Specificatie van berichten en data definities op basis van gekozen architectuur, componenten en producten.


149

6 Opgedane ervaringen m.b.t. marktverkenning

In dit hoofdstuk worden beknopt de ervaringen opgenomen die het project team heeft opgedaan tijdens de marktverkenning, met als doel deze ervaringen door te geven voor vergelijkbare toekomstige projecten. De auteurs zijn van mening dat de gevolgde aanpak, zoals beschreven in hoofdstuk 2, en de uitvoering effectief zijn geweest voor deze marktverkenning. De geschikte informatie bronnen zijn op die projectfasen ingezet, waarin ze het meest effectief zijn gebleken. De brede product verkenning heeft veel informatie en inzicht over (categorieën van) producten in andere werelddelen, standaarden en branches opgeleverd. Objectieve criteria voor een diepere verkenning en evaluatie van producten ontbraken initieel en zijn opgesteld en uitgevoerd. Hiervoor is een ook verkenning uitgevoerd naar relevante aspecten voor integratie van COTS producten, zoals standaarden voor communicatie protocollen en data definities, en standaardisatie processen. Dit heeft gerealiseerd in een breed overzicht van potentieel interessante producten, product categorieën en alternatieven voor de Applicatie Architectuur. Een meer gedetailleerde evaluatie of selectie van product categorieën en producten is momenteel nog niet opportuun, omdat de vereiste objectieve criteria vanuit de Applicatie Architectuur nog ontbreken. De relevante ervaringen met de sterke en zwakke punten van een informatie bron of verkenningsinstrument zijn op zich zelf en in afzonderlijke paragrafen verzameld; internet, e-mail, telefonische follow-up, reacties van bedrijven op questionnaires, beursbezoeken, bedrijfsbezoeken en presentaties, en het project dossier. Hieruit blijkt hoe en wanneer welk instrument of bron efficiënt gebruikt kan worden, welke vragen gesteld moeten of kunnen worden, en welke antwoorden en reacties worden verkregen. Om de relevantie van de ervaringen te kunnen beoordelen wordt eerst de context ervan geschetst in een karakterisering van het project. Hier wordt echter niet het proces en het plan van aanpak uit hoofdstuk 2 herbeschouwd.

6.1

Karakterisering van het project

Brede marktverkenning De marktverkenning is zeer breed uitgevoerd om een wereldwijd beeld te creëren van COTS software componenten en om een beeld te creëren van oplossingen voor soortgelijke problemen in andere branches. Vanuit de primaire doelstellingen is vooral gelet op de toepassing van standaardisering van architecturen, koppeling van producten, en communicatie. In een brede marktverkenning moeten veel bedrijven op een objectieve en uniforme wijze worden benaderd op een korte termijn. Dit vereist een uniforme benadering met standaard vragenlijsten (questionnaires) en documentatie ter introductie van de doelstellingen en achtergrond van de marktverkenning. Belangrijk hierbij is om een minimale hoeveelheid informatie te geven en te vragen, en op het juiste tijdstip. Om vragen goed en objectief beantwoord te krijgen is het belangrijk om de leverancier persoonlijk te benaderen om eventuele verschillen in terminologie


150

en interpretatie helder te krijgen en onderling uit te werken. Dit is met name belangrijk bij het verzamelen, evalueren en verifiëren van product informatie en questionnaires die eenzijdig zijn ingevuld door een leverancier. Product selectie Aanvankelijk was product selectie één van de doelstellingen van dit project, dit ter voorbereiding op het aanschaffen en uitproberen van één of enkele producten in vervolgprojecten. Vanuit deze doelstelling is de markt initieel ook benaderd met de longlist questionnaire, en dat heeft zeker effect gesorteerd. Een aantal bedrijven heeft zeer alert gereageerd en is het project blijven volgen om vooral op de shortlist te komen en te blijven staan. Gedurende het project is deze doelstelling bijgesteld tot het evalueren van producten op een hoger abstractie niveau teneinde trends te ontdekken in het gebruik van standaarden en product ontwikkeling. Hiertoe zijn producten in categorieën geëvalueerd en zijn conclusies en aanbevelingen met name over deze categorieën en hun standaarden getrokken. Achteraf gezien heeft de initiële formulering van deze doelstelling enige verstorende invloed gehad. De initiële formulering is door enkele leveranciers geïnterpreteerd als een aanvraag en is onterecht een verwachtingsbeeld ontstaan dat niet waargemaakt kan worden. De reactie van deze leveranciers is eerder te karakteriseren als "we willen producten verkopen" dan "we hebben geschikte COTS componenten". Dit hebben we moeten corrigeren door herhaaldelijk te benadrukken dat MATCH een marktverkenning is. Formulering van de zoekvraag Het AVB project is een project met een relatief hoog theoretisch DVM en ICT gehalte. In dit project heeft dit tot twee potentiële problemen geleid: 1. De terminologie en verkeerskundige concepten die gehanteerd worden in de communicatie en documentatie verschilt soms sterk van die bij bepaalde product leveranciers. De zoekvraag zal aangepast moeten worden aan de terminologie van de leverancier om een zinvol antwoord te kunnen krijgen. 2. De marktverkenning wordt initieel gericht op technische oplossingen die te ver van de gangbare oplossingen in de markt staan. Dit betekent dat de essentie van de initiële vraag achterhaald moet worden en conform de markt ingevuld moet worden. In dit project kon de vertaalslag gemaakt worden via architectuur en communicatie standaarden. Met andere woorden er is via producten naar standaarden gezocht die bij de AVB passen, in plaats van producten te zoeken via standaarden die conform AVB zijn.

Tijdshorizon van de markt Het AVB project is een project voor onderzoek naar, en ontwikkeling van een nationale architectuur in de toekomst met een lange termijn visie. Daarbinnen zijn demonstratie projecten gedefinieerd die op korte termijn gerealiseerd moeten worden. Deze marktverkenning is gericht op beide vragen; de eisen worden bepaald door de lange termijn visie, terwijl we componenten zoeken die nu (of binnenkort) beschikbaar zijn als product. Deze schijnbaar duale vraag vereist een lange termijn visie van de leveranciers op hun huidige producten. Leveranciers hebben doorgaans een korte termijn visie als het gaat om de verkoop van hun producten. De inspanning die wij van hen vragen kost energie en levert hen op de korte termijn niets op. We zien dan ook zeer uiteenlopende interessen uit de markt voor onze verkenning, en het vereist enige diplomatie om medewerking van bepaalde leveranciers te krijgen en om de achterliggende redenen van hun reactie in te schatten.


151

6.2 Gebruik van internet In dit project is het world wide web veelvuldig gebruikt om informatie over bedrijven, producten, standaarden, conferenties, projecten en organisaties te vinden. Een bekend feit is dat web pagina's relatief veel onderhoud vergen. Bedrijven die relatief weinig zaken doen via het internet achten web presence veelal belangrijker te zijn dan web content, en hun pagina's bevatten niet altijd actuele en correcte informatie. Zo hebben we ook in dit project alle stadia van web-site ontwikkeling kunnen waarnemen; van bedrijven die helemaal niet aanwezig zijn met (publieke) pagina's, via bedrijven die (bewust) géén contact informatie op hun site publiceren, en portals met relevante product informatie, tot prachtige sites met veelbelovende verkoopinformatie. Er zijn ook sites met alleen een standaard invulformulier waarop een vraag naar meer informatie gesteld kan worden. Deze zijn meestal even effectief als een info® e-mail adres, zie 6.3. Een tweede bekend feit is dat de informatie eenzijdig is; leveranciers publiceren alleen informatie die zij vrij willen geven, en presenteren die informatie vanuit hun gezichtspunt op de problematiek en oplossingen. De gepubliceerde informatie verschilt daardoor per leverancier, en een kritische houding ten opzichte van de gepubliceerde informatie is essentieel. Verificatie van de informatie is essentieel, maar alleen mogelijk met medewerking van de leverancier. Deze bron dient vooral de exploratieve fase van de marktverkenning om wereldwijd potentieel interessante bedrijven en producten op te sporen. Naderhand kan ook specifieke productinformatie worden nagekeken indien bedrijven hun klanten-portals openstellen.

6.3 Gebruik van e-mail Elektronische post (e-mail) is veelvuldig gebruikt voor elektronische distributie van de questionnaires, en naderhand voor persoonlijke communicatie. Voordelen van elektronische distributie van questionnaires zijn tweeledig; alle bedrijven kunnen gelijktijdig worden aangeschreven met een gepersonaliseerde begeleidende 'brief', en de resultaten kunnen ook elektronisch worden geretourneerd en vergemakkelijken verdere verwerking. Persoonlijke communicatie is vooral efficiënt voor gesprekspartners die moeilijk bereikbaar zijn of in het buitenland, en om elektronische informatie zoals delen van de questionnaires of product informatie te communiceren. Nadeel is echter dat informatie uitwisseling wordt uitgesmeerd over dagen in plaats van te concentreren in een gesprek, en dat er geen directe interactie is om misverstanden te detecteren en uit te praten. Daarvoor is een telefoon- of persoonlijk gesprek onontbeerlijk.

6.4 Telefonische follow-up Dit is erg belangrijk in twee fasen. Via internet zijn meestal alleen algemene contactadressen van bedrijven vermeld, zoals info® en een algemeen telefoonnummer. Een e-mail met een questionnaire naar info® verdwijnt ergens in het bedrijf en wordt veelal niet beantwoord. Nadien telefonisch navragen wat er met de questionnaire is gebeurd levert veelal geen resultaat op. Indien vooraf telefonisch navraag wordt gedaan volgt veelal een direct


152

contact met een persoon uit de organisatie die bereid is de behandeling van de questionnaire op te volgen. Veelal blijken grote interpretatieverschillen te bestaan bij de vragen in een questionnaire. Een telefonisch gesprek blijkt dan ook bijzonder effectief bij de evaluatie en navraag van ingevulde questionnaires om deze verschillen te identificeren en uitte praten. Het voeren van een telefonisch gesprek kost echter relatief meer tijd dan het versturen van een e-mail. Er moeten een groot aantal producten behandeld worden. Om de juiste vragen te kunnen stellen moet ieder gesprek goed voorbereid worden. Dit impliceert terug lezen van gespreksverslagen, product informatie en ingevulde questionnaires. Dit geldt evenzeer voor het verzenden van een e-mail. Verschil is echter dat een gesprekspartner niet altijd bereikbaar is, bijvoorbeeld vanwege een druk bezet agenda, of door tijdverschillen. Deze voorbereiding moet soms enige malen herhaald moet worden en die kost veel tijd. Een e-mail gevolgd door een telefoongesprek blijkt zeer efficiënt te zijn. Vragen en resultaten worden vooraf opgestuurd per e-mail zodat de ontvanger ze kan bestuderen. Het telefoongesprek kan zo zeer gericht en bondig worden uitgevoerd. Ook kan een afspraak voor telefonische opvolging worden meegestuurd. De e-mail is ook een goede reden voor een telefoongesprek indien de leverancier niet reageert op e-mails. Een telefoonconferentie is een goed middel gebleken om met bijvoorbeeld verkopers en technische experts, of met personeel van verschillende vestigingen gelijktijdig de questionnaires en andere vragen te bespreken. Bij een aantal leveranciers is het niet mogelijk een goede gemeenschappelijke taal te vinden, waardoor directe communicatie zeer moeizaam is. In die gevallen blijkt e-mail gemakkelijker en duidelijker te zijn.

6.5 Reacties van bedrijven op questionnaires De longlist questionnaires zijn naar een groot aantal bedrijven verstuurd in de DVM en in andere branches. De reacties zijn even divers. Voor verwerking zijn de bedrijven gegroepeerd in drie categorieën; bedrijven die niet, negatief of positief reageren. Bedrijven die niet uit zichzelf reageren zijn telefonisch benaderd. Daaruit blijkt dat, of de questionnaire niet bij de juiste persoon terecht is gekomen en alsnog opgestuurd kan worden, of een questionnaire is doorgestuurd naar een ander onderdeel van de organisatie, of dat het bedrijf niet relevant blijkt te zijn voor dit onderzoek en als negatief kan worden behandeld. Door de brede verkenning zullen natuurlijk een groot aantal bedrijven worden benaderd die negatief zullen reageren, of achteraf af zullen vallen. Het blijkt dat de reactie niet altijd correspondeert met de waarde van een product voor de marktverkenning. Enkele indicatieve reacties zijn vermeldenswaard. •


Een bedrijf heeft een specifieke markt, bijvoorbeeld scheepvaart of petrochemie. Het biedt wel producten die voor DVM inzetbaar zijn, maar ziet DVM niet als haar kernactiviteit, en is niet geïnteresseerd om te leveren en in onze problematiek. Het bedrijf kan negatief, niet, of beleefd terughoudend reageren. In de laatste twee situaties is enige moeite nodig

153

•

•

•

•

•

•

om de reden te achterhalen. Bedrijven die zo beleefd reageren blijken wel duidelijkheid te verschaffen in een persoonlijk gesprek per telefoon of op de beurs. Een bedrijf heeft een duidelijke geografische afzetmarkt buiten Nederland. Waarschijnlijk zijn haar producten speciaal ontwikkeld voor de locale markt. Dit bedrijf zal niet reageren op de questionnaire. Bij navraag wordt duidelijk dat onze marktverkenning geen hoge prioriteit heeft. Een holding heeft vele kleine dochterbedrijven die om historische redenen ieder een eigen product leveren en een eigen markt bedienen. De holding verzorgt de web presence of is een hyperlink pagina naar de dochterbedrijven. Noch vanuit de holding, noch vanuit de individuele bedrijven komt een duidelijke visie op een DVM architectuur en gebruik van standaarden voor koppeling van producten. Het bedrijf is een Nederlandse of Europese distributeur. De kennis over producten, architecturen en toekomst visie zit bij het moederbedrijf of een andere leverancier, die ons weer terug verwijst naar het locale bedrijf vanwege haar marktkennis en verantwoordelijkheid. Op diplomatieke wijze moet de locale vertegenwoordiging gepasseerd worden om persoonlijk contact te krijgen met de relevante technici en de juiste antwoorden te verkrijgen. Een bedrijf levert vooral consultancy of maatwerkoplossingen op project basis, in plaats van eigen COTS producten te integreren in een project. Ook deze bedrijven presenteren hun succesvolle projecten op het internet en in mooie brochures. Sommige voeren hun project resultaten op als COTS producten in de questionnaires. Deze producten zijn te filteren doordat er meestal weinig uitgebreide product informatie beschikbaar is met prijsinformatie, functionaliteit en beperkingen op hardware, communicatie standaarden en integratie mogelijkheden. De install-base is ook erg klein. Op diplomatieke wijze zal gezamenlijk geconcludeerd moeten worden dat ze geen geschikte COTS producten hebben en eigenlijk niet op de shortlist moeten staan. Een bedrijf heeft een groot commercieel belang om zijn producten geselecteerd te krijgen. Zij reageert positief op de questionnaire en biedt aan om de producten nader te presenteren bij ons. Uit persoonlijke gesprekken moet blijken of zij daadwerkelijk de voor ons onderzoek interessante COTS producten hebben, bereidt zijn leverancier onafhankelijke oplossingen te bieden, en een toekomst visie hebben op een architectuur en gebruik van standaarden. Gedetailleerde technische vragen over bijvoorbeeld koppelvlakken, interoperabiliteit en uitwisselbaarheid zijn hier belangrijk. De terminologie of problematiek van de vraagstelling en questionnaires zijn onbegrijpelijk voor een leverancier. Deze zal veelal niet uit zich zelf reageren. Telefonische navraag is veelal voldoende om het probleem te detecteren en uit te werken.

In dit project is de shortlist questionnaire ongeveer 2 maanden na de longlist questionnaire opgestuurd. Die periode is relatief erg lang. Dit levert twee nadelen op voor een marktverkenning. Een aantal bedrijven is het project en de longlist al weer vergeten, en reageren verrast dat ze toch nog op de shortlist zijn terechtgekomen. De problematiek moet dan weer opnieuw geïntroduceerd moet worden, en de aandacht en het enthousiasme voor medewerking neemt af. Een aantal bedrijven heeft de shortlist questionnaire dan ook niet meer beantwoord, en ontwijkend gereageerd op pogingen om alsnog telefonisch of per e-mail de relevante informatie te verkrijgen.


154

In het project resteerde te weinig tijd om na evaluatie van de shortlist de producten nauwkeuriger en in meer technisch detail te evalueren en om alle overblijvende bedrijven te bezoeken.

6.6 Beursbezoeken Beurzen zijn een efficiënte wijze om op korte termijn veel bedrijven en producten te bekijken. Het grote voordeel van een beurs is dat in een persoonlijk gesprek snel duidelijkheid verkregen kan worden in hoeverre het bedrijf relevante COTS producten kan aanbieden. Demo's worden getoond waarmee snel inzicht kan worden verkregen in de functionaliteit. Daarnaast blijken op beurzen ook bedrijven op te duiken die bijvoorbeeld geen internet site hebben en niet adverteren in vakbladen. Een effectieve tactiek is om producten en leveranciers direct met elkaar te vergelijken door terug te gaan naar leveranciers met specifieke vragen over nieuwe ideeën of 'onderhuidse' problemen die later tijdens de beurs zijn ontdekt. Dit is dus ook een middel om bedrijven en producten te elimineren die niet voldoen aan de zoekcriteria. Nadeel van beurzen is dat de stands veelal bemenst worden door verkopers die voor het huidige project weinig technische vragen kunnen beantwoorden. Er wordt al snel een poging gedaan om afspraken of presentaties te regelen met technici uit het bedrijf. Timing van beurzen is ook belangrijk bij de projectplanning. In ons geval waren de meeste relevante beurzen nadat de meeste longlist questionnaires waren geretourneerd. Zo konden gericht stands worden bezocht en vooraf afspraken worden gemaakt met de juiste personen. Dit blijkt een efficiënte benadering te zijn om op korte tijd vele buitenlandse bedrijven persoonlijk te benaderen op internationale beurzen.

6.7 Bedrijfsbezoeken en presentaties Een aantal bedrijven zijn persoonlijk bezocht, of zijn uitgenodigd om een product presentatie te geven bij ons. Deze persoonlijke gesprekken zijn bijzonder waardevol voor nauwkeuriger evaluatie van producten. Er is meer tijd beschikbaar om over details en toekomst visies te discussiëren. Mondeling wordt ook meer informatie gegeven dan op schrift, met name over ontwikkelproces en integratiemogelijkheden. Gezien het intensieve karaktervan deze gesprekken is dit alleen effectief voor producten die nauwkeurig zijn geëvalueerd op basis van schriftelijke productinformatie en de questionnaires.

6.8 Project dossier Er zijn verschillende soorten van project dossiers gehanteerd in de verschillende projectfasen. In de longlist fase voldoet een MS Excel spreadsheet om algemene bedrijfs-, adres- en proces status gegevens te verzamelen. In de shortlist fase is een directory structuur opgezet met aparte directories per leverancier of product, waarin alle informatie, zoals documenten, e-mails, en notities van telefoongesprekken gebundeld worden. Deze structuur hangt nauw samen met de werkwijze. Er is gekozen voor een werkverdeling waarin een medewerker verantwoordelijk is voor alle communicatie en informatie


155

verwerking van een leverancier of product. Integratie van de informatie over producten heen gebeurt door onderlinge afstemming tussen de medewerkers. Er is ook overwogen om een MS Access database aan te leggen waarin alle correspondentie en proces informatie centraal kon worden verzameld en bereikbaar was voor alle projectieden. De shortlist fase is echter geen vast gestructureerd proces, ledere leverancier reageert anders en levert haar informatie op een andere wijze aan. Een database blijkt te rigide om alle soorten informatie te kunnen archiveren, bewerken, annoteren en relateren. Ook blijkt het niet goed mogelijk om de werkwijze van alle projectieden voldoende te ondersteunen. De directory structuur blijkt een effectievere oplossing te zijn om deze informatie te structureren.

6.9 Praktische zaken Een aantal praktische zaken kunnen als aandachtspuntenlijstje bij een projectopzet gebruikt worden. Deze zaken zullen als 'triviaal' beschouwd worden maar blijken desondanks regelmatig terug te keren en meer of minder onnodige tijd te consumeren. • Voor een goede samenwerking en harmonisering van de werkwijze is het efficiënt gebleken de directe project medewerkers op één projectkamer te huisvesting. Een geringe afstand met de van huisvesting van projectleiders en domein experts is eveneens belangrijk. • Voor een wereldwijde marktverkenning zal alle correspondentie in een buitenlandse taal uitgestuurd moeten worden. Om werktijd en interpretatieverschillen te voorkomen is het aan te bevelen om alle extern te communiceren documentatie alleen in die taal te schrijven. Een Nederlands eindrapport bijvoorbeeld is niet communiceerbaar met buitenlandse bedrijven die hebben meegewerkt aan het onderzoek. • Technische ondersteuning moet voorbereid zijn om met meerdere mensen op een gemeenschappelijke directory samen te kunnen werken, en vanuit een gemeenschappelijk e-mail account questionnaires te kunnen verwerken. De telefoons moeten geautoriseerd zijn voor het buitenland, ook na Nederlandse kantooruren.

6.10 Conclusie De gekozen benadering en het gebruik van informatie bronnen en technieken voor de marktverkenning, zoals is beschreven in hoofdstuk 2, blijkt effectief te zijn voor een brede en exploratieve marktverkenning. De benadering is opgezet vanuit een bepaalde project doelstelling. De benadering zal wellicht voor andere marktverkenningen met andere doelstellingen moeten worden aangepast. Hiertoe zijn een aantal relevante aspecten uit het huidige onderzoek in dit hoofdstuk belicht.


156

Referenties

[ACTJP]

Rijkswaterstaat Adviesdienst Verkeer en Vervoer, Inspectie procedure t.b.v. het ACT project, document ACT.IP, versie 2.0, 9 november 2001. Association Franc,aise de Normalisation (AFNOR), www.afnor.fr Rijkswaterstaat Adviesdienst Verkeer en Vervoer, De AVB Applicatie Architectuur, versie 1.6, 20 mrt 2000. Rijkswaterstaat Adviesdienst Verkeer en Vervoer, ICT-aspecten van de AVB Applicatie Architectuur, versie 0.7, 4 augustus 2000. Rijkswaterstaat Adviesdienst Verkeer en Vervoer, De AVB Informatie Architectuur, versie 1.0, 28 januari 1999. Rijkswaterstaat Adviesdienst Verkeer en Vervoer, Technische Infrastructuur voor Verkeersbeheersing,

[AFNOR] [AVB.AA]

[AVB_AA_ICT]

[AVBJA]

[AVBJÏAV]

sep 2000. [AVB_VA]

[CBDi]

[CCSDS] [ICT 2002.17.0049]

[IEEE 1471]

[KAREN]

[Kaufeler et al.]

[KL] [Klijnhout] [Kwaliteitszorg] [LCR NORM]

[MESA2]


157

Rijkswaterstaat Adviesdienst Verkeer en Vervoer, De AVB Verkeerskundige Architectuur, Januari 2001. The Component-Based Development and integration forum CBDi, Buying Software Components, CBDiforum report, 2001. http://www.cbdiforum.com. Consultative Committee for Space Data Systems, http://www.ccsds.org Marktverkenning van PLC/SCADA/Industriële computers ICT Solutions, 2002.17.0049, juli 2002 IEEE Std 1471 - 2000; IEEE Recommended Practice for Architectural Description of Software-lntensive Systems Keystone Architecture Required for European Networks (KAREN), project mission and organisation: http://www.cordis.lu/telematics/tap transport/dep loyment/architecture/mission.html Kaufeler et al. Promoting ESA Software as a European Product: The SCOS-2000 example. ESA Bulletin, Vol 108, November 2001. Koninklijke Landmacht, http://www.landmacht.nl/ Introduction to ITS Architecture, Job Klijnhout Rijkswaterstaat Adviesdienst Verkeer en Vervoer, Project kwaliteitszorg advisering, 19 juli 2001. http://www.itsactif.org/architecture/site %20web%20VF/pages/P OBJ2077.HTM MESA International, MES Functionalities & MRP to

[MESA6]

[Nat ITS Arch] [NMCS2]

[NTCIP Framework] [NTCIP] [NTCIP-GuideJ

MES Data Flow Possibilities, white paper number 2, revised March 1997. http://www.mesa.org . MESA International, MES Explained: A high level vision, white paper number 6, September 1997. http://www.mesa.org . National ITS Architecture: http://itsarch.iteris.com/itsarch/ National Motorway Communications Systems, Design Manual for Roads and Bridges, The National Highway Agency, TA 72/97 Figure 3.3 uit NTCIP Standards Framework NTCIP www.ntcip.org NTCIP Guide, Joint Committees on the NTCIP (AASHTO, ITE, NEMA), V, 2.06 (Draft), December

1999 Rijkswaterstaat Adviesdienst Verkeer en Vervoer, Operational Concept Description (OCD) ACT, versie 0.4, 29-03-2002. OCIT public web site, wwww.ocit.org OSI Software, http://www.osisoft.de/ A comparison of three methods of data transfer for Center-to-Center Communications, Luke Pond,

[OCD_ACT]

[OCIT] [OSI Soft] [Pond]

1999, http://www.its.washington.edu/bbone/ASN1Whit ePaper-1.html Simple Object Access Protocol SOAP, Version 1.2,

[SOAP]

http://www.w3.org/TR/soap12-part1/ [SSDD_ACT]

Rijkswaterstaat Adviesdienst Verkeer en Vervoer, System/Subsystem Design Description (SSDD) ACT, versie 0.10, 21-12-2001. Rijkswaterstaat Adviesdienst Verkeer en Vervoer, System/Subsystem Specification (SSS) ACT, versie

[SSS_ACT]

0.12,21-12-2001. [Susanne]

Experience of traffic management in France, Etienne de Susanne, Direction Regionale de l'Equipement, 2000, http://www.utmc.dft.gov.uk/2000conf/pdf/utmcO Oedsusanne.pdf. http://www.its.dot.qov/eval/ResourceGuide/Eval Guidelines EvaluationGuidelines.htm TIH-DATEX; Project &. Architecture Summary, Courier project, 2001, http://members.trafficwales.com/courier/Courier%20TIHDATEX%20Project%20%20Architecture%20Sum mary% 202.pdf Technische Lieferbedingungen für Streckenstationen, S 1078, Bundesministerium für

[TEA-21] [TIH-DATEX]

[TLS]

Verkehr, Abteiling Strafenbau, 1993. Corba softwarebus doortrekken naar het wegkantstation, Z. Papp, T.K. ten Kate, TNO TPD Memorandum DII-MEM-020738, juni 2002. XML Definities ten behoeve van AVV, A. Meyer, D. Regtien, TNO TPD Memorandum DII-MEM020750, juni 2002. http://www.travelerinformation.com/ Home page van UTMC: http://www.utmc.dtlr.gov.uk/

[TPD 020738]

[TPD 020750]

[Travelinfo] [UTMC]


158

Suitability of NTCIP-based Communications, UTMC08 report, http://www.utmc.dtlr.gov.uk/utmc08/utmc08.htm Suitability of NTCIP Applications Messages, UTMC09 report, http://www.utmc.dtlr.gov.uk/utmc09/utmc09.htm UTMC Demonstrators: Results so far. M. Cartwright, B. Radia, B. Thancanamootoo, G., Tilley. UTMC29. Organization for the Advancement of Structured Information Standards OASIS. XML.org registry service; http://www.xml.org/xml/registry.jsp. industrie overzicht; http://www.xml.0rg/xml/industryjndustrysect0rs.j sp XML for Traffic Data Exchange, TRAIL, http://cttrailf.ct.tudelft.nl/verkeerskunde/staff/kirw an/about.html

[UTMC08]

[UTMC09]

[UTMC29]

[XML Registry]

[XML TRAIL]


159

Afkortingen

Afkorting

Betekenis

AA AC ACT AFNOR AMS AP API ASCII ATM ASTRIN AVB BASt BL BOZ BTPPL C3I CBD CCTV CCSDS CO COA COBS CORBA COTS DATEX DCS DTD DTLR

Applicatie Architectuur Application Control Applicatie Componenten Topologie Association Francaise de Normalisation Actuator Management Systeem Application Process (in CCSDS standaard) Application Programming Interface American Standard Code for Information Interchange Asynchronous Transfer Mode Association of Traffic Industries in the Netherlands Architectuur voor Verkeersbeheersing Budesanstallt für Straftenwesen Business Logic (laag) Bevoorrading op Zee Basis Transport Paket Protokoll Layer Command, Control, Communications & Intelligence Component Based Development Closed Circuit TV Consultative Committee for Space Data Systems Control Office Control Office Area Control Office Base System Common Object Request Broker Architecture Commercial Off The Shelf Data Exchange Distributed Control System Document Type Definition Department of Transport, Local Government and the Regions Dynamisch Route Informatie Paneel Dynamisch Verkeers Management Enterprise Requirement Planning Fiber Distributed Data Interface Frequency Shift Keying Finite State Machine File Transfer Protocol Graphic Design File Global System for Mobile Communications Graphical User Interface High-Level Data Link Control HyperText Transfer Protocol Human Machine Interface Hoogwegennet Informatie Architectuur Interface Definition Language International Electrotechnical Commission

DRIP DVM ERP FDDI FSK FSM FTP GDF GSM GUI HDLC HTTP HMI HWN IA IDL IEC


160

Afkorting

Betekenis

NOP t/O IP ITS IVER IVERA KAREN

Internet Inter Object Request Broker Input / Output Internet Protocol Intelligent Transport System(s) Initiatiefgroep Verkeers Regeltechnici Initiatiefgroep Verkeers Regeltechnici - Astrin Keystone Architecture Required for European Networks Koninklijke Landmacht Language de Control Routier Local Communications Controller Landelijk Verkeers Coördinatie Centrum (Spacecraft) Mission Control System Marktverkenning En Demonstratie Universele Sensoren en Actuatoren Manufacturing Execution System Management Information Base Motorway Incident Detection system Man Machine Interface MONitoring CAsco Motorway Traffic Management Multifunction Vehicle Bus National Motorway Communication System Nederlandse Spoorwegen National Transportation Communications for ITS Protocol Organisatie Architectuur Offene Schnittstelle für Gerate der StraBenverkehrstechnik Operator InterFace Object Linking and Embedding Object Management Group OLE for Process Control Openm Systems Interconnection Ontology Web Language Programmable Information Element Presentatielaag Programmable Logic Controller Point to MultiPoint Protocol Point to Point Protocol Quality of Service Openbaar Vervoer Resource Description Framework Remote Terminal Unit Standaard Applicaties voor Verkeers Informatie en Regel Algorithmes Supervisory Control And Data Acquisition Synchronous Data Link Protocol Sensor Management Systeem Simple Network Management Protocol StreckenStation Standard Transponder Simple Traffic Management Protocol Simple UTC Protocol

KL LCR LCC LVCL MCS MEDUSA MES MIB MIDAS MMI MONICA MTM MVB NMCS(2) NS NTCIP OA OCIT OIF OLE OMG OPC OSI OWL PIE PL PLC PMPP PPP QoS OV RDF RTU SAVIERA SCADA SLIP SMS SNMP SS ST STMP SUPS


161

Afkorting

Betekenis

SUT TC TCP TCIP TEDI TIC TIAV

Sessie-, User- en Taakbeheer Telecommand(ing) Transmission Control Protocol Transit Communication Interface Protocol Traffic Information Center Technische Infrastructuur Architectuur voor Verkeersbeheersing Technische Lieferbedingungen für Streckenstationen Telemetry User Datagram Protocol Union Internationale des Chemins de Fer Unified Modelling Language Urban Traffic Management and Control Universeel WegKantStation UnterZentrale Verkeerscentrale Algemeen Nieuw Eenvoudig Sturing Systeem Aanpassing Verkeerskundige Architectuur VerkeersBeheersing Verkeers Informatie- en Communicatienetwerk Vervoer Per Trein Verkeers Regel Installatie Wide Area Network Wired Train Bus Extended Markup Language

TLS TM UDP UIC UML UTMC UWKS UZ VANESSA VA VB VICnet VPT VRI WAN WTB XMS


162

Bijlage A

Lijst van aangeschreven leveranciers

iPÎIIBéiÉn^Baam]:1:1:!:-;''::!^'!1- Ï'M «Plaats?# « a i ^ ^ L a W f e : : / - : Birmingham USA [MG]2 St Paul USA 3M Intelligent Transportation Rotterdam Nederland ABB BV Spain Barcelona ACISA USA St. Paul ADDCO USA Advanced Traffic Products Inc. Everett USA Advanced Visual Systems Inc. Waltham Tegelen Nederland AGMI Nederland AinoBV ~~ZZZI Nieuwegein kuurne Belgium Air traffic Control & Vessel Nederland Alcatel Telecom Nederland BV Rijswijk (ZH) Toronto Canada Alcatel Transport Automation United Kingdom Reading Applied Traffic United Kingdom Portland Aquila Cybernetic Ltd Den Bosch Nederland Aranea Consult Den Haag Nederland ARS Traffic & Transport Üznach Switzerland ASIM Technologies Ltd. Amsterdam Nederland USA Athens Athens Technical Specialists Nederland Utrecht Atos Origin Nederland BV Aachen Germany AVE Verkehrs- und Belgium Kuurne Barco Control Rooms USA San Francisco BEI Technologies Inc. Trappenkamp Germany Beratec GmbH Pleasantown USA Braxton Technologies Inc Hattem Nederland Brimos wegbebakening bv USA Minneapolis BRW-URS Québec Canada CAE Newton USA Caliper Nederland Utrecht Cap Gemini Ernst & Young France Crolles Capsys S.A. South Spanaway USA Cascade Signal Corporation Nederland Hoofddorp Cegelec BV Nederland Vianen Cimsolutions BV Nederland Rijswijk Citee Divisie Service Nederland Den Haag CMG Public Sector USA Alameda Coastcom Sweden Jönköping Combitech Traffic Systems USA Titusville Command and Control USA Command System Inc. Fort Wayne Compaq Computer BV Nederland Utrecht Compuware BV Nederland Amsterdam


A-1

\gi • ;::l|Bedrijfsnaaniïi:;.:-r::. ; * : : : : Plaats %^-vm Comroad AG Control Technologies Croon Elektrotechniek BV CSC Computer Sciences BV CSS System Integration BV Daktronics Inc. Dambach Data Display Nederland B.V. DataCollect DC1 Electronics VOF Design4U Dialight Digital Image Inc Display Solutions Inc. DMJM + Harris Duraloop Inc. EAGLE Traffic Control Systems Eberle Design Inc. Econolite Control Products Inc. EDS Nederland BV Efkon AG Electronic Integrated Systems Electronique Controle Mesure Electro-Sensors Inc. Encom Wireless Data Solutions eNGENUITY Technologies Entran Devices Inc. Entran Devices Inc. Entran Limited Entran Sensoren GmbH ESG GmbH ETRA Group European Space Operations Eurotech SPA Exigent Software Technology Faget B.V. Fancom B.V. Ferranti Computer Systems NV Flex ICT Groep BV Florida Department of Fortran Traffic Systems Limited Gallium Software Inc. Gardner Transportation Systems Gardner Transportation Systems General Signals Inc. Gesig Getronics Business Solutions Getronics Industrial Automation Getronics System Integration BV


A-2

Unterschleisshei Sanford Rotterdam Bunnik Arnhem Brookings Kuppenheim Hendrik Ido Amb. Kerpen Kapelle Delft Farmingdale San José Norcross GA Pompano Beach McMinnville Austin Phoenix Anaheim Maarssen Graz Toronto Vandoeuvre-lesMinnetonka Calgary Montreal PQ Fairfield Les Clayes-sousWatford Ludwigshafen Munchen Valencia Darmstadt Udine Melbourne Steenwijk Panningen Antwerpen Tallahassee Toronto Ontario Den Haag Concord Murray Evansville VVien Hoofddorp Amsterdam Veenendaal

Germany USA Nederland Nederland Nederland USA Duitsland Nederland Germany Nederland Nederland USA USA USA USA USA USA USA USA Nederland Austria Canada France USA Canada Canada USA France England Germany Germany Spain Germany Italy USA Nederland Nederland België Nederland USA Canada Nederland USA USA USA Oostenrijk Nederland Nederland Nederland

:I:SiE|IBé^rüfenaam:rt:^:Hns-ïi;. v;:;;c::vpiaatsK;v:^ Getronics Telecom Solutions BV GEVAS Software Giat Industries GIS/TRANS Ltd Golden River traffic Ltd. GRE America Inc Green Center GTI Infratechniek BV H.M. Automatic a/s Hansen Information HARP Visual Communications Harris Corporation Hiflex Automatiseringstechniek Highway Information Systems Hi-Lux Technical Services P/L Hi-Q Systems Ltd HITT b.v. HNTB Corporation Houston TranStar HVL Elektrotechniek BV IBM Nederland NV ICL Nederland BV iCT Solutions BV ILOG SA Image Sensing Systems Inc. Imtech Corporation Imtech Marine & Offshore Imtech Mescon BV Incaa Computers B.V. Info Products Info Support BV Infra Engineering BV Ingenieria de Sistemas Arstecne Innovative Transportation Integral Systems Inc. Integrated Security Systems Inc. Intelligent Traffic Engineering & ïnter(VCD)BV Inter Video Communicatie BV Interface & Control Systems Inc. International Road Dynamics IQUIP Informatica BV Irvine Sensors Corporation Isolectra B.V. Isotek Electronics Ltd

ïffy Iteris Inc. JB Technology Inc. Jenoptik Laser Optik Systeme


A-3

Delft München Versailles Torrance Bicester Belmont Praha Wormen/eer Thisted Sacramento Southampton Littleton Ridderkerk Du mam Victoria Winchester Apeldoorn Alexandria Houston Eindhoven Amsterdam Maarssen Barendrecht Gentilly Cedex St. Paul Denville Rotterdam Zaandam Apeldoorn Bodegraven Veenendaal Amersfoort Barcelona Corvallis Lanham Irving Victoria BC Groningen Duiven Melbourne Saskatoon SK Diemen Costa Mesa Rotterdam Leeds Zwolle Anaheim Ridgefield Jena

Nederland Germany France USA United Kingdom USA Czech Republic Nederland Denmark USA United Kingdom USA Nederland USA Australia United Kingdom Nederland USA USA Nederland Nederland Nederland Nederland France USA USA Nederland Nederland Nederland Nederland Nederland Nederland Spain USA USA USA Canada Nederland Nederland USA Canada Nederland USA Nederland United Kingdom Nederland USA USA "~ Germany

:

edrijfsnaam Land «Plaats: Jerry E. Fondaw & Associates Phoenix iUSA jVISGEN Mountain View I USA i Kender Thijssen Solutions Veenendaal Nederland Miami Lakes i Kimley-Horn and Associates Inc. USA Delft j Kingfisher ICT Services Nederland Huntington KLD Associates TÜSA Ko Hartog Verkeerstechniek bv Heiloo Nederland KPN Business Radio Solutions Capelle ad IJssel (Nederland KPN Research Leidschendam Nederland Landis ICT Group NV I Utrecht iJSIederland ; Laser Technology Inc. Englewood FÜSA" LightGuard Systems Inc. Santa Rosa USA Logica BV Amsterdam Nederland Logica BV Rotterdam Nederland Loox Software S.A. Malakoff France Mark IV Industries Ltd. Mississauga ON Canada Miami MasTecInc. USA M^teusjTiteÊlectric Works Best • Nederland Ypqneam Illit Qsraël MAVIX Ltd. ~ "viste USA " ' McCain Traffic Supply Öbersdorf i Germany i micKS MSR GmbH Fareham United Kingdom Microsense Systems Ltd. Midian Electronics Tucson ^JSA^ "sTPauf Minnesota Department of USA Mizar Automazione SpA Torino i Italy Mobility^Te^hriologJes iVVayne^ ;USA MoeMer ^^9îcJSjV^_ _ ; Zaltbomrne[ Nederland MS^Sedco indianapolis USA M-TCM'GmbH Wien Austria M-UniComp GmbH Berlin _Gejrmany_ MVAJ^ Woking United Kingdom Rolling Meadows ÜSA MYR Group Inc. National Engineering La Mirada USA Njaztejcjric.^ ûgarjând USA Nettenbouw B.V. Amersfoort jêderlanrj Neuricam S.p.A. TrentoTN Italy Nijkerk Transport Systems B.V. Amsterdam ; Nederland Nortech International Pietermaritzburg i South Africa North American Capacitor Indianapolis [USA"3 Northwest Signal Supply Inc. J^ke Oswego _ USA' Novax Industries Corporation Nw Westminster Canada NJNT Den Haag BV Den Haag Nederland Rotteirdam Nederland Nu-Metrics Inc. Uniontown USA OMJC Signal Inc. Waterloo USA OmniVision Technologies Inc. Sunnyvale •JJSAT ~_ OMRON Automotive Group Novi jJSA 7 Chesapeake Open Roads Consulting Inc Ópen Systems Management Ltd Ascot United Kingdom


A-4

>;'^«Plaats'pvw --•.SrJ-and.:::..H • USA Nederland Nederland USA Germany Nederland USA Pd Programming Inc. Nederland Peek Traffic BV Nederland Peek Traffic BV USA Peek Traffic Systems Inc. England PEI-Genesis UK Ltd. USA Percepties Nederland PinkRoccade Public BV Precision Soïar Controls Inc. ÜSA Nederland Den Haag PriceWaterhouseCoopers NV USA Graham Progressive Traffic Products Nederland Den Haag Proven Partners BV USA Sunnyvale Pulnix America Inc. Nederland Maassluis Q&l Nederland BV USA Chicago Quixote Corp. ÜSA Ruskin Qwick Kurb Inc. USA Charlotte RAI Products Inc. Nederland Redwood Nederland Software & Houten USA Reno Reno A&E USA Boonton RFL Electronics Inc. Nederland Rotterdam Riser Business Systems BV Nederland Uithoorn Rockwell Automation B.V. Seagate Ml Italy S.C.A.E. S.p.A. Colorado Springs ÜSA .: Safetran Traffic Systems Inc. Spain Sainco Trafico S A Madrid USA Carlsbad SBS Technologies Inc France \ Montrouge Cd SchlumbergerSema Nederland Haarlem Schneider Electric USA Arlington Scientex Corporation United Kingdom Securicor Information Systems Chippenham Norway Oslo Semitronic AS Spain Madrid Sensing SL USA Sensor Technologies & Systems Scottsdale Nederland Serco Facilities Management BV Katwijk Frankrijk Tours SES Spain Madrid SICE Nederland Den Haag Siemens Business Services Nederland Den Haag Siemens Nederland NV Canada Sidney BC Sigma Technologies Inc. "ÜSA West Chester Signal Service Inc. ÜSA Signing America Corp. West Palm Nederland Rotterdam Simtech Automatisering BV USA San José SiRF Technology Inc Colorado Springs USA Skyline Products Inc.

Orbital TMS Ordina Public BV Ordina Technical Business Par Technology Corporation _PAT _ _GmbH _ _ _ _ _


A-5

Columbia Utrecht Utrecht Yorkville NY Ettlingen Naaldwijk Lafayette Amersfoort Amersfoort Tallahassee Woodley Knoxville _Voorburg ______

Bedrijfsnaam SmarTek Systems 1 Sofrel Solar Technology Inc Solari di Udine Spa Stollenburgh techniek BV : Stork Infratechniek Storm Control Systems Strukton Systems BV Sumitomo Electric USA Sun Microsystems Nederland Sunnyvale General Devices And Swarco Holding AG Synchronex Synchronex Syntegra Groep BV Tadiran Telematics Ltd TEC Traffic Systems BV : Techjiolution Tegaron telematics GmbH Telcontar Tele Atlas North America Televoke Thales Communications Thales Information Systems Thales Nederland Thales Translink The Quidditas Group TimeMark Inc. TNO Traffic and Transport TOMAR Electronics Inc. Topmode Systems TPA Traffic & Parking Traffic and Parking Control Co. Traffic Safety Corp. Traffic Solutions Traffic Technology Inc. TrafficCast/transmart Trafficmaster PIc Traficon NV Transcore Transdyn Controls Inc. Transport Simulation Systems Transver GmbH Trantex Inc. Trinité Automatisering

Plaats* Woodbridge Vem sur Seiche Allentown Udine iNeede iSon IHerndon Gouda Santa Clara Amersfoort Verdi Wattens San José San José Zoetermeer Holon Nieuwegein Gouda Bonn San José Menlo Park San Francisco Naarden Malakoff Cedex Hengelo Reading Louth Salem 'Delft GÏIbert Birmingham Arnhem : Elm Grove Sacramento | Blacktown ; Scottsdale Madison Cranfield Bissegem Dallas Duluth Barcelona Munich Houston Mijdrecht triÖpSys b.v. : Maarssen Vianen Triple P Nederland BV Truvelo Manufacturers (Pty) Ltd Lyttelton Rydalmere Tyco Integrated Systems


A-6

Land USA : France USA : Italië Nederland Nederland :USA Nederland USA Nederland USA j Oostenrijk

IÜSA USA Nederland Israël s Nederland JNIederlancl Germany USA" USA' ÜSA • Nederland France Nederland United Kingdom United Kingdom USA Nederland ÜSA United Kingdom Nederland USA USA Australia USA : ÜSA England België USA USA Spain Duitsland USA Nederland Nederland Nederland South-Africa Australia

/•' •:,5;*"s*:.:.«sBëdrljfenaaiti;;fï?;ii-1^;••: ^•••^laatsm/m Santa Fe Springs U.S. Traffic Corporation / IDC Nieuwegein UCC Groep Espoo Unigraf OY Burnaby BC Unity Wireless Zwammerdam van den Berg Haarlem Vialis Verkeer & Mobiliteit bv Zeist Vialis Volker Wessels Stevin Anaheim Vilink Communications Gateshead Tyne VMS Variable Message Signs Capelle ad Ijssel Walvis Software BV Trier Weiss-Electronic GmbH Diemen Yacht ICT BV Houten Yokogawa Nederland BV Modling Zeiisko GmbH


A-7

: ;;:

. XÎ_UKl^::USA Nederland Finland Canada Nederland Nederland Nederland USA United Kingdom Nederland Germany Nederland [ Nederland Oostenrijk

Bijlage B

Longlist van Producten

Positieve reacties, inclusief product Asea Brown Boveri (Etten-Leur) Leverancier van: energy distribution control, industrial and process control, logistics operational control systems, telecommunication network management • Sattline; distributed control system • AC800C, compact controller • AC800M, modular controller • AC250, modular controller • Operate IT, human systems interface Status: Op Shortlist, SCADA/PLC

Applied Traffic (Reading UK) Leverancier van: Weigh in motion, overweight vehicle detection, bridge monitoring, real time traffic mapping: • HI-TRAC 100, HI-TRAC 88; weigh in motion and loop vehicle classifiers Status: Afgevallen tijdens longlist beoordeling, niet modulair systeem.

Atos Origin (Nieuwegein) Leverancier van: Products and systems for road & Rail traffic, military command & control systems, spacecraft mission control systems, telecommunications, embedded software: • Advanced Crew Terminal: package to support operators in procedures and decisions Status: Afgevallen tijdens longlist beoordeling, geen ACT functionaliteit (wel interessant voor AC en BOSS), ook niet commercieel leverbaar

AVE (Aachen, D) Leverancier van: Transport management systemen • MAVE-Sys, software integration platform for distributed control centers in transport telematics Status: Op Shortlist., Totaaloplossing

Barco (Kuurne, B) Leverancier van: Visualisatie hardware & bijbehorende software • Apollo Wall Management Software, a solution for using, organising, and managing Display Walls and many other shared resources in a control room


B-1

Status: Op shortlist. Gezien de beperkte functionele omvang zal het product niet verder worden onderzocht. Bentley (Hoofddorp) Leverancier van: Software and services to help users to be more efficiënt and effective whilst the plan, design, construct, operate and manage the infrastructure of Road, Rail and Air Transportation • MicroStation, engineering creation; • ProjectWise, content management; • InterPlot, content publishing • GeoTransport ATMS, the Advanced Traffic Management System, providing the capacity to dynamically update an electronic base map, network schematic, or layout plan as changes occur in the monitored environment. Information captured by field monitoring devices can be received by ATMS from a wide variety of sources, such as closed circuit television, video surveillance camera's, inductive loop detectors, traffic signals or global positioning systems. Status: Op shortlist, Totaaloplossing

BraxtonTechnologies (Pleasanton, Ca, USA) Leverancier van: spacecraft mission control systems • ControlPoint Workstation, command and controil • Telemetry Workstation, telemetry viewing and analysis • Visual Scheduler, mission planning • Workload scheduler, ground system resource and personnel scheduling • Real-time Simulator, space vehicle and ground system simulation for test and training • WebTLM, web based telemetry viewer Status: Afgevallen tijdens longlist beoordeling , geen ACT functionaliteit (mogelijk bruikbaar voor VM)

Brimos (Hattem) Leverancier van: Wegbebakening: • Brimos Traffic Information System BTIS; configuration, maintenance and operational control for mobile or stationary Variable Message Signs ans Actuators made by Brimos Status: Op Shortlist, VMS architectuur

CAP Gemini Ernst & Young (Rotterdam) Leverancier van: • Cimplicity (Energy distribution control, industrial and process control); Manager Automation Management System, for managing applications and devices in plants and factories (Trimation, Chaam) • Factory Link (Energy distribution control, industrial and process control); real time SCADA application server (USData, Rosmalen) • Freelance 2000, scalable distributed control system (Cap Gemini, Ernst & Young, Hannover)


B-2

•

Maestro UX (industrial and process control);???? (Cap Gemini, Ernst & Young, Hannover) • OperatelT (Energy distribution control, industrial and process control); (Cap Gemini, Ernst & Young, Hannover) NB: ABB heeft product met dezelfde naam. Status: Afgevallen tijdens longlist beoordeling. Leveren zelf geen producten. De Scada/DCS/PLC producten welke zijn opgevoerd, worden daadwerkelijk geleverd door derden.

CCT, Command & Control Technologies (Titusville, Fl) Leverancier van: general purpose control system middleware, spaceport/launch control systems, launch range safety systems • Command and control toolkit, a data acquisition, command and control middleware package that provides common control system functions for mission control applications. • T-Zero, a task sequencer that helps a team of operators design an operations concept, plan various missions, and execute the missions with intuitive computer communication techniques Status: CC Toolkit op shortlist, totaaloplossing

CMG (Rotterdam) Leverancier van: Road traffic management: • Mobile Traffic services, providing Estimated Travel Times by enhancing the location information out of the telecom operators network • Gemeentelijke verkeersmanagement centrale, consisting of an integration platform and presentation and application components, aimed at city level of traffic management systems Status: • Gemeentelijke V M centrale: Afgevallen tijdens longlist beoordeling, geen product • Mobile Traffic services: Afgevallen tijdens longlist beoordeling, geen ACT functionaliteit

Combitech Traffic Systems (Jönköping Zweden) Leverancier van: Products and systems for road tolling • Premid TS32OO DSRC System, CEN compatible DSRC link (between roadside and car) for use in ETC systems • Tollmatic Single lane ETC, Turn-key ETC lane • Tollmatic Multi lane free flow system, Turn-key system for multi lane free flow ETC application • Status: Afgevallen tijdens longlist beoordeling, geen ACT functionaliteit, alleen voor electronische tolheffing

DHV BV/Delcan (Amersfoort/Toronto

Canada)

Leverancier van: Road Traffic Management: • Traffic Control and Surveillance System (TCSS), a complete ATMS (Advanced Traffic Management System) solution for traffic management


B-3

of highways, tunnels and bridges. The package provides automatic incident detection and management functions, supports a wide set of traffic management strategies and is able to interface with traffic field equipment of different technologies from manufacturers around the world. • Traffic Signal Management System, an integrated system that provides intersection control, real-time monitoring and traffic flow optimisation • Air Quality Management System, a package providing all features required for city air quality auditing, tunnel operations or for other special air quality monitoring programs. Air quality (iu.e. levels of CO, NO, etc.) and visibility are monitored in real time; • Traffic and Road Information System, a region wide traffic information system which allows scheduled and unscheduled events to be registered, logged, and disseminated to subscribers via e-mail, fax, as well as to the public through the internet. • Traffic Data Management System (TDMS), a complete software solution for the collection , storage, query and reporting of traffic data. The TDMS incorporates traffic data from a variety of sources with an intuitive user interface to produce reports, graphs and tables on screen and on paper. Status: TCSS en TSMS op shortlist Overige producten afgevallen tijdens longlist beoordeling, geen ACT functionaliteit

Drielingh BV (Nieuwegein) Leverancier van: Administrative business process integration • Cicero, desktop integration portal for integration of dynamic application information • Level8 Geneva Enterprise Integrator & Business Process Automator Status: Afgevallen tijdens longlist beoordeling, Wel CBD, geen ACT functionaliteit; alleen toepassing in administratieve business process integration

Electron Automation (Breda) Vertegenwoordigd: SAT Leverancier van: SCADA, Telecontrol (SAT), Telecommunications (integrator): • SAT 1703/ SAT 200: Telecontrol and automation system for power distribution networks Status: SAT 200 en SAT 1703 op Shortlist, SCADA/PLC architectuur

Enginuity Europe (Malakoff, F) Leverancier van: All products that needs to include a GUI: • JLOOX GIS: Visualisation Suite, enabling efficiënt visualisation, management and optimalisation of complex systems and processes Status: Op Shortlist, PL Toolkit,

Harris (Castle Rock, Co) Leverancier van: spacecraft mission control systems, military command & control, telecommunications network management:


B-4

•

OS/COMET: Data Acquisition, Data distribution, Distributed Control for spacecraft and telecommunications applications Status: Op Shortlist, Totaaloplossing

Helios Recording & Broadcast (Haarlem) Veretegenwoordigd: Harris Leverancier van: Harris Intraplex multiplexers, management systems • Harris Intraplex Transmission Solutions, one-way or bi-directional transmission of high quality audio Status: Afgevallen tijdens longlist beoordeling, geen ACT functionaliteit

IBI Group (London, UK) Leverancier van: Road Traffic Management, Airport Control systems, Logistics Operational Control System, Telecommunications Network Management: • Advanced Device Control Software, a suite of ITS device control and monitoring specific modules, to be positioned as middle tier control point, providing a distribution of overall system processing and the capability of localized operation • Advanced Traffic Management Software, that implements a set of ITS functions for traffic management and control that apply primarily to limited access motorways but also with applications on arterial roads Status: ADCS en ATMS: Op Shortlist, Totaaloplossing

ICT Solutions (Barendrecht) Leverancier van: Road Traffic Management, Logistics Operational Control System, Teiecommunications Network Management:, Industrial and Process Control • ISF; ICT Server Framework, a Java platform-centric framework that provides an out-of-the-box solution for component-based web-application development. The framework is targeted at both lightweight webcontainers such as Apache Tomcat or Jrun and highly scalable J2EE compliant application servers such as Weblogic, WebSphere, iPlanet, or Oracle AS. Status: Afgevallen tijdens longlist beoordeling, geen ACT functionaliteit

Interface & Control Systems, Inc (Melbourne, FL, USA) Leverancier van: SCL command and control systems • SCL/eSCL: a rule based expert system and scripting executive used in command and control environments Status: Op Shortlist, BL Toolbox, Open Source software voor RS & MR

/LOG (Gentilly, F) Leverancier van: product suites for visualisation, business rules and optimalisation


B-5

•

ILOG Views, powerful set of C++ graphics libraries for high performance applications • ILOG Jviews, a set of 100% Java components for building visually ritch, highly interactive Web based user interfaces • ILOG JRules, providing extensive API's and packaging them as comprehensive class libraries, based on J2EEplatform • ILOG Rules, C++ class libraries • ILOG Server, a C++ library designed to speed creation of visualisation servers by aiding devcelopment of distribution and synchronisation software Status: Op Shortlist, PBLToolkit

Imtech Marine (Rotterdam)/ Turnkiek (Delft) Vertegenwoordigd: Imtech Infra-engineering dan wel Imtech Industrie; Verkeer valt nadrukkelijk buiten core business van Imtech Marine. Leverancier van: Floating vessel control • UniMACS: UniversaI Monitoring and Control System (an Integrated bridge system and an Integrated Monitoring and control system) Status: Shortlist, PLC/SCADA architectuur.

Logica BV (Amsterdam) Leverancier van: System Integration, Enterprise Application Integration, Traffic Management, Command Control, Network Service Management • TIBCO: an enterprise application integration tooi • Kariba Solution Products, Frameworks & Servers: providing Solution Software and Frameworks for Provisioning, Activation, Meditation and Control delivery in complex, high-speed network services and applications • Remedy: a multi-user database application for workflow processes. It can be used within the AVB architecture as a "Trouble Ticketing System". • ILOG Views:: a powerful set of graphical libraries for high performance applications. Status: Afgevallen tijdens longlist beoordeling, TIBCO, Kabira & Remedy geen ACT functionaliteit (vallen onder TIAV), ILOG heeft zelf een questionnaire ingestuurd

The MathWorks BV (Gouda) Leverancier van: Matlab • Matlab Simulink Real-Time Workshop, data acquisition, analysing, visualisation, optimisation, statistics, design of controllers, simulating dynamic behaviour, estimation, version control, re-use of intellectual property, automatic real-time c-code generation for several target environments like pc-compatible systems, VX works, embedded systems. Status: Afgevallen tijdens longlist beoordeling, geen ACT functionaliteit ,wel CBD maar meer in scope van TIAV en/of BOSS

Microsense/Traffic Signals UK (Hants, UK) Leverancier van: Traffic signal control, detection and monitoring


B-6

•

TCAM, control and monitoring of Traffic Signal Controllers over leased and dial-up communication lines using TCP/IP, UDP and SNMP Status: Afgevallen tijdens longlist beoordeling, geen ACT functionaliteit ,valt onder TIAV

Mi-Services (Almere) Leverancier van: SAP Implementation partner in petrochemie, pharma, discrete industries • TransActive, an innovative, open systems solution that integrates disparate ITS technologies, provides a unified operations interface, and includes incident management systems designed to restore transport network capacity in the shortest possible timeframe Status: Op Shortlist tijdens beoordeling, totaaloplossing

Nijkerk Transport Systems (Amsterdam) Leverancier van: • RTAP and DYNAC ATMS (Advanced Traffic Management System): SCADA systems which support the implementation of the Ministries A V M system based on Commercial Off the Shellf Software Status: RTAP: Op shortlist, SCADA, echter als product van Ferranti ATMS: Shortlist, NTCIP, reeds opgevoerd bij Transdyn

Open Roads Consulting Leverancier van: Road Traffic Management: • OpenTMS™ Enterprise Components • OpenTMS™ Standard Components. This package can include: • OpenDMS (Dynamic Message Signs), • OpenCCTV™, OpenESS™ (Environmental Sensor Stations), • OpenWZM™ (Work Zone Management), • OpenIDM™ (Incident Detection and Management, • OpenTSS™ (Traffic Sensor Stations), and • OpenHAR (Highway Advisory Radio). • OpenTCS™ (Traffic Control Systems) which provides a wrapper for existing or new urban traffic control systems. Status: Op Shortlist, Totaaloplossing

OSI Software GmbH (Altenstadt, D) Leverancier van: • PI System Real Time Information Infrastructure Status: Op Shortlist, SCADA

Pd Programming Inc, (Lafayette, F) Leverancier van: Traffic safety, crash analysis


B-7

•

Intersection magie/map magie, crash data analysis. Collision diagrams, high crash locations lists, pin maps, crash lists, presentation graphics Status: Afgevallen tijdens longlist beoordeling, geen ACT functionaliteit, wellicht wel voor BOSS

Peek Traffic

(Amersfoort)

Leverancier van: Public Transport, Urban & Inter Urban Traffic, Parking, Enforcement, Counter & Classifiers, Detection, VMS, Information Provision, Services (maintenance) • Traffic Box Sensor Service, obtain Traffic related information and deliver this as raw and/or enhanced data.' • Integrated Traffic Management System, A control modular control system that is able to perform several Dynamic Traffic Management (DTM) functions • Traffic Box Actuator Management System; To control, manage and configure one or more actuators. It will impose a measure ordered by another function and monitor weather it is executed correctly Status: Op Shortlist, Specifiek systeem (drivers)

Redwood Nederland Software & Services (Houten) Leverancier van: Process Management • Cronacle: Process Management Tool Status: Afgevallen tijdens longlist beoordeling, Wel CORBA, J2EE, SNMP, maar geen ACT functionaliteit, alleen process management tools

SES, Security & Signalisation (Tours, F) Leverancier van: Road Traffic management, VMS • Variable Message Sign: real time display, VMS, central unit en modem verbinding Status: Op Shortlist, VMS

Siemens (Den Haag) Leverancier van: Road Traffic management • LD4, loop detector; • Passive Infrared Detector; for Measurement of traffic data like vehicle count, speed occupancy by means of passive infrared technology (producent AS1M) • Traffioc Eye UniversaI, for Measurement of traffic data like vehicle count, speed occupancy by means of passive infrared technology • Video Image Processing, for acquisition of traffic data by video image processing (producent: Traficon) Status: Afgevallen tijdens longlist, geen ACT functionaliteit

Solari (Udine, I)


B-8

Leverancier van: VMS • Variable Message Sign • VMS Software; application software to control variable message signs Status: Shortlist, VMS

Tec Traffic (Nieuwegein) Vertegenwoordigd: Golden River Leverancier van: Traffic Sensors, Monitoring & Traffic data logging, Integrated systems (hard and software) for Traffic Management: • ISS (Image Sensing Systems) Solo Pro video detection unit • 3 M Non Invasive Microloop • Golden River M660 traffic data logging and monitoring • TOM2000, Above ground detector with traffic data logging and monitoring capability based on laser. Status: Afgevallen tijdens longlist beoordeling, Schoorsteen pijp, geen componenten, geen duidelijke modulaire structuur

Technolution (Gouda) Leverancier van: Road traffic management, industrial and process control, telecommunications and network management: • UWKS: Universeel Wegkant Systeem, AVB compliant (AVB-Demo prototype) Status: Afgevallen tijdens longlist beoordeling, UWKS uit AVB demo zelf, geen nieuw en eigen product

Thales Communications (Huizen) Leverancier van: multimedia Communications networks for vehicles and small platforms, switch network for railway stations, airports, highways, etc. • SmartSwitch, an ATM switch with integrated access interfaces providing connectivity for all kind of audio, video and data systems. NB: de M D is ook met dit product bezig. Status: Afgevallen tijdens longlist beoordeling, geen ACT functionaliteit, ATM Switch voor TIAV; wordt door MD reeds bekeken

TPA Traffic and Parking Automation

(Nijmegen)

Vertegenwoordigd: EIS (Canada), Citilog (Frankrijk), Weiss (Duitsland) Leverancier van: Road traffic management: • l-trac based on X-trac platform; • l-trac is a software component that is designed to gather and integrate information from a sensor network, based on multiple types of detection technologies. • XTC-platform is a software architecture which is the bases for all our products. It encompasses components that are dedicated to authorisation, alarm handling, logging, and inter process communication. It is based on a


B-9

cliënt/server architecture and uses TCP/IP and a proprietary application protocol. Status: Afgevallen tijdens longlist beoordeling, Wel CBD, geen Corba geen ACT functionaliteit, wel gecentraliseerd parkeer systeem

Transdyn Controls (Duluth GA, USA) Leverancier van: Dynac Software Suite • DYNAC-ATMS Status: Op Shortlist, SCADA/PLC

Transver GmbH (Munchen, D) Leverancier van: ITS appliocations for traffic modelling, traffic control, traffic management • SAM, Strategy management Development/Application/Gestion of strategies for different ITS systems • Transaid, Evaluation and optimalisation of automatic incident detection systems, Surveillance of VMS control Status: Afgevallen tijdens longlist beoordeling, geen ACT functionaliteit

Trinité Automatisering (Mijdrecht) Leverancier van: Dynamic Subscription Software, een virtuele datapool in multivendor omgevingen, waarbij gebruikers zich kunnen abonneren op real-time data uitwisseling • IMC, Integral Management Concept, bestaande uit architecture bouwstenen waarvan zowel de eigenschappen als het gedrag dynamisch kunnen worden bepaald • ELTRIS, een event presentatie en logging systeem; • VTRIS, een presentatie tooi voor het creëren van SCADA achtige overzichten Status: Op Shortlist SCADA

Unigraph Oy (Espoo, SF) Leverancier van: Control Walls for Controllrooms • Unigraph ControlWall, a wall-sized display screen for presenting computer and video data to the entire control room personnel. Status: Afgevallen tijdens longlist beoordeling, geen ACT functionaliteit.

Ureason (Leiden) Leverancier van: Udiagnose & Ureason Platform • Udiagnose: open ended reasoning solution with powerful fault management, fault correlation and fault diagnosis facilities. • Ureason Platform: COTS set of components/libraries for creating real-time, scalable, and robust reasoning solutions (the platform in which Udiagnose is created) Status: Afgevallen tijdens longlist beoordeling, geen ACT functionaliteit


B-10

Vialis Trafic & Mobility (Zeist) Leverancier van: Autoscope communication application. This application handles the Communications with an AutoScope server for receiving traffic information • CDMS roadside application: This application handles the communication with MoniCa for receiving traffic data. • Cross Man model server: OPC-server for managing traffic controllers via an OPC-interface (NB: OPC = OLE for Process Control) • Ice Warning System: communication module to communicate with the detectors in the field • INCA Communication server: a set of communication protocols to transparently communicate with several different kinds of equipment in the field. • INCA file transfer: System for transferring files between central system and equipment in the field (Traffic light controller) • ASIM sensor driver: this application controls the ASIM DT 270 sensor • Measure MDU: this driver controls the communication with the Vialis MDU loop detector • VMS Control: this application controls communication with VMS's • RegioTic communication application: this application communicates with a Traffic Information centre using Datex to transfer information about the actual text on VMS's • Inca Time Controller: application for the time synchronisation of central and local equipment • PRIS sign control: application for communicating with and controlling of signs used for parking guidance • MSI controller: this application communicated with a lane-signal • WebGUl: User Interface built for a compact dynamic bus station, based on browser technology • Via Man GUI: a user interface template for the construction of user interfaces in combination with a terminal server. • CrossMan GUI: user interface for the presentation and managing of the state and parameters of cross section controllers. Based on OPC interface • Intersection phase viewer: application for presentation of the behaviour of intersection traffic control. Shows a flow diagram of the state in time of traffic control lights • NAVDI direct, playback manager & intercom manager: three window applications used for resp. presentation of video, storage and playback of video and handling of intercom messages • PRIS GUI: User interface used for controlling large parking guidance systems • SvST GUI: user interface for the control of access with road blockers • TravelMan GUI: user interface for the control of compact dynamic bus stations • Viaman User Application: application used for the configuration of users and their rights. • INCA Access control: application for the management of user access rights • INCA Command services: managing of commands based on time triggers. • BISTRO Traffic Jam Application: Application containing a traffic length estimator for urban environment • BISTRO Travel Time Application: Application containing a travel time estimator for urban environment


B-11

•

CDMS Route Application: An application for determining traffic jam lengths and positions and travel time in routes • CDMS Text application: application that determines the necessary texts on VMS's • Urban bottleneck manager: Application used to link several cross section controllers to avoid burdening of bottlenecks in urban area by changing max green time at intersections • PRIS core: Application for the control of P+R and parking guidance system • SvST Core: Application for access control with road blockers • Travel Time Core: Application for the measurement of travel times using camera's and licence plate recognition • Fog warning application: Application that determines the need for fog warning Status: Afgevallen tijdens longlist beoordeling en aansluitend bedrijfsbezoek: alle producten, ofwel omdat het product geen ACT functionaliteit realiseert, ofwel omdat het geen daadwerkelijk COTS product betreft

VMS Limited (Gateshead UK) Leverancier van: VMS, TMS: • TRAMS (Traffic Management System): SNMP enabled Variable Message Sign / Carpark, VMS and other roadside equipment control system • Variable Message Sign: UTMC compliant VMS Status: Shortlist, VMS

Weiss- Electron ie (Trier, D) Leverancier van: Road traffic management • UZ2000, road control, network control, node control, inflow control, automatic parking lane/shoulder release, based upon the TLS standard Status: Op shortlist, specifiek TLS Positieve Reacties, echter zonder vermelding van een product

EDS, Capelle ad Ijssel Electronique Controle Mesure (Vandoeuvre les Nancy) Getronics Imtech Inc. USA Serco Integrated Transport, mogelijk via Serco Facilities management NL

Negatieve reacties 3 M , 3 M is not marketing COTS products at this time ASIM, we are detector manufacturer CAE, core business is scheepvaart, willen zich niet in road traffic begeven Capsys, leveren sensoren/hardware Entran, no software products, only sensors ESA, mission is not in scope of reference International Fiber Systems, leveren alleen fiber optie transmission systems McTrans Center, Universiteit van Florida, leveren alleen verkeerskundige ontwerpsoftware MVA Group, zijn consultants, leveren geen producten


B-12

MX Systems, hebben we niet PIE-Genisis, we leveren alleen connectoren Securicor, concentreren zich op UK police market Solar GB, leveren solar powered LED lighting systems Stollenburgh techniek BV; bedrijfsbeëindiging Topmode Systems Traffic Sensor Corporation, only equipment for use within traffic controller assy Truvelo, software is onderdeel van hun totale systemen Verdonck, Klooster & Associates Verkehrs Systeme AG, mainly control aspects of street traffic Yacht ICT, leveren geen producten, zie website Yokogawa, leveren alleen DCS systemen aan procesindustrie


B-13

Bijlage C

Shortlist productbeschrijvingen

ABB - Industrial IT AVE - MAVE®-Sys Bentley - GeoTransport Advanced Transportation Management System (ATMS) Brimos - Brimos Traffic Information System (BTIS) versie 1.0 CCT - Command & Control Toolkit (CCTK) Delcan - Traffic Control and Surveillance System (TCSS) Electron - SAT 200 + SAT 1703 Engenuity - JLOOX 2.0 & JLOOXGis 2.0 Ferranti - Real-Time Application Platform (RTAP) Harris - OS/Comet IBI Group - Advanced Traffic Management Software (ATMS) & Advanced Device Control Software (ADCS) ICS - SCL/eSCL & RIMS ILOG-Rules & JRules ILOG - Views & JViews Imtech - UniMACS 3000 Mi Services Group - TransActive Open Roads Consulting - OpenTMS Enterprise Components OSI Software - PI system Real Time Information Infrastructure Peek Traffic - Traffic Box Schneider-Electric - Modicon SES - Mercure Solari di Udine Transdyn Controls - Dynac-ATMS Trimation - Cimplicity Trinité Automatisering - Programmable Distributed Architecture (PDA) Variable Message Signs - TRAffic Management System (TRAMS)


C-1

C-2 C-3 C-4 C-6 C-8 C-10 C-12 C-13 C-14 C-16 C-17 C-20 C-22 C-23 C-25 C-26 C-28 C-29 C-31 C-32 C-33 C-34 C-35 C-36 C-37 C-39

ABB - Industrial IT Categorie Functionaliteit

Modullen

Technische beschrijving Toepassing Leverancier

Status Bronnen

Bijzonderheden

SCADA/PLC (DCS) Industrial IT is een verzameling van meer dan 9800 componenten, inclusief de sensoren en actuatoren, waarmee de automatisering van een fabriek of een (petro)chemische plant gerealiseerd kan worden. Het hart van het systeem; de controllers met de verschillende servers kan beschouwd worden als een DCS systeem AC800 M: rail mounted controller AC 800 C: rail mounted compact controller Connectivity Server: voor het doorgeven van procesgegevens uit de controllers naar gebruikers Aspect Server: bevat de vaste gegevens een de opbouw van schematische presentaties Application Server: bevat applicatie functies Engineering Work place: ten behoeve van configuratie van controllers en field equipment, zoals sensoren en actuatoren Enterprise Optimalization Suite: ten behoeve van MES/ERP ondersteuning Workplaces: bevatten de presentatie clients Operate IT: SCADA software Controllers en Windows platformen Fabrieks- en procesautomatisering ABB, Mon Piasier 40, 4879 AN Etten Leur Frans Lambrechts, sales manager Theo van der Hoek, account manager Rijkswaterstaat COTS • ABB Industrial Solutions • Bezoek ABB Rotterdam, 10 juni 2002 Bezoek Petrotech Heeft ook het Sattline systeem, dat door de Bouwdienst gebruikt wordt voor de bewaking van objecten (bruggen, tunnels etc). ABB adviseerde om hier echter geen gebruik van te gaan maken, omdat Industrial IT een langere levensduur zou hebben.


C-2

AVE - MAVE®-Sys Categorie Functionaliteit

Modullen

totaaloplossing MAVE®-Sys is een op CORBA gebaseerd gedistribueerd verkeersmanagement systeem in een verkeerscentrale en onderstations, dat is gekoppeld aan wegkantsystemen (Unterzentralen und Streckenstationen) via de Duitse standaarden MARZ en TLS. Het beoogd vergaande integratie van verkeerskundige applicaties en maatregelen in de verkeerscentrales en wegkantsystemen.

Database distributor, Persistence manager: Centrale modulen voor data management in het gedistribueerde DVM systeem. Configuration and parameter manager: module voor configuratie beheer van alle DVM systemen. Externe Koppelingen naar wegkantsystemen: koppeligen met MARZ en TLS Report manager: External Communications: System administration tools: LVE: Lokale Verkehrsdatenerfassung: module voor data inwinning en sensor management Traffic control strategies: module voor regelscenario's

Visualisation : Presentatie laag module

Technische beschrijving

Toepassing Leverancier

Status

Bronnen Bijzonderheden

SBA: Streckenbeeinflussingsanlagen: module voor actuator management en maatregelen. VRZ: Verkehrsrechnerzentrale: communicatie naar externe gebruikers van verkeersinformatie Op CORBA gebaseerd DVM systeem met TAO object request broker; UML; C++; Communicatie vanuit centrale via MARZ en TLS communicatie standaarden. Verkeersbeheersing van hoofdwegennet in Beieren Ave Verkehrs- und Informationstechniek GmbH, Heider-Hof-Weg 23b, 52080, Aken, Duitsland, (fax) +49-2405482720, www.ave-web.de Dr.-lng. R. Ziegler, Senior Engineer, +49-240548270, [email protected] D. Lokhorst, Account Manager, +49-2405482746, [email protected] Prototype gedeeltelijk in ontwikkeling (zie status bij modulen). Het product is een prototype in ontwikkeling en de beoogde afronding is medio 2003. Hier wordt de functionaliteit van het huidige geplande prototype van medio 2003 beschouwd. Status medio 2002: • Database distributor, persistence manager, configuration manager, en externe koppelingen via MARZ en TLS naar wegkantsystemen zijn operationeel. • Report manager, external Communications, system administration tools, LVE in prototype stadium. • Regelscenario's, visualisatie, SBA, VRZ zijn nog in ontwikkeling. Verder geplande of te implementeren functionaliteit zijn niet beschouwd in de evaluatie. Powerpoint presentatie van Intertraffic 2002. Ontwikkelingsproject met veel overeenkomsten met AVB, en gaat verder dan Vanessa. Trekt CORBA door naar onderstations waarschijnlijk via MARZ.


C-3

Bentley - GeoTransport Advanced Transportation Management System (ATMS) Categorie Functionaliteit

Modulen


DVM totaaloplossing GeoTransport ATMS integreert het bewaken en beïnvloeden van het verkeer met het presenteren van geografisch informatie in real-time. GeoTransport ATMS is gebouwd op Bentley's GeoGraphics en MicroStation technologieën. Kern modules: Message Server: Dit is een real-time messaging hub waarop het ATMS product is ontwikkeld, en fungeert als router voor alle real-time inter-process communicatie. Andere modulen koppelen hieraan, en ontvangen real-time nieuw informatie en verzenden commando's via de Message Server. ATMS Operator Client: Gebruikersinterface die real-time informatie presenteert op een vector map (kaart). Interactie is gebaseerd op De module bestaat uit een verzameling kern functionaliteiten en plug-ins. Kern functionaliteiten zijn scrollen en zoomen over de kaart, schaal-afhankelijke presentatie van informatie, "point-and-click" selectie, menu structuren en selectie van apparatuur op de kaart, presentatie van iconen en symbolen, connectie met Message Server en een Oracle RDBMS, en een raamwerk voor plug-ins. ATMS Maintainer: Grafische gebruikersinterface op de Oracle database voor het beheren en bekijken van informatie van de configuratie van het ATMS. Optionele modules: Plug-ins: Dynamic Link Libraries (DLLs) met additionele functionaliteit voor de Operator Client. Plug-ins bieden een specifieke en leverancier onafhankelijke gebruikersinterface voor apparatuur, zoals CCTVs. De plug-in gebruikersinterface wordt geïntegreerd met die van de Operator Client, zodat nieuwe apparatuur kan worden geïntegreerd in het ATMS. Plug-ins kunnen ook niet-apparatuur gebonden functionaliteit worden ingevoegd, bijvoorbeeld voor incident management of alarmering. Device Drivers: Voor nieuwe apparatuur zijn naast plug-ins ook drivers nodig. De ATMS Developers Kit biedt een bibliotheek met generieke interfaces voor efficiënte real-time messaging over de gehele ATMS en netwerk. Incident Management Server: Module ondersteunt de gehele levenscyclus van het beheren van incidenten, van voorspelling van incidenten, via detectie, verificatie tot en met afronding. De module presenteert incident informatie, en accepteert gebruikersinvoer via de Operator Client. Schedule Server: Module om commando's op voorhand te plannen en af te draaien, commando's kunnen eenmalig of frequent wordt afgedraaid. Archive Server: Module verzameld en verwerkt de real-time data van de Message Server, en schrijft deze naar een database of bestand. Data kan ook periodiek worden gearchiveerd. Platforms: Windows NT Interfaces: direct interfacing door middel van maatwerk drivers en TCP/IP. Protocollen: TCP/IP sockets. Shared memory en RPC ook mogelijk. CORBA: Mogelijk XML: nee SMS functionaliteit: nee AMS functionaliteit: nee Soort BL: Geen, maar extern expert systeem (Gensym's G2 is genoemd) kan gekoppeld worden via Message Server en TCP/IP. GIS in PL: Ja, eigen GIS functionaliteit (GeoGraphics). SUT-beheer: Ja, met taak- en werkplek overdracht. Additionele functionaliteit: Geen, maar simulatie en web-browser interfacing kan gekoppeld worden via Message Server en TCP/IP.


C-4

Toepassing

Leverancier

Status Bronnen

Bijzonderheden

Veel maatwerk nodig. GeoTransport ATMS biedt alleen data distributie, GIS presentatie en resource management functionaliteit. Geen standaard interfaces naar PLC's binnen product zelf. Toepassingsgebieden buiten DVM: • Bewaken van grond voertuigen in en rond vliegvelden; • Bewaken van power, utilities en telecommunicatie faciliteiten; • Fleet management systemen; • Incident management systemen voor noodoperaties; • Overstroming- en schademanagement systemen. Bentley Systems Europe B.V., Wegalaan 2, 2131 JC Hoofddorp. http://www.bentley.com Ir Arjen de Leeuw, Account Manager, Tel: +31 23 5560 604, Fax: +31 23 5560 605, [email protected] Ted Johnson, Director Transportation, 38 Fitzroy Street, Cambridge CB1 1EW, United Kingdom, Tel: +44 1223-507813, Fax: +44 1223-507811, [email protected] lain McLeman, Product manager, (Zelfde adres en fax nr. als Ted Johnson), Tel: +44 1223-507814, [email protected] COTS Product informatie op http://www.bentley.com/transportation onder Transportation Applications en GeoTransport ATMS. Technical profile, GeoTransport ATMS Technical Note, Customising GeoTransport ATMS Twee Case Studies Stabiel bedrijf. • Hoofdkwartier voor Europa, Middeloost en Afrika is gevestigd in Hoofddorp, Nederland. • Kantoren in Australië, Bahrein, België, Brasilia, Canada, China, Czech Republic, Denemarken, Dubai, Finland, Frankrijk, Duitsland, Hongarije, India, Italië, Japan, Korea, Maleisië, Mexico, Noorwegen, Polen, Portugal, Saudi Arabia, Singapore, Zuid Afrika, Spanje, Zwitserland, UK. Andere gerelateerde producten van leverancier (TIAV, BOSS): • GeoTransport Advanced Routing and Permitting System (ARPS). • MicroStation GeoGraphics. • MicroStation Descartes. Reference gebruikers: • Alameda County Congestion Management Authority (ACCMA), Oakland, California, USA • Texas Department of Transportation, Houston, Texas, USA • New Jersey Turnpike Authority, New Jersey, USA • Georgia Department of Transportation, Atlanta, Georgia, USA • Bangkok Traffic Loop Locked Alarm System The Royal Thai Police, Bangkok, Thailand

•

Metropolitan Atlanta Regional Transportation Authority, Atlanta, Georgia, USA

Geografisch dekking leverancier: » Europe/ South Africa/ Asia/ Australia/ North and South America


c-5

Brimos - Brimos Traffic Information System (BTIS) versie 1.0 Categorie Functionaliteit

Modullen


Actuator Management Systeem BTIS is een actuator management systeem, bestaande uit software modulen in de verkeerscentrale en een PC met scherm langs de weg. In de centrale staat een server met één of meerdere clients voor wegverkeersleiders en configuratie beheerders, waarop een geografisch beeld wordt gegenereerd van alle aangesloten systemen. Actuatoren kunnen manueel bediend worden of via vooraf gedefinieerde tijdsplannen (scenario's in BTIS terminologie) die (groepen van) actuatoren bedienen voor bijvoorbeeld wegwerkzaamheden. In BTIS worden mobiele actuator systemen volledig geïntegreerd met vaste actuatoren voor bediening. Logische groepen van actuatoren zijn te definiëren, bijvoorbeeld op secties van het wegennet. De status, storingen en werkelijk getoonde beelden kunnen vanaf de actuatoren worden opgevraagd en gepresenteerd. De beelden op actuatoren kunnen vanuit de centrale en lokaal geconfigureerd worden. Een elektronisch handtekeningen mechanisme beveiligd de bediening van niet geautoriseerde beelden vanuit de centrale (zie bijzonderheden). Verschillende typen Brimos actuatoren zijn aan te sluiten; mobiele schermen, MRI's en DRIPs. Zowel tekst als grafische beelden kunnen worden getoond. Alle bedieningshandelingen worden op de actuator opgeslagen. Actuator beelden worden zowel in de panelen als in de centrale opgeslagen. De actuatoren hebben functionaliteit voor diagnose en storingsmelding. Het systeem is modulair en open voor koppeling met andere systemen via een database (zie bijzonderheden). GridClient: Client met GUI voor verkeersleider en configuratie beheerder in verkeerscentrale voor bediening van de GridServer en ScenarioServer. Meerdere van deze clients kunnen in een centrale worden aangesloten via een LAN met TCP/IP op de servers. GridServer: Server applicatie in de verkeerscentrale voor koppeling met andere dient applicaties en ScenarioServer in de centrale. De GridServer wordt bedient vanuit GridClients. De GridServer fungeert als communicatie kanaal, met een eigen protocol naar SchermPCs. Bevat storingsbeheer van aangesloten actuatoren. ScenarioServer: server applicatie die Brimos scenario's draait; dit zijn in termen van AVB maatregelen met tijdsplanningen voor de bediening van aangesloten actuatoren. De Brimos scenario's worden opgeslagen in de BTIS database. BTIS database: centrale database in de verkeerscentrale voor data en communicatie tussen cliënt en server applicaties in de centrale (zie bijzonderheden). SchermPC: PC bij het actuatorscherm langs de weg dat communicatie met de GridServer verzorgt en het scherm bedient en beheert. SchermPC vertaald bedieningscommando's naar de activering van beelden, registreert berichten en scherm status, en storingsmeldingen. SchermPC beheert ook de beveiliging van gedefinieerde beelden op de actuatoren middels een elektronisch handtekening systeem. Nieuwe beelden en teksten op het scherm kunnen zowel lokaal als vanuit de centrale worden opgegeven, en worden lokaal opgeslagen in de panelen van het scherm. GridSystemen: Het actuator scherm zelf. Brimos levert verschillende versies: GridRunner (mobiel), GridMRI (mobiel), GridScreen (langs de weg), en GridDrip (DRIP boven de weg). Windows PC systemen in verkeerscentrale en langs wegkant, die communiceren via het Brimos specifieke BopNet protocol over een modem verbinding of via een TCP/IP netwerk. BTIS wordt standaard geleverd in de stand-alone versie met een Paradox database.


C-6

Toepassing

Leverancier

Status Bronnen

Bijzonderheden

Het systeem wordt toegepast op de ring van Rotterdam (ROS), in Vlaanderen en in Duitsland (MOVE). BTIS is ontwikkeld om zowel stand-alone, remote, op mobiele actuator platformen, in een netwerk in de centrale, als geïntegreerd in een DVM systeem toegepast te kunnen worden. Brimos b.V. Wegbebakening, 4e industrieweg 1, Postbus 40, 8050 AA, Hattem, tel 038-4442333, fax 038-4446428, www.brimos.nl; J.A. te Siepe, Director, [email protected] A.C. Keijser, Head of Engineering / R&D, [email protected] COTS Gebruikershandleiding Brimos BTIS versie 1.0, 2001 Bedrijfsbezoek 12-04-2002 Intertraffic 2002 BTIS is ontwikkelt op basis van een Brimos architectuur voor koppeling en communicatie van DVM producten. De architectuur is gebaseerd op communicatie tussen modulen en producten via een landelijk gedistribueerde database. Deze architectuur biedt een schaalbare oplossing voor koppeling van apparatuur van verschillende leveranciers. Specificatie van een communicatie standaard kan beperkt blijven tot de specificatie van database definities. De huidige database kan vervangen worden en gekoppeld met de andere modulen. Er zijn verschillende configuratie mogelijkheden van de modulen op een toekomstige TIAV infrastructuur. De productlijn van Brimos bevat ook mobiele actuator systemen. Het actuator management systeem is zo ontwikkeld dat de mobiele systemen volledig geïntegreerd worden in het verkeersleidingssysteem, het configuratie beheer en systeembeheer. BTIS implementeert een strikte visie op veilig configuratie beheer. Het systeem biedt een elektronisch handtekening mechanisme waardoor voorkomen wordt dat beelden die in de verkeerscentrale gedefinieerd en bediend worden verschillen met de werkelijke beelden op de actuatoren. In dit systeem is ook logging mogelijk van de werkelijk getoonde beelden


C-7

CCT - Command & Control Toolkit (CCTK) Categorie Functionaliteit

Modulen


Toepassing

DVM totaaloplossing CCTK is een software product voor data acquisitie, bewaking en besturing van processen op afstand, afkomstig uit de ruimtevaart. Hulpmiddelen zijn mee geleverd voor configuratie en beheer door gebruikers. Kern modules: Server module: Kern module van CCTK voor centrale data verwerking, simulatie en controle functies. Software en hardware van deze module wordt afgestemd op applicatie en performance eisen. Client module: Deze module is een systeem functie voor de primaire grafische gebruikersinterface voor een individuele CCTK gebruiker. De cliënt-server architectuur is schaalbaar voor een willekeurig aantal gebruikers (met een eigen dient) op een netwerk. Optionele modules: Development Environment option: C/C++ AP1 en andere customisation tools voor de ontwikkeling van gebruiker specifieke systeem configuraties. Display Builder option: Grafische editor voor de creatie van maatwerk console schermen. Communication interface options: software drivers voor verschillende sensor koppelvlakken, waaronder low level I/O, PCM telemetry, seriële data, veldbus, multicast, peer-to-peer TCP/IP socket en timing interfaces. Platforms: Unix (IRIX of Linux) met Windows NT cliënt displays Interfaces: Via PCM telemetry, Fieldbus/lnterbus, Modbus, RS-232/RS-422, TCP/IP sockets, FDDI, en/of MIL-STD-1553B. API bindings met C, C++, en Java. Protocollen: TCP/IP, JDBC CORBA: Ja XML: Ja SMS functionaliteit: Deels (verwerking van gegevens) AMS functionaliteit: Ja Soort BL: TCL/TK scripting taal. Extern koppeling met Gensym's G2 expert systeem ook mogelijk. GIS in PL: Geen; wel strip-charts, dials, schakelaars, en grafieken. SUT-beheer: Nee Additionele functionaliteit: Simulatie en Java web dient architecture ingebouwd. Koppeling met Gensym's G2 expert systeem en MatrixX modellering tooi ook mogelijk. Verbinding met wegkant zou maatwerk zijn. Geen verbindingen met PLC's ingebouwd. Geen DVM track record. Toepassingsgebieden buiten DVM:

•

Leverancier

Launch vehicle simulatie en bewaking;

• Bewaking en besturing van processen op afstand; • Ruimtevoertuig integratie en testen, bewaking en besturing; • Mobiele Command & Control; > Netwerken- en beveiligingscontrole. Command & Control Technologies, Inc., 1425 Chaffee Dr., Suite 1, Titusville, FL 32780, USA, http://www.cctcorp.com Kevin Brown, Vice President, Business Development, Tel : +1 (321) 264.1193, Fax : +1 (321) 383.5096, [email protected] Burkhard Linke, Director (European sales representative), Enterprise Florida, Germany Office, lm Amerika Haus, Karolinenplatz 3, D-80333 Munich, Duitsland, Tel: +49 89 5151 -8885, Fax: +49 89 6001 -3447, [email protected] Rodney Davis, CCTK Product Manager, (adres, tel. & fax nrs. hetzelfde als Kevin Brown), [email protected]


C-8

Status Bronnen

Bijzonderheden

COTS CCTK product informatie op website: www.cctcorp.com/cctk.html CCTK product data sheet; CCTK Users Manual; Downloadable van CCT website http://www.cctcorp.com/techdoc.htmtfCCTK-doc: User's Manual, Administrator's Manual, Installation Manual, Developer's Manual, Release Notes, Technical FAQ, API Library. • Een basis licentie bevat 1 server en 1 cliënt module. • Klein bedrijf, nauw verbonden aan ruimtevaart toepassingen. Andere gerelateerde producten van leverancier: • T-Zero taak sequencer/scheduler, met Gantt charts. Zie http://www.cctcorp.com/tzero.htm • RangeNet voor lanceerbasis beveiliging en controle. Referentie gebruikers: • NASA Kennedy Space Center, Wallops Flight Facility, Alaska Aerospace, Lockheed Martin, Boeing, Spaceport Florida.


C-9

Delcan - Traffic Control and Surveillance System (TCSS) Categorie Functionaliteit

Modulen


DVM totaaloplossing Het Traffic Control and Surveillance System (TCSS) van Delcan is een compleet Advanced Transportation Management System (ATMS) voor verkeersmanagement van snelwegen, tunnels, en bruggen. TCSS biedt automatisch incident detectie (AID) en management functionaliteit, ondersteunt een brede verzameling van verkeersmanagement strategieën, en kan geïntegreerd worden met wegkant sensoren en actuatoren van verschillende leveranciers. Real Time Database (RTDB) : Biedt netwerk data distributie diensten van realtime status en event informatie aan programmatuur. Dit is een RAM (Random Access Memory) resident proces met "associated memory" en bewaart alle actuele data van het TCSS systeem met een vertraging tot 1 seconde. RTDB bevat ook de processen voor distributie en opslag van data, inclusief: • Remote Event Distribution Manager; • Database Registration Manager; • Database Request Manager; • Remote Re-synchronisation Manager; • Database Hot Standby Synchronisation Manager; • Database Timer Manager. Automatic Incident Detection (AID): Module voor real-time analyse van verkeersinformatie en de volgende AID algoritmen: APID (All-Purpose Incident Detection), DES (Doublé Exponential Smoothing), McMaster, Low Speed. Alarm / Event Management: Groep van processen voor detectie en beheer van apparatuur, events, en alarm condities in het TCSS. Traffic Response Plan Management: Groep van processen voor het beheer van maatregelen (traffic plans). Via de koppeling met de gebruiksinterface worden verzoeken voor executie van maatregelen en individuele apparaat bediening uitgevoerd en informatie uit monitoring apparatuur gepresenteerd. Equipment Interface Management: Groep van processen voor het beheer van controllers van specifieke apparatuur, zoals dynamische borden. Hieronder vallen verzoeken tot commando's versturen en terugkoppeling van de apparatuur ontvangen. System Management: Groep van processen voor het bewaken van software en hardware in het TCSS. Hieronder valt ook het nemen van acties bij detectie van fouten. Graphical User Interface: Groep van processen voor het beheren van een gebruikersinterface. Hieronder vallen de grafische presentatie van status informatie van apparatuur, alarmmeldingen, en ontvangt acties van de gebruiker voor incident management, maatregelbeheer en voor het genereren van rapporten. Platforms: PC-gebaseerd, met C++ voor toepassingen en C++ of Java voor user interfaces Interfaces: direct interfacing Protocollen: NTCIP, en 40 verschillende leveranciers' protocollen geïmplementeerd CORBA: nee XML: nee SMS functionaliteit: ja AMS functionaliteit ja, inclusief VMS'en Soort BL: beslisbomen (regelscenario's) en traffic (response) plans (maatregelen). CLIPS expert systeem kan ook gekoppeld worden. GIS in PL: Ja, eigen GIS-achtig functionaliteit SUT-beheer: Ja, met taak- en werkplek overdracht Additionele functionaliteit: simulatie, en automatisch incident rapportage per e-mail, fax, W W W , e.d.


c-10

Toepassing

Leverancier

Status Bronnen

Bijzonderheden

Direct interfacing met controllers. Geen toepassing buiten DVM Delcan Corporation, 133 Wynford Drive, Toronto, Ontario M3C 1K1, Canada Richard Chylinski, Manager, Software Systems, Tel: +1 (416) 391 7520, Fax: +1 (416) 441 0226, [email protected] Frans op de Beek, Project Director, Traffic Management & ITS International, DHV Environmental and Infrastructure, Laan 1914, no. 35, 3818 EX Amersfoort, Nederland, Tel: +31 (0)33 468 2869, Fax: +31 (0)33 468 2803, [email protected] COTS • Delcan International Corporation - ITS software and system products (PDF); • Presentatie Delcan aan AVV, 11 juni (Powerpoint); • Aantal Delcan case studies, b.v. COMPASS Freeway TMS, TCSS Hong Kong West Harbour Crossing, en TCSS Lantau Fixed Crossing. Bijv. opmerkingen over bedrijfsgrootte/stabiliteit: • Opgericht in 1953; • 500 medewerkers in 20 landen; • Strategisch alliantie met DHV. Bijzondere Leveringsvoorwaarden: • Tijdens zijn presentatie heeft Delcan een samenwerkingsovereenkomst met RWS voorgesteld, waardoor RWS functionaliteit zou kunnen toevoegen aan TCSS en recht zou hebben op licentie inkomsten op de toegevoegd functionaliteit. Andere gerelateerde producten van leverancier: • Traffic Signal Management System (TSMS). • Air Quality Management System (AQMS). • Traffic and Road Information System (TRIS). • Traffic Data Management System (TDMS). Reference gebruikers: • Lantau Fixed Crossing, Hong Kong • Halifax-Dartsmouth Bridge Commission, Halifax, Canada • New Hong Kong Airport, Hong Kong • Ampang Kuala Lumpur Elevated Highway, Malaysia


C-11

Electron - SAT 200 + SAT 1703 Categorie

Telecontrol

Functionaliteit

De SAT systemen kunnen worden toegepast voor Telecontrol applicaties; veilige besturing en bewaking over slechte telecommunicatie kanalen van geografisch gedistribueerde systemen, met name in de energievoorziening. De voornaamste producten zijn: • SAT 1703, een PLC achtig product • SAT 200, een SCADA pakket » SAT Toolbox voor engineering met SAT producten De Architectuur van de SAT producten wordt bepaald door de standaarden: IEC 60870 en IEC 61850. Dit zijn communicatie standaarden voor de automatisering van substations voor de elektrische energievoorziening; productie en distributie. Energieproductie en -distributie Electron Automatisering, Takkebijsters 17-1, 4817 BL Breda T.H. Lauw, directeur Marco C. Janssen, marketing manager COTS Bedrijfsbezoek op 29 mei 2002 Electron Automatisering B.V. is een dochter onderneming van VA TechSAT

Modullen



Status Bronnen Bijzonderheden

(40%) en Spie (60%) Het Oostenrijkse VATech houd zich voornamelijk bezig met water energie en metallurgische projecten. VATech SAT is het automatiseringsdeel en richt zich hoofdzakelijk bezig op het gebied van energie voorziening, zowel energie levering als distributie. Een hoofdactiviteit van VATechSAT, maar niet van Electron, is tevens de automatisering van tunnels. In Oostenrijk hebben ze op verkeersgebied een markt aandeel van 70 %. Dit wordt mogelijk veroorzaakt, doordat de ook in Oostenrijk gehanteerde TLS standaard afgeleid is van de IEC Telecontrol standaarden. Het Franse SPIE (Société Parisienne pour l'lndustrie Electrique) is een dienstenleverancier op het gebied van electrotechniek en IT services en treedt tevens op als aannemer van infrastructuur en bouwwerken. Het bedrijf bied zijn klanten een breed scala van deskundigheid, uiteenlopend van conceptuele ontwikkeling en ontwerp tot realisatie en onderhoud.


C-12

Engenuity - JLOOX 2.0 & JLOOXGis 2.0 Categorie Functionaliteit

Modulen




PL toolkit JLOOX en JLOOXGis zijn twee producten voor grafisch toolkits voor Java ontwikkeling. JLOOXGis is een uitbreiding van JLOOX voor geanimeerde kaarten en vergelijkbare geografisch GUIs. JLOOX bestaat uit: • JLOOXMaker: prototyping tooi. • JCIass Chart: 3rd party (Sitraka) charting tooi. • JLOOX JavaBeans: integratie met Java 2 IDE's zoals Borland's JBuilder of Sun's Forte for Java. • JLOOXLayout: voor complexe topologieën en diagrammen. JLOOX ondersteunt Scalable Vector Graphics (SVG). Naast SVG, ondersteunt JLOOXGis vector en raster data, in Arclnfo, DTED, TeleAtlas, Navtech, Shape files en OGDI servers. GDF formaat is niet in de documentatie genoemd. • Platforms: JLOOX en JLOOXGis zijn specifiek aan Java. • Interfaces: niet van toepassing » Protocollen: zelfs XML is niet genoemd in documentatie. Beide producten wordentoegepast voor Java ontwikkeling. Toepassingsgebieden buiten DVM: JLOOXGix is breed inzetbaar. Engenuity Europe, 1 rue EUGENE VARLIN, MALAKOFF, F-92240 Frankrijk, http://www.loox.com Pierre ORLIAC, KEY Account MANAGER, Tel: +33 1 49 65 32 94, Fax: +33 1 49 65 49 72 Jerrome Joubert, Product manager COTS Commerciële flyers voor JLOOX 2.0 en JLOOXGis 2.0. JLOOX is in het Paradigma project gebruikt.


C-13

Ferranti - Real-Time Application Platform (RTAP) Categorie Functionaliteit

Modullen


SCADA RTAP is een suite van SCADA producten. De kern - de RTAP Database - zorgt voor inwinning, verwerking en opslag van gegevens in real-time. De RTAP Visualiser is de bijbehorende Human-Machine Interface (HMI). RTAP Database (D). Real-time, object georiënteerde database, vergelijkbaar met de Database laag in ACT. Bevat een Calculation Engine (vergelijkbaar met CoMonitor), Data Historian (event & data logging), en Alarm Detector. Heeft een API voor koppelingen met de RTAP Visualiser, ActiveX en ODBC componenten. Er is ook een koppeling via ODBC met (non-real-time) Oracle databases voor het genereren van rapporten. RTAP ScanTask (S). Set van software drivers voor PLCs, DCSs en RTUs, vergelijkbaar met CoSensor. Er zijn o.a. ScanTasks voor Allen-Bradley (DH+ en INTERCHANGE), Modbus, AbNet, HP 3852A, OPC, Siemens H 1 , en VXI. RTAP Visualiser (V). Vergelijkbaar met de PL in ACT, maar dan alleen voor RTAP functionaliteit (RTAP Database en ScanTasks). Bevat Schematics, Alarm Notification, Trend Display, Report Builder (heeft Oracle nodig), en Control Panels. RTAP Configurator (C). Bevat een Scripting Tool voor o.a. BL regels. RTAP Event Manager (E). Bewaking van events in de uit de RTAP Database en initiatie van vervolgacties. Platforms: RTAP Database is beschikbaar voor Unix en Windows NT. RTAP// Database is een web-enabled versie van het RTAP Database. RTAP Visualiser is alleen beschikbaar voor Windows NT. Interfaces: Er zijn RTAP ScanTasks voor veel van de defacto standaarden

voor PLCs (zie boven).

Toepassing

Leverancier

Status Bronnen

Protocollen: ActiveX, ODBC, en API. Met behulp van het separaat product, Enterprise Link, zijn verbindingen te maken met ERP producten zoals SAP R/3, Oracle databases, en Microsoft SQL Server. RTAP is een SCADA pakket en verwacht dat gegevens worden ingewonnen uit PLC's, RTU's en/of DCS'en. Toepassingsgebieden buiten DVM: RTAP is breed inzetbaar, met in Benelux zijn grootste installed base in de energie, Utilities en facilities markten; Amsterdam Airport Schiphol (voor pijpleidingen), Rotterdam Rijn Pijpleidingmaatschappij, Nuon (electriciteit, gas en water), ENECO Energie Delfland, Westland Energie, Defensie Pijplijn Organisatie, Amylum, VDAB, Essent; BASF, Vandemoortele, en Rotterdam Antwerpen Pijpleiding. RTAP is ontworpen door de Canadese firma Verano: Ron Derynck, Director of Product Strategies, Alberta, Canada, tel: +1 (403) 299 4754, email: [email protected]. John Delaney, Director Sales Europe, Basingstoke, UK, tel: +44 1256 398 015, email: [email protected]. Benelux distributeur en added-value dienstverlener is Ferranti Computer Systems, Antwerpen, België. Guido Van de Velde, Business Unit Manager, en Sander Wijninga, Sales Executive, Antwerpen, België, tel: +32 3 540 49 1 1 , email: [email protected] en [email protected] COTS HP product data sheets voor RTAP Database en RTAP Visualiser. White paper over IPOS Lite met GPRS. Product data sheet en Verano white paper over RTAP/; web-enabled realtime database (PDF). Handouts van RTAP Users Group seminar @ Slot Zeist, 24 mei 2002. Helpfiles voor RTAP ActiveX controls, RTAP Administratie, RTAP Controls,


C-14

en RTAP Configuration Tool (HLP) RTAP Functionele Beschrijving, issue 3, mei 2002 (PDF) RTAP for Windows/NT, PC Client's Guide (PDF) RTAP for Windows/NT. Reference (PDF) RTAP for Windows/NT, Integrator's Guide (PDF) RTAP case study, Amsterdam Airport Schiphol (MS-Word) Bijzonderheden

Andere gerelateerde producten van leverancier. • •

IP Outstation (IPOS): een RTU voor PLC's. Enterprise Link: een verbinding tussen RTAP op SCADA niveau met systemen op MES/ERP niveau, zoals SAP's R/3 of Oracle.

Vroegere vertegenwoordigers/eigenaren/moederbedrijf: • Delen van RTAP zijn door Canadees firma Verano ontworpen. Verano is oorspronkelijk een onderdeel geweest van Hewlett Packard. • Ferranti CS vult de Verano producten aan. » Vertegenwoordiger van Verano en Ferranti in Nederland is Nijkerk.


C-15

Harris - OS/Comet Categorie Functionaliteit Modulen


Toepassing

Leverancier

Status Bronnen

Bijzonderheden

DVM totaaloplossing OS/Comet is een product suite voor data acquisitie, distributie, en gedistribueerde bewaking- en besturingstoepassingen. Data Distribution: Middleware voor point-to-point en broadcast communicatie. Deze is noodzakelijk voor alle applicaties. User Interface: Grafische gebruikersinterface met mimics (synoptics), strip charting, en alfanumerieke schermen. Language Processing: Uitbreidbare scripting taal voor gedistribueerde controle, procedures, en systeem configuratie beheer. Recording & Logging: Opnemen van alle systeem events, telemetry, en gebruikers'acties (inclusief geautomatiseerde en manuele commando's) Command &Telemetry: Database gestuurde commando packet formatering, en uitpakken en verwerken van telemetrie pakketen. Operations Automation: Geplande uitvoering van meerdere, simultane, afhankelijke en onafhankelijke geautomatiseerde procedures. De status van de procedures wordt getoond aan gebruikers. Simulation: Database en script gestuurde simulatie van externe subsystemen. Data definities worden uitgewisseld met de Command & Telemetry module. Platforms: Unix Interfaces: direct interfacing (ASI/ASO templates beschikbaar), plus API Protocollen: TCP/IP CORBA: nee XML: nee SMS functionaliteit: deels (gegevens verwerking voor presentatie) AMS functionaliteit: deels (commanding) Soort BL: Script taal (CCL) GIS in PL: Geen SUT-beheer: Ja, met taak- en werkplek overdracht Additionele functionaliteit: simulatie (SIM/Tool) Maatwerk is nodig, maar Application Specific Input (ASI) en Application Specific Output (ASO) templates zijn beschikbaar. Toepassingsgebieden buiten DVM: • Ruimtevaart mission controle systemen; • Militaire Command & Control systemen; • Telecommunciatie netwerk managementsystemen. Harris Corporation, 7010 Turweston Lane, Castle Rock, Co 80104, USA, http://www.harris.com Scott Criley, Business Development, Tel: +1 (303) 814-2567, Fax: +1 (303) 8149422, [email protected] Robert "Bob" Stultz, Product Manager, Harris Corporation, 1225 Evans Road, Melbourne, FL, VS, Tel: +1 (321) 726-1001, Fax: +1 (321) 676-4510, [email protected] COTS • Harris OS/Comet overview (Powerpoint); • Intraplex brochure. Bijv. opmerkingen over bed rijf sgrootte/stabiliteit: • OS/Comet ontwikkeld 1982, en re-engineered met COTS in 1992. Andere gerelateerde producten van leverancier (TIAV, BOSS): • Intraplex electronica voor digital audio. Vroegere vertegenwoordigers/eigenaren/moederbedrijf: • OS/Comet is een product van Harris Technical Services Corporation, een divisie van Harris Corporation.


C-16

IBI Group - Advanced Traffic Management Software (ATMS) & Advanced Device Control Software (ADCS) Categorie Functionaliteit

Modulen

DVM totaaloplossing ATMS is een verzameling van discrete modulen voor het implementeren van ITS functionaliteit voor verkeersmanagement van snelwegen. Hoofd functies zijn het beheer van gebeurtenissen (incidenten), files, en reistijd. Het kan gekoppeld worden met ADCS en/of SCADA systemen voor inwinning van verkeersgegevens. ADCS software is een suite van producten voor het bewaken en besturen van ITS sensoren en actuatoren. ADCS is bedoeld als onderdeel van een ATMS implementatie, maar ADCS modulen kunnen ook autonoom opereren (zonder gebruikersinterface) of gecombineerd worden met een eigen GUI (ADCS Management Tool). Modulen bestaan voor bewaken en besturen van CCTV, voorgedefinieerde en dynamisch matrix borden, en monitoren van verkeersgegevens. Advanced Traffic Management Software (ATMS): Sensor Management: Remote Weather Information System (RWIS): Communicatie met weerstation. Supervisory Control And Data Acquisition (SCADA): Communicatie met SCADA systemen. Emergency Roadside Telephone (ERT): Communicatie met praatpalen. Vehicle Detection Station (VDS COAAM): Communicatie met verkeersdetectoren, afhandeling van communicatie fouten, monitoring en afleiding van verkeerskundige data, validatie van data, en doorsturen van deze data naar de incident and queue detection / monitoring algoritmen, en aan de GUI Application Control: Graphical User Interface (GUI): Map, of kaart, gebaseerde gebruikersinterface. Meerdere gebruikers hebben gelijktijdig toegang tot het systeem. De kaart geeft een overzicht van het systeem met symbolische weergave van onder andere wegkant-apparatuur, status informatie, incidenten en files. Standaard navigatie mogelijkheden voor zoomen en scrollen. Foutbewaking en rapportering dagelijkse incidenten en files, historische verkeersdata, en storingen en gebruik

van apparatuur. Incident and Queue Detection (IQ): AID en file bewaking met volgende algoritmen: McMaster, speed adapted APID of "difference in speed", multiple speed threshold. De algoritmen bewaken ook de toe- en afname van file lengte. Travel Time (TT): Berekening van reistijden uit de VDS data. Event Manager (EAA): Event manager voor systeem- en storingsmeldingen en door gebruiker ingevoerde probleem informatie over incidenten, weer, en geplande activiteiten. Events kunnen vanuit alle modulen worden gegenereerd en worden gelogd op de centrale computer. Response Manager (RM): Proces voor het genereren van maatregelen om het publiek te informeren op bijvoorbeeld actuatoren. Bevat ook basale logica voor afhandeling van conflicten in actuator bediening door prioritering van actuator beelden en de opdrachtgever van een bediening (operator, plan, default). Centre to Centre (C2C): Communicatie tussen centrals, en handelt prioriteiten en controle af. Actuator Management Camera Control (CC): Communicatie met CCTV camera's voor het selecteren van beelden op GUIs en automatische bediening van camera's bij event

detectie.


C-17

Dynamic Message Signs (DMS): Communicatie, controle en bewaking van dynamic message signs. Meerdere communicatie protocollen op meerdere communicatie kanalen worden ondersteund. Vanaf de centrale computer kunnen DMSen bedient worden, default beelden worden geladen, en status informatie opgehaald (polling). Lane Control Signs/Variable Speed Limit Signs (LCS/VSLS): This process enables the central computer to control and monitor all LCS/VSLS signs located throughoutthe system. This process supports multiple communication protocols across multiple communication channels, and will support both dialup and direct access to sign controllers. This process enables the central computer to display a message on any sign, download a default message to a sign controller (where supported by the controller) and poll each controller for status on a regular basis. Message Broadcast Interface: Koppeling met "broadcasfapparatuur zoals fax, email, sms en interactive voice telefoon, en pager. Other: Proces koppeld met andere typen apparatuur, zoals verkeersregelingen (zoals SCOOT), verkeersregelinstallaties, verkeerslichten, en "ramp gates". Top-niveau interacties tussen de processen zijn als volgt: IBI GROUP TMS TOP LEVEL DATA FLOWS (SIMPLIFIED)

Sensor Management System

Application Control

Actuator Management System

(^Y

l

COMM ƒ

Otter Appücation Control RWIS ERT VDS SCADA

Remote W«»th«r Infoimahon Syslem Emero*riey Rotdside Tatophon* Vvhicl* Detection Station Eupwviwy Contwl & Data Actfjaibor,

IQ TT EM RM RM C2C GUI

Incident and Ouaus I Travel Timo Event Manager Rispons» Manager Response Manager Centre-To-Centre Graphical Usai Intar

DMS LCS VSLS

Camera Control Dynamic Massage Sipis Lam Control Signs Variable Speed Limit Signs

Advanced Device Control Software (ADCS): Sensor Management System - SMS: Gedistribueerde koppelvlakken tussen sensoren en regionale en nationale verkeerscentrales. Beheer en configuratie van verkeersdata sensoren en hun interfaces van op afstand. Bewaking en rapportage van status en storingen. Monitoring en afleiding van verkeerskundige informatie uit sensor data. Actuator Management System - AMS: Gedistribueerde koppelvlakken tussen actoatoren en apparatuur langs de weg, en verkeerscentrales. Real-time bediening, status bewaking, beheer en configuratie, zowel locaal als van op afstand uit centrales. Mogelijkheid voor automatische en manuele bediening van actuatoren. Voorzien ondersteuning voor Vicon CCTV, ECM Traffic Monitoring Units, en Monitor Electronics Variable Speed en Lane Control Signs. Andere actuatoren zijn te integreren.


C-18


Toepassing

Leverancier


Platforms: (ATMS) ANSI C en C++, ODBC database access, en Windows NT/2000; (ADCS) ANSI C & C++ en Posix (en voor embedded toepassingen QNX of OS/9) Interfaces: ADCS-ATMS ("center-to-tïeld") is SNMP over TCP/IP. ADCS drivers zijn beschikbaar voor "een klein aantal" leveranciers specifiek interface standaarden Protocollen: NTCIP, TCP/IP, SNMP CORBA: nee XML: nee SMS functionaliteit: ja (ADCS) AMS functionaliteit ja (ADCS) Soort BL: traffic (response) plans (maatregelen) GIS in PL: Ja, ESRI product SUT-beheer: Ja, behalve taak- en werkplek overdracht Additionele functionaliteit: Geen Vereist maatwerk om nieuwe software drivers te maken. Geen toepassing buiten DVM. IBI Group (UK) Ltd, 1st Floor, Kemp House, 152-160 City Road, London EC1V 2NP, Verenigd Koninkrijk, http://www.ibigroup.com Scott Stewart, Director, Tel: +44 (0)207- 629-7018, Fax: +44 (0)207 251 8339, ssieâfj^bjgrp_u-p_1c,o_m COTS ATMS GUI manual (PDF). Bijv. opmerkingen over bedrijfsgrootte/stabiliteit: • IBI Group heeft vier speerpunten: Urban land, Facilities, Transportation, en Systems. ITS is verantwoordelijkheid van Transportation. Vroegere vertegenwoordigers/eigenaren/moederbedrijf: • ITS was werkterrein van Murray & Murray Associates. In juli 2000 is Murray & Murray onderdeel geworden van IBI Group. Reference gebruikers: Attiki Odos Motorway, loannis Nassoulis, Manager ITATMS, 113 Neratziotissis St, 15124 Maroussi, Greece, Tel: +30 (0)1061 76800, Fax: +30 (0)1061 98905, [email protected] Connecticut Department of Transportation, Mr. Harold Decker, Manager, Highway Operations, State Transportation Building, P.O. Box 317546, 2800 Berlin Turnpike, Newington, CT 06131-7546, Tel: +1 (860) 594-2636, Fax: +1 (860) 594-2655, [email protected] City of Toronto Transportation Department, Martin Maguire, Manager RESCU, Works & Emergency Services, 5th Floor, 703 Don Mills Road, North York, Ontario, M3C 3N3, Tel: + 1 - (416) 392-5243, Fax: +1-(416) 3975777 Massachusetts Highway Department, Mr. Russ Bond, Manager ITS Programs Unit 10 Park Plaza, Room 7210, 7* Floor, Boston, MA 02116, Tel: +1 (617) 973 7358, Fax: +1 (617) 973 8861, Ru5juBjMd@StatejiiaJis


C-19

ICS - SCL/eSCL & RIMS Categorie Functionaliteit

Modulen

BL toolkit De suite bestaat uit twee producten: SCL (en zijn web-gebaseerd versie: eSCL) en RIMS. RIMS is en Java-gebaseerde dient toolkit voor SCADA-achtige monitoring en grafisch presentatie van gegevens. SCL is een real-time, regelgebaseerd expert systeem ontwikkeld voor SCADA toepassingen. SCL is een toolkit met de BL functionaliteit ter aanvulling op RIMS. Daarom is RIMS met SCL/eSCL beschouwd als één product in dit project. Real-Time Engine (RTE): inference engine, command interpreter, en scheduler. DatalO: data acquisition and decommutation (decompositie van gegevens uit data pakketten), real-time aanpassen van de SCL database en veranderingen melden bij de RTE. SCL Compiler: compiler voor SCL; zowel voor ontwikkeling als voor run-time

compilatie.


Toepassing

Leverancier

Status Bronnen

Bijzonderheden

Software Message Bus: communicatie bus voor communicatie tussen SCL modules en processen, en koppelingen met commanding gateways, legacy en custom applicaties. SCL Viewer: SCL command line interface, RTE status, en debugging capabilities. RIMS: Java gebaseerde web server interface voor remote monitoring via web browsers. SCLserver: 3rd party graphics driver Platforms: Unix, Windows NT, embedded systems Interfaces: API beschikbaar Protocollen: TCP/IP, UDP, SNMP, XML Toepassingsgebieden buiten DVM: • Militaire Command & Control • Ruimtevaart (spacecraft mission control systemen) • Industrieel en proces controle systemen • Logistiek operationele controle systemen Interface & Control Systems, Inc., 1938 S. Dairy Rd, Melbourne, FL 32904, USA www.interfacecontrol.com/products Brian Buckley, Executive Vice President, Tel: +1 (321) 723-0399 x203. Fax: +1 (321) 722-9052, E-mail: [email protected], Website: http://www.interfacecontrol.com COTS Facts Sheets voor het gebruik van SCL en RIMS in controlekamers, voor "intelligent alerts", voor autonome systemen, planning en tasking, en voor (militaire) inlichtingen. Powerpoint presentaties voor het gebruik van SCL/eSCL en RIMS in controlekamers, voor intelligent alerts, en voor web-gebaseerd monitoring en controle systemen. Commercieel "Corporate Capabilities" document. Veel product documentatie (b.v. white papers, gebruik voor embedded systems, en nieuws) is te vinden op www.interfacecontrol.com/products . SCL, eSCL en RIMS zijn open source producten • eSCL is een versie van SCL voor e-business • ICS is nauw verbonden met Lockheed Martin SCL/eSCL en RIMS bieden de volgende additioneel functionaliteit boven de AVB/ACT behoeften: • Input van UML diagrammen uit Rational Rose • Fault-tree modelling • Automated machine learning voor data mining

•

Voice-activated en call-tree capabiliteiten

•

Synthesised voice alerts (toekomst)


C-20

•

Wireless application support (toekomst)

Referentie gebruikers: Lockheed Martin M&DS - SBIRS High program, Lockheed Martin Commercial Systems, Space Systems Loral, Johns Hopkins University, Applied Physics Lab, Goddard Space Flight Center, Kennedy Space Center, Ball Aerospace, Naval Research Laboratory, Stanford University, University of Colorado, Jet Propulsion Lab, US Air Force Research Laboratory, GE-Transportation Systems, dassified customers.


c-21

ILOG - Rules & JRules Categorie Functionaliteit

Modulen

BL toolkit ILOG Rules en ILOG JRules zijn gelijkaardige producten met dezelfde functionaliteit en overeenkomstige module: Rules is voor C++ en JRules voor Java. Beide producten bestaan uit gelijkaardige modulen; een 'rule engine' en een bibliotheek van business-rule classes. De rule engine van beide producten gebruiken dezelfde Rule Kit, bestaand uit:

Rule Repository: bibliotheek (repository) voor gecentraliseerde opslag, beheer


Toepassing

en distributie van business rules in een organisatie. De bibliotheek is open en uitbreidbaar. Rule Builder: geïntegreerde ontwikkelomgeving voor ontwikkeling en debugging van business rule applicaties. Business Rule Language: taal voor definitie van regels. Taal is aanpasbaar en uitbreidbaar. Rule Editor: editor voor aanpassen van regels door gebruikers, via een web interface gebaseerd op JavaBeans. Platforms: C++ (Rules) en Java (Jrules) Interfaces: niet van toepassing Protocollen: geen ITS-specifiek; wel XML, web services en J2EE Rules is verbonden aan C++ en JRules aan Java.

Toepassingsgebieden buiten DVM: breed inzetbaar voor o.a. spoorwegen Leverancier

Status Bronnen

luchtverkeersleiding; zie reference gebruikers. ILOG, 3-5 avenue Galliéni, batiment Orsud, GENTILLY, 94257 Frankrijk, http://www.ilog.fr of http://www.ilog.com. Ludovic DUZAN, Sales Manager, Europe - Transport & Utilities Tel: +33 1 49 08 35 95, Fax: +33 1 49 08 36 10, E-mail: [email protected] MargaretTHORPE ([email protected]), Product Manager (J)Rules COTS product informatie http://www.ilog.com/products/rules/ rule kit informatie http://www.ilog.com/products/rules/kit Commerciële flyers in PDF formaat. Een MATCH team lid heeft het ILOG/Logica transportation seminar bijgewoond op 28 maart 2002. Een veelvoud van case studies zijn aan de

orde geweest. Bijzonderheden

Verder interactie via e-mail. Reference gebruikers:

Rules: Paris airport, Fedex, Sncf, Ratp, Dutch Railways (NSR), Faa, Swisscontrol, Csee Transport, Siemens transportation system, Alstom, Inrets, Atmb, City of Lyon, Bouygues telecom, France Telecom, Compaq, LHS, MCI Worldcom, Nortel networks, Motorola, Orange ... JRules: SNCF, Southwest airline, Bell South, Ericsson, LHS, Lucent, Orange, Qwest, Siemens, Visa, Providence Washington, Business loan express, Intershop, Abaxx, Zurich Financial Services, Harrah's entertainment, Ing, Gogo worldwide

vacation


C-22

ILOG - Views & JViews Categorie Functionaliteit

Modulen


Toepassing

Leverancier

Status Bronnen

Bijzonderheden

PL toolkit ILOG Views en ILOG JViews zijn gelijkaardige producten met dezelfde functionaliteit en suite van grafische bibliotheken voor het maken van GUI's. ILOG Views bestaat uit een basis product en additionele ("add-on") modules. Basis modules zijn: • ILOG Views 2D Graphics: High performance en interactive 2D graphics • ILOG Views Controls: Standard dialog objecten Additionele modules zijn: • ILOG Views Charts: Data presentatie • ILOG Views Maps: Map data inlezen en beheer • ILOG Views Graph layout: Automatische grafiek opmaak • ILOG Views Data Access: Koppeling van applicatie met vele data bronnen zoals databases en XML ILOG JViews bestaat uit een kern module en additionele ("add-on") modules. Kern module is: • ILOG JViews Graphics Framework: grafische editor (BGO Composer) om met point-en-click grafische objecten te bewerken Additionele modules zijn: • ILOG JViews for Workflow: Componenten voor het maken van business process modelers en real-time monitor schermen. • Maps: Module met cartografïsche functionaliteit • Graph Layout: (Op)maken van visualisaties van netwerken en grafen, bijvoorbeeld voor workflow. • Gantt Chart: (Op)maken van Gantt figuren voor taak en resource scheduling. • Charts: (Op)maken grafieken en charts voor web-interfaces. • Platforms: C++ (Views) en Java (Jviews) • Interfaces: niet van toepassing • Protocollen: geen ITS-specifiek; wel XML met Views Data Access module • GIS: Views/JViews Maps additioneel module essentieel Views is verbonden aan C++, en JViews aan Java. Toepassingsgebieden buiten DVM: breed inzetbaar voor o.a. spoorwegen luchtverkeersleiding; zie reference gebruikers. ILOG, 3-5 avenue Galliéni, batiment Orsud, GENTILLY, 94257 Frankrijk, http://www.ilog.fr of http://www.ilog.com Ludovic DUZAN, Sales Manager, Europe - Transport & Utilities Tel: +33 1 49 08 35 95, Fax: +33 1 49 08 36 10, E-mail: [email protected] Christophe BORDE ([email protected]) , Product Manager (J)Views COTS Views product informatie op: http://www.ilog.com/products/views/ Jviews product informatie op: http://www.ilog.com/products/jviews/. Commerciële flyers in PDF formaat. Een MATCH team lid heeft het ILOG/Logica transportation seminar bij gewoond op 28 maart 2002. Een veelvoud van case studies zijn aan de orde geweest, inclusief de Vanessa presentatielaag prototype. Verder interactie via e-mail. Reference gebruikers: • Road traffic: Brussels, Lyon, ATMB, Luxembourg, Lille, Canton de Vaulx, Canton de Vallois, Toulouse, ... • Railways: SNCF, Deutsche Bahn, RENFE, Siemens Transportation System, CSEE Transport, Alstom, RATP ... • Air: Air France, British Airways, STNA, Eurocontrol, DFS, Sabre, Paris Airport, Roma Airport, ...


C-23

Sea: Port of Singapore, Port of Felixstowe, Lookheed Martin, ... Power provider: Edf, Enel, Tractebel, Gdf, Long Island Power Authority Telecom: Alcatel, NTT, Orange, Deutsche Telekom, Ericsson, HP, IBM, Space: Comsat RSI, Envisat, Intelsat, Matra Marconi Space, British Aerospace, ...


C-24

Imtech - UniMACS 3000 Categorie Functionaliteit

Modullen



Status Bronnen

Bijzonderheden

SCADA/PLC Het Unimacs 3000 systeem is opgezet als een geïntegreerd systeem voor het totale operationele management van een vaartuig. Het integreert daartoe de drie klassieke scheepsmanagement gebieden: navigatie, platform ('machinekamer') en payload (lading of operationele taak). Het centrale deel van het systeem is opgezet rond een redundant netwerk, dat de systeemcomponenten met elkaar verbind. Het systeem kan de volgende standaard componenten bevatten: • Manoeuvreer paneel (voortstuwingsregeling en stuurinstallatie); • Werkstation (20 inch, Windows NT4/2000), waarop een aantal interface applicatie functies kan worden aangebracht in de vorm van 'clients', • Electronische Zeekaart (ECDIS); • Navigatie, bestaande uit een aantal separate navigatie modules, onder andere: Windrichting, koers en diepte; • Platform management, bestaande uit een (redundante) SCADA Server en een aantal PLC's. Hierbij wordt gebruik gemaakt van standaard industriële producten van derden, waaronder Cimplicity (Scada) alsmede Allan Bradley en Modicon (PLC's). De verbinding tussen de PLC's en de SCADA servers gaat via een separaat netwerk; • Fire fighting & Damage Control, bestaande uit een electronisch piotbord voor het weergeven van de locatie, de omvang en de aard van mogelijke calamiteiten, alsmede de bestrijdingsacties; • Remote Maintenance applicatie, waarbij via een Web server interface vanaf afstand onderhoud uitgevoerd kan worden; Datalogging Windows NT/2000 De communicatie tussen de clients en servers over het centrale netwerk wordt gerealiseerd middels het Maritiem message based MITS (Maritime Information Technology Standard) protocol SCADA: Cimplicity van Trimation PLC: Modicon van Schneider-Electric Scheepvaart Imtech Marine & Offshore, Sluisjesdijk 155, Postbus 5054, 3008 AB Rotterdam Leo Franke, Product Manager COTS • Bedrijfsbezoek 22 mei 2002 • Company Profile • UniMACS 3000 Integrated Bridge System • Imtech jaarverslag 2001 Imtech is in 2001 ontstaan uit Internatio-Mülier, waarvan de onderdelen die niet tot de technische poot behoorden, zoals pharmacie, zijn verkocht. Imtech bestaat uit een aantal clusters: • Imtech Infra (Nettenbouw, Infratechniek, Infra Engineering, City Com; • Imtech Industrie; • Imtech Telecom (Datelnet). • Imtech ICT (per januari 2003) met daarin o.a. de volgende bedrijven: Turnkiek, PAC, Bostec, Dirkzwager, Mountside, Baltic;. • Imtech Marine en Offshore. Imtech Marine heeft in tweede instantie (kort voor het uitbrengen van dit rapport) aangegeven, dat ze bij nader inzien geen activiteiten buiten hun 'core-business area' (scheepvaart en offshore) willen ondernemen. Voor verkeerssystemen verwijzen ze nu naar Imtech Industrie. De ondeleveranciers Trimation en Schneider-Electric willen nog steeds graag leveren


C-25

Mi Services Group - TransActive Categorie Functionaliteit

Modulen


Toepassing

Leverancier

Status Bronnen

Bijzonderheden

DVM totaaloplossing TransActive is een suite van functionele modules voor bewaking en besturing van verkeersnetwerken. Het is een innovatief, open systeem, met een geharmoniseerde gebruikersinterface. Er zijn TransActive modules voor o.a. CCTV besturing, sensor bewaking, verkeersdetectie, incident management, tunnel bewaking en besturing, telecommunicatie sub-systemen, en rapportage. Core (CORBA integration, Process Management) Alarm Management CCTV control Video Control Expressway Map Module GIS Viewer Module Incident Detection Integration Incident Management Plan Module Facilities Viewer (SCADA displays) Traffic Detection Modules Traffic Statistics Emergency Telephone Module Message Communication Module Network Monitor Region Manager Traffic Signal Control Integration User Application Integration Platforms: Unix / Linux, Windows 2000, en Oracle Interfaces: direct interfacing via OPC, en PLC integration via Modbus Protocollen: TCP/IP en SNMP CORBA: Ja XML: nee SMS functionaliteit, ja AMS functionaliteit: ja Soort BL: Perl script taal GIS in PL: Ja, ESRI product, plus SCADA-achtige displays SUT-beheer: Ja, met taak- en werkplek overdracht Additionele functionaliteit: Verzamelen van statistische verkeersgegevens PLC via Modbus, of direct interfacing via OPC Toepassingsgebieden buiten DVM: Spoorwegverkeersleiding Mi Services Group, 85 The Esplanade, South Perth 6155, Australia, http://www.mi-services.com Gregory J Smith, Product Manager, Tel: +61 8 9368 8600, Fax: +61 8 9368 8699, [email protected] Peter ten Hove, Senior Account Executive (Nederland & Europa), M l Services Group, Radioweg 2, NL-1324 KW Almere, Nederland, Tel: +31 (0)36 546 1620, Fax: +31 (0)36 536 0554, [email protected] COTS product website: http://www.mi-services.com/au/transport/transport.htm Functional Overview van TransActive systeem Functional Overview voor elk module Flyer over Integrated Freeway Management Systems Project informatie voor, Adelaide Traffic Control Centre, Melbourne Citylink Central Computer Control System, Perth Traffic Management and Control System ^^ Bijv. opmerkingen over bed rijf sgrootte/stabiliteit: • 650 medewerkers • Australië, Nieuw Zeeland, UK, Singapore, Italië, VS


C-26

Huidige ontwikkelingen en planning vanaf dit jaar: • Meer functionaliteit in incident management en plan systeem • Safety Interlock Checker, dit is een bewaking of operaties veilig zijn onder gegeven condities. • Back-up centrale op andere locatie bij rampen • Field Processor Integration om een common CORBA compliant protocol in het veld op wegkantsystemen te kunnen draaien. • Algoritme voor reistijdschatting. • High performance PLC integratie met Modbus TCP/IP protocol voor hoge I/O count -100,000+ voor koppeling met een "controlling tunneP'en veiligheidssystemen. • Video streaming control voor streaming van geselecteerde video beelden in een intern netwerk. • Koppelvlak naar een onderhoudsbeheersysteem voor het genereren van werkopdrachten. • Verschillende specifieke koppelvlakken naar video switches, actuatoren, PABX systemen en radio systemen die worden gebruikt in lopende projecten. Referentie gebruikers: Melbourne Citylink, Perth Traffic Control Centre, Adelaide Southern Expressway, Singapore Kallang Paya Lebar Expressway


C-27

Open Roads Consulting - OpenTMS Enterprise Components Categorie Functionaliteit

Modullen



Status Bronnen

DVM totaaloplossing Het OpenTMS systeem bestaat uit het OpenTMS platform dat naast een GIS kaart interface bestaat uit een aantal basis functies zoals 'scheduling' en 'datalogging'. Op het OpenTMS platform kan een aantal interface applicatie functies worden aangebracht in de vorm van 'clients', waardoor de besturing van de applicatiefuncties die zijn uitgevoerd als 'server componenten' mogelijk gemaakt wordt. De interface applicatie functies voegen een overlay met icons toe aan de GIS kaart interface. OpenDMS, voor de besturing van Dynamic Messages Signs op basis van het NTCIP protocol of van product specifieke protocollen. De component kan ook gebruikt worden voor de besturing van andere actuatoren, zoals o.a. dynamische route informatie panelen, matrixborden en kantelwalsen; OpenCCTV voor de besturing van bewakings camera's en de bijbehorende video wall presentatie hardware, en videorecorders; OpenESS, voor het bewaken van de weercondities, in het bijzonder de mogelijke beperking van het zicht. De communicatie met de weersensoren is gebaseerd op het NTCIP protocol; OpenTSS, voor het inwinnen van sensor informatie van meerdere typen sensoren van verschillende leveranciers; OpenHAR, voor het doorgeven van verkeersinformatie via het (Amerikaanse) "Highway Advisory Radio" systeem en het bewaken van het zenderpark daarvan; OpenWZM, voor het inplannen van wegwerkzaamheden en het gedurende de gewenste tijdvakken activeren van de daarvoor benodigde dynamische verkeersmanagement apparatuur, zoals actuatoren, camera's en 'HAR' zenders; OpenIDM, voor het implementeren van Incident Detectie algoritmes. De component ondersteunt daarnaast ook de incident afhandeling; OpenTCS, voor een interface naar (nieuwe of bestaande) stedelijke verkeerslicht regelingen. De cliënt-server communicatie tussen modulen (componenten) op basis van Corba National ITS Architecture Open Roads Consulting Inc., 708 S. Battlefield Blvd., Chesapeake 23322, USA Barbara Skiffington, President: Steve Beckwith, Vice President COTS Corporate Summary

Product Brochure

Bijzonderheden

Product Description Sheets Bezoek stand op ITS America in Long Beach Open Roads Consulting Inc. bestaat ongeveer twee jaar en heeft zes mensen in vaste dienst. Het bedrijf heeft twee verkeersmanagementsystemen gerealiseerd in Richmond Smart Traffic Center en het Anaheim Traffic Management System.


C-28

OSI Software - PI system Real Time Information Infrastructure Categorie

SCADA

Functionaliteit

Het systeem verzamelt gegevens vanuit systemen op procesniveau, zoals wegkant stations. De gegevens worden verwerkt en geaggregeerd naar bruikbare informatie. Die vervolgens getoond kan worden in configureerbare interactieve presentaties op de gewenste plaats. Het systeem kan bijna ongelimiteerde hoeveelheden gegevens opslaan met de originele resolutie. Alhoewel het systeem voornamelijk gebruikt wordt in de procesindustrie, is het ook elders toe te passen, waar gegevens met een grote nauwkeurigheid dienen te worden beheerd COM Connectors, Maakt de koppeling buiten de database om mogelijk tussen modules van het PI systeem en andere 'enterprise systems' PI ActiveView, maakt 'PI ProcessBook' presentaties beschikbaar op internet. PI Advanced Computing Engine (PI ACE), Maakt het mogelijk om formules te definiëren, die kunnen worden toegepast op willekeurige datasets PI AlarmView, Maakt een samenvatting van de 'PI Alarm server' informatie en kan deze gegevens in een boomstructuur beschikbaar maken voor presentatie. PI BatchView, Presenteert 'PI Batch' gegevens op Windows desktop computers. PI ControlMonitor, Geeft de toestand weer van een proces besturings systeem en genereert een historisch overzicht PI DataAccess Package, Een toolset waarmee systeembeheerders gegevens in het PI systeem kunnen benaderen en manipuleren. PI DataLink, Een interface naar spreadsheet programma's PI DataStorage, Opslag van operationele procesgegevens. PI Interactive Configurable Environment, Maakt het mogelijk om interactieve configureerbare internet pagina's en portals te genereren. PI Interfaces, Creëert verbindingen naar gegevensbronnen waarmee met hoge snelheid gegevens ingewonnen kunnen worden. PI ManualLogger, Brengt op gecontroleerde wijze gegevens over van draagbare apparatuur naar het PI systeem. PI Module Database, Sorteert de gegevens van het PI Systeem in nuttige groepen en slaat parameters en specificaties op, zodat ze direct kunnen worden gebruikt in programma's en presentaties. PI ProcessBook, Een eenvoudig te gebruiken grafisch pakket, dat gebruikers in staat stelt om dynamische interactieve presentaties te creëren, waarin real-time PI Systeem gegevens getoond kunnen worden. PI ProcessTemplates, Maakt het voor gebruikers mogelijk om procesvariabelen te evalueren in achtereenvolgende perioden. PI ProfileView, Creëert een compacte presentatie van oppervlakte gegevens van "sheet products". PI Server Applications, Een set van verwerkings programma's die de gebruiker helpen om meer informatie uit zijn gegevens te krijgen PI Services, Ondersteuning ten behoeve van installatie en onderhoud PI System Management Tools, Een set applicaties om het PI Systeem mee te beheren vanaf cliënt PC's. RLINK, Een bidirectionele verbinding tussenhet PI systeem "enterprise resource planning" (ERP) pakketten, zoals SAP R/3 Sigmafine, Valideert de productie gegevensstroom en produceert consistente en betrouwbare gegevens. UniversaI Data Server, Wint gegevens in afkomstig van verspreide bronnen en routeert deze door de infrastructuur van het PI Systeem. Fungeert als basis van het PI Systeem, waarop de overige modulen van het PI Systeem kunnen worden aangebracht.

Modullen


C-29

Technische beschrijving Toepassing Leverancier

Status Bronnen

Bijzonderheden

MS Windows Scada OSI Software GmbH, Hauptstrasse 30, Altenstadt, 63674 Duitsland P.A. van Wordragen, sales executive COTS Rapport: PI Systems, Industrial Results, Samenvatting: PI System Plant Information System OSIsoft is in 1980 opgericht en heeft in een aantal jaren het PI Systeem ontwikkeld. Het hoofdkantoor staat in San Leandro, Califomia, USA. Naast vestigingen in Amerika en Nieuw Zeeland, is er een vestiging in Canada, Azië en Europa


C-30

Peek Traffic - Traffic Box Categorie Functionaliteit

Modullen


Toepassing

Leverancier


DVM totaaloplossing Traffic Box is een locaal processorstation (wegkantstation), dat gebruikt kan worden als onderdeel van een verkeers management systeem Het is een I/O besturingssysteem Voor elke sensor en actuator is een device driver beschikbaar, die de interface verzorgt tussen verkeerskundige applicaties in de Traffic Box en de op profibus aangesloten sensor of actuator. Er zijn momenteel twee device drivers en een applicatie voor de Traffic Box beschikbaar: • Traffic Box Sensor Service, waarmee sensor informatie of de hiervan afgeleide verkeerskundige informatie kan worden verkregen uit inductieve lusdetectoren. • Traffic Box Actuator Management System, waarmee LED matrix signaalgevers kunnen worden aangestuurd • Integrated Traffic Management System, een applicatie welke ondermeer filestaartbeveiligingkan realiseren. De Traffic Box is gebaseerd op een Motorola Power PC en is voorzien van een profibus en een TCP/IP Ethernet aansluiting. Elke device driver beschikt over een SNMP agent, waarmee remote maintenance kan worden gerealiseerd. De interface tussen de componenten is niet gebaseerd op Corba, omdat dit volgens Peek Traffic niet het gewenste real-time gedrag zou hebben. De Traffic Box wordt toegepast in een tunnel beveiligingsproject in Stockholm (Söderlanken). Peek Traffic B.V., Postbus 2542, 3800 GB Amersfoort Willem Hartman, Technical Sales Manager Frans van der Veer, Product Manager COTS Bedrijfsbezoek 7 maart 2002 Peek Trafic B.V., opgericht in 1990 is een middelgroot bedrijf dat zich met haar producten richt op diverse segmenten binnen de verkeersmarkt. Het bedrijf heeft zich gespecialiseerd in het ontwikkelen, leveren en onderhouden van hoogwaardige electronica- en software oplossingen ten behoeve van verkeer en vervoer problemen. Peek Traffic B.V. maakt onderdeel uit van het wereldwijde Peek concern met vestigingen binnen Europa, Azië en de Verenigde Staten van Amerika


C-31

Schneider-Electric - Modicon Ca.tegorie Functionaliteit

PLC (+ SCADA) Het Modicon programma bestaat uit een aantal PLC's en een SCADA pakket, die koppelbaar zijn via een open TCP/IP Ethernet verbinding. De PLC's zijn programmeerbaar op basis van IEC 61131.

Modullen

Voor onderhoudsdoeleinden zijn de PLC's uitgerust met een Web Embedded Server & Utility, waarmee van afstand onderhoud gepleegd kan worden met behulp van een verythin-dient in de vorm van een standaard web-brouwser. Modicon TSX Momentum, een familie van PLC besturingsmodules: I/O modules, processoren, communicatie adapters, waaruit een PLC kan worden samengesteld. Modicon Premium, rack mounted modulair PLC systeem. Modicon Quantum, high end rack mounted modulair PLC systeem.


Toepassing

Leverancier


Monitor Pro Version 7, Factory Link supervisory, control and data acquisition software system Communicatie op basis van TCP/IP Ethernet of veldbussen (o.a. Profibus, Modbus). energiedistributie, industrie, infrastructuur, utiliteit, verkeer en vervoer (scheepvaart:o.a. HMS Amsterdam, metro o.a. Rotterdam Erasmuslijn) Schneider-Electric, Waarderweg 40, Postbus 836, 20003 RV, Haarlem Winston Korsten, Account Manager business line industrial automation COTS Bezoek Schneider-Electric aan AVV Rotterdam, 31 mei 2002 Schneider-Electric is een in 1836 opgericht Frans bedrijf, dat nu dochterbedrijven heeft in elf landen. De voornaamste merken zijn Telemechanique, Merlin Gerin, Modicon en Square D. Het bedrijf levert producten en diensten voor vier kernmarkten: energiedistributie, industrie, infrastructuur en utiliteit. Modicon is voortgekomen uit Bedford Associates, dat in 1968 de eerste PLC voor MOdular Digital CONtrol op de markt bracht.


C-32

SES - Mercure Categorie Functionaliteit

Modullen

Actuator Management Systeem Mercure is een actuator en sensor management systeem in de verkeerscentrale. Vele typen actuatoren kunnen worden aangesloten, zoals DRIPs, matrix en prisma borden. Mercure heeft een grafische interface voor de wegverkeersleider met een geografisch beeld van aangesloten systemen. Beelden en tekst kunnen vanuit de centrale worden geconfigureerd. Mercure heeft ook functionaliteit voor storingsmelding. Sensoren en inwinsystemen van SIAT kunnen worden aangesloten en bediend. Er is een expert systeem ingebouwd voor regelscenario's. Meer informatie hierover ontbreekt. Ook kunnen cyclische gebeurtenissen, en geplande (weg)werkzaamheden in tijdsplannen voor actuator bediening worden gedefinieerd. Mercure is een systeem dat wordt ingepast in DVM systemen in verkeerscentrales, eventueel in combinatie met de SIAT producten voor inwinning van verkeerskundige data uit sensoren en monitoren. VMS: scherm, controller (= rack in SES teminologie) en behuizing. Central Unit: Front-end-processor met software modulen en PC in centrale Communication module: modem communicatie module tussen VMS en Central

Unit Technische beschrijving

Toepassing

Leverancier

Status Bronnen

Windows PC en OS. PCs kunnen stand-alone of in locaal of remote netwerken in de verkeerscentrale(s). De front-end PC in de verkeerscentrale kan op verschillende manieren communiceren met racks in het veld: modem, X25, ATM met protocollen NTCIP/SNMP, TEDI, NMCS2, BSC. Een actuator is gekoppeld via een LONWORKS netwerk verbinding met het rack (controller). Windows PC systemen, stand-alone of geïntegreerd in DVM systeem via netwerk in centrale, en remote PCs. Wordt toegepast in verkeerscentrales in Frankrijk, Hongarije, Maleisië, Autstralië, China en VS. Securite & Signalisation SES, 35-39 Ave. du Danemark, BP 7267, 37072 Tours Cedex 2, Frankrijk, fax +33-247542897, www.ses-signalisation.com Ms S. Pitou, Export Project Manager, tel +33-247626626, [email protected] Y. Lahary, Product Manager, [email protected] COTS • Product brochures van Mercure en SIAT

• Bijzonderheden

Intertraffic 2002.

SIAT is onderdeel van SES


C-33

Solari di Udine Categorie Functionaliteit

Modullen


Toepassing

Leverancier

Status Bronnen

Bijzonderheden

Actuator Management Systeem Het Solari systeem is een actuator management systeem, bestaande uit een PC met software in de verkeerscentrale en een wegkantsysteem met controller en LED matrix en grid displays. De verkeersleider kan direct actuatoren bedienen via de FEP. Actuator bedieningsopdrachten kunnen ook vanuit andere applicaties aan de FEP worden opgedragen. De displays zijn zowel voor tekst als voor grafische symbolen. Deze kunnen vanuit de centrale en lokaal gedefinieerd en beheert worden. Groepen van actuatoren zijn te definiëren voor secties van het wegennet. De FEP logt alle bedieningshandelingen en storingsmeldingen. Verkeerskundige en bedrijfsstatus van actuatoren kunnen opgevraagd worden. De FEP en display controller hebben functies voor diagnose en storingsmelding, voor o.a. stroomverbruik, communicatie problemen, functioneren per LED cluster, driver logic, interne temperatuur. De controller regelt ook de helderheid van de LED's in functie van omgevingscondities. Het actuator management software systeem op de FEP heeft geen productnaam maar wordt optioneel meegeleverd met de actuatoren. Front end processor: PC met software voor actuator management en communicatie in de verkeerscentrale. FEP logt bedieningshandelingen en storingen. Diagnostische functies zijn aan te roepen via de FEP. Message display: actuator hardware met communicatie en control unit. Volgende typen LED actuatoren zijn leverbaar: Alphanumeric Variable Message Displays, Graphic Variable Message Displays, Graphic Changeable Message Displays De FEP is een Windows PC, en kan zowel stand-alone als in een netwerk worden geintegreerd in een verkeerscentrale. De FEP is via maatwerk of http web-based interface aanspreekbaar voor andere DVM applicaties. Communicatie tussen FEP en actuator is via modem verbinding, seriële verbinding met ANSI Polling/Selecting, of glasvezel verbinding met SNMP en TCP/IP. Er zijn geen nationale DVM of ITS communicatie standaarden in Italië. De FEP gebruikt een eigen (eenvoudige) database, die te vervangen is door bijv. Oracle (dat is overkill voor alleen actuator management). De software is wel modulair opgezet maar gesloten (dus geen API). Solari levert wereldwijd LED, LCD, flap, CRT, en plasma display systemen voor DVM, maar ook voor informatie systemen op vliegvelden, stations. DVM systemen zijn geleverd in Italië, Frankrijk, Spanje en VS. Solari di Udine, Via Gino Pieri 29, Udine, 33100, Italië, fax +39-0432-480160, www.solari.it Alessio Beltrame, [email protected] Maurizio Salamon, Area Manager, tel +39-0432-4971, msalamon@£Q_krLit COTS • algemene product info op: www.solari.it • customer portal Solari levert ook Net2000, een control systeem met een gemeenschappelijke gedistribueerde architectuur die worden toegepast voor informatie systemen. Solari levert ook data collection terminals.


C-34

Transdyn Controls - Dynac-ATMS Categorie Functionaliteit

SCADA (/PLC) Voor verkeersmanagement toepassingen levert Transdyn het product: Dynac, een core (SCADA) product dat wordt aangepast aan de wensen van de gebruikers. Het aanpassen/uitbouwen kan zowel door Transdyn als door de (geautoriseerde) gebruiker gebeuren. Uitgangspuntvan het systeem zijn mimics (symbolische presentaties), zoals deze in de procesindustrie gebruikt worden. Daarnaast zijn er ook geografische kaarten (ERSI GIS). Derhalve zijn ze de enige die een weergave op rijstrook niveau hebben en niet op rijbaan of weg niveau zoals bij de andere Amerikaanse leveranciers. De mimics tonen wegdelen op diverse niveaus waarmee virtueel kan worden ingezoomd. Sterke punten zijn tevens: het gebruik van referentieplaatjes bij alle presentaties. Hiermee behoudt de operator de oriëntatie en kan snel worden geschakeld naar een andere locatie. De opbouw van presentaties in layers, waardoor de presentatie aangepast kan worden aan de taak. Het is een multi-operator product, met taakbeheer functionaliteit. Wel moet worden opgemerkt, dat ze een systeem geleverd hebben voor een verkeersgebied wat door drie centrales gemanaged werd, een situatie die min of meer vergelijkbaar is met de Nederlandse. De afbakening was hier echter vast omdat het een afbakening tussen verschillende instanties (twee staten en een locale autoriteit) betrof. Tevens werkten de drie centrales met hetzelfde systeem, in casu op dezelfde database, met een centraal systeembeheer.

Modullen

Technische beschrijving Toepassing

Leverancier


Het Dynac systeem bevat een brede range aan ondersteunende applicaties, naast de primaire operationele functies zijn er applicaties voor History (datalogging), System utilities (mail, session & system monitor), database configuration (definitie van tags en presentaties) en configuratie (devices, alarmen, on/disabling, response plans, road configuration) Transdyn ziet het gebruik van PLC's als oplossing voor ons wegkantsysteem. Hun voorkeur gaat dan uit naar Modicon, geleverd door Schneider-Electric. Zij passen deze systemen ook reeds toe in vergelijkbare industriële situaties. Omdat zij werken met SCADA technologie, vormt de interface tussen het Dynac systeem en PLC's geen enkel probleem en voor Modicon hebben ze deze dus al. Windows NT Verkeersmanagement Industrie Transdyn Controls, 2855 Premiere Pkwy, Ste F, Duluth GA, 30097, USA Clive Gillon, Business Development Manager COTS Bezoek stand op ITS America in Long Beach Transdyn is systeemleverancier en een aannemer van speciale 'turnkey' constructie projecten. Het producten en diensten pakket van Transdyn omvat ondermeer software, apparatuur selectie en levering, ontwerp, constructie, systeem integratie, project management, installatie, training en onderhoud. Transdyn is een van de marktleiders op het gebied van geavanceerde computer besturings- en communicatiesystemen op het gebied van watervoorziening, riolering, transport, energie voorziening en industrie.


C-35

Trimation - Cimplicity Categorie Functionaliteit

Modullen




SCADA (+PLC) CIMPLICITY HMI biedt complete oplossingen voor besturings- en controletaken, zoals real-time-besturing en -bewaking van productieprocessen of energiemanagement. Cimplicity is er in drie uitvoeringen: • Plant edition • Machine edition • Manager System Log Review : Met de System Log Review (SLR) kunnen gelogde historische alarm data bekeken worden in een soort van alarm-viewer. Alarm Printer + : Met de Alarm Printer + is het mogelijk om te printen naar verschillende LPT poorten, netwerkprinters of log-files Dynamic Graphic Review : De Dynamic Graphic Review (DGR) module maakt het mogelijk om historische data af te spelen in CIMPLICITY schermen. Operator Trending : De Operator Trending module wordt gebruikt voor RealTime Data Trending. De operator wordt hiermee in staat gesteld om tot 16 lijnen verdeeld over 4 grafieken te tonen. MSDE-viewer: De MSDE-viewer is een tooi waarmee de data in MSDE- of SQL-database kan worden bekeken. Tevens is het mogelijk om met de MSDEviewer databases, tabellen of gebruikers aan te maken en eventueel te verwijderen. De software is ontwikkeld op een 32-bit-platform voor het besturingssysteem Windows (95, 98 en NT). GE Fanuc werkt nauw samen met Microsoft. Dit resulteert in productkenmerken als ODBC, OPC, ActiveX, OLE, COM etc. en de daarop gebaseerde open communicatie met de meeste PLC's van andere fabrikanten. SCADA GE Fanuc Automation, Minervum 1603a, Postbus 7230 4800 GE Breda Ad van de Noort, Sales Manager Belgium & Netherlands Trimation, Gilzeweg 2, Postbus 28 4860 AA Chaam Angel Schneiderberg, sales engineer COTS Bezoek door GE Fanuc en Trimation aan AVV, 6 juni 2002 GE Fanuc Automation is een wereldwijde leverancier van geautomatiseerde besturingssystemen. GE Fanuc is een joint-venture tussen General Electric (50%) en Fanuc (50%). GE Fanuc/Fanuc is marktleider op het gebied van CNC (Computer Numerical Controls) ten behoeve van machine automatisering Trimation was voorheen zelfstandig SCADA leverancier en is nu onderdeel van het GE conglomeraat als het GE Fanuc Scada/PLC Competence Centre


C-36

Trinité Automatisering - Programmable Distributed Architecture (PDA) Categorie Functionaliteit

Modulen


Toepassing

Leverancier

Status Bronnen

Bijzonderheden

DVM totaaloplossing PDA is Trinité's structurele oplossing voor het opzetten van gedistribueerde, real-time architecturen die bestaan uit een combinatie van monitoren, sturen en managen. Denk hierbij aan Dynamisch Bus Stations, Meetnetten, Verkeerskundige architecturen, en Coordinated Plant Control. Dynamic Subscription Software (DSS) vormt de middleware. Het creëert een virtuele real-time datapool over systeemgrenzen heen. Applicaties kunnen, eenmaal gekoppeld aan deze datapool, zich abonneren op informatie van andere poolmembers of zelf informatie klaarzetten voor derden. Informatie in DSS is in de vorm van InformatieElementen (lE'en). Integral Management Concept (IMC) is de motor van PDA. Met behulp van dynamische"en on-line aan de architectuur toe te voegen "Controls" beschikt de gebruiker over een krachtig stuk gereedschap voor het aanbrengen van nieuwe (abstracte) architectuurlagen, besturingen, filters, e.d. Het IMC is gebaseerd op Programmeerbare lE'en (PIE'en). Elke PIE kan drie programma's hebben: SET, UPDATE en TIME. Direct na het activeren is de eventuele uitvoer van een "Control" beschikbaar voor iedereen in het netwerk. Ook sensoren en actuatoren zijn in essentie "Controls" en kunnen dus voorzien worden van extra business-logic. Het inbrengen van diverse scenario's is met PDA gereduceerd tot configuratie van "Controls". V-TRIS is een programmeerbare visualisatie tooi voor het presenteren van informatie uit de DSS-datapool. Met behulp van V-TRIS kunnen gebruikers informatie op een overzichtelijke wijze presenteren. Configuration Builder is een definitie, configuratie en ontwikkel tooi voor een PDA-omgeving. Platforms: Uitsluitend Unix/Linux; ontworpen in C++, Qt, Oracle, en Java Interfaces: direct interfacing, door middel van maatwerk "bridges". Bridges worden geleverd door Trinité op fixed-price basis. Protocollen: eigen CORBA: "beslist niet" XML: nee SMS functionaliteit: Ja, door middel van definiëren van PIE'en (maatwerk) AMS functionaliteit: Ja, door middel van definiëren van PIE'en (maatwerk) Soort BL: Programmeerbare Informatie Elementen (PIE'en), d.w.z. active objects, beperkt tot SET, UPDATE en TIME. GIS in PL: Ja, eigen GIS-achtig functionaliteit (VTRIS) SUT-beheer. Nee Additionele functionaliteit: Geen Maatwerk "bridges" naar wegkantapparatuur Geen toepassing buiten DVM. Trinité Automatisering B.V., Nijverheidsweg 23-H, NL-3641 RN Mijdrecht, Nederland, Tel: +31 (0)297 287949, Fax: +31 (0)297 273049, [email protected]. http://www.trinite.nl Erik Hooft, Office-manager Frank Ottenhof, Product Manager COTS - PDA is nog in ontwikkeling Flyers voor PDA, DSS, ELTRIS, V-TRIS, en Open DRIP Architectuur (ODA). Beeld, systeemarchitectuur verkeerscentrale Noord Holland "De Wijde Blik" • Presentatie over PDA (PDF). Bijv. opmerkingen over bedrijfsgrootte/stabiliteit: • Firma heeft 12 medewerkers Andere gerelateerde producten van leverancier (TIAV, BOSS): • ELTRIS (onderdeel van V-TRIS geworden?)


C-37

• •

ODA (opgenomen in PDA) TRISLINE (nu PDA)

Referentie gebruikers: • Rijkswaterstaat Directie Noord-Holiand : Verkeerscentrale Noord-Holiand de Wijde Blik • Provincie Noord-Holiand, Gemeente Alkmaar: Pilot Alkmaar


C-38

Variable Message Signs - TRAffic Management System (TRAMS) Categorie Functionaliteit

Modullen


Toepassing

Leverancier

Status

Bronnen Bijzonderheden

Actuator Management Systeem TRAMS is een DVM monitoring en control software systeem. TRAMS ontvangt verkeerskundige informatie van sensoren of van het MIDAS systeem (Motorway Incident Detection and Automatic Signalling) en presenteert deze info grafisch. De WvL kan actuatoren aansturen vanuit TRAMS. De WvL kan ook tijdplannen maken om data in te winnen en/of actuatoren automatisch aan te sturen. VMS, kantelwalsen en matrix borden kunnen worden aangestuurd. Sensoren en actuatoren van andere leveranciers kunnen ook worden gekoppeld met TRAMS. Statische overzichten kunnen (met MS Excel) worden gegenereert. Er is wel user authorisatie en sessie beheer, maar er is geen taakbeheer. TRAMS heeft basis logica in de verkeerscentrale voor priorisering van actuator bedieningscommando's . TRAMS SW is OO, maar er worden geen specifieke SW modulen publiek bereikbaar gemaakt, wel HW modulen. GUI: Grafische gebruikersinterface op TRAMS (LCC) in centrale LCC Local Communications Controler: soort FEP en server voor TRAMS Transponder: server in het veld voor communicatie met outstations en actuator devices. SNMP MIB: Management Information Base voor TRAMS en voor VMS control Andere (COTS) producten die als modullen aan TRAMS worden gekoppeld: MIDAS: is feitelijk geen onderdeel van TRAMS, maar wordt wel gekoppeld als wegkant systeem voor inwinning en incident detectie. VMS: LED matrix en DRIPs systemen voor tekst en symbolen op basis van de RIGEL technologie. Bestaat uit een SNMP communicatie naar de Highways Agency NMCS2 protocol converter, een MIB voor VMS control, en de VMS driver. MS Access database Windows PC met MS Access database. SW ontwikkelt in Borland C, C++. NMCS2 communicatie naar actuatoren. Radio, telefoon of RS485 verbindingen. NTCIP compiiant. NMCS2 wordt uitgebreid tot UTMC. TCP/IP en UDP, en SNMP worden ontwikkeld (sept 2002). TRAMS wordt naast stedelijk DVM (parkeren) ook op beperkte schaal voor lokaal en regionaal snelwegverkeersmanagement toegepast. Voorbeelden zijn DRIPs voor wegafsluitingen en omleidingen, objectbeheer (brug) en waarschuwingssystemen voor weersonstandigheden in de UK. Voor DVM op nationale schaal (zoals gevraagd in SL questionnaires) zullen herzieningen nodig zijn aan de software en communicatie. Variable Message Signs Limited., 227 Kingsway, TVTE, Gateshead, Tyne & Wear, NE11 OQJ , UK, www.vmslimited.co.uk, fax +44 191 2023 405 John Raffle, Sales Manager, tel +44 191 2023 248, [email protected]. Mark Johnson, Product Manager TRAMS. David R. Hargreaves, SW engineer, +44 191 2023 444, [email protected] COTS producten. UTMC en SNMP compliance zijn nog in prototype stadium en worden in 2002 opgeleverd. www.vmslimited.co.uk VMS UK Ltd is een dochter van Rolls Royce pie. TRAMS wordt ontwikkeld in en over projecten heen, op basis van een eigen architectuur en kern van software modulen.


C-39

Bijlage D

Questionnaires

Market Survey of Traffic Management Components Longlist Questionnaire

D1 Begeleidende brief, 18 March 2002 D2 M A T C H - M a r k e t Survey of Traffic Management Components D3 Questionnaire

D2 D4 D18

Shortlist Questionnaire D4 Product Compliancy Questionnaire D5 ACT Compliancy Questionnaire


D-1

D21 D26

To

(See covering email)

Bijlage D1

Contact

Telephone

[email protected]

+31 10 282 51 75

Date

Endosure(s)

18 March 2002

2

Our reference

Your reference

IBI02-693/TJG

-

Subject

Projectcode

Market survey of traffic management software components

112001.023

Dear sir/madam, Later this year the Ministry will be purchasing Commercial Off-The-Shelf (COTS) software products for modernisation of the Dutch motorway control system. We would appreciate your help in obtaining information on the availability of suitable products. The Dutch motorway network suffers from congestion, particularly in the morning and evening rush-hours. Although extensive investment has resulted in a comprehensive and effective road-traffic control system, the Ministry is looking ahead to the next generation. In particular, the Ministry has developed an integrated architecture - known by its Dutch title "Architectuur voor Verkeersbeheersing" (AVB) - that encompasses all parts of the control system, from sensors and associated road-side installations, through the Communications network, to the regional and national control centres, and back to the motorway displays and actuators. AVB development has adopted the component-based approach. A component is defined as an existing piece of software with well-defined behaviour and well-defined interfaces that can be (re-)used in a variety of applications. We have now reached the stage where we are surveying the market for suitable COTS products that could implement the following groups of software components for the Application Architecture (AA) layer of AVB: • Sensor Management System (SMS); • Application Control (AC); and • Actuator Management System (AMS). Our aim is to obtain insight into the availability and applicability of products on the market for implementing the AVB Application Architecture. We expectto


D-2

have compiled a long-list by the end of this month (March 2002) and a shortlist by the end of April 2002. The short-list will be the basis for selection and procurement. For this reason, potential suppliers will benefit from collaborating in our market survey. The attachments to this letter give more details about dynamic road-traffic management in The Netherlands, about the AVB, and about the SMS, AC and AMS groups of software components withïn the AA layer. If you have one or more COTS products that you believe may be a suitable candidate for implementing one or more of the components within the SMS, AC, and/or AMS, piease complete the attached questionnaire and return it to us, preferably by email ([email protected]). Candidates are not limited to software developed for road-traffic control purposes. We expect that software developed for other control systems (e.g. spacecraft mission control systems, military Command & Control systems, energy distribution control systems, industrial and process control systems, and real-time telecommunications network management systems) may equally well be suitable candidates. Candidate products may also be found as modules or subsystems of a larger control system, or they may be a combination of software and hardware (e.g. sensors and actuators). If you do not have any COTS products to offer but know of other organisations you can recommend, then piease inform us by email ([email protected]). I am grateful for the time you spend in reading and replying to this letter. Piease feel free to contact my team, preferably by email ([email protected]) or telephone (Ronald Moerman for SMS (+31 10 282 51 75), Tim Grant for AC (+31 10 282 51 76), and Bart Netten for AMS (+31 10 282 51 77) 1 ), if you have any questions about the market survey or the information in this letter and its attachments, or if you need any assistance in completing the questionnaire. Yours sincerely,

Ir. E.J. van de Kaa Deputy Head of AVV Transport Research Centre On behalf of THE MINISTER OF TRANSPORT, PUBLIC WORKS AND WATER MANAGEMENT

1

Monday to Friday between 09:00 and 16:00, European time. Piease allow for time-zone

differences, where applicable.


D-3

MATCH - Bijlage D2 Market Survey of Traffic Management Components


D-4

1

Background 1.1 Mobility The smooth flow of road traffic is important to the national economy and for safety. Over the past few decades there has been an explosive growth in roadtraffic demand in The Netherlands, especially on the motorways. This trend is expected to continue for the foreseeable future. Since the motorway network has a limited capacity, this means that congestion is growing still faster. This has adverse effects for the Dutch and European economies and for road-safety. 1.2 Dynamic Traffic Management Congestion can be eased by improved use of the available road network. One way of increasing efficiency is by better management of the traffic flow in realtime. For this reason, dynamic traffic management - "Dynamisch Verkeersmanagement" (DVM) in Dutch - is increasingly important to society. Automated systems are essential to DVM, for monitoring traffic streams in realtime, for controlling traffic lights, road barriers, ramp metering, variable speed limit and message displays above and beside the motorway, and in the regional and national control centres. Many systems have been introduced on the Dutch motorway network, with each system supporting one or more traffic-control measures. Examples include fog- and mist-warning, ramp-metering, and icewarning systems. Within The Netherlands, the Ministry of Transport, Public Works and Water Management is responsible for road-traffic management. During the past 20 years or more, the Ministry has introduced a variety of road-traffic control systems. Each one has been developed independently from the others, often to meet requirements that are specific to the Dutch motorway network. These systems overlap in function and employ a great diversity of computer and Communications technologies, many of which are outdated. If they are linked to one another, the inter-system interfaces are unique and opaque. Road-traffic controllers must contend with disparate control-room displays and controls, making it difficult to gain a coherent picture of the current situation on the motorway network. Maintenance of the existing systems and the addition of new functions is severely limited by the variety of technologies employed. In short, experience has shown that the existing approach to developing, installing and maintaining road-traffic control systems results in the following problems: • There is a lack of integration between systems, leading to a growing maintenance problem. • The cost of inserting new functionality in existing systems remains extremely high. • It is difficult to exploit the full potential of new technologies in system development. • Too little use is made of existing products and of developments outside the Netherlands. • The technical infrastructure for the existing Dutch road-traffic control system is outdated. • Despite common boundaries with other European countries, there has been no structural agreement on cross-border interoperability.


D-5

1.3 The AVB Architecture The Ministry's architecture for traffic management - Architectuur voor Verkeersbeheersing (AVB) in Dutch - is the first step towards solving these problems. Derived from the European Intelligent Transportation System (ITS) framework architecture, Keystone Architecture Required for European Networks (KAREN), AVB provides a conceptual framework for designing future road-traffic control systems. The architecture is built up in layers and, within each layer, of components2. The component-based approach enables the separation of policy from execution and of function from technology. It also lays a simple basis for adding new traffic-control measures and for applying new technologies with minimal change to the rest of the road-traffic control system. As shown in Figure 1, there are five layers in the AVB architecture: • Traffic Management Architecture. The Traffic Management Architecture (TMA) - Verkeerskundige Architectuur (VA) in Dutch - is a business process layer, and does not include any software or hardware. It is concerned with the professional and operational aspects of road-traffic control, including the operational concept adopted in The Netherlands, the control strategies and tactics, the standard operating procedures, and the measures that the road-traffic controllers can put in place to influence traffic flows. • Application Architecture (AA). Applications software is found in the AA. It includes real-time, on-line applications for sensing and assessing the road-traffic situation, for selecting the appropriate control measures (including decision-support to the operator), and for executing the necessary actions to put the selected measures into effect. These applications may be distributed between the control centres and the road-side systems. In addition, the AA includes off-line applications for maintaining the on-line functionality. • Technical Infrastructure Architecture (TIAV). The TIAV covers the underlying, generic software and hardware services needed to deploy and distribute the AA components over the control network, nationwide. Notably, this includes the middleware and database services ("software bus"), the universal workstations beside the motorways ("UWKS") and workstations and servers in the control centres ("UBP" and "USP", respectively), and the telecommunications network ("VicNet"). • Information Architecture (IA). The IA provides the AVB-wide data model, together with data definitions. Importantly, the IA complies with international standards, e.g. for modelling a motorway network, for determining the geographical position of parts of the control system (e.g. sensors and actuators) and vehicles, and for describing road-traffic situations. • Organisational Architecture (OA). The OA defines the organisational and business processes needed (largely within the Ministry) to operate and manage road-traffic control in The Netherlands.

2

A component is defined as a piece of software with well-defined behaviour and well-defined

interfaces that can be (re-)used in a variety of applications.


D-6

Organisation Architecture (<

Figure 1. Overview of AVB architecture.

In AVB, the components are the building blocks out of which a road-traffic control system can be constructed. A control system is implemented by selecting components from a component library, configuring, instantiating and linking them together, and then deploying them over a geographicallydistributed network of underlying hardware, software and Communications services. This component-based approach to control system development implies a shift from software design and programming towards the assembly and parameterisation of components. Most importantly, it opens up the possibility for the procuring components as COTS software products, as well as the traditional design and programming of tailor-made software.


D-7

2

The MATCH project In the MATCH project, our aim is to obtain insight into the availability and applicability of products on the market for implementing the AVB Application Architecture (AA). The scope of the MATCH project is restricted to the AA, as indicated by the red dashed box in Figure 1. In practice, we recognise that some COTS3 products may combine AA components with underlying hardware and software from the TIAV (e.g. sensors and/or actuators). We are looking for products based upon one of the following three approaches: • Components compliant with the AVB Application Architecture. This means that all components must be able to exchange information with other components in real-time using CORBA 2.3. • Products compliant with Intelligent Transportation System (ITS) interface standards like NTCIP, UTMC, and OCIT; • General-purpose (industrial or otherwise) products, based upon open interfacing standards.

Traffic Controllers"

Maintainers

1 1 Application Control Sensor Management System

Actuator Management System

I

t

Sensors

Actuators

Figure 2. Overview of AA component groups. There are three groups of AA components (see Figure 2): • Sensor Management System (SMS). This component-group represents and manages the road-side sensors. • Application Control (AC). This component-group displays information to users, and manages users, sessions, traffic-control tasks, traffic scenarios, and traffic-control measures. • Actuator Management System (AMS). This component-group represents and manages the road-side actuators. Readers should not assume that the component-groups are deployed either in control centres or in road-side workstations. For example, an AC component can run on a UWKS, as well as UBPs and USPs. Similarly, an SMS or AMS component can run on a UBP or USP, as well as on UWKSs. Each component-group is described in more detail in the following chapters.

1


Commercial Off-The-Shelf, i.e. a product that is available on the commercial market.

D-8

3

Sensor Management System (SMS) The purpose of the "MATCH-SMS" project is to obtain information about the availability and the applicability of COTS products for: • The interface between road-side sensors and the regional and national control centres. • The (remote) management and control of sensors and their interfaces for maintenance purposes. • The combination of measurement values from a single sensor or from a group of different sensors, at a certain moment in time or over a period of time. 3.1 Sensor management components A traffic monitoring and control system requires input data about traffic and weather conditions so as to be able to present the traffic situation to operators and to control traffic via e.g. variable message signs. The required input data is provided by the Sensor Management (sub)System. The general term sensor is used to identify all traffic and other sensors, transducers and input systems from which a traffic controller receives input to manage traffic. The main purpose of the Sensor Management System (SMS) is to manage sensors. This includes: installation, configuration, interfacing, pre-processing, transformation of technical measurement data into traffic information, integration or accumulation of information from a combination of different sensors, detection of malfunctioning and support of remote preventive and curative maintenance and modifications. The tasks of the Sensor Management System are: • To provide traffic data that enables traffic monitoring and control, such as: Sensor measurement value(s), derived values and operational sensor state and traffic alarms/warnings; • To enable operation of controllable sensors such as video cameras by remote traffic control operators; • To enable remote maintenance, such as the configuration of sensor parameters and the generation of sensor alarms/warnings. 3.1.1 Traffic data information requirements •

•

•

SMS components have built-in self-monitoring capabilities to detect anomalies in their health state condition, such as faults and failures in hardware, software, communication, and traffic signalling. Sensor information can be provided automatically or immediately upon request from (remote) traffic control centres. Health state information can be provided automatically or immediately upon request from (remote) traffic control centres. Measures for graceful degradation of SMS software components in case of anomalies.

3.1.2 Sensor operation requirements •


Controllable sensors can be operated in real time from (remote) traffic control centres.

D-9

3.1.3 Remote maintenance requirements The following properties of an SMS can be configured: • Parameter settings for hardware and communication. • Geometrical location and topological position of sensors. • SMS can be configured locaJIy from road-side stations and/or remotely from traffic control centres. • SMS can be reconfigured without modifying the hardware or software of the SMS. • SMS should be maintainable and extendable for new types of sensors.


D-10

4

Application Control (AC) This chapter describes the AC components sought. Expected readers are the potential suppliers of COTS software products that could be used to implement one or more of the AC components. The purpose of the AC group of components is to present information to users and to manage users, sessions, traffic-control tasks, traffic scenarios, and traffic-control measures. The AC components are divided into four groups: • Component(s) for presenting information to users. • Components for managing of users, sessions, traffic-control tasks. • Components for managing traffic-control scenarios and measures. • A component for managing fault reports. In the Netherlands, there are some four regional control centres, one national control centre, and several smaller control centres for monitoring and controlling major infrastructure objects, such as bridges and tunnels. The control centres operate 24 hours per day, 365 days per year. In a typical control centre there are between 5 to 13 traffic controllers, working in shifts. Each controller - wegverkeersleider (WVL) in Dutch - uses a workstation consisting of a video-wall, a range of Communications facilities, and up to 4 computer terminals. Each controller is assigned one or more traffic-control tasks within a geographical region of The Netherlands. Tasks include the monitoring and control of: • One or more major infrastructure objects. • One or more motorways. • Audio and/or video communication facilities. The particular set of tasks that a controller is working on varies according to the time of day, the day of the week, and the current traffic situation. In addition, there are maintainer-users, who work weekdays. Each maintainerbeheerder in Dutch - is assigned one or more maintenance-control tasks, covering the maintenance of: • Elements of the traffic-control system itself, both hardware and software. This covers maintenance of the traffic-control system configuration and the solution of failures reported in the traffic-control system. • Administration of traffic-control system users, sessions and tasks. 4.1 Presentation component(s) The Presentation component(s) enable the users to view information from and to issue instructions to the traffic-control system. Data processing specific to traffic control and user decision support is excluded. The component(s) must be functionally capable of: • Displaying video information. • Sounding audio information. • Defining, loading and displaying geographical information relating to road-traffic control (and specifically a road-traffic network) in the form of maps and schematics. • Overlaying information on the maps and schematics. Possibie examples of the information to be overlaid include the average speed and intensity of traffic, the motorway lanes closed for repair, the current state of stop-lights and matrix boards, the current location of


D-11

•

• • •

• •

emergency vehicles, and so on. The Presentation component(s) must provide an overlay facility and a set of libraries of symbols for this purpose. Displaying standard user-interface objects such as windows, panes, menus, task-bars, list-boxes, buttons, icons, radio-boxes, check-boxes, input fields, slider-bars, etc, as well as user-defined user-interface objects. Defining new user-interface objects for addition to one or more libraries of user-interface objects. Displaying around 4000 user-interface objects whose attributes may be updated every 4 seconds. Allowing the user to define and modify the allocation of user-interface windows to the video-wall or specific computer screens or specific locations on a computer screen on his/her workstation. The allocation may be user- and task-dependent, and there may be restrictions on specific layouts. For example, to maintain situation awareness the traffic controllers may not be allowed to close or cover up any window(s) showing the current traffic situation. Allowing the user to save and retrieve defined/modified user-interface window allocations. Allowing the user to manipulate user-interface elements using a variety of means, including command-line interface(s) and direct manipulation of the geographical and schematic displays.

The Presentation component(s) must be capable of handling geographical data in GDF format, intersection locations using the ILOC standard, and geographical location references according to the BPS standard. In developing AVB, the Presentation sub-layer has not been detailed into components. Potential suppliers are free to propose COTS software products that provide a subset of the functionality sought, as well as those that provide the full Presentation functionality (or even a superset of the Presentation functionality). 4.2 User-, session- and task-management components During shift-changes in the control centres, the set of tasks allocated to each off-going traffic controller will be handed over to a colleague on the on-coming shift. This hand-over usually takes place without the off-going user first having to close down the running tasks before they can be restarted for the new user. There are some tasks that must not be closed down. Similarly, if during the course of a shift a controller's workload becomes excessive (e.g. because an accident has occurred), it must be possible for one or more tasks allocated to that controller to be handed over to another controller. Task management consists of the functions necessary for defining types of tasks and for selecting, starting, handing over, and closing down tasks. Before a task can be started or handed over, a check must be made that the intended user is a member of a user-group with the necessary authorisation for running that task. User management consists of the functions necessary to define and maintain user-groups and users and to allocate users to user-groups. Session management consists of logging users in and out of the traffic-control system and of checking that the users' actions are authorised ones.


D-12

Related scenarios include: • Logging in. One of the computers in each workstation provides a standard facility for users to log in. Security is by means of user-names, user-groups and passwords. The session management components check the validity of the login details. If no other user is already logged in to that workstation, then a list of tasks for which the user is authorised is presented. The task-list will be dependent on the user's user-group. If another user is already logged in to that workstation, then the session management components perform a workstation hand-over, as described below. •

•

•

•

•


Logging out. One of the computers in each workstation provides a standard facility for users to log out. The user may only log out if he/she has no tasks running. Some tasks cannot be closed, but can only be handed over to another user. Tasks can only be closed if there are no running task-actions that must be completed. Task request. One of the computers in each workstation provides a standard facility for users to view the list of tasks for which the user is authorised. The list will show whether or not the task is running, to whom (if anyone) it is allocated, and, if so, on which workstation it is running, whether it is exclusive, and whether the user is monitoring the task or also controlling it. The user can select a task, obtain details of the selected task, and - if the task is not running - start it. On starting a task, the user is given the option of presenting the task information according to a pre-defined screen layout, or of allocating the task window to a specific screen on the workstation. He/she will also be asked whether he/she wants just to monitor the task-related information or also to control the objects relating to the task (i.e. to be able to change their state). If the task is exclusive (i.e. it can only be controlled by one user at a time) and under the control of another user, then a task hand-over (see beiow) will be initiated. Task closure. One of the windows relating to a running task provides a standard facility for users to close the task down. When the user requests a task to be closed down, the session management components check if the task is of a type that must be kept running continuously or if there are running task-actions that still must be completed. If not, the task is closed down, and all windows summarising the task status are updated. Otherwise, the session management components refuse the user's request, giving an explanation. Task hand-over. A user may attempt to take over a running task from another user or to hand over a running task to another logged-in user. When a user attempts to take over a running task, the existing user of that task receives a message asking if he/she accepts the take-over request. If he/she accepts the request, then a new task is started by the user making the request. To avoid deadlocks, the existing task is only closed down when the new task has been successfully started. The list of tasks on all workstations is updated. If the existing user refuses the take-over request, then the situation remains as it was. Handing over running tasks is equivalent, with the users' roles exchanged. Workstation hand-over. A workstation can be handed over to another user without first closing down all running tasks, e.g. for shift changes. When the new user logs in, then the session management components perform user validation as for a normal login. If validation succeeds, then all running tasks are handed over to the newly logged-in user.

D-13

When this is successfully completed, the previous user is automatically logged out. 4.3 Traffic-control scenario- and measure-management components The operational concept of traffic-control management in The Netherlands is based on implementing traffic-control strategies and tactics in the form of scenarios ("regelscenario's") and control measures ("maatregelen"). A scenario can be regarded as an IF-THEN rule that expresses a set of possible ways in which the traffic situation can develop over a period of time (typically a day) in a particular region. The complete plan for the day (an "Integrated Scenario") consists of a set of such scenarios. When a scenario is activated, the branching conditions on the IF-side of the rule (the "script") are matched to the actual traffic situation, obtained from the Sensor Management System. If the IF-side is matched, then the THEN-side of the rule determines the appropriate traffic-control measures to be executed and triggers them. The measures are then instantiated according to the actual traffic situation and implemented by issuing a series of requests to the road-side actuators via the Actuator Management System. An example is the implementation of lane closure when a vehicle is stranded on the motorway4. Vehicle detection sensors at the road-side would warn the traffic controller in the regional control centre if a group of vehicles stop on the motorway. By using a TV camera or on the receipt of a telephone message from driver(s), the traffic controller is able to determine that the stoppage is the result of a vehicle becoming stranded (and not merely a traffic jam). Since such a stoppage is a recurring event, a suitable scenario will have been activated. Part of its IF-side conditions will match the situation on the affected segment of the motorway. The THEN-side will then trigger the appropriate traffic-control measure to close off the lane in which the vehicle is stranded. The traffic will be diverted afew hundred metres upstream of the closed-off lane-segment, and the lane a few hundred metres downstream will be opened up again. The lane closure and traffic diversion is effected by sending instructions to the appropriate matrix signs over the motorway to display suitable messages to drivers. When the motorway assistance services have removed the stranded vehicle, they inform the traffic controller. The actual situation no longer matches the IF-side conditions of the scenario, leading to the traffic-control measure being withdrawn. The lane closure and traffic diversion instructions are withdrawn, and the matrix signs are switched off, allowing drivers to use the whole lane once more. The traffic-control scenario- and measure-management components must be capable of: • Modelling traffic situations in a form equivalent to IF-THEN rules. • Modelling a sequence of instructions to road-side actuators to implement a traffic-control measure. • Defining, configuring, and instantiating traffic-control scenarios and measures. • Assembling configured and instantiated scenarios and measures into an Integrated Scenario for defined geographical regions and timeperiods. • Starting (activating) and stopping (deactivating) the script.

4


For clarity, this example is simplified.

D-14

•

•

On activation, configuring the traffic-control scenario and associated control measures using parameters obtained from the configuration database. While activated: • Obtaining data representing the current traffic situation from the Sensor Management System. • Matching the data representing the current traffic situation against the script of branching conditions. • Triggering the appropriate traffic-control measures when the script matches the current traffic situation. • When triggered, issuing a sequence of requests to the Actuator Management System. • When de-triggered, withdrawing the previously-issued sequence of requests to the Actuator Management System.

4.4 Fault management component Traffic-control systems are distributed systems with many components and physical connections. The chance of faults arising is high, not least as the result of road-side maintenance activities. A Fault Management component has been introduced to manage fault reporting. All AVB components will have the ability to detect and report faults to the Fault Management component. The Fault Management component must be functionally capable of: • Registering fault reports. It should be possible to raise fault reports automatically or manually. Fault reports will be registered centrally to enable an overview to be maintained of the condition of the trafficcontrol system. Registration includes the functionality for displaying and prioritising fault reports and for allocating responsibilities for their resolution. • Distributing fault reports. The traffic controllers and the maintainer are informed about the progress in resolving faults in the system. This will include help-desk functionality. • Closing fault reports. Components can subscribe automatically to fault reports raised by other components. The desired behaviour of the components that receive fault reports is configurable by the trafficcontrol system maintainers. When a fault is resolved, the fault closure reports are registered centrally and distributed to the subscribers. Maintenance functionality, such as deployment, resource management, starting, stopping, testing, and configuration of components, is outside the scope of the Fault Management component. The capability of importing and exporting information to/from products such as HP/OpenView is desirable.


D-15

5

Actuator Management Systems (AMS) A traffic controller's means to affect traffic is through traffic signs or signalling installations such as matrix panels, warning lights, dynamic route information panels, or ramp metering installations. The general term actuator is used to identify all traffic signs and signalling installations with which a traffic controller can act to manage traffic. 5.1

Actuator management component

The main purpose of the Actuator Management System (AMS) is to manage, control, and configure actuators from application control (AC). An AMS invokes the measures taken by traffic controllers and traffic control systems for dynamic traffic management. An AMS also enables the actuators and actuator control systems to be configured and managed. 5.1.1 Traffic Management Functionality •

• •

The AMS enables real-time control of traffic actuators from national, regional and local traffic control centres, as well as from road-side stations. Actuators can be controlled automatically and manually. The current status of actuators can be requested immediately for presentation to traffic control.

5.1.2 Configuration Management •

• • • •

The following properties of an AMS can be configured: • Parameter settings for hardware and communication. • Geometrical location and topological position of actuators. • Definition and configuration of the traffic signs and signals of actuators, such as the images and text on matrix or grid screens and the location of these signals on the screens. • Traffic management states relating to the traffic signs and signals of actuators. AMS can be configured locally from road-side stations and/or remotely from traffic control centres. AMS can be reconfigured without modifying the hardware or software of the AMS. Configuration settings can be stored in local databases and in central databases on a network. AMS should be maintainable and extendable for new types of actuator systems, components, and signals.

5.1.3 System Management • •

•


Actuator signalling events should be logged locally and/or centrally and in real time. AMS components have built-in self-monitoring capabilities to detect anomalies in their health state condition, such as faults and failures in hardware, software, communication, and traffic signalling. Faults and failures should be dassified in levels of severity; e.g. fatal and non-fatal.

D-16

Anomalies should be reported immediately to traffic control. Anomalies should also be logged locally and/or centrally and in real time. Health state information can be provided immediately upon request from (remote) traffic control centres. Statistics on, and histories of health state, anomalies, and signalling events can be provided immediately upon request from (remote) traffic control centres. Generate summaries of signs and anomalies over specific periods of time on request for reliability analyses. Measures for graceful degradation of AMS software components in case of anomalies. Measures for handling multiple and potentially conflicting requests for actuator activation. Software components can be run and moved to any computing platform in the network; e.g. AMS components can be run locally on a road-side station as well as at a traffic control centre.


D-17

MATCH - Bijlage D3 Market Survey of Traffic Management Components Questionnaire


D-18

Questionnaire When you have filled in this questionnaire, piease e-mail it together with any product flyers/brochures (in zip-file) to: [email protected] Contact Information Name: Function: Company: Address: City: Zip code: Country: Telephone number: Fax number: E-mail address: Website: Parent company: (if applicable) Representative in Netherlands/Europe (if different from Contact Information) Name: Function: Company name: (if different from Company Information) Address: City: Zip code: Country: Telephone number: Fax number: E-mail address: Geographical area The Netherlands / Benelux / Western Europe / Others (piease specify): covered:

General Product Information Key markets: (multiple answers possible)

Major product-lines: Geographical areas covered:


D-19

road traffic management / rail traffic control / military command traffic control / airport control system / airiine operational control spacecraft mission control systems / energy distribution control / process control / logistics operational control system / telecommu management / Others (piease specify):

Candidate Product Information (Piease copy and fill in this part of template for each candidate product described.) Product name: Description of product functionality: AVB component SMS / AC/ AMS coverage: Scale of product: Turn-key solution / complete system / sub-system or module component Product status: Operational with multiple clients / Operational trial / Under c Architecture (Road traffic) AVB / KAREN / FRAME / ITS / NTCIP / UTMC compliance: CURS/ Other road traffic (piease specify): (Other markets) ATCCIS / Dll COE / Compass / JTA / TAFI/V / (Super)MOCA / (New)MAAP / MDA / MESA / IFS / COSP Other non-road-traffic (piease specify): Standards CORBA / J2EE / TCP/IP / UDP / SNMP compliance: Others (piease specify): Reference users: Is product itself divided into modules? (If so, piease list main modules, together with summary of each module's function and whether it could be delivered separately). Development CMM (specify level) / ISO 9000 / IEEE 12207 / MOD-STD-4: ESA PSS-05 Other (piease specify): process standards: Component-based Yes / No development approach applied: Description of development planned or in progress: (if applicable) Product website: Product manager's name: Company name: (if different from Company Information) Address: City: Zip code: Country: Telephone number: Fax number: E-mail address:


D-20

MATCH - Bijlage D4 Market Survey of Traffic Management Components Product Compliancy Questionnaire


D-21


D-22

Product Compliancy Questionnaire When you have filled in this questionnaire, piease e-mail it to: match(S)avv. rws.minvenw.nl Piease use a separate form for each product. Product Identification Product name Contact Information

Name: Function: Company: Date: Product Requirements

This questionnaire contains tables of functional and non-functional product requirements. Piease place a tick in the appropriate column against each requirement to show the level of compliance of your product. The column headers and levels of compliance should be interpreted as follows: • Full: the product is fully compliant with the requirement. • Partial: the product is partially compliant with the requirement. Piease give a brief explanation at the end of the questionnaire, together with the requirement's reference (section.number.letter). • None: the product is not compliant with the requirement. • NA: the requirement is not applicable to your product. 1.

Functional Requirements

Product requirement 1.

Traffic Management: The product shall provide (road) traffic management functionality by which the traffic controller can: A. Gain full insight into the current traffic situation (monitoring). B. Implement measures to influence and control traffic. C. Gain full insight into the traffic-related state of all sensors, actuators, trafficcontrol scenarios and measures (e.g. the current parameter values output by sensors, the actual message displayed on matrix displays, and the like). D. Control all sensors, actuators, traffic-control scenarios and measures. E. Obtain notification of all relevant anomalies in the current traffic situation or state of the traffic-control system (alarming). F. Gain full insight in the status of traffic-control system hardware, software,and Communications, including failures affecting the traffic management process. 2. Configuration management: The product shall enable (re-)configuration of the traffic-control system by which the configuration manager can: A. (Re-)Configure all connected sensors, actuators, traffic-control scenarios and measures. B. Allow or disallow the use of sensors, actuators, traffic-control scenarios and measures by traffic controllers.


D-23

A.

Technical systems management: The product shall enable technical systems management of the traffic-control system by which the system manager can: A. Gain full insight into the technical status of the traffic-control system hardware, software and Communications, as well as the sensors, actuators, scenarios and measures. B. Gain full insight into the running time of sensors and actuators. C. Activate and deactivate all parts of the traffic-control system. D. Configure and adjust the parameters of all parts of the traffic-control systerr E. Obtain notification of all relevant anomalies (including failures) in the traffic control system. B. Operator task separation. The product shall enable separation of tasks among operators within a given function. C. Operator task reallocation. The product shall enable the (re-)allocation of tasks ' operators within or between traffic-control centres. D. Functional task separation. The product shall enable the strict separation of functional tasks into traffic management (by traffic controllers and traffic managers), configuration management (by configuration managers) and technic systems management (by system managers) tasks. E. Data logging: The product shall provide event and data logging on a time and/c an event basis. F. Availability information. The product shall provide information on the availabilit of connected sensors and actuators in duration and percentage terms. 2. Non-functional Requirements 2.1

Product integration

Product requirement 1. 2.

3.

2.2

User interface integration: If the product has its own user interface, then it shall be possible to replace it by or to integrate it with another user interface. Traffic-control measure integration. If the product contains its own trafficcontrol scenarios and/or measures, then it shall be possible to replace them by oi to integrate them with other traffic-control scenarios and/or measures. Database integration: If the product has its own database, then it shall be possible to place it by or integrate it with another database. Product integration: It shall be possible to integrate the product with or interface it to other products and applications, independent of: A. platform, B. operating system, C. software language, and D. development environment (including compiler) Product performance


2.

3.


Modular structure: If the product has a modular structure, then it shall be possibl to add, replace and remove modules without affecting the remaining functionalit of the product. Extendibility: It shall be possible to modify and extend the functionality (traffic control applications) of the product with minimal impact on the other functionalities of the traffic-control system. Supplier independence: It shall be possible for other suppliers or developers to ac or modify the functionality of the product.

D-24

4.

5.

6. 7.

2.3

Scale: It shall be possible to apply the product for traffic management throughout the Netherlands with an anticipated scale of 5000 road-side outstations, 20,000 actuators and 40,000 sensors. Scalabiiity: It should be possible to scale up the numbers of outstations, actuators and sensors managed by the product by a factor of 10 times the numbers mentioned in requirement (4) above. Processing capacity; The product shall have sufficient processing capacity for handling updates in 100,000 to 200,000 data items every 4 seconds. Scalabiiity of processing capacity: It should be possible to scale up the product's processing capacity by a factor of 3 times the numbers mentioned in requirement (6) above. Product support

Product requirement ^L 2. 3. 4. 5. 6. 7.

2.4

COTS: The product shall be available commercially off the shelf. Large installed base: The product should have a large installed base of more than 100 installations. Medium installed base: The product shall have an installed base of more than 10 installations. Product support: The product shall be commercially supported by a sales department in Europe. Product service: The product shall be technically supported by a first-line maintenance department in the Netherlands. Product lifecycle: The product shall be supported for at least the next 10 years. Remote maintenance: The product shall be maintained remotely, e.g. for parameter adjustments. This requirement does not apply to mechanical interventions. Product interface

Product requirement 1. 2.

3.

4. 5.

6.

7.


Device Interface Extensibility: If the product has an interface to sensors or actuators, then it shall be possible to increase the number of these interfaces. Pluriform Interface: If the product has an interface to sensors or actuators, then it shall support several types of hardware I/O (digital, analogue, potential, current, etc). Multiple protocols: If the product has an interface to sensors or actuators, then multiple standard protocols shall be available for this interface, and it shall be possible to add new protocols. Redundant I/O: If the product has an interface to sensors or actuators, then it supports redundant data acquisition and processing. Sensor output to other products: If the product has an interface to sensors, then it shall be possible for the product to provide this sensor information to other systems. Sensor input from other products: If the product uses sensor information, then it shall be possible for the product to receive similar information supplied from another data acquisition system. Actuator input from other products: If the product has an interface to control actuators, then it shall be possible for the product to receive and relay actuator control actions from other systems.

D-25

8.

Actuator output to other products: If the product can generate actuator commands, then it shall be possible for the product to forward these command to other systems that are actually in control of the actuator. 9. (VicNet) Network communication: Products deployed decentralised (i.e. outs the control centre(s)) shall communicate to other parts of the traffic-control sysi via VicNet (the IVlinistry's TCP/IP Ethernet network). 10. Local operations. Products deployed decentralised shall be capable of local operation and configuration (i.e. in the field). 11. ITS standards: The product shall support the use of widely-known ITS standar such as NTCIP, OCIT, UTMC, and (Traffic) XML. 2.5

Traffic-Control Measures


2.

3.

4.

5.

6.


Invoking and blocking traffic-control measures: If the product executes traffic-control measures, then it shall be possible for other parts of the trafficcontrol system to invoke or block these traffic-control measures. Traffic-control measure parameterisation: If the product executes trafficcontrol measures, then it shall be possible for the product to return the current parameter values of traffic-control measures on request or to set the traffic-coni measure parameters to requested values. Separation of decision and execution: If the product executes traffic-contro measures, then the decision process leading to the invocation of traffic-control measures (e.g. an executing traffic-control scenario) shall be separated from the execution of the traffic-control measure. Decentralised control: The product shall enable the decentralised (i.e. outsic control centres) deployment and execution of critica! traffic-control measures, without being affected by failures in the communication links to/from any contr centre. Real-time l/O: The acquisition and processing of traffic data and the commanding of actuators shall be executed in real-time and in parallel with othf traffic-control applications. Real-time control: Traffic-control scenarios and measures shall be executi in real-time and in parallel with other traffic-control applications.

D-26

MATCH - Bijlage D5 Market Survey of Traffic Management Components ACT Compliancy Questionnaire


D-27

ACT Compliancy Questionnaire When you have filled in this questionnaire, piease e-mail it together with any product flyers/brochures (in zip-file) to: [email protected] Product Identification Product name

Contact Information Name: Function: Company: Date:

Product Requirements This questionnaire contains tables of functional and non-functional product requirements. Piease place a tick in the appropriate column against each requirement to show the level of compliance of your product. The column headers and levels of compliance should be interpreted as follows: • Full: the product is fully compliant with the requirement. • Partial: the product is partially compliant with the requirement. Piease give a brief explanation at the end of the questionnaire, together with the requirement's reference (section.number.letter). • None: the product is not compliant with the requirement. • NA: the requirement is not applicable to your product. Detailed Product Information 1.

Actuator Management

Product requirement 1. The product shall provide the following functionality for controlling actuators, SL as Variable Message Signs: A. Controlling objects (= software objects / components for controlling each physical actuator). 2. The product shall provide the following functionality for controlling actuators, SL as Variable Message Signs: A. Controlling objects (= software objects / components for controlling each physical actuator). B. Basic logic in the controlling objects for prioritising commands received fror multiple traffic-control measures by means of a list of current commandrequests and their originating measure. 3. The product shall provide the functionality for defining a controlling object for each logical group of physical actuators. The product shall provide the following functionality for configuring physical actuators and their interfaces: A. (Re-)definition of text and images and their layout on the actuator's displa> B. Setting parameters for communication with the physical actuator. 5. The product shall provide the following functionality for configuring physical


D-28

6.

7.

8.

9.

2.

actuators and their interfaces: A. (Re-)definition of text and images and their layout on the actuator's display. B. Setting parameters for communication with the physical actuator. C. Setting parameters for the physical actuator. The product shall provide the following functionality for maintenance of the controlling objects: A. Instantiation and maintenance of the controlling objects (as in an objectfactory). The product shall provide the following functionality for maintenance of the controlling objects: A. Instantiation and maintenance of the controlling objects (as in an objectfactory). B. Saving and retrieving the configuration of the controlling objects in a database. The product shall enable the provision of information on the traffic situation and on the operational and configuration status of one or more actuators and/or controlling objects. The product shall be able to generate historical overviews of texts and images displayed on the actuator(s).

Sensor Management

Product requirement 1. The product provides the following functionality for data acquisition from the physical sensors: 2. The product provides the following functionality for data acquisition from the physical sensors: A. Making available the traffic-related parameter-values acquired from the physical sensors 3. The product provides the information objects / components together with the associated algorithms for the aggregation of information ("data fusion") from logical groups of sensors. 4. The product provides the following functionality for configuring the physical sensors and their interfaces: A. Setting parameters for communication with the physical sensor 5. The product provides the following functionality for configuring the physical sensors and their interfaces: A. Setting parameters for communication with the physical sensor B. Setting parameters for the sensor hardware 6. The product provides the following functionality for the maintenance of the dataacquisition object(s) (= software object(s) / component(s) for data acquisition): A. Instantiation and maintenance of the data-acquisition object(s) (as in an object factory). 7. The product provides the following functionality for the maintenance of the dataacquisition object(s) (= software object(s) / component(s) for data acquisition): A. Instantiation and maintenance of the data-acquisition object(s) (as in an object factory). B. Storing the configuration of the data-acquisition object(s) in a database 8. The product makes available information about the traffic-specific status, working state, and configuration of one or more sensors and data-acquisition objects.


D-29

3. Application Control

3.1

Presentation layer

Product requirement 1. The product provides a presentation layer. This enables visible representatiot to be made in geographical, schematic, iconic, list and text form of trafficmanagement related entities, separately from or together with their trafficrelated and working states, to the users (i.e. the traffic controllers, and configuration and system managers). Display in 2D and/or 3D, image contrc (e.g. pan or scroll left / right / up /down, zoom in / out), manipulate the displayed entities, and hide / close the visual representations of: A. One or more geographical areas of the Dutch motorway network. B. One or more maintainable complex entities in the Dutch motorway networ such as bridges and tunnels. C. One or more parts of the traffic-control system itself, including the physical sensors and actuators, road-side stations, control centres, software objects , components, and the linking Communications network. D. One or more control centres internally, with its rooms / spaces, workstatior video-walls, tasks, computer monitors and services. 2. The presentation layer shall be able to display geographic and schematic maps with updates in data for around 4000 objects every 4 seconds. 3. The presentation layer shall be able to import geographic data in GDF-format. 4. The presentation layer shall be able to display, control and remove video data. 5. The product provides a presentation layer. This enables visible representatior to be made in geographical, schematic, iconic, list and text form of trafficmanagement related entities, separately from or together with their trafficrelated and working states, to the users (i.e. the traffic controllers, and configuration and system managers). Display in 2D and/or 3D, image contrc (e.g. pan or scroll left / right / up /down, zoom in / out), manipulate the displayed entities, and hide / close the visual representations of: A. One or more geographical areas of the Dutch motorway network. B. One or more maintainable complex entities in the Dutch motorway networl such as bridges and tunnels. C. One or more parts of the traffic-control system itself, including the physical sensors and actuators, road-side stations, control centres, software objects / components, and the linking Communications network. D. One or more control centres internally, with its rooms / spaces, workstation video-walls, tasks, computer monitors and services. 6. The presentation layer shall be able to display geographic and schematic maps with updates in data for around 4000 objects every 4 seconds. 7. The presentation layer shall be able to import geographic data in GDF-format. 8. The presentation layer shall be able to display, control and remove video data. 9. The presentation layer shall be able to play, control and silence audio data.


D-30

3.2

Business-logic layer

Product requirement The product provides the following functionality for maintaining and configuring traffic-control objects (= software objects / components for trafficcontrol scenarios and measures): A. Instantiation and maintenance of the traffic-control objects. B. Setting parameters for communication with the traffic-control objects. C. Storing the configuration of the traffic-control objects in a database. D. Making available the configuration of the traffic-control objects. 2. The product provides the following functionality for the operational use of the traffic-control objects: A. Tuming the traffic-control objects on and off. B. Identifying specific traffic-control situations on the basis of the traffic-related sensory parameter-values. C. Initiating the appropriate traffic-control measure when the traffic-control situation matches a situation specified by one of the scenarios. D. Coordinating multiple traffic-control measures. E. Producing instructions from the coordinated traffic-control measures, with the aim of influencing the traffic by requesting traffic-specific actuator states. 3. The product provides the following functionality for the operational use of the traffic-control objects: A. Turning the traffic-control objects on and off. B. Identifying specific traffic-control situations on the basis of the traffic-related sensory parameter-values. C. Initiating the appropriate traffic-control measure when the traffic-control situation matches a situation specified by one of the scenarios. D. Coordinating multiple traffic-control measures. E. Producing instructions from the coordinated traffic-control measures, with the aim of influencing the traffic by requesting traffic-specific actuator states. F. Making available information about the states of the traffic-control objects and instructions. 4. The product provides the following functionality for maintaining anomaly reports (including alarms): A. Instantiation and maintenance of anomaly reports and alarms. B. Storing details of anomaly reports and alarms in a database. C. Making available information about anomaly reports and alarms.


D-31

Bijlage E

Functionele en niet-functionele eisen

In het kader van het MATCH project is de navolgende lijst met functionele en niet functionele eisen opgesteld door het project management team, bij het ontbreken hiervan in de AVB en ACT documentatie. 1.1 Functioneel 1. Het product moet verkeersmanagement mogelijk maken, waarbij de operator: • volledig inzicht heeft (of kan krijgen) in de verkeerstoestand (monitoren); • het verkeer kan beïnvloeden, door middel van het inzetten van maatregelen; • volledig inzicht heeft (of kan krijgen) in de verkeerskundige toestand van alle aangesloten sensoren, actuatoren en aanwezige regelingen (regelscenario's en maatregelen); • alle aangesloten bedienbare sensoren, actuatoren en aanwezige regelingen (regelscenario's en maatregelen) kan beïnvloeden; • geïnformeerd wordt (alarmering) over alle relevante afwijkende verkeerskundige toestanden; • volledig inzicht heeft (of kan krijgen) in de toestand van DVM systeemdelen (hardware, software, communicatie), inclusief storingen die het verkeersmanagement proces beïnvloeden. 2. Het product moet verkeerskundig configuratie beheer mogelijk maken, waarbij de operator • alle aangesloten sensoren en actuatoren en regelingen (regelscenario's en maatregelen) kan configureren; • alle aangesloten sensoren, actuatoren en regelingen (regelscenario's en maatregelen) beschikbaar kan maken voor of onttrekken aan de weg verkeersleider. 3. Het product moet technisch systeembeheer (het onderhoud van het DVM systeem zelf) en onderhoud mogelijk maken, waarbij de operator • volledig inzicht heeft (of kan krijgen) in de technische toestand van alle aangesloten sensoren, actuatoren en aanwezige regelingen (regelscenario's en maatregelen) en (sub)systemen; • volledig inzicht heeft (of kan krijgen) in het aantal bedrijfsuren van aangesloten sensoren en actuatoren; • alle aangesloten bedienbare DVM (sub)systemen en devices kan in- en uitschakelen; • alle aangesloten technische DVM (sub)systemen en devices kan instellen of configureren; • geïnformeerd wordt over alle relevante afwijkende technische toestanden (inclusief storingen); 4. Het product moet operator taakscheiding mogelijk maken tussen operators met eenzelfde functie.


E-1

5. Het product moet operator taakoverdracht mogelijk maken, waarbij bepaalde taken kunnen worden overgedragen tussen operators, zowel op dezelfde locatie als op verschillende locaties (centrales). 6. Het product moet taakscheiding tussen verkeersmanagement (verkeersleiders), verkeerskundige (configuratie beheerders) en technisch (systeembeheerders) beheer operators mogelijk maken. 7. Het product moet event- en datalogging, zowel op event en/of op tijdbasis bevatten 1.2 Niet Functioneel 1.2.1 Product integratie 1. Indien het product een gebruikersinterface bevat, dan moet deze kunnen worden vervangen door of geïntegreerd met een andere gebruikersinterface. 2. Indien het product een regeling bevat, dan moet deze kunnen worden geïntegreerd met een regeling (regelscenario's en maatregelen) van een ander product. 3. Indien het product een database bevat, dan moet deze kunnen worden vervangen door of geïntegreerd met een database van een ander product. 4. Het product moet kunnen integreren met andere componenten, onafhankelijk van: • het gebruikte platform • het gebruikte operating system • de software taal • de ontwikkelomgeving (inclusief compiler)

1.2.2 Product performance 1. Het product moet modulair zijn opgebouwd en het moet mogelijk zijn modules toe te voegen, om te ruilen of te verwijderen. 2. De functionaliteit (de applicaties) van het product moet gewijzigd en uitgebreid kunnen worden, met een minimale impact op de rest van het DVM (dynamisch verkeersmanagement) systeem 3. Het toevoegen of wijzigen van functionaliteit dient door een andere leverancier te kunnen gebeuren 4. Het product moet kunnen worden ingezet op de gewenste schaal (Nationaal: 5000 wegkantstations, 20.000 actuatoren en 40.000 sensoren) 5. De schaalgrootte van het product moet aanzienlijk (factor 10) kunnen worden uitgebreid 6. Het product moet voldoende verwerkingscapaciteit hebben (verkeersmanagement centrale: 100.000 tot 200.000 gegevensitems per 4 sec)


E-2

7. De verwerkingscapaciteit van het product moet aanzienlijk kunnen worden uitgebreid (factor 3)

1.2.3 Product support 1. Het product moet commercieel verkrijgbaar zijn, hetzij commercial off the shelf, hetzij "customisable" off the shelf 2. Indien het product verkrijgbaar is moet een grote (groter dan 100) of een ruime (tussen 10 en 100) installed base hebben. 3. Indien het product verkrijgbaar is, moet het product ondersteund worden vanuit Europa 4. Indien het product verkrijgbaar is, moet het product "geserviced" kunnen worden vanuit Nederland 5. Indien het product verkrijgbaar is, dient het product tenminste nog 10 jaar ondersteund te worden 6. Het product moet, behoudens mechanische ingrepen, van afstand kunnen worden onderhouden, ondermeer door middel van het instellen van parameters

1.2.4 Product interface 1. Indien het product een interface naar sensoren of actuatoren bevat, dient deze in aantal flexibel uitbreidbaar te zijn 2. Indien het product een interface naar sensoren of actuatoren bevat, dient deze meerdere typen hardware l/O (digitaal, analoog, stroom, spanning) te kunnen ondersteunen. 3. Indien het product een interface naar sensoren of actuatoren bevat, dienen hiervoor meerdere (algemeen bekende) standaard protocollen aanwezig te zijn, alsmede moet het mogelijk zijn een nieuw protocol te implementeren. 4. Indien het product een interface naar sensoren of actuatoren bevat, dient het product redundant te kunnen worden geïnstalleerd 5. Indien het product een interface naar sensoren bevat, dan moet de informatie die hieruit verkregen wordt aan andere systemen geleverd kunnen worden. 6. Indien het product sensorinformatie nodig heeft dan moet deze kunnen worden aangeleverd door een ander data acquisitie systeem 7. Indien het product een interface naar actuatoren bevat, dan moeten deze actuatoren via dit product ook door andere systemen kunnen worden aangestuurd. 8. Indien het product actuator sturing kan genereren, dan moet de daadwerkelijke aansturing ook via een ander systeem kunnen worden gerealiseerd


E-3

9. Decentraal geplaatste producten dienen communicatie met andere verkeersmanagement (sub) systemen te kunnen realiseren via VicNet (TCP/IP ethernet). 10.Decentraal geplaatste producten, moeten beschikken overeen locale user interface voor het bedienen en instellen van de locaal aanwezige functies 11. Het product moet het gebruik van internationale ITS standaarden ondersteunen, zoals bijvoorbeeld: NTCIP, OCIT, UTMC, en XML (traffic)

1.2.5 Product regelingen 1. Indien het product verkeerskundige maatregelen kan realiseren, dan moet een de uitvoering van een maatregel buiten het product aan of uitgezet en geblokkeerd kunnen worden 2. Indien het product verkeerskundige maatregelen kan realiseren, dan moeten de parameters van deze maatregel buiten het product opgevraagd en ingesteld kunnen worden. 3. Indien het product verkeerskundige maatregelen kan realiseren, dan dient het beslissingsproces dat leidt tot het inzetten van de maatregel en de uitvoering van de maatregel van elkaar gescheiden te zijn. 4. De uitvoering van vitale verkeerskundige maatregelen moet decentraal kunnen worden uitgevoerd, waarbij de verbindingen met overige systeemdelen kunnen uitvallen, zonder dat de uitvoering van de verkeerskundige maatregel hierdoor verhinderd wordt 5. De inwinning en verwerking van verkeerskundige gegevens en het aansturen van verkeerskundige signaleringen moet in een real-time omgeving worden uitgevoerd, waarin meerdere verkeerskundige applicaties naast elkaar kunnen draaien 6. De uitvoering van verkeerskundige regelingen (regelscenario's en maatregelen) moet in een real-time omgeving worden uitgevoerd, waarin meerdere verkeerskundige applicaties naast elkaar kunnen draaien


E-4

Marktverkenning Componenten DVM-systeem

Recommend Documents