HIGH TECH ONDERZOEK SYSTEEMPROGRAMMATUUR WEGKANTSTATIONS RAPPORT VAN BEVINDINGEN. : High Tech Automation BV Rob Vriens, Ewald Annink

Transcriptie

1 HIGH TECH ONDERZOEK SYSTEEMPROGRAMMATUUR WEGKANTSTATIONS RAPPORT VAN BEVINDINGEN Auteur(s) : High Tech Automation BV Rob Vriens, Ewald Annink Datum : 11 Juli 1997 Uitgave : 1.0

2 H R G H TECH JSJSP UITGAVE 1.0 DATUM PAGINA 2

3 ^», GH TECH ' T O M A T I 9 MANAGEMENT SAMENVATTING MANAGEMENT SAMENVATTING Het onderzoek "Systeemprogrammatuur Wegkantstations" heeft als doel een overzicht te krijgen van de op de markt verkrijgbare voor wegkantstations bruikbare real-time operating systems. (RTOS). Het RTOS is een belangrijk onderdeel van de totale automatiseringsinfrastructuur die daarnaast bestaat uit het hardware platform, de netwerkprogrammatuur en de beheerprogrammatuur. Wegkantstation Verkeerskundige toepassingen Beheerprogrammatuur 1 Ontwikkelomgeving Netwerkprogrammatuur RTOS Hardware Het ter beschikking hebben van een gestandaardiseerde automatiseringsinfrastructuur heeft voor RWS een groot aantal voordelen met betrekking tot de ontwikkel- en beheerkosten van (nieuwe) verkeerskundige toepassingen, de benodigde kennis binnen RWS voor het aanbesteden en begeleiden van projecten en de mogelijkheid tot verdere integratie van toepassingen. Zeker als men zich realiseert dat RWS vanaf 2000 een grootschalige infrastructuur te beheren heeft. Dit onderzoek staat niet op zichzelf. Het onderzoek vindt plaats in het kader van het deelproject "Architectuur wegkantstations" van het VISI (Verkeers Informatie Systeem Integratie) project. Binnen dit deelproject lopen ook de onderzoeken naar de netwerktoepassingsmogelijkheden (NTCIP), het platform zelf (de processor, bus etc.) en een onderzoek naar de bedrijfskundige consequenties hiervan voor RWS. Uitgangspunt voor dit onderzoek was niet zozeer een "vervanger" te zoeken voor de huidige generatie wegkantstations, maar te zoeken naar een architectuur die geschikt is voor een generatie van systemen die na 2000 operationeel kunnen worden. We spreken dan over de introductie van nieuwe DVM-maatregelen (o.a. rekening rijden, in-car systemen en video-systemen) gebaseerd op nieuwe technologie. Tezamen met de ontwikkelingen op netwerkgebied (VICNET) stelt dit totaal andere (zwaardere) eisen aan de benodigde automatiseringsinfrastructuur in vergelijking met de huidige generatie van systemen. UITGAVE 1.0 DATUM PAGINA I

4 GH TECH \ 1, ' ' O M A I ' MANAGEMENT SAMENVATTING Bij het onderzoek en selectie van voor RWS interessante RTOS's is uitgegaan van het belang van RWS. Dit belang wordt gerepresenteerd door een viertal (hoofd)criteria : 1. Bruikbaarheid. Hierbij gaat het om de bruikbaarheid en toepasbaarheid van het RTOS m.b.t. de (nieuwe) generatie van DVM-systemen. 2. Toekomstvastheid. Hierbij gaat het om de mogelijke geschiktheid op langere termijn en de doorgroeimogelijkheden. 3. Openheid van de markt. Hierbij gaat het om goede mogelijkheden voor leveranciers om mee te kunnen dingen in het offerte traject en de beschikbaarheid van kennis bij de industrie voor zowel de ontwikkeling als het onderhoud. 4. Kosten. Hierbij gaat het om de beperking van de integrale kosten van ontwikkeling tot onderhoud. Deze (hoofd)criteria dienden als basis voor de ontwikkeling van een uitgebreide lijst van (sub)criteria en factoren op basis waarvan de selectie heeft plaatsgevonden. Het onderzoek heeft het volgende proces doorlopen : O ntwikkeling criteria-stelsel M arktsurvey potentiële kandidaten "Short-list" van relevante RTOS's Bepaling m inim ale eisen ("m ust-criteria") "Long-list" van kandidaten Detail onderzoek eigenschappen RTOS "short-list" Selectie op basis van "m ust-criteria" Evaluatie & Conclusies Frappant was dat van de 14 potentiële kandidaten (de "long-list") slechts twee RTOS's voldeden aan alle must criteria ("short-list": psosystem en VxWorks). Deze lijst werd met slechts één RTOS (VRTXsa) uitgebreid als één belangrijk "must-criterium" niet van toepassing werd verklaard. Het detail onderzoek gaf aan dat psosystem en VxWorks elkaar niet veel ontlopen. Twee systemen (JavaOS en ChorusClassiX) waren nog dermate nieuw op de markt dat er momenteel nog niets te zeggen valt over hun potentie (open markt en toekomstvastheid) en zijn daarom niet verder geëvalueerd. Dit leidt tot de hoofdconclusie dat psosystem en VxWorks beide geschikt zijn als RTOS waarbij de risico 's voor de bedrijfsbelangen zo veel mogelijk beperkt zijn. UITGAVE 1.0 DATUM PAGINA I!

5 H R G H TECH jsbr' % ' <i»""' MANAGEMENT SAMENVATTING ^W Uit het onderzoek kwam tevens naar voren dat de markt van RTOS's nogal dynamisch is. Er zijn een groot aantal leveranciers met beperkte produkten en marktpenetratie meestal gericht op een specifiek gebied. Er komen nog steeds nieuwe RTOS's op de markt. Standaardisatie is nog ver te zoeken. Dit leidt tot de tweede conclusie dat RWS een definitieve keuze zo laat mogelijk moet nemen. Een korte marktsurvey, waarin nieuwe en veranderde RTOS's worden geëvalueerd, kan aan die definitieve keuze voorafgaan. Hoewel de geselecteerde RTOS's op een groot aantal verschillende platformen (processors, bussen) kunnen werken is er voor een specifiek hardware platform een additioneel pakket nodig, het z.g. Board Support Package (BSP). Dit BSP wordt veelal geleverd door de platformleverancier en is vaak tot stand gekomen doordat gebruikers een dergelijk pakket nodig met specifieke eigenschappen en een BSP in eigen beheer ontwikkeld hebben. Hierdoor is de kwaliteit van BSP's discutabel. In het kader van dit onderzoek is dit niet onderzocht. Dit leidt tot de conclusie dat de kwaliteit van de beschikbare BSP 's een risico vormt. Dit risico kan worden beperkt door een integrale keuze te maken van een RTOS, tezamen met het platform en een BSP en van tevoren deze zaken te integreren en te testen voordat Tot de ontwikkeling van verkeerstoepassingen wordt overgegaarit^ Tijdens het onderzoek is ook gezocht naar op de markt verkrijgbare beheerprogrammatuur pakketten. Dergelijke pakketten zijn voor RWS interessant aangezien zij bij toepassing aanzienlijke besparingen kunnen opleveren tijdens de onderhoudsfase. Gebleken is dat dergelijke pakketten, voor gebruik met een RTOS in een wegkantstation niet beschikbaar zijn. Dit in tegenstelling tot de in grote hoeveelheid verkrijgbare pakketten op grotere platformen (die o.m. gebruikt worden in de verkeerscentrale). Wel zijn ontwikkelfaciliteiten en pakketten leverbaar om deze beheerprogrammatuur te ontwikkelen. Dit leidt tot de conclusie dat RWS zal moeten investeren in de ontwikkeling van beheerprogrammatuur op een zodanige wijze dat deze beheerprogrammatuur aansluitbaar is op de beheerprogrammatuur in centrales. Tot zover de belangrijkste conclusies van dit onderzoek. Wat is de betekenis van de bovenstaande conclusies voor RWS? In de nabije toekomst zal RWS aanbestedingen doen voor nieuwe DVM-systemen gebaseerd op nieuwe technologie. Naar verwachting ontstaat na 2000 een totaal nieuwe generatie wegkantstations als onderdeel van een grootschalige infrastructuur. Leveranciers zullen hiervoor voorstellen doen en hun oplossingen aanbieden. UITGAVE 1.0 DATUM PAGINA I

6 H GH TECH ^ 'O M A T I * MANAGEMENT SAMENVATTING RWS zal bij de beoordeling van deze voorstellen en oplossingen niet alleen (meer) het functionele aspect moeten beoordelen maar ook de hierbij aangeboden automatiseringsinfrastructuur. Deze infrastructuur zal moeten passen in een RWS beleid hieromtrent. Alleen dan kunnen de RWS bedrijfsbelangen zo goed mogelijk behartigd worden en kan ervoor worden zorggedragen dat de totale infrastuctuur beheersbaar en betaalbaar blijft. RWS zal dit beleid moeten ontwikkelen en de expertise en organisatie moeten opbouwen om dit beleid daadwerkelijk tot uitvoering te brengen. U1TGAVE 1.0 DATUM PAGI NA IV

7 w HRGH TECH *jj3jjjp ""'OMAT^* INHOUDSOPGAVE ^ F INHOUDSOPGAVE 1 INLEIDING ACHTERGROND DOEL INFORMATIE OVER DIT DOCUMENT REFERENTIES AFKORTINGEN _ Afkortingen van geheugen types 7 2 DEFINITIES WEGKANTSTATION EN ZIJN OMGEVING COMPONENTEN VAN EEN WEGKANTSTATION WAAROM AUTOMATISERINGSINFRASTRUCTUUR STANDAARDISEREN? 10 3 EVALUATIE METHODE 12 4 UITGANGSPUNTEN VAN DE EVALUATIE APPLICATIE EIGENSCHAPPEN EVALUATIE CRITERIA Bedrijfsbelang RWS Onderverdeling van criteria MINIMALE EISEN, MUST-CRITERIA._ Overzicht must-criteria in relatie tot bedrijfsbelangen RWS 17 5 SELECTIE VAN POTENTIËLE OPERATING SYSTEMS LONG-LIST VAN OPERATING SYSTEMS SCORE VAN OS'S T.O.V. MUST-CRITERIA SHORT-LIST VAN OPERATING SYSTEMS 27 6 EVALUATDZ VAN POTENTIËLE OPERATING SYSTEMS ALGEMENE KENMERKEN CONFIGURATIE OP BASIS VAN PSOSYSTEM Algemeen Pakketten in configuratie Evaluatie resultaten CONFIGURATIE OP BASIS VAN VXWORKS Algemeen Pakketten in configuratie Evaluatie resultaten 37 7 CONCLUSIE EN AANBEVELINGEN OVERZICHT EVALUATIERESULTATEN CONCLUSIE 49 8 APPENDIX, OVERZICHT EVALUATIE CRITERIA 51 9 APPENDIX, MOGELIJKE GEHEUGEN CONFIGURATIE APPENDK, GERAADPLEEGDE INFORMATIEBRONNEN 56 UITGAVE 1.0 DATUM PAGINA 3

8 H jtg H TECH '"'.»,.> * INHOUDSOPGAVE 10.1 PSOSYSTEM VXWORKS OVERZICHT BRONNEN 56 UITGAVE 1.0 DATUM PAGINA 4

9 4? GH TECH,* ' OMAtl INLEIDING INLEIDING 1.1 ACHTERGROND Dit onderzoek vond plaats in het kader van deelproject 'Architectuur wegkantstations' van het VISI (Verkeers Informatie Systeem Integratie) project. Doel van het VISI project is het ontwikellen van een geschikte architectuur en een migratieplan voor de verdere ontplooiing, samenwerking.en integratie van de verschillende systemen voor dynamisch verkeersmanagement, reisinformatie en aanverwante systemen na het jaar Het deelproject 'Architectuur wegkantstations' concentreert zich daarbij op de architectuur en migratie van de apparatuur langs de kant van de weg. 1.2 DOEL Vanuit het deelproject 'Architectuur wegkantstations' heeft de opdrachtgever behoefte aan een overzicht van op de markt verkrijgbare pakketten systeemprogrammatuur voor gebruik in diskloze wegkantstations, inclusief een inzicht in de voor- en nadelen van de verschillende configuraties van pakketten in dit toepassingsgebied. Dit overzicht heeft betrekking op de volgende typen systeemprogrammatuur: Real-time operating system Communicatieprogrammatuur Beheersprogrammatuur voor operationeel (stations)configuratiebeheer Ontwikkelomgevingen voor de ontwikkeling van programmatuur voor deze omgeving. De systemen waar het hier over gaat zouden na het jaar 2000 naast enof na de huidige systemen operationeel kunnen worden. Daarom moeten ze geschikt zijn om de toekomstige applicaties (rekeningrijden, in-car-systemen en handhaving) en daarbij gebruikte technologie te ondersteunen. 1.3 EVFORMATDE OVER DIT DOCUMENT Na de inleiding (hoofdstuk 1) volgen enkele definities (hoofdstuk 2) welke van belang zijn voor begrip van de scope en omvang van dit onderzoek. Hierna wordt ingegaan op de gevolgde evaluatie methode (hoofdstuk 3), de uitgangspunten van de evaluatie (hoofdstuk 4), de selectie van potentiële operating systems (hoofdstuk 5) en de evaluatie zelf (hoofdstuk 6). De conclusie en aanbevelingen van het onderzoek staan in hoofdstuk 7. De bijlagen bevatten detail informatie welke voor begrip van de onderzoeksresultaten en de conclusie niet essentieel is. Ze bieden achtergronden voor geinteresseerden en voor eventuele vervolgonderzoeken. UITGAVE 1.0 DATUM PAGINA 5

10 H I G H TECH J S S B P " ü ' 0 A^0* INLEIDING ^ ^ Voor de leesbaarheid worden de volgende tekst-stijlen gebruikt in dit document: Gewone tekst wordt in Times Roman font weergegeven. De in dit rapport gedefinieerde RWS bedrijfsbelangen en evaluatie criteria worden in 'Arial font tussen quotes' weergegeven. Specifieke termen en termen afkomstig uit het automatiseringsjargon worden italic weergegeven. De voor dit onderzoek benodigde product informatie is voor een groot gedeelte rechtstreeks afkomstig van producenten en leveranciers. Om het risico van foute of misleidende product informatie te beperken werd daarom zoveel mogelijk feitelijke informatie gevraagd. Garanties voor juistheid van de door de leverancier verstrekte informatie en de daaruit voortkomende resultaten van dit onderzoek kunnen echter niet worden gegeven. 1.4 REFERENTIES [RTOSEVAL] Philips CFT en High Tech Automation: Real Time Operating Systems, Evaluation results, Release 1.0 (27 maart 1997). [RTOSMETH] Philips CFT en High Tech Automation: Real Time Operating Systems, An evaluation method and results, Release 1.0 (29 februari 1996). [SENSACT] Technolution in opdracht van AW RWS: Verkeerstechnische sensoren en actuatoren, Versie 1.0 (1 augustusj-997). 1.5 AFKORTINGEN API ATM AW BD BSP CFT DSP DWW FTP GNU HW IO IEEE ITS MD MIB MMU NTCIP Application Programming Interface Asynchronous Transfer Mode Adviesdienst Verkeer en Vervoer Bouwdienst Board Support Package (zorgt voor het aanpassen van het RTOS aan het gebruikte hardware platform) Philips Centre for Manufacturing Technology Data Signal Processing Dienst Weg en Waterbouw File Transfer Protocol Gnu's Not Unix (Zeer betrouwbare en efficiënte ontwikkelomgeving welke door specialisten op vrijwillige basis is ontwikkeld en als free ware software beschikbaar gesteld) Hardware (electronica) Input Output Institute of Electrical and Electronics Engineers Intelligent Transportation Systems Meetkundige Dienst Management Information Base Memory Management Unit National Transportation Communications for ITS Protocol UITGAVE 1.0 DATUM PAGINA 6

11 HJÜG GH TECH ' O M A T I 0 9 INLEIDING OEM OS PC POSIX RD PPP RTOS RWS SNMP SW TCPIP VISI WWW Original Equipment Manufacturer (OEM producten worden als halffabrikaat verkocht aan derden) Operating System Personal Computer Portable Operating System Interface for Computer (bekende IEEE standaard voor OS API's) Regionale directie Point-to-Point Protocol Real-Time Operating System Rijkswaterstaat Simple Network Management Protocol Software Transmission Control ProtocolInternet Protocol Verkeers Informatie Systeem Integratie World Wide Web Afkortingen van geheugen types Bat-RAM Battery powered RAM (kan ongelimiteerd op snelle wijze beschreven worden, bewaart data bij spanningsuitval) EEPROM Electrical Erasable Programmable ROM (kan enkele keren in zijn geheel op trage wijze beschreven worden, bewaart data bij spanningsuitval) Flash-PROM Flits PROM (kan vaak in delen op vrij sneue wijze beschreven worden, bewaart data bij spanningsuitval) RAM Random Access Memory (kan ongelimiteerd op snelle wijze beschreven worden, verliest data bij spanningsuitval) ROM Read Only Memory (kan eenmaal bij fabricage beschreven worden, bewaart data bij spanningsuitval) PROM Programmable ROM (kan eenmaal beschreven worden, bewaart data bij spanningsuitval) UITGAVE 1.0 DATUM PAGINA 7

12 H^GH TECH DEFINITIES DEFINITIES WEGKANTSTATION EN ZIJN OMGEVING De kontekst van een wegkantstation is weergegeven in Figuur ' ^Weökaritsötiof) '. ' s Figuur 1: Kontekst van een wegkantstation (gearceerd: wegkantstation) Via het netwerk worden berichten uitgewisseld met andere wegkantstations enof met een of meer centrales. De berichten zijn verkeerskundig of beheerstechnisch van aard. Via de actuatoren en sensoren wordt informatie uitgewisseld met de direkte omgeving van het wegkantstation, waaronder de verkeersdeelnemers. Via de ontwikkelomgeving wordt toepassingsprogrammatuur van het wegkantstation ontwikkeld en eventueel in het netwerk in het wegkantstation geladen. UITGAVE 1.0 DATUM PAGINA 8

13 GHTECH " ' O M A T l DEFINITIES 2.2 COMPONENTEN VAN EEN WEGKANTSTATION Het wegkantstation is opgebouwd zoals weergegeven in Figuur 2. f Netwerk j Wegkantstation Verkeerskundige toepassingen Beheerprograrrenattfur f A 1 OmwiRketomgeying X NetweI<pjograrnrpatyijr ''''' «TCCS ' x ' ' Hardware i f Actuatoren en \ V sensoren J Figuur 2: Opbouw van een wegkantstation (gearceerd: systeemprogrammatuur) De hardware vormt de fysieke interface tussen de software van het wegkantstation en zijn omgeving (netwerk, actuatoren en sensoren). Een Operating System (OS) is een software programma. Het verleent diensten, ook wel services genoemd, aan de overige programmatuur. Zo 'n dienst verzorgt bijvoorbeeld de toewijzing van hardware aan een toepassingsprogramma. Een OS stelt toepassingsprogramma 's in staat om op een efficiënte en 'eerlijke' wijze gebruik te maken van de hardware. Een real-time operating system (RTOS) stelt toepassingsprogramma 's in staat om op een deterministische wijze, dit wil zeggen binnen een gegarandeerde voorspelbare tijd, te reageren op asynchrone gebeurtenissen. Ten opzichte van een niet-real-time OS vereist dit een afwijkende methode van toewijzing van de hardware. Dit wil dus niet zeggen dat RTOS's per definitie erg snel moeten zijn. Over het algemeen bieden ze echter wel een snellere reaktie tijd op asynchrone gebeurtenissen dan nietreal-time OS's. Het RTOS bestaat uit software modulen welke de hardware afschermen van de overige software modulen. De netwerkprogrammatuur bestaat uit software modulen waarmee een protocol-stack is geimplementeerd. Een protocol-stack verzorgt het opbouwen van een netwerkverbinding en is verantwoordelijk voor de wijze van versturen en ontvangen van berichten. De toepassingsprogrammatuur kan de protocol-stack gebruiken om op eenvoudige wijze verkeerskundige en beheerstechnische berichten uit te wisselen met een centrale of een ander wegkantstation. UITGAVE 1.0 DATUM PAGINA 9

14 4 GH TECH DEFINITIES De beheerprogrammatuur bestaat uit software modulen met behulp waarvan op afstand (bijvoorbeeld vanuit een centrale) beheerstechnische functies kunnen worden uitgevoerd. Dit zijn software laden, herstarten en status ophalen. De verkeerskundige toepassingen bestaan uit software modulen welke verantwoordelijk zijn voor het uitvoeren van de verkeerskundige taak van het wegkantstation. Al deze software modulen, behalve de verkeerskundige toepassingen, vormen samen de totale systeemprogrammatuur van het wegkantstation. Mogelijk kunnen hiervoor standaard verkrijgbare pakketten worden gebruikt. De systeemprogrammatuur, inclusief de ontwikkelomgeving, waarop dit onderzoek betrekking heeft is in Figuur 2 (op pag. 9) gearceerd weergegeven. 2.3 WAAROM AUTOMATISERINGSINFRASTRUCTUUR STANDAARDISEREN? In het systeem bestaat een zekere gelaagdheid. Duidelijk te onderscheiden zijn de verkeerskundige toepassingen en de automatiseringsinfrastructuur (zie Figuur 3). De automatiseringsinfrastructuur bestaat uit het hardware platform en de systeemprogrammatuur (bestaande uit RTOS, netwerkprogrammatuur en beheerprogrammatuur). Wegkantstation Y f (netwerk-services)wegkantstation Z Verkeerskundige toepassihgen ' BetieerDfbgra'mrriattfur 7 'Netwerkpwgramrpatuiir Hacdware Verkeerskundig Beheerstechnisch Protocol stacfc Fysiek netwerk Verkeerskundige toepassihgen ^heerpfogrémrrïatuijr ', IMetwePkpKigramroatuMr. K V UÖ»acdware, K sensoren J Figuur 3: Automatiseringsinfrastructuur (gearceerd) in het systeem De automatiseringsinfrastructuur (hardware, RTOS, netwerkprogrammatuur en beheerprogrammatuur) zorgt ervoor dat verkeerskundige toepassingen gebruik kunnen maken van aangesloten sensoren en actuatoren en dat ze verkeerskundige services met elkaar kunnen uitwisselen. Als zodanig vervult de automatiseringsinfrastructuur een ondersteunende rol voor de verkeerskundige toepassingen. UITGAVE 1.0 DATUM PAGINA 10

15 G H TECH r M *' l c,* DEFINITIES Het standaardiseren (van één of meer onderdelen) van de automatiseringsinfrastructuur heeft een aantal voordelen: De automatiseringsinfrastructuur hoeft slechts eenmaal te worden samengesteld wat voorkomt dat die activiteit voor ieder type wegkantstation c.q. verkeerstoepassing moet worden herhaald. Dit werkt kostenbesparend en doorlooptijdverkortend. Door de standaardisatie van automatiseringsinfrastructuur worden minder verschillende producten (hardware componenten en software pakketten) gebruikt in grotere aantallen. Dit werkt kostenbesparend en vereenvoudigd de beheerstechnische complexiteit. De leverancier van verkeerskundige toepassingen beperkt zich tot de hoofdzaak; de verkeerskundige toepassing zelf. Dit werkt kostenbesparend, doorlooptijdverkortend en kwaliteitsverhogend. De automatiseringsinfrastructuur moet voldoende functionaliteit bieden en flexibel genoeg zijn om voor de verschillende verkeerskundige toepassingen te kunnen worden gebruikt. Voor sommige verkeerskundige toepassingen lijkt de automatiseringsinfrastructuur in eerste instantie te zwaar. Door scalability (schaalbaarheid) is dit echter op te vangen. UITGAVE 1.0 DATUM PAGINA 11

16 HIGH TECH "*É8P* '"' o "" '' EVALUATIE METHODE ^r EVALUATIE METHODE Dit hoofdstuk geeft een samenvatting van de gevolgde evaluatie methode. De evaluatiemethode is gebaseerd op [EVAL METH] en uitgevoerd volgens onderstaande stappenplan: 1. Bepaal applicatie eigenschappen van de wegkantstations. Voor een evaluatie van de mogelijke bruikbaarheid van standaard pakketten voor een bepaalde applicatie (in dit geval het wegkantstation) is het essentieel om rekening te houden met de eigenschappen van die applicatie zodat voor- en nadelen van een mogelijke keuze kunnen worden geidentifïceerd. 2. Bepaal evaluatie criteria. De evaluatie criteria zijn afgeleid van het bedrijfsbelang van RWS. Deze hoofdcriteria zijn opgesplitst in sub-criteria en vervolgens in factoren (zie appendix 7 op pag. 42) om de relatie tot de pakketten te verduidelijken. 3. Bepaal minimale eisen (must-criteria) Nadelen van een pakket kunnen zodanig sterk zijn dat ze hierdoor niet in aanmerking komen voor een mogelijke inzetbaarheid. Bepaalde evaluatie-criteria krijgen hierdoor de status MUST; dit wil zeggen dat er aan moet zijn voldaan om het pakket inzetbaar te noemen. 4. Stel een long-list van pakketten samen Op basis van expertise van de onderzoeker wordt een long-list van pakketten samengesteld welke tijdens dit onderzoek worden meegenomen in de evaluatie. 5*. Verzamel pakket-data in relatie tot de minimale eisen Van de verschillende pakketten wordt informatie verzameld zodat ze op basis van de must-criteria kunnen worden geëvalueerd, zodra een pakket op een of meer mustcriteria negatief scoort wordt er verder geen informatie verzameld. 6. Reduceer long-list tot short-list aan de hand van de minimale eisen De pakketten van de long-list welke op alle must-criteria positief scoren worden overgenomen op de short-list. 7. Stel configuraties samen uit de pakketten in de short-list Rond de pakketten op de short-list worden configuraties systeemprogrammatuur samengesteld welke zullen worden geëvalueerd in dit onderzoek. 8. Verzamel pakket-data in relatie tot de evaluatie criteria Van de samengestelde configuraties systeemprogrammatuur wordt pakket-data verzameld op het nivo van de factoren. 9. Beschrijf evaluatie resultaten a.h.v. de pakket-data in relatie tot de evaluatie criteria Over de configuraties systeemprogrammatuur wordt gerapporteerd op het nivo van de sub-criteria. UITGAVE 1.0 DATUM PAGINA 12

17 H I G H TECH "jjlsp " " ' M A ' l * UITGANGSPUNTEN VAN DE EVALUATIE ^ F 4 UITGANGSPUNTEN VAN DE EVALUATIE 4.1 APPLICATIE EIGENSCHAPPEN Wegkantstations zijn onderdeel van de verkeerkundige infrastructuur en zijn geplaatst langs de kant van de weg. Hun primaire taak is het controleren, monitoren en informeren van het verkeer, gebruik makend van sensoren en actuatoren, eventueel in samenwerking met andere wegkantstations of gecontroleerd vanuit een centrale. Voorbeelden van verkeerskundige toepassingen zijn: snelheidsmeting, aanwezigheidsdetectie, visuele (video) inspectie, weermeting en mededelingen. Rekeningrijden, in-car-systemen en handhaving zullen in de komende jaren steeds meer worden toegepast. En juist déze toepassingen vragen om een echt real-time gedrag en een grotere performance van de wegkantstations. Vanwege het grote aantal wegkantstations (vele duizenden) en hun lastige fysieke bereikbaarheid is een goede beheerbaarheid via het netwerk noodzakelijk voor een efficiënte bedrijfsvoering van RWS. Typische karakteristieken van deze wegkanttoepassingen zijn: Quantity; er wordt een groot aantal wegkantstations in gebruik genomen. Dit leidt o.a. tot een noodzakelijke beperking van de omvang van systeem- en toepassingsprogrammatuur om geheugengebruik en daarmee hardwarekosten, software laadtijden en beslag op netwerkcapaciteit te beperken^ Upgradability; het moet mogelijk zijn de functionaliteit van het wegkantstation op eenvoudige wijze uit te breiden of te wijzigen i.v.m. nieuwe functionaliteit en uitbreidingen. Life span; de tijd dat het wegkantstation met zijn systeemprogrammatuur in gebruik is, is in de orde van 10 jaar. Dit is relatief lang; ter vergelijking heeft een toepassing op een PC een levensduur in de orde van 3 jaar. Concurrency; verschillende verkeerskundige toepassingen moeten tegelijk actief kunnen zijn zonder significant te beinvloeden. Het gebruik van een multiprocessor omgeving moet mogelijk zijn. Hard real-time constraints; vanwege de verdere toename in het gebruik van netwerken, video en car-wal-communicatie (o.a. handhaving, rekeningrijden) is het gebruik van een RTOS noodzakelijk. Datacommunication; wegkantstations zijn onderling en met één of meer centrales verbonden door middel van netwerken zodat een goede netwerk-ondersteuning door het RTOS van belang is. UITGAVE 1.0 DATUM PAGINA 13

18 H G H TECH ""'""" o,* UITGANGSPUNTEN VAN DE EVALUATIE Device interfacing, control & monitoring; zonder uitzondering hebben alle activiteiten van de wegkantstations betrekking op de interactie met randapparatuur (sensoren en actuatoren) zodat een goede ondersteuning door het RTOS van belang is. Het observeren van de buitenwereld door middel van sensoren wordt hierbij aangeduid met monitoring en het besturen van de buitenwereld door middel van actuatoren wordt hierbij aangeduid met control. Level of robustness; vanwege het grote aantal wegkantstations, het continue gebruik, de fysieke lokatie en het feit dat er geen directe gebruiker is (om direkt in te grijpen bij een calamiteit), is het noodzakelijk dat het wegkantstation stabiel en betrouwbaar is. Hierdoor is ook het gebruik van een hard-disk ongewenst. In [EVAL METH] paragraaf 4.4 worden bovenstaande application characteristics nader toegelicht. 4.2 EVALUATDE CRITERIA Bedrijfsbelang RWS Bij de bepaling van voor- en nadelen van configuraties van pakketten is primair uitgegaan van het bedrijfsbelang van RWS. Dit bedrijfsbelang komt tot uitdrukking in de 4 hoofd-criteria te weten: Functionele en technische 'bruikbaarheid'. Hierbij gaat het om een goed werkend wegkantstation in het systeem, zowel verkeerskundig als beheerstechnisch. Toekomstvastheid'. Hierbij gaat het om mogelijke geschiktheid op langere termijn. Dit betekent het beperken van de risiko's welke kleven aan het gebruik van een bepaald product. 'Openheid van de markt'. Hierbij gaat het om goede mogelijkheden voor toeleveranciers om mee te kunnen dingen in het offerte-traject voor de levering van wegkantstations. Beperking van de 'kosten'. Hierbij gaat het om beperking van de integrale kosten van ontwikkeling tot onderhoud en beheer. UITGAVE 1.0 DATUM PAGINA 14

19 HIGH TECH ZÜHF "" T M * T ' * UITGANGSPUNTEN VAN DE EVALUATIE ^W Onderverdeling van criteria Een software product laat zich echter moeilijk aan de hand van dusdanig grove criteria beoordelen. Daarom zijn deze hoofd-criteria nader onderverdeeld in sub-criteria. De op deze manier ontstane sub-criteria leggen een duidelijk verband tussen het bedrijfsbelang van RWS enerzijds en de te evalueren producten anderzijds. De relatie tussen deze hoofd-criteria en onderliggende sub-criteria is als volgt: 1. Functionele en technische bruikbaarheid' is opgesplitst in de volgende subcriteria: 1.1. 'Basic services' Met 'basic services' wordt hier bedoeld de gewenste functionaliteit welke door het RTOS moet worden ondersteund omdat anders de functionaliteit van de toepassingsprogrammatuur beperkt wordt. Deze 'basic services' moeten in voldoende mate aanwezig zijn 'Extended services' Met 'extended services' wordt hier bedoeld de gewenste functionaliteit welke door het RTOS zou kunnen worden ondersteund maar welke anders door de toepassingsprogrammatuur toch wel te realiseren is. Ondersteuning door het OS is echter efficiënter en daardoor aan te bevelen 'Performance' Vormt de te realiseren 'performance' met het RTOS een belemmering ~~ voor een goede werking van het wegkantstation? 1.4. 'Betrouwbaarheid' Vormt de 'betrouwbaarheid' van het RTOS een belemmering voor een betrouwbare werking van het wegkantstation? 1.5. 'Beheerbaarheid' Ondersteunt het RTOS beheermogelijkheden zodat 'beheerbaarheid' van het wegkantstation in voldoende mate te realiseren is? 2. Toekomstvastheid' is opgesplitst in de volgende sub-criteria: 2.1. 'Marktpositie' Vormt de 'marktpositie' van het RTOS een risiko voor de 'toekomstvastheid' van het wegkantstation? 2.2. 'Flexibiliteit' Biedt het RTOS voldoende 'flexibiliteit' om geen risiko te vormen voor de 'toekomstvastheid' van het wegkantstation? 3. 'Openheid van de markt' is opgesplitst in de volgende sub-criteria: 3.1. 'Installed base' Is het RTOS voldoende in gebruik om geen risiko te vormen voor 'openheid van de markt'? 3.2. 'Verkrijgbaarheid kennis' Is kennis van het product gemakkelijk genoeg te verkrijgen om geen risiko te vormen voor 'openheid van de markt'? UITGAVE 1.0 DATUM PAGINA 15

20 4 GH TECH UITGANGSPUNTEN VAN DE EVALUATIE 3.3. 'Ontwikkelomgeving' Biedt de 'ontwikkelomgeving' voldoende mogelijkheden om geen risiko te vormen voor 'openheid van de markt'? 3.4. 'Hardware afhankelijkheid' Worden voldoende hardware platforms (zoals processors en bussen) ondersteund om geen risiko te vormen voor 'openheid van de markt'? 4. 'Kosten' zijn opgesplitst in de volgende sub-criteria: 4.1. 'Initiële kosten' Zijn de 'initiële kosten' bij de ontwikkeling van toepassingsprogrammatuur van een wegkantstation niet bovenmatig? 4.2. Terugkerende kosten' Zijn de 'terugkerende kosten' tijdens de onderhouds- en beheerfase van de life cycle van een wegkantstation niet bovenmatig? Evaluatie resultaten op het nivo van deze sub-criteria geven een duidelijk beeld van een product, maar geven nog onvoldoende kader voor een goede evaluatie. Daarom zijn deze sub-criteria op hun beurt opgesplitst in factoren. Het niveau van de factoren tenslotte geeft een verifieerbaar stelsel van beoordelingen. Aangezien deze lijst nogal omvangrijk is, is deze opgenomen in appendix 7, pag. 42. Een overzicht van de relaties tussen de hiervoor genoemde hoofd- en sub-criteria is _weergegeven in Figuur 4. Op deze wijze ontstaat een heldere^boomstructuur die de relatie legt tussen het RWS bedrijfsbelang en de individuele beoordelingen. Hoofdcriteria (RWS bedrijfsbelang) 1 Bruikbaarheid 2 Toekomstvastheid 3 Openheid van de mai 4 Kosten Subcriteria Basic services 1.2 Extended services 1.3 Performance 1.4 Betrouwbaarheid 1.5 Beheerbaarheid Factoren Marktpositie 2.2 Flexibiliteit Installed base 3.2 Verkrijgbaarheid kennis 3.3 Ontwikkelomgeving 3.4 Hardware afhankelijkheid Initiële kosten 4.2 Terugkerende kosten Figuur 4: Overzicht evaluatie criteria UITGAVE 1.0 DATUM PAGINA 16

21 4 'GH TECH """' UITGANGSPUNTEN VAN DE EVALUATIE 4.3 MINIMALE EISEN, MUST-CRITERIA Er zijn een groot aantal potentiële RTOS's op de markt verkrijgbaar. Het is ondoenlijk om al deze RTOS's individueel te beoordelen. Dit is ook niet nodig. Kijkend vanuit de applicatie eigenschappen is het goed mogelijk om te bepalen aan welke eisen een RTOS in ieder geval moet voldoen om in aanmerking te komen voor verdere evaluatie. In deze paragraaf wordt een overzicht gegeven van de minimale eisen, oftewel de mustcriteria, aan de hand waarvan de long-list van pakketten wordt teruggebracht tot een short-list van potentiële RTOS's. Hierbij geldt dat een OS slechts in de short-list wordt opgenomen als ALLE mustcriteria positief kunnen worden beantwoord. Anders gezegd, een OS komt voor verdere evaluatie niet in aanmerking als op één of meer must-criteria negatief wordt geantwoord. Deze regel volgt uit het besef dat de hieronder beschreven must-criteria essentieel zijn om een betrouwbaar, real-time en mission critical gedrag, onafhankelijke werking van meerdere toepassingsprogramma's, diskloze werking en aansluitbaarheid op VICnet te garanderen in het kader van de bedrijfsbelangen van RWS Overzicht must-criteria in relatie tot bedrijfsbelangen RWS In deze paragraaf wordt per must-criterium aangegeven wat de reden is om er een mustcriterium van te maken. Bovendien wordt de relatie met de bedrijfsbelangen van RWS gelegd: T. Het OS moet een RTOS zijn. " Vanwege het karakter van de verkeerskundige toepassingen en de ontwikkelingen op dat gebied is het niet acceptabel dat de reaktie-tijd van een wegkantstation onvoorspelbaar is. Dit must-criterium heeft betrekking op de sub-criteria 'basic services' en 'performance' van het bedrijfsbelang 'bruikbaarheid'. 2. Het RTOS moet op een multiprocessor target systeem kunnen draaien, waarbij het RTOS voor de interproces communicatie en verdeling van processesthreads over de processors zorg draagt. In verband met de sterk toenemende complexiteit van de verkeerskundige toepassingen, de daarmee gepaard gaande vraag naar performance en het groter wordend aantal aangesloten sensoren en actuatoren is het essentieel dat de processor-capaciteit van een wegkantstation kan worden uitgebreid. Om e.e.a. beheerbaar te houden is het niet acceptabel dat hiervoor de architectuur (het ontwerp) van de verkeerskundige programmatuur moet worden aangepast. Dit dient te worden uitgevoerd door het RTOS. Dit must-criterium heeft betrekking op de sub-criteria 'basic services', 'performance' en 'beheerbaarheid' van het bedrijfsbelang 'bruikbaarheid' en sub-criterium 'flexibiliteit' van het bedrijfsbelang 'toekomstvastheid'. UITGAVE 1.0 DATUM PAGINA 17

22 w HHGH TECH ^SSBp '* I """ 1 ' UITGANGSPUNTEN VAN DE EVALUATIE ^ F 3. Het protected memory model en kernel data protection moeten worden ondersteund. Een eventuele fout in een van de toepassingsprogramma's mag niet zomaar leiden tot het disfunctioneren of uitvallen van andere toepassingsprogramma's of het RTOS (en daarmee het gehele wegkantstation). Dit mustcriterium beperkt de kans daarop aanzienlijk. Dit must-criterium heeft betrekking op de sub-criteria 'basic services' en 'betrouwbaarheid' van het bedrijfsbelang 'bruikbaarheid'. 4. File device IO management moet worden ondersteund. Dit is essentieel voor beheerbaarheid van het wegkantstation. Het maakt het gebruik van een RAM-disk mogelijk voor zowel de executie van het RTOS en de toepassings-programmatuur als voor de opslag van data. Dit must-criterium heeft betrekking op de sub-criteria 'basic services' en 'beheerbaarheid' van het bedrijfsbelang 'bruikbaarheid'. 5. Eén of meer interproces communicatie mechanismes moeten worden ondersteund door het OS. Dit is essentieel voor het real-time gedrag van parallelle processen of threads binnen verkeerskundige toepassingen. Dit must-criterium heeft betrekking op sub-criterium 'basic services' van het bedrijfsbelang 'bruikbaarheid'. 6. Enige vorm van semqforen en timers moet worden ondersteund. Overige synchronisatie mechanismes zijn niet noodzakelijk. Dit is essentieel voor het real-time gedrag van parallelle processen of threads binnen verkeerskundige toepassingen. Dit must-criterium heeft betrekking op de sub-criteria 'basic services' en 'betrouwbaarheid' van het bedrijfsbelang 'bruikbaarheid'. 7. Multiprocess enof multithread moet worden ondersteund. Dit is essentieel voor de onafhankelijke werking van verschillende verkeerskundige toepassings-programma's in de vorm van processen en threads. Dit must-criterium heeft betrekking op sub-criterium 'basic services' van het bedrijfsbelang 'bruikbaarheid'. 8. Pre-emptive scheduling moet worden ondersteund. Dit is essentieel voor het real-time gedrag van verkeerskundige toepassingen. Dit must-criterium heeft betrekking op de sub-criteria 'basic services' en 'performance' van het bedrijfsbelang 'bruikbaarheid'. 9. Interrupt service routines moeten interruptible zijn. Dit is essentieel voor de tijdige afhandeling van hoge prioriteit interrupts. Dit must-criterium heeft betrekking op de sub-criteria 'basic services' en 'performance' van het bedrijfsbelang 'bruikbaarheid'. UITGAVE 1.0 DATUM PAGINA 18

23 H(ÜC G H TECH UITGANGSPUNTEN VAN DE EVALUATIE 10. System calls moeten re-entrant zijn. Dit is essentieel voor de onafhankelijke werking van verschillende verkeerskundige toepassings-programma' s. Dit must-criterium heeft betrekking op de sub-criteria 'basic services' en 'betrouwbaarheid' van het bedrijfsbelang 'bruikbaarheid'. 11. Zowel hardware clock als software clock moeten worden ondersteund. Een hardware clock is essentieel voor de beschikbaarheid van de actuele datum en tijd na het (her)starten van een wegkantstation. Door de aanwezigheid van een software clock is een RTOS in staat tijdmanagement functionaliteit aan te bieden aan de toepassingsprogrammatuur. Dit must-criterium heeft betrekking op sub-criterium 'basic services' van het bedrijfsbelang 'bruikbaarheid' en sub-criterium 'flexibiliteit' van het bedrijfsbelang'toekomstvastheid'. 12. De mogelijkheid om na een statement exception verder te gaan met normale code moet worden ondersteund. Dit criterium is essentieel om de beschikbaarheid van een wegkantstation te kunnen garanderen. Een toepassingsprogramma moet namelijk in staat worden gesteld de gevolgen een eventueel gemaakte fout (statement exception) op te lossen. Anders zou de systeemprogrammatuur of het RTOS onverwacht eindigen onder vermelding van een foutcode. _^_ Dit must-criterium heeft betrekking op de sub-criteria 'basic services' en 'betrouwbaarheid' van het bedrijfsbelang 'bruikbaarheid'. 13. Het RTOS moet volledig kunnen executeren vanuit ROM. Dit is essentieel voor een diskloze werking. Een diskloze werking is noodzakelijk omdat onderhoudbaarheid en beschikbaarheid in extreme omstandigheden (o.a. temperatuur, trillingen) niet gewaarborgd zijn. Dit must-criterium heeft betrekking op de sub-criteria 'basic services' en 'beheerbaarheid' van het bedrijfsbelang 'bruikbaarheid'. 14. Het gebruik van TCPIP moet door het RTOS worden ondersteund. Dit zorgt voor een snelle efficiënte werking van de TCPIP protocol-stack. Dit must-criterium heeft betrekking op sub-criterium 'basic services' van het bedrijfsbelang 'bruikbaarheid' en sub-criterium 'flexibiliteit' van het bedrijfsbelang'toekomstvastheid'. 15. Het gebruik Man een protocol-stack met daarin ATM, TCPIP, SNMP, FTP moet mogelijk zijn. Dit is essentieel voor een mogelijke aansluiting van het wegkantstation op beheerprogrammatuur in een netwerkcentrale. Dit must-criterium heeft betrekking op sub-criterium 'extended services' van het bedrijfsbelang 'bruikbaarheid' en sub-criterium 'flexibiliteit' van het bedrijfsbelang'toekomstvastheid'. UITGAVE 1.0 DATUM PAGINA 19

24 HflGH TECH "SfiP """o MA1»»* UITGANGSPUNTEN VAN DE EVALUATIE ^ir 16. Meerdere bussen en veldbussen moeten door het RTOS worden ondersteund. Als hier niet aan wordt voldaan, beperkt dat de interface standaardisering van sensoren en actuatoren en daarmee beperkt het de uitwisselbaarheid van technologie. Dit must-criterium heeft betrekking op sub-criterium 'extended services' van het bedrijfsbelang 'bruikbaarheid' en sub-criterium 'flexibiliteit' van het bedrijfsbelang'toekomstvastheid'. 17. Er moeten mogelijkheden zijn om de 'performance' te optimaliseren (zoals selectie scheduling algoritme). Het optimaliseren (tunen) van het real-time gedrag van parallelle processen of threads is essentieel voor een correcte werking van het wegkantstation. Dit must-criterium heeft betrekking op de sub-criteria 'basic services' en 'performance' van het bedrijfsbelang 'bruikbaarheid'. 18. Het aantal known bugs moet afnemen. Zodra er fouten zijn die niet meer (kunnen) worden opgelost is dat een teken aan de wand voor een product aan het einde van zijn levenscyclus met een steeds verder toenemend aantal gevonden en geïntroduceerde fouten. Bovendien vergroot dat de kans van optredende fouten. Dit must-criterium heeft betrekking op sub-criterium 'betrouwbaarheid' van het bedrijfsbelang 'bruikbaarheid' en sub-criterium 'marktpositie' van het bedrijfsbelang 'toekomstvastheid'. 19. Er moeten nog nieuwe ontwikkelingen worden verricht aan het RTOS. Zodra er geen nieuwe ontwikkelingen meer worden verricht is dat een teken aan de wand voor een product aan het einde van zijn levenscyclus met een steeds verder toenemend aantal gevonden en geïntroduceerde fouten. Bovendien heeft het te maken met de beschikbaarheid van kennis op de markt en heeft daarmee een marktconsequentie. Dit must-criterium heeft betrekking op sub-criterium 'betrouwbaarheid' van het bedrijfsbelang 'bruikbaarheid', sub-criterium 'marktpositie' van het bedrijfsbelang 'toekomstvastheid' en sub-criterium 'verkrijgbaarheid kennis' van het bedrijfsbelang 'openheid van de markt'. 20. Het RTOS moet zijn opgebouwd rond een microkernel zodat scalability, en daarmee weglaatbaarheidvan ongebruikte functionaliteit, is gewaarborgd. Een microkernel architectuur zorgt in de eerste plaats voor de mogelijkheid tot beperken van de te laden software tot elementen die daadwerkelijk benodigd zijn. Bovendien is een microkernel, ten gevolge van zijn kleine omvang in vergelijking tot bijv. een monolitische architectuur, minder complex waardoor het aantal programmeer-fouten kleiner is. Dit must-criterium heeft betrekking op de sub-criteria 'basic services', 'betrouwbaarheid' en 'beheerbaarheid' van het bedrijfsbelang 'bruikbaarheid'. UITGAVE 1.0 DATUM PAGINA 20

25 HIGH TECH lüfip 1 """>» i > * UITGANGSPUNTEN VAN DE EVALUATIE ^ r 21. Het RTOS moet zich een relevante marktpositie hebben verworven en de 'installed base' (aantal verschillende toepassingen) in Europa moet relevant zijn. Doordat een RTOS een relevante marktpositie heeft: Is de beschikbare capaciteit voor ontwikkelingen, support, helpdesk en opleidingen groter. Zijn er meer producten op de markt verkrijgbaar welke voor dat RTOS geschikt zijn gemaakt. Is er relatief veel kennis aanwezig over dat product. Is het risiko kleiner dat het product zou verdwijnen. Dit must-criterium heeft betrekking op sub-criterium 'marktpositie' van het bedrijfsbelang 'toekomstvastheid' en sub-criterium 'installed base' van het bedrijfsbelang 'openheid van de markt'. 22. End-of-life mag nog niet zijn aangekondigd, verwacht worden, of in zicht zijn. Anders is er geen sprake van toekomstvastheid. Dit must-criterium heeft betrekking op sub-criterium 'marktpositie' van het bedrijfsbelang'toekomstvastheid'. 23. Het RTOS moet geschikt zijn voor gebruik op minimaal 2 processor-families van minimaal 2 verschillende fabrikanten. Als een RTOS niet te gebruiken is op meerdere processor-families van minimaal 2 verschillende fabrikanten beperkt dat de-mogelijkheden tot het selecteren van het hardware platform en het beperkt de flexibiliteit waarmee op een ander platform zou kunnen worden overgestapt. Bovendien heeft het te maken met de beschikbaarheid van kennis op de markt en heeft daarmee een marktconsequentie. Dit must-criterium heeft betrekking op de sub-criteria 'marktpositie' en 'flexibiliteit' van het bedrijfsbelang 'toekomstvastheid' en sub-criterium 'verkrijgbaarheid kennis' van het bedrijfsbelang 'openheid van de markt'. 24. Support en helpdesk moeten een vestiging in Europa hebben. Voor toegankelijkheid van support en helpdesk is het essentieel dat de lokale tijd niet teveel afwijkt van die van de supporthelpdesk organisatie, zodat er tijdens ontwikkeling van toepassings-programmatuur optimaal gebruik van kan worden gemaakt. Bovendien bevordert een geringe afstand het gebruik van on-site support. Tevens heeft het te maken met de beschikbaarheid van kennis op de markt en heeft daarmee een marktconsequentie. Dit must-criterium heeft betrekking op sub-criterium 'verkrijgbaarheid kennis' van het bedrijfsbelang 'openheid van de markt'. UITGAVE 1.0 DATUM PAGINA 21

26 4\ 1. GHTECH,* ' OUA11 UITGANGSPUNTEN VAN DE EVALUATIE 25. Ontwikkeling moet vanaf meerdere platforms worden ondersteund (minimaal UNIX en Windows 95NT). Dit zijn veelgebruikte ontwikkelplatforms. Dit must-criterium heeft betrekking op sub-criterium 'ontwikkelomgeving' van het bedrijfsbelang 'openheid van de markt'. 26. Diagnostic tools en source level debuggers moeten beschikbaar zijn. Voor een betrouwbare werking van het wegkantstation is het essentieel dat er voldoende testmogelijkheden zijn. Dit must-criterium heeft betrekking op sub-criterium 'verkrijgbaarheid kennis' van het bedrijfsbelang 'openheid van de markt'. UITGAVE 1.0 DATUM PAGINA 22

27 HIGHTECH SELECTIE VAN POTENTIËLE OPERATING SYSTEMS «SELECTIE VAN POTENTIËLE OPERATING SYSTEMS In dit hoofdstuk wordt een overzicht gegeven van de in dit onderzoek meegenomen long-list van operating systems en de wijze waarop deze aan de hand van de mustcriteria tot een short-list van potentiële operating systems wordt gereduceerd. 5.1 LONG-LIST VAN OPERATING SYSTEMS De long-list, welke als vertrekpunt dient bij de evaluatie vaa.operating systems, is samengesteld door een scan op de markt naar bekende en relevante producten (het is dus nadrukkelijk géén complete lijst van operating systems). In Tabel 1 volgt de long-list van operating systems, aangevuld met informatie betreffende hun producent: Tabel 1: Long-list van operating systems Operating system C EXECUTIVE ChorusClassiX irmx Java LynxOS Nucleus OS2 OS-9, OS-9000 psosystem QNX RTKernel SCO UNIX SPOX VRTXsa VxWorks Windows NT Producent JMI Software Consultants Chorus Systems Radysis (was: Intel) Sun Microsystems Lynx Real-Time Systems Accelerated Technology IBM Microware System Corp. Integrated Systems QNX Software On Time Marketing Santa Cruz Operation Spectron Microsystems Microtec Research Wind River Systems Microsoft Land U.S.A. Fankrijk U.S.A. U.S.A. U.S.A. U.S.A. U.S.A. ~ U.S.A. U.S.A. Canada Duitsland U.S.A. U.S.A. U.S.A. U.S.A. U.S.A. Marktintroductie ? in ontwikkeling (versie 4.0) 1989? SCORE VAN OS'S T.O.V. MUST-CRITERIA Bovenstaande operating systems uit de long-list worden onderworpen aan de mustcriteria. De producten welke voldoen aan alle must-criteria worden opgenomen in de short-list. Indien operating systems echter aan één of meer must-criteria niet voldoen komen ze niet in aanmerking voor opname in de short-list, waardoor het niet nodig is om voor deze operating systems de overige must-criteria nog nader te onderzoeken. Op basis van de must-criteria zijn de volgende operating systems afgevallen: * C EXECUTIVE Multiprocessor wordt door C EXECUTIVE niet op de gevraagde wijze ondersteund. Bovendien heeft het een kleine 'installed base'. Zowel 'bruikbaarheid' als 'toekomstvastheid' als 'openheid van de markt' zijn hierdoor onvoldoende. UITGAVE 1.0 DATUM PAGINA 23

28 H f u H TECH jsfip '" ri1 """* SELECTIE VAN POTENTIËLE OPERATING SYSTEMS ^ r x x ChorusClassiX ChorusClassiX is medio 1996 op de markt gebracht en heeft zich daardoor nog geen significante marktpositie verworven. De 'installed base' is (nog) klein. Door zijn jonge bestaan heeft het nog niet de noodzakelijke 'betrouwbaarheid'. In principe heeft dit RTOS wèl de potentie om tot een geschikt RTOS uit te groeien. Op dit moment is het echter nog te vroeg. Zowel 'toekomstvastheid' als 'openheid van de markt' zijn hierdoor (nog) onvoldoende. irmx Multiprocessor wordt door irmx niet ondersteund. De 'installed base' is relevant (in top 5 van embedded RTOS's) maar het product is in 1995 door Intel afgestoten (officieel aangekondigd als end-of-life) en verkocht aan het bedrijf Radisys. Zowel 'bruikbaarheid' als 'toekomstvastheid' zijn hierdoor onvoldoende. x JavaOS JavaOS is in ontwikkeling en dus nog geen stabiel product. Het is geen RTOS, maar zou dat door toekomstige uitbreidingen wellicht kunnen worden. Multiprocessor kan, afhankelijk van de toegepaste virtual machine, worden ondersteund. - Zowel 'toekomstvastheid' als 'openheid van de mafkf zijn hierdoor (nog) onvoldoende. x x x LynxOS Multiprocessor wordt door LynxOS niet op de gevraagde wijze ondersteund en dan nog slechts op één hardware platform. De 'installed base' is vrij klein maar komt vlak achter de top 5 van embedded RTOS's. Zowel 'bruikbaarheid' als 'toekomstvastheid' als 'openheid van de markt' zijn hierdoor onvoldoende. Nucleus Multiprocessor wordt door Nucleus niet ondersteund. Bovendien heeft het een kleine 'installed base'. Zowel 'bruikbaarheid' als 'toekomstvastheid' als 'openheid van de markt' zijn hierdoor onvoldoende. OS2 OS2 is (net als Windows NT) een uitgebreid disk-geörienteerd RTOS. Het is niet ROM-able. De real-time 'performance' blijft bovendien sterk achter bij die van de typische embedded RTOS's. De 'bruikbaarheid' is hierdoor onvoldoende. UITGAVE 1.0 DATUM PAGINA 24

29 4 'GH TECH SELECTIE VAN POTENTIËLE OPERATING SYSTEMS x x x OS-9 Multiprocessor wordt door OS-9 niet op de gevraagde wijze ondersteund en is slechts mogelijk voor Motorola 68k processors. De 'installed base' is relevant (in top 5 van embedded RTOS's) maar het product is, afkomstig van de eerste plaats, sterk marktaandeel aan het verliezen. Zowel 'bruikbaarheid' als 'toekomstvastheid' zijn onvoldoende. QNX Multiprocessor wordt door QNX niet ondersteund. Het is slechts geschikt voor Intel x86 processors. De 'installed base' is vrij klein maar komt vlak achter de top 5 van embedded RTOS's. Zowel 'bruikbaarheid' als 'toekomstvastheid' zijn hierdoor onvoldoende. RTKernel Multiprocessor wordt door RTKernel niet ondersteund. Het is niet ROM-able. Het is slechts geschikt voor Intel x86 processors, als RTOS-schil bovenop MS-DOS. Bovendien heeft het een kleine 'installed base'. Zowel 'bruikbaarheid' als 'toekomstvastheid' als 'openheid van de markt' zijn hierdoor onvoldoende. x SCOUNTX SCO UNIX is (net als andere uitvoeringen van UNIX) geen RTOS. Het is een ' uitgebreid disk-geörienteerd OS en is niet ROM-able. ^ De 'bruikbaarheid' is hierdoor onvoldoende. x x x SPOX Multiprocessor wordt door SPOX niet ondersteund. Het is is slechts geschikt voor DSP processors. De 'installed base' is vrij klein maar komt vlak achter de top 5. Zowel 'bruikbaarheid' als 'toekomstvastheid' zijn hierdoor onvoldoende. VRTXsa Multiprocessor wordt door VRTXsa niet op de gevraagde wijze ondersteund. De 'bruikbaarheid' is hierdoor onvoldoende. Windows NT Windows NT is (net als OS2) een uitgebreid disk-geörienteerd RTOS. Het is niet ROM-able. De real-time 'performance' blijft bovendien sterk achter bij die van de typische embedded RTOS's. De 'bruikbaarheid' is hierdoor onvoldoende. Uit de gevoeligheidsanalyse (waarin we kijken naar de betekenis van dit resultaat) blijkt dat er slechts één RTOS is dat, indien er één belangrijk must-criterium zou komen te vervallen, alsnog opgenomen zou kunnen worden in de short-list (zie Tabel 3). Het gaat hierbij om VRTXsa dat alleen vanwege het niet voldoen aan het belangrijke multiprocessor must-criterium is komen te vervallen. Dat wil zeggen dat door een wijziging van één van de must-criteria (al dan niet van toepassing verklaren) er geen groot verschil in dit resultaat zou optreden. UITGAVE 1.0 DATUM PAGINA 25