BESTURING EN BEHEER VAN EEN BREEDBAND HUISNETWERK Algemeen model &implementatie in EBIN
auteur
M.C.M. Peeters
Datum
16 juli, 1991
Mentoren
ir. C.M.W. Gabriël ir. J.W. van Hardeveld ir. M.J.M. van Weert Prof. ir. M.P.J. Stevens
PTT Research, Leidschendam Hoofdafdeling Communicatie Systemen (CS) Projectgroep Breedband Abonnee Netten (BAN)
Technische Universiteit Eindhoven (TUE) Faculteit Informatie Techniek (ITE) Vakgroep Digitale Systemen CEB)
(PTT Research) (PTT Research) (TUE) (TUE)
auteur: M.C.M. Peeters
Datum : 16 juli 1991
BESTURING EN BEHEER VAN EEN BREEDBAND HUISNETWERK Algemeen model & implementatie in EBIN
VOORWOORD
Voorwoord Voor u ligt het verslag van mijn afstudeerperiode bij de hoofdafdeling Communicatie Systemen (CS) van PTI Research. Het is de afronding van mijn studie Informatie Techniek (ITE) aan de Technische Universiteit Eindhoven (TUE). In een periode van ruim negen maanden is dit verslag tot stand gekomen. Tijdens deze periode heb ik een flinke portie praktijk ervaring opgedaan. Vanuit de Technische Universiteit Eindhoven ben ik begeleid door prof. ir. M.P.J. Stevens en ir. M.J.M. van Weert. Naar de heer van Weert gaat mijn dank uit voor de goede begeleid- ing vanuit de vakgroep digitale systemen (EB). Vanuit PTI Research ben ik begeleid door Chris Gabriël en JanWillem van Hardeveld. Beide ben ik veel dankverschuld-igd voor de vele reviews van mijn verslagen en andere letteren. Tevens heb ik met hun een gezellige tijd door gemaakt als kamergenoot. De laatste periode van mijn afstuderen heb ik tijdens het implementeren en specificeren samengewerkt met René Nieuwenhuizen, hetgeen een prettige samenwerking was. Verder wil ik alle (ex-)leden, (ex-)afstudeerders en (ex-)stag-aires van de projectgroep Breedband Abbonee Netten (BAN) bedanken voor hun prettige samenwerking tijdens mijn afstuderen. Tevens gaat mijn dank uit naar enkele mensen buiten BAN, met name Jan van Veldhoven, René Wilms en Wouter Segeth.
iv
SAMENVATTING
Samenvatting Dit verslag is het resultaat van mijn afstudeerperiode bij PTI-Research in Leidschendam, van 1 oktober 1990 tot en met 15 juli 1991. Mijn afstudeerperiode is uitgevoerd bij de projectgroep Breedband Abonnee Netten (BAN). Deze projectgroep houdt zich bezig met het realiseren van een Experimenteel Breedband lnhuis Netwerk CEBIN). Met het EBIN-project had men een tweedelig doel voor ogen: Het doel van fase één was het toepassen van de Asynchrone Transfer Mode (ATM) als communicatietechniek op een passieve optische boom. De tweede fase van het EBIN had als doel de diensten van huisnetwerk te demonstreren. Diensten van EBIN zijn kort samengevat het besturen van audio- en video-apparatuur en het veranderen van informatiestromen (audio, video en data) hetgeen impliceert dat verbindingen niet vast liggen. Mijn afstudeerperiode is gestart toen er een optische passieve boom was gerealiseerd waarover ATM als communicatietechniek kon worden toegepast. Op dat ogenblik was er een User Interface (UI) gerealiseerd waarop een gebruiker de status van het netwerk kan aflezen, verbindingen tussen audio- en video-apparatuur grafisch kon weergeven en video- en audioapparatuur grafisch kon bedienen. De koppeling tussen deze twee produkten van het EBIN is de besturing en het beheer. Besturing en beheer van een huisnetwerk moet in het Breedband-Protocol Referentie Model (Breedband-PRM) in de higher layers (in het Nederlands hogere lagen) geplaatst worden. Hiervoor heb ik een algemeen concept opgezet en uitgewerkt. Daarna heb ik het concept toegepast op het EBIN. Voor het concept voor de hogere lagen van het breedband-PRM, dus voor de besturing en het beheer van het huisnetwerk, is gekozen voor de principes van Telecommunication Management Networks CTMN). In mijn concept zijn enkele principes van TMN toegepast. Er is sprake van een distributie van informatie, tevens kan men spreken van een "Object-Oriented" (0-0) oplossing voor het algemene geval. De functionele splitsing van de hogere lagen van het Breedband-PRM is afgeleid van Home Systems (ESPRIT-project). Het concept voor de besturing en het beheer is toegepast op het EB IN. De specificaties van de besturing en het beheer zijn uitgevoerd in Specifications and Description Language (SDL). Deze specificaties zijn geïmplementeerd in MODULA 2. Bij het specificeren en implementeren van het algemene concept is uitgegaan van het algemene concept voor de besturing en het beheer van huisnetwerken. Tevens is de functionele splitsing van de hogere lagen toegepast in het EBIN.
vi
INHOUDSOPGAVE
Inhoudsopgave
BAND 1 1. Inleiding 2. Huisnetwerken 2.1 Inleiding 2.2 Huidige netwerken in huis 2.3 Huisnetwerken 2.3.1 Apparatuur aangesloten aan een huisnetwerk 2.3.2 Kosten baten analyse huisnetwerken · 2.3.3 Ontwikkelingen 2.4 Openbare telecommunicatienetten 2.4.1 Huidige netwerken 2.4.2 ISDN 2.4.3 De referentie configuratie 2.4.4 B-ISDN 2.4.4.1 OSI Referentie Model 2.4.4.2 Asynchronous Transfer Model 2.4.4.3 Het Breedband-Protocol Referentie Model
4 5 5 6 7 11 12 13 13 15 17 18 20 21 22
3. Experimenteel Breedband lnhuis Netwerk 3.1 Inleiding 3.2 Gebruikerseisen 3.3 Topologie 3.4 Functionaliteit Lagere Lagen 3.4.1 ATM binnnen het EBIN 3.4.2 Allocatiemechanisme 3.4.3 Cel-timing 3.4.4 Metasignalering 3.4.5 Signalering 3.5 VME-systeem 3.6 Apparatuur aangesloten aan het EBIN 3.7 Taakstelling UI 3.8 Concepten voor de UI
26 27 27 28 30 30 31 32 32 33 34 34 35 36
4 Diensten 4. 1 Inleiding 4.2 Diensten van het Telecommunicatie netwerk 4.2.1 ISDN Telediensten 4.2.2 ISDN Supplementaire diensten
38 39 39 39 40 viii
Inhoudsopgave 4.2.3 B-ISDN Diensten 4.3 Diensten van het huisnetwerk 4.4 Diensten in EBIN
41 43 44
5 Probleem Analyse 5.1 Inleiding 5.2 Probleemstelling 5.3 Multi-User omgeving 5.4 Inventarisatie huisnetwerken algemeen 5.4.1 General Purpose Communication lnfrastructure (GPCI) 5.4.2 Hogere lagen 5.5 Inventarisatie EBIN 5.6 Taakstelling van de hogere lagen 5.6.1 Relatie met de GPCI 5.6.2 Relatie met de User Interface 5.6.3 Relatie met de apparatuur van het huisnetwerk 5. 7 Systeem analyse
45 46 46 47 48 49 49 51 52 52 52 53 53
6. Algemeen concept van de hogere lagen 6. 1 Inleiding 6.2 Telecommuncation Management Network (TMN) 6.2. 1 Management framework 6.2.2 Systems Management 6.2.3 Manager-Agent model 6.2.4 Managed objects 6.2.5 Management lnformation Base 6.3 Toepassing van het algemeen model op het huisnetwerk 6.3.1 Managed objects van een huisnetwerk 6.3.1. 1 Apparatuur als Managed Objects 6.3.1.2 Verbindingen als Managed Objects 6.3.1.3 Diensten als Managed Objects 6.3.2 lnformation Base CIB) 6.3.3 Fysieke plaats IB 6.3.3.1 IB centraal in het huisnetwerk 6.3.3.2 IB gedecentraliseerd in het huisnetwerk 6.3.3.3 IB gedistribueerd in het huisnetwerk 6.3.4 Naming scheme 6.3.5 Consistent houden informatie tussen manager 6.3.6 Originelen en kopieën 6.3. 7 Common Control & In formation-Protocol
54 55 56 57 58 58 59 61 62 62 63 66 67 67 68 68 69 70 72 72 73 73
ix
Inhoudsopgave 7. Functionele splitsing hogere lagen 7.1 Inleiding 7.2 Node lnitialisation Module (NIM) 7.3 Gommand Language SeNlee Element CCLSE) 7.4 lnformation Base CIB) 7.5 lnformation Base Manager (IBM) 7.6 Message Transfer SeNice Element (MTSE)
76 77 77 78 78 78 79
8. Toepassing van het algemeen model op het EBIN 80 8. 1 Inleiding 81 8.2 Managed Objects in het EBIN 81 8.2. 1 apparatuurobjecten 81 8.2.2 Verbindingsobjecten 82 8.2.3 Luidsprekerpaarobject 83 8.2.4 Dienstobjecten 83 8.2.5 Het manipuleren van objecten 84 8.2.6 Informatie behoefte 84 8.3 Functionele splitsing van de hogere lagen 84 8.4 Gebruikte functionaliteit van lagere lagen 88 8.4.1 Het aansluiten van apparaten 88 8.4.2 Het manipuleren van een verbinding 88 8.5 Overzicht van de hogere lagen in het EBIN 89 8.5. 1 De CLSE 90 8.5. 1. 1 RS232 Interface 91 8.5.1.2 Het leggen van een verbinding 92 8.5.1.3 Het uitbreiden van een verbinding 92 8.5. 1.4 Het verwijderen van een verwijderen 92 8.5. 1.5 Luidsprekerparen 93 8.5. 1.6 Manipulatie van objecten 93 8.5.1.7 Aansluiten van VME-systemen 94 8.5. 1.8 Aansluiten van een macintosh 94 8.5.2 De MTSE 95 8.5.2.1 Het routeren van Cel-berichten 95 8.5.2.1. 1 Unieke objecten 95 8.5.2.1.2 Berichten en bestemmingen 95 8.5.2.1.3 Het verzamelen van routeringsinformatie 97 8.5.2.2 Het associëren van verbindingen en processen 98 8.5.2.3 Coderen en decoderen van Cel-berichten 99 8.5.2.4 Versturen van berichten met ontvangsbevestiging 99 8.5.2.5 Het wijzigen van de netwerkconfiguratie 100 8.5.2.5. 1 Het installeren van VME-systemen 100 8.5.2.5.2 Het verwijderen van VME-systemen 101
x
Inhoudsopgave 9. Conclusies 9.1 Inleiding 9.2 Status van het EBIN 9.2.1 Hardware 9.2.2 De lagere lagen software 9.2.3 De hogere lagen software 9.3 Demonstratie ruimte van het EBIN 9.4 Conclusies
102 103 103 103
103 103 104
106
Literatuurlijst Lijst van Afkortingen
xi
Inhoudsopgave
BAND 2 Appendix A:
Huisnetten
Appendix B:
Functionele splitsing volgens Home Systems
Appendix C:
Recordtypes apparatuurobjecten
Appendix D:
Recordtype verbindingsobject
Appendix E:
Recordtype Luidsprekerpaarobject
Appendix F:
Recordtype Dienstobject
Appendix G:
IBproc.def en IBproc.mod
Appendix H:
SDI-diagrammen
Appendix 1:
MODULA 2 -software
Appendix J:
Codering berichten over RS232-poort
xii
1. INLEIDING
Hoofdstuk 1
Inleiding Wie zou nu niet willen dat hij/zij met een oogopslag op een willekeurig beeldscherm op afstand kan aflezen of de deuren en ramen gesloten zijn en/of op een beeldscherm kan zien welke lichten in huis branden? Dit zijn futuristische zaken die door de internationale ontwikkelingen op het gebied van huisautomatisering (huisnetwerken) steeds dichterbij komen. Tevens zien we een ontwikkeling in het openbare net dat men naar één drager van informatie (audio, video en data) toe wil, een breedbandig openbaar net (B-ISDN). Dit netwerk en zijn voorloper ISDN biedt de abonnees een scala van diensten en mogelijkheden. Het Experimenteel Breedband lnhuis Netwerk-Project (EBINproject) is in de eerste plaats opgestart om de afstemmingproblemen die er zijn bij de koppeling van huisnetwerken en het Breedband-lntegrated Service Digital Netwerk (B-ISDN) te bestuderen. Als we een huisnetwerk bekijken kunnen we dit doen door te kijken naar de functionaliteit van de infrastructuur, maar tevens kan de verschillende apparatuur die op een huisnetwerk kan worden aangesloten als uitgangspunt worden genomen. In de meeste huizen wonen meerdere mensen die gezamelijk gebruik maken van de aanwezige faciliteiten (infrastructuur en apparatuur) in huis. De bewoners moeten ongestoord gebruik kunnen maken van het huisnetwerk met de daaraan gesloten apparatuur, de besturing en het beheer van het huisnetwerk dient hiervoor borg te staan. Tevens willen de bewoners vanuit verschillende kamers in huis de status van het huisnetwerk en aangesloten apparatuur kunnen aflezen en besturen. De infrastructuur van een huisnetwerk biedt de bewoners van een huis de mogelijkheid verbindingen tussen apparaten te leggen en te veranderen naar eigen idee. Vaste verbindingen zullen verdwijnen. De gebruiker geeft aan dat er verbindingen moeten worden gelegd, middels interactie met de User Interface (UI). De besturing en het beheer van
2
Hoofdstuk 1
Inleiding
een huisnetwerk moet dan zorg dragen dat de nodige acties worden ondernomen en dat alle Ul's in het huisnetwerk geaktualiseerd worden. Bjj het aanpassen van een verbinding zullen tevens de nodige acties moeten worden ondernomen om de verbindingen aan te passen. Van de eventuele aanpassingen en resultaten moeten alle Ul's op de hoogte worden gesteld. Bij het besturen en het beheren van de aangesloten apparatuur moet de gebruiker geen weet hebben hoe de daadwerkelijk bediening van een apparaat in zijn werk gaat. Het huisnetwerk biedt een uniforme bediening op de UL de manipulaties die de gebruiker pleegt op het apparaat via de UI worden door de besturing en het beheer vertaald naar acties op het apparaat. Voor de besturing en het beheer van een huisnetwerk mag het niet uit maken van welke fabrikant de apparatuur afkomstig is. De besturing en het beheer van een huisnetwerk is een zeer belangrijk onderdeel van het huisnetwerk. Dit verslag behandelt het ontwerp van een algemeen concept voor de besturing en het beheer van een algemeen huisnetwerk en de toepassing van dit concept in het Experimenteel Breedband lnhuis Netwerk CEBIN).
3
2.
NETWERKEN
Hoofdstuk 2.
Netwerken
2.1 Inleiding In dit hoofdstuk worden de algemene doelstellingen van huisnetwerken toegelicht. Allereerst wordt de huidige situatie in huis bekeken waardoor de aanleiding voor onderzoek naar huisnetwerken duidelijk wordt. Aan de hand van de apparatuur die zich in een huisnetwerk bevindt wordt duidelijk gemaakt welke diensten er door een huisnetwerk geleverd worden. Tevens wordt er een opsomming gegeven van punten die essentieel zijn voor een succesvolle invoering van huisnetwerken in onze thuissituatie. In het tweede gedeelte van dit hoofdstuk wordt ingegaan op de telecommunicatie netten in Nederland. De ontwikkelingen die we daarin zien zijn een drijfveer voor het onderzoek naar huisnetwerken.
2.2 Huidige netwerken in huis Als we momenteel in ons huis rondkijken en letten op de aanwezige netwerken, zien we daarin een grote verscheidenheid. Zo is er het 220 Volt voedingsnetwerk, waarop men allerlei soorten apparatuur kan aansluiten. Apparaten kunnen onderling weer een netwerk vormen met hun eigen transmissietechniek en informatiesoort. Een computer en printer worden onderling verbonden door een datakanaaL Een versterker en CD-speler hebben onderling een verbinding waarover audio getransporteerd kan worden. Een TV en Videorecorder kunnen onderling videocommunicatie plegen. Op het moment zijn de meeste huizen aangesloten op een centraal kabelnet CCATV). Een CATV aansluiting bestaat uit twee signalen: één voor het radio-signaal en één voor het tv-signaal. Een dergelijke CATV-aansluiting wordt vaak in woonhuizen vertakt, hetgeen betekent dat er aansluitpunten bijkomen.
5
Hoofdstuk 2.
Netwerken
In 95 °/o van de Nederlandse woningen is een telefoonaansluiting aanwezig. Mensen leggen een telefoonnetwerk in huis aan, om bijvoorbeeld rustig te kunnen telefoneren en/of op verschillende plaatsen in huis de telefoon te kunnen beantwoorden. In de meeste woningen vind je enkele afstandsbedieningen. Deze vormen welliswaar nog geen netwerk in huis, maar voegen wel een extra communicatietechniek CRemote Control systeem voor Philips CRC5), Damestic Digital Bus CD2B)) aan het huis toe. Als men vanuit deze optiek een woonhuis bekijkt treft n'len toch een zekere overbedrading en inefficiënt apparatuurgebruik aan. Zo zijn er in huis verschillende soorten informatiedragers te vinden welke dezelfde informatiesoort transporteren (telefoon- en audiokabel transporteren beide geluid). In een huis zijn ook apparaten te vinden met dezelfde functionaliteit die echter niet kunnen worden uitgewisseld, daar de communicatietechniek niet gelijk is (zoals het antwoord apparaat van de telefoon en het cassettedeck). Meer voorbeelden van apparatuur die dezelfde functionaliteit hebben en dus eigenlijk elkaar moet kunnen vervangen zijn te vinden in tabel 2. 1. Deze inefficiëntie heeft er onder andere toe geleid dat men is gaan nadenken over huisnetwerken waarin maar één netwerk aanwezig is waarop alle apparatuur aangesloten kan worden. In Tabel 1.1 ziet men tevens dat apparatuur in de linker kolom overbodig is in een huisnetwerk. De apparatuur in de linker kolom moet echter uit evolutieoogpunt toch aangesloten kunnen worden op een huisnetwerk.
2.3 Huisnetwerken Een huisnetwerk is een voorziening in huis waaraan men verschillende apparaten (elektrisch van aard) kan koppelen, zodat informatie (beeld, geluid en data) tussen apparatuur kan worden uitgewisseld. Doordat er een koppeling met het
6
Hoofdstuk 2.
Netwerken
Tabel
2.1
Vervangbare apparaten
I Vervangbare apparaten
11
Apparaten
Telefoon
Microfoon & Luidspreker
Telefoonbeantwoorder
Cassettedeck
Monitor PC
TV Monitor
Geïntegreerde TV luidsprekers
Luidsprekers Stereoinstallatie
Tijdschakelaars
PC
Klokradio
Stereoinstallatie & PC
Picturefoon
TV monitor, luidsprekers, camera en microfoon
openbare telecommunicatienet mogelijk is, kan het huisnetwerk gebruik maken van de diensten die het openbare net biedt. Tevens betekent dit dat een gebruiker van buiten het huis ook toegang tot het huisnetwerk kan hebben. Het doel van een huisnetwerk is echter niet enkel het transporteren van informatie. Met behulp van een huisnetwerk moet de aangesloten apparatuur kunnen worden bediend. Buiten de diensten die door het openbare net worden geboden, worden er door het huisnetwerk in huis ook nog extra diensten geboden, zoals het automatisch gewekt worden door favoriete muziek. De diensten van het huisnetwerk kunnen bijvoorbeeld ook (door middel vanhard-en/of software) automatisch in werking treden, bijvoorbeeld het automatisch bellen van de brandweer bij brand. 2.3. 1 Apparatuur voor het huisnetwerk
In paragraaf 2.2 "Huidige netwerken in huis" is reeds gesproken over de apparaten die men in een huis allemaal kan tegenkomen. De apparaten die men aan een huisnetwerk kan aansluiten zijn te verdelen in zes categorieën: • Witgoed;
7
Hoofdstuk 2.
Netwerken In deze categorie van huishoudelijke opporaten vindt men opporaten die voor één specifiek doel zijn ontworpen en waorop de besturing tevens is afgesteld. Voor iedere huishoudelijke taak wordt een opporoot ontwikkeld. Het gevolg hieNon is dot er een groot aantol verschillende opporaten en gebruiksvoorwerpen is. De aandocht van ontwikkelaars richt zich voorol op een zo loog mogelijk energieverbruik. De aandocht voor signalering is minimaal; enkele koelkosten of diepvriezers geven een melding als de deur open blijft staan. Voor het automatiseren van witgoed is voorol de magnetronoven interessant. Bijvoorbeeld het 's avond op afstond instellen van de magnetron, waarin men 's ochtens de maaltijd heeft geplaatst. • Bruingoed; De witgoedprodukten van een huisnetwerk zijn voorol te vinden in de keuken en het washok. De bruingoed produkten zijn voorol te vinden in de woonkamer. De doeleinden wooNoor deze opporaten zijn ontworpen, zijn onder te verdelen in drie categorieën: o Ontspanning (Entertainment).
o Informatie-inwinning. o Educatie.
Vroeger was er alleen sproke van losstaande apparatuur, tegenwoordig ziet men steeds vaker complete audiovisuele installaties. Een uniforme koppeling van audio-opparatuur is reeds in een vroeg stadium ontstaan (Duitse Industrie Norm (DIN)). Tegenwoordig is het ook mogelijk om video-opparatuur van verschillende fabrikanten op elkoor aan te sluiten via de SCARToonsluiting. Tevens was het tot voor kort niet mogelijk om met de afstandsbediening van de ene fabrikant het opporoot van de andere fabrikant te bedienen. Nu ziet men echter een trend richting universele, pro-
8
Hoofdstuk 2.
Netwerken
grammeerbare afstandbedieningen en standaardisatie tussen fabrikanten onderling. Een belangrijke ontwikkeling is die van de Dornestic Digital Bus (D2B). Dit is een door Philips ontwikkelde norm voor de besturing van gekoppelde audio- en videoapparatuur. • Grijsgoed; Dit zijn apparaten zoals personal computers en bijbehorende randapparatuur. In tegenstelling tot de verwachtingen valt de populariteit van personal computers in westerse huishoudens sterk tegen. De penetratie van deze apparaten in woonhuizen was medio 1987 ongeveer 12%. Dit is volgens Pradére (PAD88) met name te wijten aan: o
Gebrek aan standaardisatie.
o Complexiteit. o Gebrek aan aantrekkelijke applicaties. o Snel veranderende technologie.
Enkele toepassingen van de computer in huis zijn: o
Tekstverwerking De computer is de opvolger van de typemachine.
o Entertainment
De computer wordt door jong en oud gebruikt voor computerspelletjes. o Educatie
Er zijn programma's op de markt waarmee kinderen spelenderwijs kunnen leren. De software wordt ook wel aangeduid met de term edutainment. o
Tele-arbeid en thuiswerk Een van de redenen van bedrijven om PC-privé
9
Hoofdstuk 2.
Netwerken
projecten te starten is om de mensen thuis wegwijs te laten maken met een computer. Tevens wordt door de aanwezigheid van een computer, bij werknemers, tele-arbeid gemakkelijker. o
Communicatie Middels een modem kunnen mensen met andere computerbezitters en bulletinboards communiceren. Daarnaast worden PTI-diensten geboden waardoor het bezit van een PC nog aantrekkelijker wordt, zoals: girotel, viditel, etcetera.
• Beveiligings apparatuur; Beveiliging wordt door de meeste mensen gezien als belangrijkste reden voor de aanschaf van een huisnetwerk (HS91). De beveiliging van de bewoners en hun eigendommen behoort dan ook zeker tot de functies van een geautomatiseerd huis. Verschillende sensoren kunnen rook, temperatuurverhogingen, wateroverlast (lekkage) en de aanwezigheid van personen detecteren. De beveiligingsinstallatie kan in eerste instantie de bewoner en eventueel in tweede instantie de politie of brandweer waarschuwen. Het is belangrijk dat de beveiligingsinstallatie de bewoners zo min mogelijk hindert in het uitvoeren van de dagelijkse activiteiten. Het inbraakalarm mag niet reageren op de aanwezigheid van de "normale" bewoners. • Klimaatbeheersings apparatuur; Als we spreken over het klimaat van de woning kunnen we drie factoren onderscheiden: o
Temperatuur; In het Nederlandse klimaat denken we hier meestal aan verwarming, maar er zijn ook gebouwen waarin koelinstallaties zijn opgenomen.
o
Luchtvochtigheid; het regelen van de luchtvochtigheid bij zogenaamde "droge" lucht.
10
Hoofdstuk 2.
Netwerken o
Luchtkwaliteit; Hierbij kan gedacht worden aan de hoeveelheid stofdeeltjes in de lucht, maar ook aan schadelijke stoffen.
Door middel van moderne elektronica is het mogelijk om de woning te voorzien van een klimaatbeheersings-installatie waarmee de bovengenoemde parameters kunnen worden gemeten en geregeld.
• Meters van de nutsbedrijven; Bij elektriciteits- en gasbedrijven is men bezig met het automatiseren van het uitlezen van de meterstànd (0LS91). Dit sluit aan bij de ontwikkeling van het geautomatiseerde huis. Er zijn apparaten die in meer dan één categorie voorkomen. De CD-speler C bruingoed ) kan, als deze gebruikt wordt als CD-ROM voor de persenol computer, in de categorie grijsgoed vallen. De indeling in categorieën kan men weer afspiegelen op een vijftal toepassingsgebieden (ZWE90):
• Energiebeheer. • Ontspanning. • Brand- en inbraakbeveiliging. • Huishoudelijke apparaten en verlichting. • Telecommunicatie.
2.3.2 Kosten en baten huisnetwerken We hebben nu een aantal produktcategorieën (witgoed, bruingoed, grijsgoed, beveiliging, klimaatbeheersing en meteruitlezing) gezien en de bruikbaarheid in verscheidene toepassingsgebieden (Energiebeheer, Ontspanning, Branden inbraakbeveiliging, Huishoudelijke apparaten en verlichting, Telecommunicatie).
11
Hoofdstuk 2.
Netwerken
Met huisnetwerken willen we een gemeenschappelijke gestandaardiseerde communicatie infrastructuur aanbieden. Het huisnetwerk is ontworpen om een huis aan de volgende algemene menselijke behoeften te laten voldoen (HS 91): • Produktiviteit. • Ontspanning ( entertainment ). • Gerieflijkheid (Comfort). • Geldbesparing (Energie beheer). • Gemoedsrust (veiligheid en beveiliging). • Communicatie. Voor het slagen van de invoering van huisnetwerken zal aan de bovengenoemde punten moeten worden voldaan. Het is belangrijk dat de consument de voordelen en de meerwaarde van het systeem ziet en daardoor tot aanschaf overgaat. Voor de consument is dit een kosten-baten analyse. Over de invoering van huisnetwerken en de daarbij betrokken kosten-baten analyse zal in latere hoofdstukken meer aandacht worden besteed. Bij het ontwerpen van een huisnetwerk of essentiële delen daarvan, zal men met deze punten van te voren rekening moeten houden. 2.3.3 Ontwikkelingen
Op het ogenblik zijn op gebied van huisnetwerken vele ontwikkelingen gaande. Er worden vele standaarden door verschillende commissies in onderzoek-programma's in de VS, Europa en Japan ontwikkeld. Een opsomming hiervan is te vinden in appendix A en (BAA 91).
12
Hoofdstuk 2.
Netwerken
2.4 Openbare telecommunicatienetten In deze paragraaf wordt een overzicht gegeven van de huidige situatie van de telecommunicatie en de ontwikkeling daaNan in de toekomst. Figuur 2.1 geeft een overzicht. Diensten
Netten
1991/93
1995 e.v.
Spraak Tekst S-ISDN Data
B-ISDN
Beeld Radio/TV
Kabel TV
Figuur 2.1 Evolutie van het Telecommunicatie net. 2.4. 1 Huidige Netwerken • Telefoonnet Anno 1991 heeft ca. 95 % van de Nederlandse woningen een aansluiting op het openbare telefoonnet. Buiten transport van het gesproken woord kan het telefoonnetwerk ook gebruikt worden voor datatransport, telefax en videotex. HieNan wordt in de meeste huishoudens weinig gebruik gemaakt. Het huidige telefoonnetwerk heeft slechts een geringe bandbreedte. Over een gewone telefoonlijn kan data met een snelheid van 2400 bit/sec tot en met 9600 bit/sec worden verzonden. • Telexnet De telexdienst verkeert aan het einde van zijn levenscyclus. door het gebruik van telefax en de beschikbaarheid van een goed telefoonnet. Het telexnetwerk pUlresearch . . .
~
13
Hoofdstuk 2.
Netwerken heeft 40.000 aansluitingen in Nederland. De transmissiesnelheid over het telexnet bedraagt thans maximaal 50 bit/sec.
• Datanet Het Datanet 1 kent momenteel ongeveer 12000 abonnees. De maximale transmissiesnelheid is 64 Kbit/sec bij een rechtstreekse aansluiting op een van de centrales in Amsterdam, 's Gravenhoge of Arnhem. Bij een aansluiting op een van de zogenaamde sattelietcentrales bedraagt de maximale snelheid 9600 bit/sec. Het datanet werkt met een techniek die packet-switching wordt genoemd. De dienstverlening van Datanet1 richt zich de komende jaren steeds meer op de toepassingen waarbij een relatief geringe hoeveelheid data met hoge integriteit moet worden overgebracht. Dat betreft voornamelijk financiële transacties, zoals betaalautomaten, maar kan ook betrekking hebben op het raadplegen van bestanden. • Mobiele net Het mobiele net is sterk in opkomst en kent meer dan honderdduizend abonnees. Het wordt gebruikt voor semafonie, mobilofonie, marifonie en autofonie. Over het hele land zijn zend/ontvangbases verspreid, waar het mobiele net gekoppeld is aan het telefoonnet. Tussen basis en abonnee wordt gebruik gemaakt van een radioverbinding. • Kabelnet Een andere vorm van openbare netten wordt gevormd door de kabelnetten (radio en televisie). Op dit moment is ongeveer 70 % van de Nederlandse huishoudens aangesloten op zo'n analoog breedbandig netwerk. Het betreft hier, in tegenstelling tot de communicatie over het andere openbare netten, éénrichtingsverkeer (distributie). Er zijn proeven met twee richtings verkeer. De kabelnetten worden geëxploiteerd door zelfstandige kabeltelevisiemaatschappijen, terwijl de hiervoor behandelde netten worden geexploiteerd door de PTI. Een regeringscommissie, de commissie Zegveld, heeft geadviseerd deze netwer-
14
Hoofdstuk 2.
Netwerken
ken in de toekomst te integreren in één PTI-netwerk.
• Videoconferendng net Voor videoconferencing is een 2 Mbit/sec infrastructuur aanwezig voor afwikkeling van deze dienst. Er wordt ook gebruik gemaakt van satelliet verbindingen (project EVE: Europeaan Videoconferencing Experiment). Tabel 2.2 Overzicht huidige netwerken ([ISDN86] EN [TEL91])
I
Overzicht netten :
Aantal aansluitingen:
mobiel net
105
mobilofonie, semafonie
telefoonnet
7 * 106
telefonie, videotex, data
datanet
12 * 103
packet switched data
telexnet
3 .. 104
telex
alarmnet
?
alarmering
videoconferencingnet
102
videoconferentie, computercommunicatie
kabelnetten
4 * 106
distributie beeld en geluid
Diensten:
I
Een overzicht van deze netten is te zien in tabel 2.2. 2.4.2 ISDN
Halverwege de jaren negentig zullen de bestaande PITtelecommunicatienetten (zie figuur 2.1, pagina 13) worden geïntegreerd tot één netwerk, het ISDN (lntegrated Services
15
Hoofdstuk 2.
Netwerken Digital Network). Het betreft een digitaal netwerk waarover meerdere diensten kunnen worden geboden. De diensten kunnen in twee hoofdgroepen worden verdeeld: • Netwerkdiensten (Bearer services) • Telediensten
(Teleservices)
De netwerkdiensten omvatten de schakel- en transmissiediensten, waar de gebruiker zelf weinig van merkt. De telediensten zijn de diensten waar de gebruiker wel mee te maken heeft, zoals telefonie, telefax en videotex. Er wordt ook nog een tweede indeling gehanteerd: • Basis diensten
(basic services)
• Supplementaire diensten
(supplementary services)
Op deze diensten wordt in paragraaf 3.2 verder ingegaan. Per ISDN aansluiting is het mogelijk maximaal acht toestellen aan te sluiten (telefoontoestel, telefax, personal computer etcetera). De aansluiting bestaat uit drie aparte kanalen: • Twee datakanalen
(de 8-kanalen)
• Eén signaleringskanaai
(het 0-kanaa()
Het voordeel hiervan is dat een abonnee schijnbaar twee buitenlijnen (B-kanalen) ter beschikking heeft. Door de aanwezigheid van de tweeB-kanalen is het mogelijk gelijktijdig te telefoneren en te faxen. Door het aparte D-kanaal is een abonnee ook tijdens het telefoon gesprek voor signalering bereikbaar. De maximale transmissiesnelheid van digitale signalen over de ISDN aansluiting bedraagt 144 Kbit/sec. De abonnee beschikt over twee B-k analen van ieder 64 Kbit /sec en één D-kanaal van 16 Kbit/sec. Met deze capaciteit is het onder andere niet mogelijk hoge kwaliteit videobeelden over te zenden.
16
Hoofdstuk 2.
Netwerken 2.4.3 De referentie configuratie Complexe systemen worden vaak in verschillende functionele eenheden verdeeld, onderling gescheiden door middel van koppelvlakken, omdat dit bij ontwerp, fabricage en bedrijfsvoering belangrijke voordelen geeft. Exacte definitie van de functie van iedere module is in zo'n situatie noodzakelijk. In de praktijk onderscheidt men fysieke koppelvlakken van functionele koppelvlakken. Hiermee wordt uitgedrukt dat een fysiek koppelvlak een tastbaar uitgevoerde koppeling tussen apparaten is. Een functioneel koppelvlak geeft aan welke functies aan beide zijden worden uitgevoerd zonder in te gaan op de praktische uitvoering van de koppeling tussen de apparatuur of de programmatuur die deze functies verricht.
LT HET R
•
~
ET = Exchange Terminatien LT = Line Terminatien NT = Netwerk Terminatien TE = Terminal Equipment TA= Terminal Adapter
Figuur 2.2 De referentie configuratie Over de koppelvlakken S en T worden de procedures vastgelegd waarmee de eindapparatuur toegang tot het net kan verkrijgen. Het is belangrijk het aantal verschillende koppelvlakken zo klein mogelijk te houden. De plaats van de functionele koppelvlakken in de ISDN-installatie wordt aangegeven in een referentie-configuratie, zie figuur 2.2. Aan de kant van de centrale worden twee functionele eenheden gedefinieerd. De ET-eenheid verzorgt de centrale functie van de centrale en de LT-eenheid verzorgt de eenpUlresearch ;,
...
17
Hoofdstuk 2.
Netwerken
trale transmissie. Het $-referentiepunt geeft de plaats aan van het fysieke koppelvlak, waarop een ISDN-eindapparaat (TE 1) wordt aangesloten. Apparatuur die niet is voorzien van zo'n standaard koppelvlak (TE2) wordt via een terminal-adaptor (TA) aangesloten. De NT verzorgt aan de ene kant de aansluiting van de verschillende terminals (TE) en anderzijds voor de transmissiefunctie. Daarom wordt de NT onderverdeeld in de NTl, waar de aanpassing plaats vindt van de signalen op het huisnetwerk en de signalen van de abonneelijn, en de NT2, waar de signalen van de NTl worden gedistribueerd over de verschillende terminals. Bij een eenvoudig huisnetwerk is de NT2 eigenlijk niet meer dan een kabel door het huis met op verschillende plaatsen connectoren voor de aansluiting van terminals. In dat geval wordt meestal gesproken van $-bus. 2.4.4 8-ISDN
Er is momenteel een vraag naar breedbanddiensten als LAN-interconnection en video-conferencing. Voor onze woonhuizen is beeldtelefonie een voorbeeld van een potentiële toepassing. Er zal een goede infrastructuur moeten komen die deze diensten kan bieden. Het smalbondige ISDN zal daarom uitgroeien naar een breedbandig ISDN (B-ISDN). Het B-ISDN zal mogelijk nog een extra functie krijgen wat het tot een echt geïntegreerd diensten net maakt; het verzorgen van distributieve diensten, bijvoorbeeld televisie en radio. Ook deze functie kan in een B-ISDN worden geïntegreerd. Echter in hoeverre dit uiteindelijk doorgang zal vinden hangt mede af van de ontwikkelingen op het gebied van satellietcommunicatie en kabel-TV. Een B-ISDN moet toekomst vast zijn, daarvoor moet een ontwerp van een breedbandig netwerk aan de volgende eisen voldoen: • Flexibiliteit.
18
Netwerken
Hoofdstuk 2.
Tabel 2.3 Eigenschappen van diensten
I Eigenschap Breedband bursty
H
11 H
smalband
continue
conneetion oriented nectionless
I
Voorbeeld beeld
H
spraak
LAN interconnection foon {PCM) H
con-
H
tele-
telefonie post
H
electronische
interactief
H
distributief
telefonie
H
TV
punt-punt
H
'multi-punt'
telefonie
H
tele-conferencing
mobiel
immobiel
H
autotelefonie
H
telex
De belangrijkste eis die aan het netwerk wordt gesteld is de flexibiliteit. Het netwerk moet veel, zo niet alle, bestaande en toekomstige diensten kunnen aanbieden. Wil het netwerk deze diensten kunnen aanbieden, dan moet het aan de eisen voldoen, die de verschillende diensten aan het netwerk stellen. Tabel 2.3 geeft een overzicht van verschillende eigenschappen die een dienst kan hebben.
• Evolutie: Het netwerk moet kunnen evolueren. Het netwerk moet gemakkelijk nieuw ontwikkelde diensten kunnen toelaten; nieuwe diensten worden altijd ontwikkeld: nieuwe technologische ontwikkelingen zijn drijfveren achter nieuwe diensten en standaarden (bijvoorbeeld HDN). Evolutie-flexibiliteit is ook vereist op economische gronden: netwerken vergen enorme investeringen die pas op de lange duur kunnen worden terugverdiend. Naast de hoofdeis ten aanzien van flexibiliteit en evolutie mogelijkheden van het netwerk komen natuurlijk nog een aantal voor min of meer zich sprekende eisen: efficiëntie, betrouwbaarheid, kosten, etc.
19
Hoofdstuk 2.
Netwerken Samenvattend: Gezien de beperkingen van S-ISDN en nieuwe telecommunicatie mogelijkheden en behoeften moet breedband ISDN worden ingevoerd. Bij de ontwikkeling van een nieuwe dienst moet echter niet de behoefte aan een uitbreiding van het B-ISDN rijzen. In de volgende paragrafen wordt dé communicatie techniek voor B-ISDN toegelicht: Asynchronous Transfer Mode CATM) tevens wordt het Breedband-Protocol Referentie Model (Breedband-PRM) uit de doeken gedaan in zoverre dit van nut is voor het begrip van dit verslag. Alvorens ik het Breedband-PRM toelicht moeten de principes van het Open System lnterconnecting-Referentie Model (OSI-RM) duidelijk zijn. I
I
2.4.4. 1 051 Referentie Model Het principe waarop OSI berust is het ontwerpen van een netwerk als een opeenvolging van lagen. Zo wordt een studie van het geheel gereduceerd tot een studie van de lagen en het hele proces wordt daardoor beter handelbaar. Het idee komt van Julius Caesar: "Verdeel en Heers". Het doel van een laag is bepaalde services te bieden aan hoger liggende lagen en deze lagen af te schermen van details over hoe de lager liggende lagen functioneren. Het OSI model bestaat uit zeven lagen. De principes die ten grondslag liggen aan de gelaagdheid zijn: 1. Een laag moet gecreëerd worden als een andere laag van abstractie nodig is. 2. Elke laag moet een goed gedefinieerde functie hebben. 3. De functie van iedere laag moet gekozen worden met het oog op het definieren van internationaal gestandcriseerde protocollen. 4. De laaggrenzen moeten zó gekozen worden dat de informatie die tussen de
20
Hoofdstuk 2.
Netwerken lagen vloeit geminimaliseerd wordt. 5. Het aantal lagen moet groot genoeg zijn om verschillende functies die niet bij elkaar genomen moeten worden ieder in een laag onder te brengen en klein genoeg om de architectuur hanteerbaar te houden.
2.4.4.2 Asynchronous Transter Mode (ATM) Zowel aan een B-ISDN als aan een huisnetwerk moeten gemakkelijk nieuwe diensten kunnen worden toegevoegd.· Na een grondig onderzoek, onder andere in Research on Advanced Communications in Europe (RACE) verband, is gebleken dat ATM hiervoor de meest geschikte communicatietechniek is om toe te passen in een breedbandig netwerk. In de (toekomstige) openbare ATM-netwerken is een ATMcel gecodeerd als in figuur 2.3.
;.; ••:Z:.Y
j
:<:·•<...t I
VPt
VPI VCI
PT HEC
VPI/' VCl
VCl
· F'Ti R..l I
I
:
I
HEC
INFOAMATlE
I
Virtual Path ldéntifier, geeft aan welk (virtueel) pad wordt gebruikt. Virtual Channel ldentifier, geeft aan bij welk (virtueel) kanaal de cel hoort. Payload Type, geeft aan wat voor inhoud de cel heeft. Header Error ControL controlegetal om de fouten in de header te detecteren.
figuur 2.3 Codering van een ATM - cel Bij deze keuze waren de volgende eigenschappen van ATM doorslaggevend:
ptt research .
.
21
Hoofdstuk 2.
Netwerken
• dynamische bandbreedte. • geringe overhead. • distributieve diensten zijn mogelijk. • geen directe tijdsrelatie nodig in het netwerk tussen zenden en ontvangen van informatie (kan ook een nadeel zijn). ATM maakt gebruik van datapaketten (cellen). Hierdoor is er geen vaste bitsnelheid. De bandbreedte van een kanaal kan worden gevarieerd door meer of minder cellen te versturen. Bij het verzenden van cellen wordt gebruik gemaakt van tijdsloten. De bestemming van de cel wordt niet bepaald door de frequentie, maar door het bestemmingsadres in de header van de cel. 2.4.4.3 Het Breedband-Protocol Referentie Model
Het breedband protocol referentie model is gebaseerd op de zelfde principes als het OSI-PRM. Bij een vergelijking van deze twee PRM moet men zich bewust zijn van het verschil in gebruik van deze twee modellen. Het abstracte OSI-PRM biedt een gereedschap voor het modelleren van datacommunicatie, terwijl het de bedoeling van B-ISDN is om de gebruiker alle mogelijke diensten te kunnen bieden. Het OSImodel is georiënteerd op computer-communicatie, daar tegenover staat dat het breedbandnetwerk ontworpen is om telediensten en extra functies te ondersteunen, waarbij ATM als uitgangspunt is genomen. Het OSI-referentiemodel biedt een abstract conceptueel en functioneel raamwerk voor het ontwerp van computercommunicatie standaarden van elke laag en heeft niet de intentie om te dienen als een implementatie-specificatie. In B-ISDN, wordt ATM als communicatietechniek gebruikt, daardoor moeten bepaalde implementatie aspecten die ATM oplegt worden meegenomen.
22
Hoofdstuk 2.
Netwerken
I
I
I
I I
Hlrg.,_ Laye,.
,
HIIJher Lay•,.
i
A TM Adaptation lay«
Figuur 2.4 B-ISDN Protocol Referentie Model Het Breedband-PRM uit figuur 2.4 bestaat uit de volgende lagen: • Physical layer
De physieke laag verzorgt het transport van cellen tussen direct verbonden netwerkknooppunten. De Service Data Units (SDU 's) die door de physieke laag worden verwerkt, zijn ATM-cellen. De physieke laag kan eventueel worden onderverdeeld in sublagen waarvan de onderste sublaag overeenkomt met de fysieke laag van het OSI referentie model. • ATM layer
De ATM-Iaag bevat functies die gemeenschappelijk zijn aan alle diensten. De belangrijkste taak is het verzorgen van communicatie, hetgeen neer komt op het aan elkaar knopen van virtuele kanalen, het routeren van cellen, het verwijderen van foutieve cellen, genereren van de HEC codering, detecteren van congestie, etcetera. De grens tussen de ATM-laag en de ATM Adoptie-laag correspondeert met de grens tussen headerfunctie en functie van het informatieveld.
pUiresearch
23
Hoofdstuk 2.
Netwerken • ATM Adaption Layer (AAL) De functies van de Adoptie-laag zijn dienstafhankelijk. De verschillen tussen 'Constant Bit Rate' (CBR) diensten en 'Variable Bit Rate '(VBR) diensten zijn evident en komen in de AAL dan ook tot uiting. • Higher foyers De hogere lagen dragen zorg voor call controL conneetion control en netwerk supervisie functies. De definitieve invulling van de verschillende lagen van het breedband protocol referentiemodel is nog steeds een onderwerp van discussie tussen de verschillende standaardisatie organen en onderzoeksprojecten (bijvoorbeeld CCITI, ETSI, ANSI, RACE, COST). Tevens bestaat het Breedband-PRM uit drie vlakken: • user plane Het user plane, met zijn gelaagde structuur, draagt zorg voor de overdracht van gebruikersinformatie en de bijbehorende controles (bijvoorbeeld flow controL fouten correctie). • control plane Dit vlak heeft een gelaagde structuur en draagt zorg voor decall control en conneetion control functies. In dit vlak wordt de signalering, nodig voor het opzetten. beheren en afbreken van calls en connecties, afgehandeld. Het verschil, indien aanwezig, tussen locale en globale control plane functies in de breedband omgeving is voor verdere studie. • management plane Het management plane verzorgt twee types van functies; Plane management functies; het plane management voorziet in managementfuncties die gerelateerd zijn aan het systeem in z'n geheel en verzorgt coördinatie tussen de lagen onderling. Layer management functies; layer management verzorgt functies (bijvoorbeeld meta-signalering) garelateert aan de resources en parameters aanwezig in
24
Hoofdstuk 2.
Netwerken
de protocollen Het concept van user plane, control plane en management planeis afkomstig van het smalband ISDN-PRM.
25
3. EXPERIMENTEEL BREEDBAND INHUIS NETWERK
Hoofdstuk 3.
Experimenteel Breedband lnhuis Net
3.1 Inleiding In de projectgroep Breedband Abonnee Netten (BAN) wordt sinds 1987 gewerkt aan de realisatie van een Experimenteel Breedbandig lnhuis Netwerk (EBIN). Met hetEBINwil men de mogelijkheden van huisnetwerken demonstreren. Het experimentele net bestaat uit een passief optisch boomnetwerk waarover data wordt getransporteerd met een (bruto) snelheid van 155,52 MBit/s (netto 140 Mbit/s). De aan te sluiten terminals zijn relatief eenvoudige apparaten die geschikt zijn voor het verwerken van een dienstcomponent (video, audio, etcetera). Vanwege de voordelen die optreden bij het toepassen van ATM (zie 2.4.4.2 "Asynchronous Transfer Mode") in het B-ISDN heeft men binnen de projectgroep BAN besloten om van deze communicatietechniek in het EBIN gebruik te maken. De realisatie van hetEBINis verdeeld in twee fasen:
Fase 1
Het hoofddoel van fase 1 is het aantonen van de realiseerbaarheid van ATM-technieken in een passieve optische boomstructuur. Fase 1 is succesvol afgerond.
Fase 2
In fase 2 wordt sterk de nadruk gelegd op de diensten en de gebruikersaspecten van het netwerk, en zal een integratie met audio- en videodiensten worden gerealiseerd.
Mijn afstudeer periode is gestart tegen het einde van fase 1.
3.2
Gebruikerseisen
Het EBIN is ontworpen aan de hand van een aantal punten die gebruikers van een dergelijk netwerk wenselijk zouden vinden: •
flexibele uitbreiding van het netwerk en diensten
•
koppeling met het openbare communicatienet
27
Hoofdstuk 3.
Experimenteel Breedband lnhuis Net
•
(gelijktijdig) gebruik van meerdere diensten
•
toekomstzekerheid
•
aansluiten bij standaardisatie
•
mogelijkheid van aanleggen in een bestaand huis
•
eenvoudige bediening
3.3 Topologie In een huisnetwerk moet het op een eenvoudige manier mogelijk zijn om extra aansluitpunten voor nieuwe apparatuur te installeren. Dit zou op dezelfde manier kunnen gebeuren als bij het spanningsnet, waar gemakkelijk nieuwe stopcontacten of verlengsnoeren kunnen worden geplaatst. Voor communicatienetwerken kunnen verschillende topologieën worden gekozen Czie figuur 3.1 ):
•
maasvormig netwerk
Cfiguur 3.1a)
•
ringvormig netwerk
Cfiguur 3.1b)
•
stervormig netwerk
(figuur 3. 1c)
•
busvormig netwerk
(figuur 3.ld)
(a)
f1guur 3. 1 Mogelijke Tapologieën voor netwerken ptt Iresearch ~
.
.
..
28
Hoofdstuk 3.
Experimenteel Breedband lnhuis Net Een maasvormig netwerk heeft als groot fysiek nadeel dat bij een uitbreiding zeer veel verbindingen moeten worden gelegd. Een logisch nadeel van een ringvormig netwerk is het feit dat één defecte of storende terminal het gehele netwerk ophoudt of stoort. Een fysiek nadeel van een sternetwerk is dat het moeilijk uit te breiden is omdat alle verbindingen naar de centrale terminal moeten worden gelegd, en bove·ndien is het netwerk gevoelig voor storingen in dit centrale hoofdpunt. Bij een busstructuur is het zeer eenvoudig om een nieuwe terminal aan te sluiten. Dit netwerk heeft als logisch nadeel dat er gemakkelijk botsingen optreden als twee terminals tegelijk iets zenden, afhankelijk van het toegangsprotocol (bij een takenbus is dit niet het geval).
Twee connectoren met aanttuttkabet
Lal
Figuur 3.2 Tapologie van het EB IN Voor het EBIN is gekozen voor een optische boomstructuur, een combinatie van een ster- en een busnetwerk. De bus kan zich hierbij een aantal malen vertakken. Het voordeel pt t
lf·'
r-.,• (
11
29
Hoofdstuk 3.
Experimenteel Breedband lnhuis Net van zo'n structuur is de simpele uitbreidbaarheid. Een dergelijk topologie wordt ook gebruikt voor het elektriciteitsnetwerk in huis. Figuur 3.2 geeft een beeld van de topologie van het netwerk. De spliters in figuur 3.2 zijn passieve optisch elementen, die een optische signaal splitsen in twee signalen van gelijk vermogen of twee optische signalen samenvoegen. Een nadeel van een boomstructuur is dat er botsingen tussen signalen van verschillende terminals kunnen optreden als zij gelijktijdig iets versturen. Om dit te voorkomen is een allocatiemechanisme noodzakelijk. De optische boom bestaat uit monomode glasvezel, met een maximale lengte tussen de centrale HNC (Home Net Controller) en TE (Terminal Equipment) van 100 meter. In EBIN worden twee parallelle optische bomen gebruikt; een 'downstreem '-boom voor AlM-celtransport van HNC naar de terminals en een 'upstream'-boom voor AlM-celtransport van de terminals naar HNC. Een verbinding tussen twee terminals verloopt altijd via de HNC.
3.4 Functionaliteit Lagere Lagen 3.4. 1 ATM binnen het EBIN De Asynchrone Transfer Mode CATM) is reeds in het vorige hoofdstuk (2.4.4.2) toegelicht. In het EBIN is voor ATM als transmissie techniek gekozen. Het enige verschil met ATM zoals in 2.4.4.2 besproken, is de celgrootte. De keuze met betrekking tot het aantal te gebruiken Bytes is gemaakt voordat de standaardisatiecommissie CCCITI) een uitspraak had gedaan. In het EBIN worden ATM-cellen gebruikt die niet uit 53 (standaard) maar uit 52 bytes bestaan. Een ATM-cel zoals die in het EBIN voorkomt is te zien in figuur 3.3. Bij het EBIN is er rekening mee gehouden dat de gebruikte ATM-cellen eenvoudig zijn om te zetten naar ATM-cellen die gebruikt gaan worden in het openbare net (en andersom). De terminals die aan het netwerk zijn aangesloten kunnen met elkaar communiceren via zogenaamde virtuele kano30
Hoofdstuk 3.
Experimenteel Breedband lnhuis Net len. Langs deze virtuele kanalen worden de ATM-datacellen verzonden. De term 'virtueel' geeft aan dat er vanaf een terminal gezien. een rechtstreekse verbinding met een andere terminal aanwezig lijkt te zijn, terwijl de communicatie in feite via de Home Net Controller (HNC) en de optische boom verloopt. Het is ook mogelijk om over één fysieke verbinding meerdere virtuele kanalen te hebben.
--------------···1/.VCl
ALLOCATOA
I
INFORMATIE
j
i < byteS o--------,-6_ _ _ _ __....32_(bft)_ ....4877" ....____. ·
ALLOCATOR;
wordt door de HNC verzonden om aan te geven welke terminal mag gaan zenden (zie 3.4.2).
VCl;
om aan te geven bij welk kanaal de cel hoort.
Figuur 3.3 ATM - cel binnen het EBIN Om een verbinding tussen twee terminals of tussen HNC en een terminal op te kunnen zetten, te wijzigen of af te breken, is een signaleringskanaai (een speciaal virtueel kanaal) nodig. Via dit signaleringskanaai worden berichten als SETUP, CONNECT, DISCONNECT, etcetera met diverse parameters (calling party, called party, bondbreedte, etcetera) verstuurd. Dit signaleringskanaai moet bij het aansluiten van een nieuwe terminal ook eerst worden opgezet. Hierbij wordt gebruik gemaakt van de zogenaamde metasignalering. Het metasignaleringskanaal is de enige (niet-fysieke) verbinding van de HNC met de terminals die altijd aanwezig is. Dit is een punt-multipunt verbinding.
3.4.2 Allocatiemechanisme Om te zorgen dat het netwerk zo optimaal mogelijk wordt ptt, tf'semch
31
Hoofdstuk 3.
Experimenteel Breedbond lnhuis Net benut moet ervoor gezorgd worden dat terminals niet gelijktijdig cellen gaan zenden (in de upstream richting) zodat botsingen en daaruit voortvloeiende hertransmissies worden voorkomen. Er vindt geen multiplexing van optische signalen (alleen passieve splitsers worden gebruikt) plaats in de informatiestroom richting de Home Net Controller, zodat de terminals ieder op hun beurt zenden. De Home Net Controller kan wel altijd vrijuit zenden, omdat deze de enige bron is die in de richting van de terminals (downstream) zendt. I
I
Voor de terminals is een allocatiemechanisme aanwezig. De HNC stuurt geregeld allocatoren om aan te geven welke terminal mag gaan zenden. Door de frequentie van de uitgezonden allocatoren te veranderen kan de HNC de zend-bandbreedte van de terminals beïnvloeden. 3.4.3 Cel-timing De terminals binnen het netwerk kunnen op verschillende afstanden van de Home Net Controller CHNC) geplaatst zijn. Als een dichtbij de HNC gelegen terminal een cel zendt naar een terminal die zich op een grote afstand bevindt, kunnen deze cellen overlappen. Een verminkte cel is het gevolg. Om deze situatie te voorkomen is een looptijdcompensatie aan de terminals toegevoegd. Als een terminal wordt aangesloten, meet de HNC de looptijd voor deze terminal. Deze looptijd wordt gemeld aan de terminal, zodat deze een vertraging kan instellen. Daardoor zullen cellen precies op het juiste tijdstip bij de HNC arriveren. De terminals dichtbij de HNC hebben hiervoor een grotere vertragings-instelling nodig dan de terminals die verder verwijderd zijn. Een gevolg hiervan is dat er sprake is van een maximale afstand. 3.4.4 Metosignolering Het metasignaleringskanaal wordt door de HNC en terminals gebruikt om de afstand tussen HNC en een nieuwe terminal te meten en om een signaleringskanaai op te zetten. Dit werkt als volgt. De HNC stuurt een meetallocator naar de terminals. Alle nieuwe terminals reageren hierop door direct een speciale meetcel terug te zenden. Deze meetcel heeft
32
Hoofdstuk 3.
Experimenteel Breedband lnhuis Net een patroon dat zodanig gekozen is, dat een botsing met een andere cel gemakkelijk en betrouwbaar kan worden gedetecteerd. Binnen deze meetcel is een gedeelte gereserveerd om het (unieke) terminal-identificatie nummer te kunnen meezenden. Als de HNC de ontvangen meetcel heeft gecontroleerd en goedgekeurd wordt een 'SetDelay'-cel verzonden. Deze cel bevat informatie over de in te stellen delay, het nieuw op te zetten signaleringskanaai en ook het terminal-Identificatie nummec zodat alleen de terminal die als laatste de meetcel heeft verzonden op deze cel reageert. De informatie over het signaleringskanaai bestaat uit een signaleringsallocatoL een 'up'-VCI (Virtual Channel ldentifier) en een 'down'-VCl. De signaleringsallocator wordt regelmatig door de HNC verzonden, om aan te geven dat een terminal een signaleringsbericht mag verzenden. De 'up'-VCI wordt door de terminal gebruikt om een signaleringsbericht naar de HNC te sturen, terwijl de HNC van de 'down'-VCI gebruik maakt om een bericht naar een specifieke terminal te zenden.
3.4.5 Signalering Alle verbindingen die worden opgezet lopen fysiek via de HNC. De HNC is dan ook degene die het opzetten van verbindingen initieert. Zowel terminals als HNC kunnen de afbraak van een verbinding initiëren. Als er eenmaal een signaleringskanaai aanwezig is, kan dit gebruikt worden om een verbinding op te zetten of af te breken. Het opzetten van een verbinding geschiedt altijd vanuit de HNC middels signaleringsberichten. Als de HNC een verbinding wil opzetten tussen terminall en terminal2, dan stuurt hij beide terminals een SETUP-bericht. De terminals kunnen hierop reageren met een CONNECT-bericht, ten teken dat zij de verbinding accepteren, of met een RELEASE-bericht, ten teken dat zij de verbinding afwijzen. Als een verbinding moet worden afgebroken stuurt de HNC een DISCONNECT-bericht naar de betreffende terminal. De terminal reageert hierop met een RELEASE-bericht.
33
Hoofdstuk 3.
Experimenteel Breedband lnhuis Net
3.5 VME-systeem Zowel de HNC als de terminals zijn in het EBIN ondergebracht in VME-systemen. VME-systemen bestaan bij het EBIN uit een 19" kast met een busprint, een voeding en een ventilator. In de busprint kunnen gekochte en zelfgefabriceerde insteekkaarten gestoken worden. De busconnector, waar de kaarten ingestoken worden, bestaat voor de helft uit de VME-bus waarover de berichtenuitwisseling tussen kaarten onderling plaatsvindt. De tweede helft is niet gestandaardiseerd en mag dus zelf gespecificeerd worden. Bij het EBIN bevinden zich op de tweede helft van de busconnector voornamelijk de databussen. De VME-systemen die bij het EBIN gebruikt worden voor de aansluitpunten van de audio- en video-apparatuur en de HNC zijn voorzien van een M68010 microprocessorkaart met RAM.
3.6 Apparatuur aangesloten aan het EBIN Aan de terminals in het EBIN wordt de volgende apparatuur aangesloten:
•
één Multi-sync monitor
•
twee Macintoshes
•
twee camera's
•
één CD-Speler
•
vier luidsprekers
•
twee microfoons
•
drie audio-versterkers
•
een muis
•
een draadloze trackerball (via infrarood verbinding)
34
Hoofdstuk 3.
Experimenteel Breedband lnhuis Net De muis en de trackerball fungeren als "lnstruction Receiver". Een draadloze trackerball is een soort muis die door middel van infra-rood stralen communiceert met een ontvanger. Met de bal "in" de trackerball kan men de positie van de cursor op het beeldscherm veranderen. Tevens zijn er functie-knoppen op de trackerball aanwezig waarmee standaard functies kunnen worden geprogrammeerd. Het gebruik van de trackerball heeft als doel de gebruiker de mogelijkheid te bieden om vanuit een luie stoel het huisnetwerk te bedienen
3.7 Taakstelling UI Om de gebruiker een overzicht te geven van de status van de infrastructuur en de produkten in het huisnetwerk wordt er in huisnetwerken gebruik gemaakt van een User Interface (UI). Via de UI moet het mogelijk zijn om alle taken in een woning op afstand (remote) te kunnen bedienen. Als we kijken naar de taken in de woning, kunnen we opmerken dat deze in drie categorieën te verdelen zijn: •
Taken waarbij geen elektrische apparaten worden gebruikt, zoals ramen wassen en bedden opmaken. Bij deze taken is het huisnetwerk niet nuttig.
•
Taken die kunnen worden ondersteund, zoals koken en winkelen, hier is enige overlap met de eerste categorie mogelijk.
•
Taken waarbij het gebruik van het huisnetwerk vrijwel onvermijdelijk is, zoals het bedienen van audio-visuele apparatuur/ Informatie-verwerking en communicatie.
Deze laatste taak wordt in het EBIN gedemonstreerd. Naast de gebruikelijke taken in huis zal het huisnetwerk zelf min of meer nieuwe taken introduceren, zoals configureren, programmeren, verhelpen van storingen en privilege-beheer. Het is mogelijk dat sommige van deze taken slechts door één van de bewoners zullen worden gebruikt. Een
35
Hoofdstuk 3.
Experimenteel Breedbond lnhuis Net speciale taak is het routeren van de informatiestromen in het huisnetwerk. Om in staat te zijn met het huisnetwerk te werken, zou de gebruiker eigenlijk moeten weten hoe hij het netwerk kan vertellen welk apparaat hij wil gaan gebruiken en met welke andere apparatuur dit apparaat wordt verbonden. In de praktijk zal dit laatste niet absoluut noodzakelijk zijn, omdat standaardverbindingen kunnen worden aangebracht. De instructien receiver draagt zorg voor de interactie tussen gebruiker en huisnetwerk. De instructies kunnen in het EBIN door middel van een (draadloze) trackerball of een muis worden gegeven. Men kan de instructien receiver zien· als de besturings-input van het huisnetwerk.
3.8 Concepten voor de UI Een toepasselijk concept voor de UI is de butler-semafoor CNJE 90), omdat de functies van het huisnetwerk vergeleken kunnen worden met het werk van een butler. De meest toepasselijke dialoogstijl is middels natuurlijke taal. Daarom ligt een spraakgestuurd systeem ook het meest voor de hand. Spraaksturing en de interpretatie van natuurlijke taal bevinden zich echter nog in een experimenteel stadium en verder moet de UI te realiseren zijn met de huidige stand der techniek. Om diverse redenen is een QWERN-toetsenbord, het enige serieuze alternatief, niet gewenst. Dit betekent dat een UI in deze vorm niet kan. voldoen aan de gestelde eisen. Een alternatief concept, dat wel kan worden gerealiseerd met de huidige stand der techniek, is een grafische UI met een aanwijsinstrument. In dat geval kunnen de aangesloten apparaten en diensten zich in windows op het scherm presenteren. Het moet ook mogelijk zijn om het netwerk te bedienen met uitsluitend een afstandsbediening. Wanneer een display, bijvoorbeeld een LCD, en soft keys (programmeerbare functietoetsen) onderdeel uitmaken van een afstandsbediening, kan een menu-gestuurde dialoog aan de gebruiker worden aangeboden. Met dit menu kunnen eenvoudige taken worden uitgevoerd, zoals het selecteren van een televisiekanaal, het starten van de videorecorder of
36
Hoofdstuk 3.
Experimenteel Breedband lnhuis Net het regelen van volume. De spraakgestuurde UI lijkt beter dan de grafische UI CZWE90). Dit spraakgestuurde systeem kan met de huidige stand der techniek echter niet worden gerealiseerd en voldoet dus niet aan de gestelde eisen. Men kan deze UI zien als een toekomstbeeld. Zodra de technologie van de spraakherkenning en -interpretatie het punt heeft bereikt dat het mogelijk is het te gebruiken in commerciêle produkten moet het toepassen van deze technologie in de UI van het huisnetwerk overwogen worden. De userinterface in het EBIN is op een Macintosh in Supercard geïmplementeerd.
37
4. DIENSTEN
Hoofdstuk 4.
Diensten
4.1 Inleiding In het voorgaande hoofdstuk is uiteengezet wat er meegespeeld heeft bij de ontwikkeling van huisnetwerken, zoals de aan te sluiten apparatuur en de infrastructuur zowel in als buiten het huis. Dit hoofdstuk beschrijft de diensten die door een huisnetwerk worden geboden. Zo zijn er de diensten die door het telecommunicatienetwerk worden geboden en de specifieke diensten van het huisnetwerk. ·
4.2 Diensten van het Telecommunicatie netwerk Zoals reeds eerder vermeld zal de invoering van B-ISDN vooraf worden gegaan door de invoering van ISDN (of Smalband-ISDN (S-ISDN)). In deze paragraaf worden allereerst enkele diensten van het ISDN gegeven, waarna de diensten van het B-ISDN besproken zullen worden.
4.2.1 ISDN Telediensten In het ISDN zullen de op dit moment bestaande diensten worden geboden: • Telefonie • Telex • Teletex • Videotex (bijvoorbeeld Viditel) • Facsimile Naast deze bestaande diensten wordt gedacht aan een reeks van nieuwe diensten: • Audioconferentie, telefonisch vergaderen. Deze dienst biedt . de gebruiker de mogelijkheid om met meerdere gebruikers gelijktijdig een audioverbinding op te zetten (of een eigen "party-lijn"). • Elektronische post. De gebruiker kan visuele of auditieve informatie naar een andere gebruiker sturen (niet echt nieuw denk aan memocom en email).
39
Hoofdstuk 4.
Diensten • Interactieve tekstcommunicotie. De gebruiker kan communiceren door middel van tekst ter aanvulling of vervanging van spraak. • Openbare datobase occess. De gebruiker heeft de mogelijkheid om openbare bestanden te raadplegen bijvoorbeeld om computerprogramma Is voor de huiscomputer of telefoonnummers op te vragen (denk aan bulletinboards). I
• Telewinkelen (Teleshopping). De gebruiker kan thuis via een beeldscherm produktgegevens opvragen en een bestelling doen (denk aan girotel). • Thuisbankieren. De gebruiker kan thuis via een beeldscherm informatie opvragen met betrekking tot z'n bank- of girorekening en overboekingen verrichten. • Tekstverwerking. Via een beeldscherm en het telecommunicatienet kan de gebruiker teksten invoeren en bewerken. • Telemetrie. De mogelijkheid om op afstand te sturen, meten of regelen. • Videofonie. Telefonie met beeld en geluid.
4.2.2 ISDN Supplementaire diensten Supplementaire diensten worden gebruikt ter ondersteuning van telediensten. Bij een bepaalde teledienst kunnen één of meerdere supplementaire diensten gekozen worden. Enkele van deze diensten worden hier genoemd: • Oproepoonkondiging. Dit is de mogelijkheid dat een gebruiker van wie de aansluiting bezet is een indicatie krijgt dat er een oproep aanwezig is. • Doorschakelen. De mogelijkheid om een oproep door te schakelen naar een andere aansluiting. Denk hierbij ook aan de nieuwe (*21 )-dienst. • Besloten gebruikersgroep. In dit geval behoort de aansluiting tot een groep waarvoor beperkingen gelden voor
40
Hoofdstuk 4.
Diensten inkomende en uitgaande oproepen (een soort van PABX). • Automatisch terugbellen. Dit is de mogelijk dat een verbinding automatisch tot stand wordt gebracht nadat een eerdere poging mislukte. De supplementaire diensten werken niet altijd even goed voor telediensten. Bijvoorbeeld bij het doorschakelen van de telefoon wordt ook andere informatiestromen doorgeschakeld, een huisnetwerk zou hiervoor een oplossing kunnen bieden.
4.2.3 B-ISDN Diensten De komst van B-ISDN (met zijn hogere bandbreedte) maakt een aantal telediensten mogelijk, die met S-ISDN niet mogelijk zijn, zoals: • Beeldtelefonie of videotelefonie met hoge kwaliteit. • Video-on-demand. Dit is een variant op de videotheek. Over het B-ISDN wordt video-informatie naar de gebruiker verzonden en de control-informatie (start, stop, terugspoelen) van de gebruiker naar de video-on-demand-leverancier. • Video classified advertisments. Dit is een dienst waarbij abonnees die iets willen verkopen een advertentie maken, compleet met videobeelden, en deze opslaan in een databank. Potentiële kopers kunnen door de advertenties zoeken en desgevraagd de bijbehorende video-opname bekijken. • Tele-educatie. Bij deze dienst kan de gebruiker, via het BISDN, (video-)cursussen volgen op in zijn eigen tempo. • Telesophy. Dit is een multi-media-informatiesysteem waarvan de gebruiker over het B-ISDN gebruik kan maken. Naast de nieuwe diensten zal het B-ISDN natuurlijk ook de "oude" ISDN-diensten bieden.
41
Hoofdstuk 4.
Diensten
4.3 Diensten van het huisnetwerk Het huisnetwerk zal de gebruiker extra functionaliteit bieden. Er moet aansluiting zijn met de behoefte van de gebruikers. De functies van het netwerk kunnen als volgt worden onderverdeeld: • Routering van de informatiestroom door het netwerk. De mogelijkheid om informatie te routeren door het netwerk is de belangrijkste functie van het netwerk. Hierdoor worden de andere functies mogelijk gemaakt. Alle apparaten kunnen aan het netwerk worden aangesloten, zodat de gebruiker zelf de informatieroutering kan kiezen. De koppeling met het telecommunicatienet geeft de mogelijkheid om informatie door het openbare net te routeren. • Bediening van de op het netwerk aangesloten apparatuur en diensten op afstand, zelfs van buiten de woning. Alle apparaten, zoals in "Apparatuur aangesloten aan een huisnetwerk" (2.2.2) beschreven, moeten op afstand bestuurd kunnen worden. Dit betekent dat: de gebruiker apparatuur aanwezig in andere ruimtes kan besturen. o
o apparatuur welke normaal niet van een afstandsbediening is voorzien, nu wel op afstand bestuurbaar is. o de gebruiker meer bedieningsgemak wordt geboden door een twee-weg afstandsbediening. Bij de huidige afstandsbedieningen is geen terugkoppeling naar de gebruiker aanwezig.
• Automatisch uitvoeren van door de gebruiker gegeven opdrachten op een bepaald moment (timer-functie) of bij een bepaalde gebeurtenis. Het netwerk biedt een multi-functionele timer functie waarmee diensten en apparatuur op ingestelde tijdstippen actief worden. Wanneer het netwerk met een dergelijke functie wordt uitgerust kan de timer-functie 42
Hoofdstuk 4.
Diensten in de apparatuur weggelaten worden. Dit heeft als voordeel dat apparatuur goedkoper wordt en dat de gebruiker maar één timer, die van het huisnetwerk, kent (consistentie). Het huisnetwerk kan tevens geprogrammeerd worden om bij een bepaalde gebeurtenis of op een bepaald moment een bedieningsopdracht aan een apparaat, verbinding of dienst te geven. • Integratie van applicaties, doordat informatie uit een applicatie direct kan worden overgebracht naar een andere. Met behulp van het huisnetwerk kunnen applicaties tot op zeker niveau worden geïntegreerd. Informatie van de ene applicatie kan als invoer dienen voor een andere applicatie. • Ondersteuning van taken in en om de woning. Het huisnetwerk kan de gebruiker ondersteunen bij zijn werkzaamheden, bijvoorbeeld door middel van een agenda, kalender, rekenfunctionaliteit, boekhouding et cetera. Daarnaast kan het huisnetwerk de gebruiker ondersteunen bij het kiezen van de juiste middelen om een taak uit te voeren. De gebruiker moet aan het huisnetwerk duidelijk maken welk doel hij wil bereiken, zodat het huisnetwerk na kan gaan welke functies, diensten of apparaten beschikbaar zijn, waarmee het gewenste doel kan worden bereikt.
4.4 Diensten in EBIN In het huisnetwerk binnen EBIN hebben wij voornamelijk te maken met audio- en videoapparatuur van de categorie bruingoed. De diensten binnen EBIN zijn daarom audio- en videodiensten. Binnen EBIN is er onderscheid tussen de volgende diensten: • video distributie Vanaf alle monitors die aangesloten zijn op het huisnetwerk is het mogelijk om een TV kanaal te kiezen en te bekijken.
43
Hoofdstuk 4.
Diensten • audio distributie Onafhankelijk van de positie van audio-apparatuur in huis is audio distributie over het huisnetwerk mogelijk tussen de verschillende in- en output audio apparatuur. • tele control In het EBIN is het mogelijk om apparatuur op afstand te bedienen. • home automotion De gebruiker geeft opdrachten aan het huisnetwerk die uitgevoerd moeten worden op een bepaald tijdstip of bij een bepaalde gebeurtenis. • videotelefonie Met behulp van een gekozen monitor, luidspreker, microfoon en camera is beeldtelefonie mogelijk met een andere gebruiker van het huisnetwerk. • video- en audiobewaking Een bewakingsfaciliteit is wellicht een van de belangrijkste reden om een huisnetwerk te kopen (TEL91). Dit kan op verschillende manieren, bijvoorbeeld bij video door een camera de huisingang te laten observeren. Vele van deze diensten (home automation niet) worden door de gebruiker samengesteld en opgezet. De gebruiker kan een dienst, zoals bijvoorbeeld videafonie of het luisteren naar de CD-speler op de slaapkamer, na gebruik afbreken of default maken. Een default dienst kan op een willekeurig moment opnieuw aangesproken worden. Het huisnetwerk bewaart de instellingen en zorgt op verzoek voor het hernieuwd opzetten van de dienst.
44
5. PROBLEEM ANALYSE·
Hoofdstuk 5.
Probleemanalyse
5. 1 Inleiding In de voorgaande hoofdstukken is uit gelegd wat huisnetwerken zijn en welke diensten er door huisnetwerken geboden kunnen worden. In dit hoofdstuk volgt na het geven van een probleemstelling, een probleemanalyse. De probleemanalyse spits zich toe op de besturing en het beheer van een breedbandig huisnetwerk. De probleemanalyse wordt toegelicht aan de hand van de inventarisatie van het huisnetwerk. De taakstelling van de hogerè lagen van een breedbandig huisnetwerk (higher layers breedband-PRM) · vloeit hieruit voort.
5.2 Probleemstelling Door het grote aantal gebruikersmogelijkheden van een huisnetwerk is het aantal benodigde functies voor de besturing en het beheer van het netwerk zeer groot. Voor het efficiënt functioneren van het huisnetwerk is het een vereiste dat deze functies op een juiste manier over het huisnetwerk en de apparatuur gedistribueerd worden. De besturing en het beheer van het netwerk en de aangesloten apparatuur is een functie van de hogere lagen (zie "het Breedband Protocol Referentie model", 2.4.4.3). De hogere lagen van een huisnetwerk zijn, op plaatsen in het huisnetwerk waar zich een gebruikersinterface bevindt, via de user interface (UI) toegankelijk voor de gebruiker van het huisnetwerk. Dit legt bepaalde eisen op aan de hogere lagen. Aan de andere kant moet rekening gehouden worden met de functionaliteit van de onderliggende lagen van het huisnetwerk en het gekoppelde breedband telecommunicatienet. Bij een huisnetwerk heeft men in het algemeen te maken met een multi-user omgeving. Dit kan leiden tot conflictsituaties. die de hogere lagen tot in zeker mate moeten zien te voorkomen.
46
Hoofdstuk 5.
Probleemanalyse Mijn opdracht is onder te verdelen in twee delen: •
Het opstellen van een algemeen model van de hogere lagen van een huisnetwerk (Customer Premisses Network).
•
Toepassing van het algemeen model op het Experimenteel Breedband lnhuis Net ( EBIN ).
In een huisnetwerk worden velerlei informatiestromen getransporteerd. In het breedband-PRM wördt onderscheid gemaakt tussen de verschillende informatie stromen. Bij het EBIN-project wil men het huisnetwerk laten aansluiten op het B-ISDN. Om deze reden is het afstudeerwerk gebaseerd op het breedband-PRM en niet op het OSI-PRM.
5.3 Multi-user omgeving Als we de situatie in huis op dit moment bekijken zien we dat iedere bewoner of bezoeker van een huis elk aanwezig apparaat kan bedienen. In deze situatie kan een huisnetwerk verandering brengen. Indien de kopers van een huisnetwerk er waarde aan hechten hun apparaten of een deel daarvan af te schermen van gebruik door anderen (bewoners of bezoekers) dan moeten de hogere lagen hiertoe de mogelijkheid bieden. De gebruikers van een huisnetwerk bestaan in een huis uit:
• gemachtigden, personen die gemachtigd zijn het huisnetwerk te manipuleren. • niet-gemachtigden,personen die niet-gemachtigd zijn het huisnetwerk te manipuleren. Onder de gebruikers moeten ook gebruikers die van buiten het huis het huisnetwerk willen manipuleren worden gerekend. Deze kunnen ook weer onderverdeeld worden in gemachtigden (in principe bewoners) en niet gemachtigden (in principe niet-bewoners). Als men als bewoner rustig naar de muziek van een CD-
47
Hoofdstuk 5.
Probleemanalyse speler wil luisteren, moet men niet gestoord kunnen worden door andere bewoners die ook op dat moment naar de CD-speler willen luisteren. Tenzij die bewoners daar "meer" recht toe hebben. In de gebruikersomgeving kunnen dit soort problemen tussen de gemachtigde (bewoners) opgelost worden door een prioriteitenmechanisme te laten gelden, waardoor een onderlinge hiërarchie ontstaat. De bewoner mag tijdens het gebruik van een dienst niet gestoord worden door andere bewoners (met gelijke of lagere prioriteit). Een "voordeel" van het prioriteitenmechanisme is dat bijvoorbeeld het hoofd 1 van een gezin er voor kan zorgen dat de kinderen het bekijken van TV-programma's, het telefoneren met het buitenland, etcetera wordt ontzegd. Het grootste probleem bij het toepassen van een prioriteitenmechanisme is het identificeren van de gebruiker. Bij een spraakgestuurd huisnetwerk zou de identificatie eenduidig moeten zijn, echter de huidige stand der techniek is nog niet zover. Als voor de bediening het QWERTY-toetsenbord, de computer-muis of trackerball gebruikt wordt, hebben alle als nadeel dat er een identificatie procedure aan vooraf moet gaan alvorens de gebruiker geoorloofd is om het huisnetwerk te manipuleren. Een oplossing hiervoor kan geleverd worden door gebruik te maken van een personalcreditcard of personaltrackball. Deze oplossingen zijn echter niet gebruikersvriendelijk. Een voorbeeld van gemachtigd gebruik van buitenaf door niet-bewoners is het op afstand aflezen van de meterstand door een bevoegd orgaan.
5.4 Inventarisatie van het huisnetwerk In het algemene geval van het huisnetwerk kunnen we de architectuur van het netwerk splitsen in de volgende onder1 )
Het hoofd van het gezin moet bij installatie bepaald worden. In dit verslag is er van uit gegaan dat het gezin niet geleid wordt door een van de kinderen.
48
Hoofdstuk 5.
Probleemanalyse delen; • General purpose communication infrastructure (GPCI). • Hogere lagen
5.4.1 General purpose communication infrastructure (GPCI) Met de infrastructuur worden de communicatiekanalen aangeduid waarover informatie wordt verzonden. Bij een huisnetwerk kunnen de informatiestromen tussen verschillende objecten op ieder willekeurig moment worden veranderd. In een GPCI kan een gebruiker verbindingen : •
Creëren
•
Verwijderen
•
Veranderen (uitbreiden, inkrimpen)
Deze verbindingen kunnen verschillende informatiestromen door het huisnetwerk transporteren. Bij verschillende informatiestromen is te denken aan besturings-, audio- en videoinformatie. Het is mogelijk dat in een huisnetwerk verschillende infrastructuren aanwezig zijn, die onderling met elkaar kunnen communiceren. Bij verschillende infrastructuren denk ik bijvoorbeeld aan de bedrading voor audio-apparatuur en aan de telefoonbedrading in een huis. Communicatie tussen de twee infrastructuren zou betekenen dat een telefoongesprek over de audioinstallatie is te voeren. Interconnectie van alle gelijksoortige apparaten in huis wordt middels de GPCI mogelijk. Daarvoor moeten niet alleen de gezamenlijke commando's en protocollen voor communicatie gestandaardiseerd zijn, ook de apparatuur van de verschillende fabrikanten moet uitwisselbaar worden.
5.4.2 Hogere Jagen Op de GPCI is apparatuur aangesloten die door het huisnetwerk bestuurd en beheerd moet worden. Eén of meerde-
49
Hoofdstuk 5.
Probleemanalyse re apparaten en een bepaalde capaciteit van de GPCI kunnen samen een dienst vormen. De set van apparaten aangesloten aan een huisnetwerk en de capaciteit van het communicatiekanaal zijn variabel. Voor een dienst staan echter altijd de benodigde apparaten en communicatievoorzienigen vast. De aangesloten apparaten van een huisnetwerk worden verdeeld in twee categorieën; Apparaten waar wel en apparaten waar geen gebruikersinterface (User Interface, UI) aanwezig is. Normaliter heeft iedere apparaat een bedienings paneel (al is het maar de aan/uit-schakelaar). Het huisnetwerk van de toekomst zorgt ervoor dat de gebruikerspanelen bij sommige apparaten zullen verdwijnen. De kosten van apparaten zullen daardoor lager worden, hetgeen de bezitters van een huisnetwerk geld kan besparen. Als dat geld tenminste niet in de noodzakelijke uitbreiding van het huisnetwerk zit. Apparatuur zoals een cassettedeck, magnetron, etcetera heeft een manuele gebruikers interface of biedt de mogelijkheid om de apparatuur op afstand te bedienen. Deze bedieningsmogelijkheid is toegespitst op het specifieke apparaat zodat vanaf dergelijke apparatuur niet de rest van het huisnetwerk bestuurd of beheerd kan worden. Een meer algemeen bedieningsargaan is de microfoon. Dit bedieningsargaan kan input leveren voor het beheer en de besturing van het huisnetwerk, net als een computer muis, trackerbaiL QWERTY-toetsenbord, etcetera. Deze apparaten worden ook wel Instructien Receivers (IR' s) van het huisnetwerk genoemd. Een IR ontvangt de opdrachten van de gebruiker en in de hogere lagen van het huisnetwerk volgt een vertaling naar één of meerdere berichten, die in het huisnetwerk de juiste weg vinden naar de applicaties. Een monitor en luidspreker kunnen alleenstaand of in samenwerking de terugkoppeling naar de gebruiker leveren. De User Interface (UI) moet de status van het netwerk, de aanwezige diensten en de status van de applicaties weergeven. Uit onderzoek is gebleken dat een monitor daar een belangrijke rol in speelt (ME 91).
50
Hoofdstuk 5.
Probleemanalyse De mogelijke aan het huisnetwerk aangesloten apparatuur is in een hoofdstuk 2 reeds beschreven. In de toekomst moet het mogelijk zijn apparatuur aan te sluiten op een B-ISDN. Dit betekent dat de gelaagdheid van het Breedband-PRM, en de bijbehorende functionaliteit, in het apparaat terug te vinden is. Een apparaat kan dan op drie manieren bediend worden; • met de hand, • middels een afstandsbediening en • middels het huisnetwerk. Het zou wenselijk zijn als het regelpaneel van een apparaat ook fysiek van stand veranderd, als het apparaat op afstand wordt bediend. Op dergelijke wijze krijgt de gebruiker een duidelijk beeld van de status van een apparaat. Van groot belang voor de besturing is, dat de statusinformatie van het apparaat in het huisnetwerk opgeslagen wordt. Dit betekent dat er ook terugkoppeling moet zijn naar het netwerk bij bediening met de hand.
5.5 Inventarisatie EBIN De algemene inventarisatie van huisnetwerken wordt in deze paragraaf afgebeeld op het EBIN. De GPCI komt overeen met de Physicallayer, de ATM layer en de ATM Adoption Layer (AAL) van de Home Net Controller (HNC) en de TE's in het EBIN. Door de functionaliteit van deze lagen in de verschillende netwerkonderdelen te gebruiken, kunnen verbindingen opgezet en beheerd worden. De GPCI biedt de mogelijkheid om gepakketteerde informatie tussen entiteiten in de hogere lagen van de protocolstock over te zenden. Deze berichten worden 'unitdata' berichten genoemd. De berichten kunnen informatie bevatten waarmee het huisnetwerk bestuurd en beheerd kan worden. In het EBIN zijn op een VME-systeem (TA) meerdere appara51
Hoofdstuk 5.
Probleemanalyse
ten (TE2 's) aangesloten. Van de audio-apparatuur kan maximaal één input en één output apparaat op de VMEsysteem aangesloten zijn, voor de set video-apparatuur geldt hetzelfde. Als een monitor wordt aansloten aan het huisnetwerk, moet hierop het UI-beeld zichtbaar gemaakt kunnen worden. In EBIN zijn de monitors onderdeel van de macintoshes.
5.6 Taakstelling van de hogere lagen 5.6.1 Relatie met de GPCI
Verbindingen die over het netwerk zijn opgezet maken gebruik van de functionaliteit van de Physical layer, ATM layer en ATM Adeption Layer (AAL). Deze functionaliteit komt overeen met de functionaliteit van de GPCI. Vanuit de hogere lagen kunnen verbindingen gewijzigd of verbroken worden. De hogere lagen wisselen opdrachten uit middels speciale primitieven met de lagere lagen (de GPCI). 5.6.2 Relatie met de User Interface
In de hogere lagen komen de notificaties binnen van instructies die zijn uitgevoerd door het huisnetwerk. De hogere lagen moeten er voor zorgen dat de informatie (die via de user interface wordt weergegeven) wordt geactualiseerd. Als aan een huisnetwerk, dat reeds operationeel is, een nieuw apparaat met user interface wordt aangesloten, wordt er een initialisatie procedure opgestart. Het apparaat met de nieuwe user interface wordt daarmee voorzien van de relevante informatie uit de rest van het huisnetwerk. De opdrachten van de Instructien Receiver (IR) worden in de hogere lagen vertaald naar berichten, die uitgewiseld worden met de desbetreffende netwerkonderdelen. Hiervoor moet de benodigde informatie van manipuleerbare netwerkonderdelen aanwezig zijn. De hogere lagen moeten tevens controleren of de aanvraag gehonoreerd kan worden. De uitvoering van de
52
Hoofdstuk 5.
Probleemanalyse opdracht is afhankelijk van het geldende prioriteitenmechanisme (Bijvoorbeeld: is de geïdentificeerde gebruiker geoorloofd om het huisnetwerk te manipuleren?).
5.6.3 Relatie met de apparatuur van het huisnetwerk Opdrachten die aankomen in de hogere lagen van de apparatuur van het huisnetwerk, moeten worden vertaald naar acties op de apparaten. Naast het zorgdragen voor de uitvoer van de instructies worden de veranderingen doorgegeven via de user interfaces. De hogere lagen moeten controleren of de aanvraag gehonoreerd kan worden. Manipulatie van apparatuur is ook hier afhankelijk van het geldende prioriteitenmechanisme. In het EBIN is dit bij bediening met de hand niet mogelijk.
5. 7 Systeem analyse In het huisnetwerk, zoals het tot zover geschetst, is kunnen we de volgende systeemeigenschappen onderscheiden: • distributie van taken. Tussen het geven van een opdracht en de reactie van het huisnetwerk heeft ieder netwerkonderdeel zijn bijdrage in de uitvoering. • object georiënteerd. Apparaten, verbindingen en diensten worden gezien als objecten. Door een object te manipuleren manipuleert men de verbinding, de dienst of het apparaat. Een object wordt gekenmerkt door objectspecifieke informatie, mogelijke opdrachten, eigenschappen en te geven terugmeldingen. • multi-user omgeving. Het huisnetwerk kan door meerdere gebruikers (gelijktijdig) worden gemanipuleerd.
53
6. ALGEMEEN CONCEPT· HOGERE LAGEN
Hoofdstuk 6
Algemeen concept Hogere Lagen
6. 1 Inleiding Voor het ontwerp van een algemeen concept van de hogere lagen in het huisnetwerk heb ik na een grondige probleemanalyse (Hoofdstuk 5) gekozen om gebruik te maken van de principes van Telecommunicatie Management. De aanpak die men verkiest bij Telecommunicatie Management sluit aan bij de aanpak die gekozen kan worden voor de besturing en het beheer van een huisnetwerk. Besturing en beheer van het huisnetwerk is de taak van de hogere lagen. Beheer of Telecommunicatie Management (of netwerkmanagement, of netwerkbeheer) is een onderwerp dat nationaal en internationaal steeds meer aandacht vraagt en krijgt. Wat ik met behulp van de principes uit Telecommunicatie Management wil bereiken in een huisnetwerk komt onder andere neer op de volgende punten: •
Nieuwe apparatuur moet eenvoudig in het netwerk geïnstalleerd kunnen worden.
•
De gebruiker kan alle functies via de User Interface (UI) besturen. De lokale besturing-, systeem- en applicatiekennis moet tot een minimum beperkt blijven.
•
De uitgevoerde acties moeten op de UI zichtbaar zijn en de UI moet altijd de huidige stand van zaken weergeven.
•
De actuele stand van zaken m.b.t. het netwerk moet altijd opvraagbaar zijn, bijvoorbeeld bij het aansluiten van een nieuwe User Interface.
In dit hoofdstuk wordt vaak verwezen naar Telecommunication Management Network (TMN), dit hoofdstuk geeft zeker geen volledig overzicht. Enkele zaken uit Telecommunication Management Network (TMN) worden aangestipt. Ik wil hiervan echter enkel de principes gebruiken. Voor een uitgebreid overzicht van TMN verwijs ik dan ook naar (TMN90).
55
Hoofdstuk 6
Algemeen concept Hogere Lagen
6.2 Telecommunication Management Network (TMN) Door de ontwikkelingen van de laatste jaren is de wens naar voren gekomen om te beschikken over een integrale procesbesturing, waarvoor informatie-overdracht tussen diverse technische beheersystemen en administratieve systemen nodig zijn. Dit vereiste de introductie van een beheernetwerk als integrerend element waarmee vanaf een willekeurig (standaard) element toegang kan worden verkregen tot de (beheer)systemen en waarmee de noodzakelijke onderlinge koppelingen tussen systemen gerealiseerd kunnen worden. '
Nadere studies, zowel in Nederland als elders in de wereld, leidden tot de conclusie dat een dergelijk beheerconcept noodzakelijk is. Deze redenen komen in grote lijnen overeen met de uitgangspunten van het beheerconcept dat wij voor een huisnetwerk willen realiseren. Te noemen zijn: •
een toenemende beheerfuncties
behoefte
aan
te
verrichten
•
een groeiend aantal via het netwerk te leveren diensten
•
een multi-vendor beleid, waardoor een aantal systemen van verschillende fabrikanten in een beheergebied kan komen te staan
•
een eenduidige wijze wgorop beheertaken door de operator kunnen worden uitgevoerd
•
de mogelijkheid om beheerfuncties eenvoudig te kunnen uitbreiden
•
de wens om een klant zelf een service te kunnen laten beïnvloeden
•
de noodzaak om het netwerk als een integraal geheel te beheren in plaats van als een aantal netwerkelementen afzonderlijk
Hierdoor werd het nodig een integraal beheerconcept in de vorm van een beheernet met daarin opgenomen
56
Hoofdstuk 6
Algemeen concept Hogere Lagen beheersystemen (een Telecommunicatie Network) te ontwikkelen.
Monogement
De aspecten die aan de orde komen bij een TMN zijn zeer geschikt voor het concept van de hogere lagen van een breedband huisnetwerk.
6.2.1 Management framework Deel 4 van het OSI Basic Reference Model, het Management Framework, definieert een raamwerk voor dè ontwikkeling van standaarden ten behoeve van netwerk- en systeembeheer (OSI management). Daarin wordt de grondslag gelegd voor een aantal belangrijke concepten, te weten: Monogement objects, Monogement lnformotion Base (in dit verslag wordt elders in een aparte paragraaf gesproken over de In formation Base (IB)), manieren om management-informatie uit te wisselen en Functionele Gebieden. Een Monoged Object is de OSI Management "view" van een resource die moet worden beheerd. Een resource kan iets logisch of iets fysieks zijn, zoals een switch of een connection. Populair gezegd is een managed object "het beeld van de resource wanneer er met een management bril op naar het netwerk wordt gekeken". Alle managed objects in een systeem, vormen samen de Monogement In formation Base (M/BJ van dat systeem. De MIB bevat informatie die met behulp van OS/ Monogement Protocollen kon worden getransporteerd of beïnvloed. OSI Management definieert drie manieren om managementinformatie uit te wisselen:
• Systems Monogement • (N-) Loyer Monogement • (N-) Protocol Operotion Systems Management heeft de voorkeur omdat dit de
57
Hoofdstuk 6
Algemeen concept Hogere Lagen normale manier is voor het uitwisselen van informatie in OSI, namelijk door middel van een applicatie protocol tussen System Management Application Entities (SMAE's). Hierbij wordt gebruikt gemaakt (zoals in alle OSIapplicatieprotocollen) van de door de onderliggende OSIIagen geleverde services.
6.2.2 Systems Management Systems Management is gedefinieerd in de ISO-standaard Systems Management Overview (SMO). In het algemeen (en dus ook in het geval van het huisnetwerken) biedt Systems Management faciliteiten voor het bewaken en besturen van resources in de OSI omgeving. Tevens biedt het een standaard protocol voor de uitwisseling van management-informatie die betrekking heeft op de resources. Ten einde managementoperaties op resources te kunnen beschrijven, worden de resources als managed objects gemodelleerd. Systems Management is in het bijzonder van toepassing op de lagen van het OSI model, maar is daar niet toe beperkt. Systems Management kan worden gebruikt in een brede range van distributed processing- en communicatie-omgeving. Deze omgevingen kunnen variëren van local area netwerken, waarmee kleine systemen worden gekoppeld, tot netwerken op internationale schaal. Eenvoudige omgevingen worden vaak gemanaged door één manager die de open communicatie omgeving controleert en coördineert door middel van een aantal, aan hem ondergeschikte agents. In meer complexe omgevingen zijn er meestal meer, en meer niveaus van, managers. Echter: de standaarden en principes van Systems Management zijn ook daar van toepassing.
6.2.3 Manager-Agent model Systems management is een gedistribueerde applicatie. Het ene open systeem, Monoging Open System, beheert het andere open system, wat het Monoged Open System wordt genoemd. Dit gebeurt modelmatig door twee applicatieprocessen. Het ene applicatie-proces heeft daarin de rol van manager, het andere proces de rol van Agent. In figuur 6.1 wordt dit schematisch weergegeven.
58
Hoofdstuk 6
Algemeen concept Hogere Logen
ManagedOpen System
Mansging Open System
~
'
--
MIS-User (manager rolell
m~agement
: . \
j.
:
management 'opendions
1 operaticins , \ I MIS-User notiflca1ions /i j (agent role) lemitteá
:----
/ i !
:n0Ufica1:1ons
;
0 ·.···.·
O
( ) ' ..
M818g8d Objecal
i Local system emlirOI'Iment
MIS-User = Management lnformation Service-User Figuur 6.1 Manager-Agent model
Beide processen zijn MIS-user, dat wil zeggen dat ze gebruiker zijn van de Management lnformation Service. Met dit protocol kan de MIS-user die de manager rol heeft, operaties (opdrachten) sturen naar de MIS-user in de Agent rol. En omgekeerd stuurt de Agent notificaties (gebeurtenismeldingen) naar de Manager. De agent die een management-operatie ontvangt, moet zorgdragen voor de uitvoering, welke wordt vastgelegd in de object definitie. Evenzo wordt daarin vastgelegd wanneer notificaties moeten worden verstuurd. De definitie van managers en agents betekent dat we te maken met een asymmetrisch protocol. De managerrol (cq. agentrol) behoeft echter geen vast gegeven te zijn. Een systeem kan op een bepaald moment een managerrol zijn toebedeeld en op een ander moment een agentroL 6.2.4 Monoged objects
Een managed object behoort altijd tot een bepaalde objectklosse. Managed objects met dezelfde karakterisering behoren tot dezelfde objectklasse; bijvoorbeeld, Switch 1 en Switch2 behoren tot objectklasse Switch. In een objectklasse
59
Algemeen concept Hogere Lagen
Hoofdstuk 6
worden eigenschappen van objecten gedefinieerd. De definitie van een objectklasse bestaat uit een beschrijving van: •
Eén of meer attributen. Een attribuut is een eigenschap van een objectklasse en daarmee van alle objecten die tot die objectklasse behoren; bijvoorbeeld, Baudrate is een attribuut van objectklasse Modem en dus van de objecten Modem 1 en Modem2. Een attribuut heeft een waarde.
•
De operaties die op de objecten van die objectklasse kunnen worden uitgevoerd. Deze worden in de objectklasse bijgehouden. Voorbeelden zijn "geef attribuut een waarde", "vraag waarde attribuut op" etcetera. I
•
Het gedrag van de objecten van die objectklasse als reactie op een operatie.
•
De notificatie die gegenereerd worden bij bepaalde gebeurtenissen. Object-klasse: Modem
attribuut: bauarate of)IH8tiOniJJStB
operatie:
diagnoseTest
avent:
aJarm
-
gedrag:
Figuur 6.2 Object-klasse Modem De objectklassedefinities zijn er slechts om de managementinformatie te definiëren die kan worden uitgewisseld. Met andere woorden: om de management berichten vast te leggen. Hoe een operatie op een object van objectklasse Modem zoals "SET baudrate 19200" werkelijk wordt geïmplementeerd, dus word vertaald naar een interne boodschap voor de reel resource (het modem) is nu nog niet van belang. Het kenmerk van Open Systemen is de I
I
60
Hoofdstuk 6
Algemeen concept Hogere Logen specificatie van implementatie-onafhankelijke interfaces; de nadruk ligt op interworking, men wil zo weinig mogelijk van een implementatie vastleggen. Met figuur 6.2 is gepoogd het beeld van een objectklasse te verduidelijken. Het grote voordeel van een 'Object-Oriënted' (0-0) aanpak, is dat deze aanpak hergebruik van specificaties bevordert (KEY90). Men hoeft niet telkens opnieuw te beginnen, maar specialiseert op basis van reeds aanwezige objectklassen. De reeds voor de superclass gedefinieerde berichten zijn ook yan toepassing op de subclass. Dit betekent ook dat de manager die nog niet op de hoogte is van de specificatie, de "nieuweling" toch (gedeeltelijk) kan managen, gebruik makend van de berichten die voor zijn superclass zijn gedefinieerd. Dit laatste wordt mogelijk gemaakt door het mechanisme dat allomorfisme wordt genoemd. Allomorfisme verwijst naar de mogelijkheid van een object van een bepaalde klasse om een gedrag te vertonen overeenkomstig met dat van een andere klasse. Het maakt het mogelijk dat nieuwe apparatuur in het netwerk kan worden opgenomen zonder dat de management systemen van een nieuwe programmatuur-versie zijn voorzien.
6.2.5 Monogement lnformotion Base Conceptueel bevinden de managed objects van een Managed Open System zich in de Management lnformation Base (MlB). De toegangsstructuur tot de MIB, de manier om individuele objecten te selecteren, wordt vastgesteld met een Naming Scheme. De Naming scheme moet ook gestandaardiseerd worden. Hoe de MIB wordt geïmplementeerd (opslagstructuur, etcetera), is geen onderwerp van standaardisatie.
61
Algemeen concept Hogere Lagen
Hoofdstuk 6
6.3 Toepassing op het algemeen model van een huisnetwerk 6.3. 1 Managed objects van een huisnetwerk De apparatuur aangesloten aan een :~uisnetwerk, de verbindingen en de diensten van het huisnetwerk zijn alle managed objects uit een bepaalde objectklasse. Een objectklasse bevat een set van attributen die onderverdeeld kunnen worden in: object-specifieke attributen, controle attributen en attributen ter ondersteuning van het geldende prioriteitenmechanisme. Object-specifieke attributen zijn de parameters van een apparaat. Deze zijn instelbaar middels manuele acties, een afstandsbediening of door het huisnetwerk. Voor het beheer van het huisnetwerk is het tevens van belang om te weten van welke informatiesoort het apparaat of de verbinding is, het attribuut Bearer Capability geeft dit aan. Object Klasse Real Resource Attributen ; Operaties
Operaties
-
~
....
Gebemtenissen ~--~
: Notificaties '
Gedrag
Figuur 6.3 Definitie van een object-klasse De controle attributen van een object, zijn de attributen die een object uniek identificeerbaar maken in het huisnetwerk (ObjectName, Objectldentifier).
62
Hoofdstuk 6
Algemeen concept Hogere Logen
De status informatie van een object wordt aangegeven door het attribuut state, hiermee wordt aangeduid of een object vrij voor gebruik door een ieder. (free), door een gebruiker gemanipuleerd wordt (occupied) of niet actief (default) is. Het belangrijkste attribuut ter ondersteuning van het prioriteitenmechanisme (zie 5.3 "Multi User omgeving") bestaat uit het attribuut LastUser. Het attribuut LastUser geeft aan welke gebruiker het object het laatste gemanipuleerd heeft. Met het geldende prioriteitenmechanisme kan dan bepaald worden of de gebruiker die het object wil manipuleren hiertoe geoorloofd is. Behalve de attribuutverzameling is er in een managed object een specificatie van de operaties die toegestaan worden en het gedrag plus bijbehorende notificaties die verwacht mogen worden. De operaties en notificaties worden gespecificeerd middels het "Common Control and lnformation-protocol" (6.3.7). Figuur 6.3 is de definitie van een object-klasse te zien. Het gedrag van de objecten op operaties, die worden ontvangen door het object worden in SOL-diagrammen gespee ificeerd. In de volgende paragraaf worden enkele voorbeelden van 'managed objects' gegeven. 6.3. 1. 1 Apparatuur als Monoged Objects
Als we de apparatuur van het huisnetwerk bekijken, zien we overeenkomsten tussen de verschillende objecten.ln figuur 6.4 wordt een voorbeeld gegeven van een CD-speler als object. Een overeenkomst tussen alle apparatuurobjecten is de unieke identificatie. Bij het aansluiten van een apparaat op het netwerk wordt een objectidentifier bepaald, die samen met het apparaatsoort het apparaat uniek identificeerbaar maakt. Tevens is ieder apparaat van een bepaalde informatiesoort (Bearer Capability), zoals daar zijn audio, video en data. Variabele attributen zijn de te regelen instellingen van een apparaat, de status (free, occupied) van het object, de ruimte waar zich het object bevindt, etcetera.
63
Hoofdstuk 6
Algemeen concept Hogere Lagen
Object Klasse CD-speler
Attributen Track Time lastUser
" Opernties ~·-~-
: Notificaties
CD-speler
....
UPDATE CHANGE Gebeurtenis NOTIFV
Figuur 6.4 Object CD-speler
Hieronder wordt als voorbeeld de object klasse van een CDspeler gegeven. Voorbeeld: Object-Klasse CD-Piayer
A 71RIBUTEN: Object Name Object ldentifier Bearer capability State Last User ldentifier Power Status Track Time Link ldentifier Service ldentifier Room OPERATIES: CLAIM UNCLAIM CHANGE UPDATE
64
Hoofdstuk 6
Algemeen concept Hogere Logen GEBEURTENISSEN: NOTIFY GEDRAG: SDL diagrammen
Het gedrag van de CD-speler op operaties die worden ontvangen door het object worden in SOL-diagrammen gespecificeerd. In Tabel 6.1 wordt de attribuutverzameling van de CD-speler toegelicht. De Operaties en notificaties worden in 6.3. 7 "Common Control and lnformation-Protocol'' toegelicht. Tabel 6.1 Attributenlijst CD-speler
Attribuutsoort
Attribuutwaarde
Object Name
CD
Object Identifier
Identifier
State
(Free, Occupied)
Powerstatus
on I Off
Trackstand
0
Time
Hours: Minutes: Seconds
Room
(living, Kitchen, Bedroom, etcetera)
Bearer Capability
(Audio, Video, Data)
Last User Identifier
Identifier
Link Identifier
Identifier
Service Identifier
Identifier
-
..
player
50
65
Hoofdstuk 6
Algemeen concept Hogere Lagen 6.3.1.2 Verbindingen als Managed Objects
Als we de attribuut verzameling van een verbinding (Link) samenstellen, is het belangrijk dat de getransporteerde informatiesoort bekend is en de apparatuur waartussen de informatie soort wordt getransporteerd. Daaruit is voornamelijk de attribuut verzameling uit Tabel 6.2 samengesteld. De State van een link object kan de waarde default hebben. Default wil dan zeggen de link als object aanwezig is echter niet "fysiek" in de GPCI. Tabel 6.2 Attribuutverzameling van een verbinding Attribuut
I Attribuutwaarde
ObJeCt. Name Object Identifier
Link
Outputdevice Identifier /i
Inputdevice Identifier
') Bearer Capa..tnlity
!dentifier
!
Identifier
i
I
I Identifier ! (Audio, Video,
/1
I Data)
:/ .>tate ,I ;
(Free, 1 Occupied, I Default)
! Last User Identifier
/ Identifier
' ServJ.ce , Identifier
I !dentifier i
I
I
Tabel 6.3 Attributenlijst van een telefonie dienat Attribuut Object name Object. Id.antifier
Attribuutwaarde Telefony
IIdentifier
Audiolink Ident.J.fier
:ctentifier
Audiolink Id.antifier
Id.antifier
State
(Free, Occupied, Default)
!.ast User IdentJ.fier
Identifier
66
Hoofdstuk 6
Algemeen concept Hogere Lagen 6.3. 1.3 Diensten als Monogeel Objects Een dienst in een huisnetwerk bestaat uit set van apparatuur en gedeelte van de GPCI. De apparatuur voor een dienst moet tot de beschikking van een dienst staan en de benodigde verbindingen moeten opgezet zijn, alvorens men over een aktieve dienst spreekt. De attribuut verzameling van een dienst (seNice) bestaat uit een aantal link identifiers die nodig zijn voor het gebruik van de dienst. Bij het opzetten van de verbindingen is de benodigde apparatuur reeds tot de beschikking van de dienst gesteld. In Tabel 6.3 wordt een voorbeeld gegeven van de attribuutlijst van een telefonie dienst. Een telefonie dienst beheert twee audioverbindingen: één audioverbinding verbindt de microfoon van persoon A met de luidspreker bij persoon B en één audioverbinding verbindt de luidspreker bij persoon A met de microfoon van persoon B.
6.3.2 lnformation Base (18) In 6.2.5 is reeds gesproken over de Management lnformation Base.
Q1
Figuur 6.5 Algemene lnformation Base
ptt research
'
....
67
Hoofdstuk 6
Algemeen concept Hogere Lagen De structuur van de IB (van het algemeen concept) is gevisualiseerd in figuur 6.4. In hoeverre de IB over het netwerk verdeeld is, gecentraliseerd, gedecentraliseerd of gedistribueerd, wordt in de volgende paragrafen uitgewerkt. Tevens moet de bijbehorende database structuur gekozen worden. De toegangsstructuur is afhankelijk van de database structuur. In (TMN90) wordt gesproken over een Management lnformation Tree CMIT), de IB in het algemeen concept heeft geen echte boomstructuur. Er zijn kruis- of dwarsverbanden aanwezig. Vanuit een link zijn de gegevens van de aangesloten objecten opvraagbaar en vanuit een object is bekend aan welke link het object is aangesloten. De dwarsverbanden zijn niet in de IB getekend. Uit de definitie attributen verzameling van de managed objects komen (zie 6.3.1.1, 6.3.1.2 en 6.3.1.3) de dwarsverbanden duidelijk naar voren.
6.3.3 Fysieke plaats 18 De verdeling van de IB over het huisnetwerk is onafhankelijk van de soort database structuur. Er zijn voor een huisnetwerk drie mogelijkheden: 7 gecentraliseerd 2 gedecentraliseerd 3 gedistribueerd
6.3.3. 1 18 centraal in het huisnetwerk De IB is centraal in het huisnetwerk bijvoorbeeld in de GPCI zie figuur 6.5, gesitueerd. Eén centrale IB heeft als voordeel dat de informatie slechts op een plaats gewijzigd hoeft te worden, de ruimte die de IB dan in beslag neemt is minimaal. De performance van het systeem neemt af. Op welke plaats in het netwerk dan ook de informatie nodig is, de informatie moet worden opgehaald op één centrale plaats in het huisnetwerk. Als de centrale plaats uitvalt, valt het hele huisnetwerk uit. Een centrale plaats voor de IB is geen logische keuze. De gebruikers interfaces van het netwerk moeten hun informatie uit de IB halen om de UI te aktualiseren. Als een apparaat door een gebruiker gemanipuleerd wordt moet in de centrale IB gekeken of de gebruiker daartoe bevoegd is.
68
Hoofdstuk 6
Algemeen concept Hogere Lagen
I i
8 Figuur 6.6 18 Centraal in het huisnetwerk 6.3.3.2 18 gedecentraliseerd in het huisnetwerk Het netwerk is dan verdeeld in stukken die apart van elkaar bestuurd kunnen worden. Bij zo'n deel van een netwerk hoort ook weer een eigen stuk 18, waardoor een gedecentraliseerd stuk van het huisnetwerk een apart huisnetwerk met een bijbehorend beheer- en besturingssysteem vormt. In totaal vormen de stukken van het netwerk het totale netwerkbeheer en besturing. De gedeeltes van de 18 worden zo dicht mogelijk bij de managers, die de applicaties beheren, gepositioneerd. Eén groot voordeel van deze gedecentraliseerde oplossing is dat als een gedeelte van het huisnetwerk uitvalt, dat niet wil zeggen dat het hele systeem uit de lucht is. Vertragingen zullen minimaal zijn, daar de informatie dicht bij de manager is geplaatst. Het is een nadeel dat er een zoekprocedure aanwezig moet zijn die de 18 informatie, die verdeeld is over verschillende delen van het totale netwerk, opspoort. Een zoekprocedure zal echter weer vertragingen opleveren.
69
Hoofdstuk 6
Algemeen concept Hogere Lagen lnstruction Reelever
. Natwar
F·······.............................. .
. O!J:O!J . M
I
I
8
\@
Figuur 6.7 IB gedecentraliseerd in het huisnetwerk Tevens zullen problemen ontstaan als objecten van verschillende stukken van het huisnetwerk in één dienst beheerd of bestuurd moeten worden.
6.3.3.3 18 gedistribueerd in het huisnetwerk In de specifieke netwerkonderdelen worden stukken van de besturing en het beheer uitgevoerd. Bijvoorbeeld het manipuleren van een apparaat kan het beste in TE. Dit zou inhouden dat een specifieke opdracht aan het TE voldoende is en dat daarna de afhandeling door het TE gebeurt. De delen bij elkaar vormen tesemen de IB. Er is echter overlapping. De IB is niet strikt in stukken verdeeld, er kan op twee plaatsen in het huisnetwerk dezelfde object informatie aanwezig zijn (zie 6.3.6 "Originelen en kopieën"). Dit is een logisch gevolg van het feit dat de UI alle informatie omtrent de status van het huisnetwerk moet hebben. Voordeel van een gedistribueerde IB is dat de informatie aanwezig is op de plaats waar de informatie gemanipuleerd wordt of gecontroleerd wordt (UI en IR). De distributie van de objecten uit de IB over het huisnetwerk komt overeen met het gedistribueerde terminal concept.
70
Hoofdstuk 6
Algemeen concept Hogere Lagen ~
(Netwerk
DID
Figuur 6.8 IB gedistribueerd in het huisnetwerk Een nadeel is dat informatie gedupliceerd wordt. Duplicatie van informatie houdt in dat de informatie van één object meerdere malen wordt opgeslagen en bijgehouden op verschillende plekken in het huisnetwerk. De hoeveelheid informatie die bijgehouden wordt over het hele huisnetwerk is groter dan bij de twee andere alternatieven, tevens moeten de kopieën steeds worden geaktualiseerd. De distributie van de !B over het netwerk verdient de voorkeur, op het punt van performance. Het opvragen van informatie op een centraal punt kost meer tijd dan bij opgetrede veranderingen de kopie-informatie te actualiseren. Tevens is het efficiënter als informatie aanwezig is daar waar de veranderingen (daadwerkelijk) worden doorgevoerd. Door analyse te plegen middels de kopie-informatie kan men nagaan of het versturen van operaties zin heeft. Daardoor wordt de performance van het systeem beter ten opzichte van een centrale of decentrale verspreiding van de IB. Bij een gedistribueerde IB belast een object het netwerk niet als de object informatie geraadpleegd wordt.
ptt research .
~
.
~
.
71
Hoofdstuk 6
Algemeen concept Hogere Lagen 6.3.4 Naming scheme Toegang tot de informatie uit de IB en onderhoud van de IB wordt verkregen middels het Naming Scheme (ontleent aan (TMN90)). De benodigde procedures voor het manipuleren van de objecten zijn: • 18_ Claim, waarmee de informatie van een object kan worden geclaimd. • 18_UnCiaim, waarmee de informatie van een object wordt vrijgegeven. • 18_ CreateObject, waarmee een nieuw object kan worden gecreëerd in de IB. • 18_0elete0bject, waarmee een object kan worden verwijderd uit de IB. • 18_ChangeAttribute, waarmee de attribuutwaarde van een specifiek object kan worden veranderd. • 18_/nquireAttribute, waarmee de attribuutwaarde van een specifiek attribuut kan worden opgevraagd. • 18_ GetObject/nfo, waarmee de waardes van alle attributen van een object kunnen worden opgevraagd.
6.3.5 Consistent houden informatie tussen managers In het huisnetwerk moet de informatie bij managers geaktualiseerd worden na opgetreden verandering in de objecten. Hiervoor zijn twee oplossingen: • rechtstreekse verbinding tussen twee managers. In TMN zou men hiervoor een X-interface definieren. Deze Xinterface zou dan tussen alle managers gelegd moeten worden. Dit betekent dat bij uitbreiding van het aantal managers van n naar n+ 1 er n transparante verbindingen bij moeten komen (maasnetwerk). • middels broadcastberichten.
72
Hoofdstuk 6
Algemeen concept Hogere Lagen Het aktualiseren van de informatie bij de managers kan ook gebeuren met behulp van een broodcast bericht, dat aan alle gebruikers van het netwerk de veranderingen doorgeeft die zijn opgetreden. Bij uitbreiding van het managers protocol van n naar n+ 1 zou er één bericht meer moeten worden verzonden, hiervoor hoeft enkel de verzendlijst aangepast te worden. De oplossing die gebruik maakt van de broodcastberichten is de meest flexibele oplossing en krijgt daarom de voorkeur. Deze oplossing komt tevens overeen met het notificeren van managers (zie 6.2.4 "Managed Objects").
6.3.6 Originelen en kopieên In het netwerk is de informatie van een agent op meerdere plaatsen beschikbaar. De IB van de UI (de manager) bevat status informatie van alle applicaties en diensten aanwezig. Deze objecten noem ik de kopieën. De originelen van het huisnetwerk bevinden zich in de TE waar de applicatie (de agent) zich bevindt. Een opdracht van een gebruiker wordt naar de TE gerouteerd waar zich het originele object (bij de agent) bevindt. In deze TE bevindt zich de originele objectinformatie van de applicatie. Als gevolg van de veranderingen op de applicatie verandert de bijhorende IB object informatie. Als de verandering op het originele object is uitgevoerd worden alle kopieën van het desbetreffende object in het huisnetwerk genotificeerd. Op het moment dat de notificaties door de kopie objecten zijn verwerkt is er sprake van een geactualiseerd netwerk.
6.3.7 Common Control and lnformation-Protocol Voor de uitwisseling van informatie tussen de hogere lagen van de verschillende netwerk entiteiten wordt het Common Control and lnformation-Protocol (CCI-Protocol). Het Celprotocol biedt de hogere lagen gebruiker de service om informatie over te zenden naar de juiste bestemming. Control in CCI staat voor de besturings informatie die overgezonden wordt om object te manipuleren. lnformation staat voor de informatie die over gezonden wordt om deIB's actualiseerd.
73
Hoofdstuk 6
Algemeen concept Hogere Lagen
Dit CCI-protocol ondersteunt precies de operaties en notificaties die bij objectklassen kunnen worden gedefinieerd. Met andere woorden, de operaties en notificaties van de managed objects (de informatiemodellering) kunnen één op één op de CCI-berichten (het transport) worden afgebeeld. De CC!-berichten ter ondersteuning van de operaties zijn: • CREATE het toevoegen van een nieuw object van een bepaalde objectklasse; • DELETE het verwijderen van een object; • CHANGE een opdracht aan een object om een operatie uit te voeren; • UPDATE een opdracht die van een nieuwe User Interface aan het huisnetwerk met als doel dat alle objecten in het huisnetwerk de nieuwe User Interface inlichten over hun status;
Het CCI-bericht ter ondersteuning van de notificatie is: • NOTIFY de rapportage van een gebeurtenis.
CCI-berichten die het geldende prioriteits mechanisme ondersteunen zijn: • CLAIM wordt verstuurd als een gebruiker een verbinding, dienst en apparaat voor eigen gebruik wil hebben. • UNCLAIM Als een gebruiker een verbinding, dienst of apparaat vrij geeft voor iedereen.
Het grote voordeel van het CC I-protocol is dat CCI-berichten onafhankelijk zijn van de objecten die bestuurd moeten
74
Hoofdstuk 6
Algemeen concept Hogere Lagen
worden. De parameters die mee worden gestuurd zijn maatgevend voor de actie die in de applicatie wordt uitgevoerd. Bij het aansluiten van een nieuwe applicatie wordt ervan uitgegaan dat de Cel-berichten door de applicatie kunnen worden ontvangen. De fabrikant moet er dus zorg voordragen dat de Cel-berichten ontvangen kunnen worden.
75
7. FUNCTIONELE SPLITSING· HOGERE LAGEN
Hoofdstuk 7.
Functionele splitsing hogere lagen
7.1 Inleiding In dit hoofdstuk wordt de functionele splitsing van de hogere lagen besproken. Het doel van de functionele splitsing is het onderscheiden van taken in de hogere lagen, dit maakt het onderscheidden en specificeren van de componenten eenvoudiger. De functionele splitsing van de hogere lagen is een afgeleide van de splitsing die bij Home Systems (HS 91) is toegepast, zie hiervoor appendix B. De vijf beiOngrijke componenten die men in de hogere lagen kan onderscheiden zijn: • NIM
(Node lnitialisation Module),
• CLSE
(Command Language Service Element),
• MTSE
( Message Transfer Service Element),
• IBM
(lnformation Base Manager) en
• IB
(lnformation Base).
7.2 Node lnitialisation Module (NIM) Naast de uitwisseling van Common Control and lnformationberichten (zie 6.3. 7 CC I-protocol) vind er ook verwerking van management berichten plaats. Deze management berichten omvatten bijvoorbeeld de indicatie van terminal-aansluiting en -verwijdering: NewTe (New Terminal) en TeGone (Terminal Gone). Bij de aansluiting van een nieuwe terminal wordt in de hogere lagen door de Node lnitialisation Module (NIM) een management bericht ontvangen. De NIM zorgt er dan voor dat er een verbinding opgezet wordt waarover Cel-berichten kunnen worden uitgewisseld. De IB's moeten bij terminal-aansluiting of -verwijdering aangepast worden aan de nieuw ontstane situatie. Dit is geen taak van de NIM, maar een taak van de CLSE.
77
Hoofdstuk 7.
Functionele splitsing hogere lagen
7.3 Command Language Service Element (CLSE) Functies die aan de CLSE zijn toegewezen zijn: • Object creatie & verwijdering; De CLSE verzorgt het creëren of verwijderen van objecten. Bij het aansluiten of verwijderen van een terminal moet de CLSE de nodige objecten creëren of verwijderen, hetgeen aangeven wordt door de NIM. • lnformation Bases (IB's) bijhouden; Actueel houden van de informatie in de hogere lagen. • Attributen van objecten wijzigen; HieNoor moet de lnformation Base worden gemanipuleerd. De berichten worden in de CLSE gecreëerd en afgehandeld. • Communicatie via de UI; De berichten afkomstig van de UI worden door het CLSE-blok vertaald en omgezet in acties op de desbetreffende objecten. Omgekeerd moeten berichten afkomstig van het netwerk vertaald worden in acties zichtbaar op de UI.
7.4 lnformation Base (IB) In de IB bevindt zich informatie over het netwerk en de aangesloten randapparatuur. De lnformation Base is in het vorige hoofdstuk uitvoerig behandeld.
7.5 lnformation Base Manager (IBM) De lnformation Base Manager zorgt voor een schil rond de lnformation Base. In de IBM zijn procedures gedefinieerd waarmee men de information base kan manipuleren (zie 6.3.4 Naming Scheme).
78
Hoofdstuk 7.
Functionele splitsing hogere lagen
7.6 Message Transfer Service Element CMTSE) Functies die aan de MTSE zijn toegewezen zijn: • Op Confirmed basis werken; Bij ontvangst van een bericht moet een terugmelding gecreëerd worden. Tevens moet een timer worden gezet als er een bericht verstuurd wordt. Als er geen terugmelding op een bericht plaats vindt moet het bericht opnieuw verzonden worden. • Ondersteuning uitwisseling CCI-berichten; Het MTSE zorgt voor de uitwisseling van CCI-berichten. De MTSE geeft de berichten transparant door. De eerste zorg van het MTSE is de codering van het CCI-bericht. Hiertoe verpakt het MTSE het CC I-bericht in een 'unitdata' -bericht De cellen worden aan de adoptielaag aangeboden. Cellen die afkomstig zijn van de adoptielaag en bestemd zijn voor objecten worden in het betreffende apparaat uitgepakt, zodat de cel-berichten weer beschikbaar komen. • Routering; Een andere functie van hetMTSEis het routeren van Cel-berichten. De routering vindt plaats aan de hand van informatie uit de lnformation Base.
79
8. TOEPASSING VAN HET· ALGEMEEN MODEL OP HETEBIN
Hoofdstuk 8
Toepassing van het algemeen concept op het EBIN
8.1 Inleiding In dit hoofdstuk wordt de toepassing van het concept van de hogere lagen op het EBIN beschreven. Het concept van de hogere lagen is uitvoerig besproken in hoofdstuk 6. De software van de hogere lagen is gecodeerd in MODULA 2. MODULA 2 is geen object-georienteerde programmeertaal, echter het concept wat uitgaat van objecten (objectklasse) kan in MODULA 2 worden geïmplementeerd. De implementatie in MODULA 2 is gebaseerd op specificaties middels SOL (Specification and Description Language). De functionele splitsing van de hogere lagen van hoofdstuk 7 is in het EBIN toegepast. De splitsing van de hogere lagen van het EBIN wijkt af van het algemeen model, deze afwijkingen zullen terloops in dit hoofdstuk worden aangegeven. Allereerst kan men stellen dat het algemeen model uitgaat van apparatuur zoals die in de toekomst op de markt zal zijn indien er gebruik wordt gemaakt van breedbandige (huis)netwerken. In het EBIN zijn meerdere apparaten aan een VME-systeem gekoppeld. De plattegrond, met daarin zichtbaar alle verbindingen, alle apparatuur en alle diensten, is op de monitor van de Macintosh aanwezig.
8.2 Managed Objectsin het EBIN De managed objects van het EBIN kunnen als volgt worden verdeeld: • apparatuur objecten. • verbindings objecten. • luidsprekerpaar objecten. • dienst objecten. 8.2.1 Apparatuurobjecten
De apparaten die bestuurd kunnen worden zijn:
81
Hoofdstuk 8
Toepassing van het algemeen concept op het EBIN • Monitor (onderdeel van de macintosh); • Camera; • Luidspreker; • Microfoon; • CD-speler. Objecten als monitor, camera, luidspreker en CD-speler kunnen van afstand bestuurd worden. Voor het besturen van deze objecten manipuleert de macintosh hun attributen. Als een attribuut gemanipuleerd wordt moet het object eNoor zorgen dat er RC5-berichten naar het apparaat wordt gestuurd, zodat de gewenste manipulatie wordt uitgevoerd. RC5 is een in Philips-apperatuur gebruikte afstandsbedieningscode. De apparatuur in het EBIN wordt bestuurd vanaf de macintosh, hetgeen ook een apparaat van het EBIN is. De signalen van een trackerballof een muis worden door de macintosh verwerkt, en de opdrachten worden over het EBIN gerouteerd naar het originele apparatuurobject. In Appendix C zijn de recordtypes van de apparatuurobjecten gespecificeerd.
8.2.2 Verbindingsobjecten Een verbindingsobject beheert een verbinding van bron naar put(ten). Met bron wordt het producerende object (OutputObject) bedoeld, bijvoorbeeld een CD-speler, en met put wordt het consumerende object (lnputObject) bedoeld, bijvoorbeeld een luidspreker. De macintosh kan de volgende opdrachten, ten aanzien van verbindingsobjecten, geven: • Maak een verbinding tussen bron en put (Create). • Voeg een put toe aan een verbinding (Attach).
82
Hoofdstuk 8
Toepassing van het algemeen concept op het EBIN • Verwijder een put uit een verbinding (Detach). • Verwijder de verbinding in zijn geheel (Delete). Alle opdrachten hebben acties in de HNC tot gevolg. Dit komt doordat verbindingen alleen vanuit de HNC opgezet en uitgebreid kunnen worden. Het is dus logisch om verbindingsobjecten in de HNC te plaatsen. In appendix D is het recordtype van het verbindingsobject gespecificeerd.
8.2.3 Luidsprekerpaarobject Een luidsprekerpaarobject is een object waarmee een paar luidsprekers beheerd kan worden. In het EBIN bestaat een luidsprekerobject uit een audioversterker met daarop aangesloten een luidspreker. Volume- en toonregeling is volkomen symmetrisch voor beide luidsprekers. Balansregeling daarentegen is asymmetrisch. Dit betekent dat als men stereo geluid wil hebben, de balans door een speciaal object geregeld moet worden. Het luidsprekerpaarobject draagt zorg voor de berekening van de nieuwe waarden van de Volume-attributen, hetgeen afhankelijk is van de Balance-stand. Daarna moeten de nodige CHANGE-berichten worden verstuurd. In appendix E is het recordtype van het luidsprekerpaarobject gespecificeerd.
8.2.4 Dienstobjecten Een dienstobject is een object waarmee een dienst beheerd kan worden. De diensten die het EBIN biedt zijn toegelicht in 4.4 "Diensten in het EBIN" zijn: • videodistributie • audiodistributie • telecontrol • home automation
83
Hoofdstuk 8
Toepassing van het algemeen concept op het EBIN
• videotelefonie • video- en audio-bewaking Het dienstobject beheert de verbindingen die de dienst mogelijk maakt en draagt zorg voor de effectuering van de besturing van de dienst. Een videotelefoniedienst bestaat bijvoorbeeld uit twee audio- en twee video-verbindingen die beheerd moeten worden. Een gebruiker heeft de mogelijkheid om zijn eigen beeld te zien hetgeen inhoudt dat één videoverbinding van "zijn" camera naar "zijn" monitor gelegd moet worden. In appendix F zijn de recordtypes van de dienstobjecten gespecificeerd. 8.2.5 Het manipuleren van objecten
Het manipuleren van objecten in een omgeving met meerdere macintoshes kan problemen opleveren. Om te voorkomen dat meerdere macintoshes tegelijkertijd toegang hebben tot één en hetzelfde object moeten objecten opgeëist worden. Een object dat opgeëist is kan alleen gemanipuleerd worden door de macintosh die hem opgeëist heeft. Als de macintosh de manipulaties heeft uitgevoerd moet het object worden vrijgegeven. In het EBIN zijn twee bedieningstations (Macintoshes) aanwezig. Beide stations hebben een gelijke prioriteit. 8.2.6 Informatie-behoefte
Voor het creëren en manipuleren van objecten is informatie nodig. Bij de macintosh is er behoefte aan informatie, omdat de macintosh allereerst moet weten welke objecten in het netwerk aanwezig zijn en wat hun toestand is, zodat de macintosh zinvolle opdrachten kan geven.
8.3 Functionele splitsing van de hogere lagen De functionele splitsing van hetEBINwijkt enigzins af van de functionele splitsing uit hoofdstuk 7, de functionaliteit van
84
Hoofdstuk 8
Toepassing van het algemeen concept op het EBIN
de NIM is in de MTSE opgenomen. In het EBIN netwerk zijn we uitgegaan van twee blokken namelijk de MTSE en de CLSE, daarbij ondersteunt de IB de CLSE. • Functies MTSE De basisfunctie van de MTSE is het transporteren van berichten tussen VME-systemen en het VME-systeem van de HNC. Voor het transporteren van berichten tussen VMEsystemen en het VME-systeem van de HNC zijn de volgende functies nodig: o
het routeren van berichten;
o
het coderen en decoderen van CCI-berichten naar en van het netwerk;
o
het versturen van berichten met ontvangstbevestiging.
Verder verzorgt de MTSE de initialisatie van VME-systemen die aangesloten worden. Onder CCI-berichten worden de berichten verstaan die CLSE's met elkaar uitwisselen. • Functies CLSE De basisfunctie van de CLSE is het ten uitvoer brengen van opdrachten, die worden gegeven via de macintosh. De CLSE in de HNC houdt zich bezig met het manipuleren van verbindingen, diensten en luidsprekerparen. Terwijl de CLSE in een VME-systeem waarop apparatuur en/of een macintosh is aangesloten zich bezighoudt met communicatie met de macintosh en/of het aansturen van apparaten. De functies van de CLSE in de HNC zijn de volgende: o het manipuleren van verbindingen; o
het manipuleren van luidsprekerparen.
85
Hoofdstuk 8
Toepassing van het algemeen concept op het EBIN
De functies van de CLSE in de andere VME-systemen zijn de volgende: o
het plegen van communicatie met de macintosh;
o
het aansturen van apparaten, d.m.v. RC5-codes.
Beide CLSE' s moeten zorgen voor terugmeldingen, zodat de macintoshes geïnformeerd blijven over de meest actuele toestand van objecten. • De lnformation Base De CLSE kan alleen functioneren op basis van informatie van de objecten. De macintoshes moeten weten welke objecten beschikbaar zijn en wat hun toestand is. In de Home Net Controller (HNC) is informatie over luidsprekerparen, de opgezette diensten en de verbindingen aanwezig. Bij alle macintoshes is een IB aanwezig. Deze IB bevat kopie-informatie van alle in het netwerk aanwezige informatie. Het onderhoud van deze informatie vindt plaats op basis van terugmeldingen die objecten in het netwerk verzenden. Deze IB moet nog geïmplementeerd worden in de het supercard programma van de Macintosh. Bij de VME-systemen is een beperkte IB aanwezig, waarin alleen informatie van de ter plekke aanwezige apparatuur in objecten ligt opgeslagen. In de HNC bevat de IB informatie van alle ter plekke aanwezige objecten; de verbindings-, dienst- en luidsprekerpaar-objecten. Alleen informatie in de IB van objecten die ter plekke aanwezig zijn, is actueel. Overige informatie wordt verzameld aan de hand van terugmeldingen van objecten en hoeft dus niet actueel te zijn. Zoals reeds eerder is gezegd bevat de IB bij de moe-
86
Hoofdstuk 8
Toepassing van het algemeen concept op het EBIN
intosh kopie-informatie. Deze informatie hoeft niet actueel te zijn. Toch wordt op basis van deze informatie bekeken of manipulatie van een object mogelijk is, waarna de operatie eventueel wordt verstuurd. Hierdoor wordt onnodig berichtenverkeer over het netwerk voorkomen. Het kan dus voorkomen dat de kopie-informatie niet actueel is, daardoor treden echter geen fouten op. De operatie wordt uitgevoerd na controle middels de originele informatie, bij de real resource. Voor het onderhouden van de IB zijn de volgende procedures voldoende (zoals al eerder genoemd in 6.3.4 "Naming Scheme"): o /BC/aim, waarmee de informatie van een object
geclaimd wordt. o IBUnC/aim, waarmee de informatie van een object vrijgegeven wordt.
o IBCreateObject, waarmee informatie van nieuwe objecten opgenomen wordt. o IBDeleteObject, waarmee informatie van een ob-
ject verwijderd wordt. o /BChangeAttribute, waarmee een attribuutwaarde van een object kan worden gewijzigd.
o /8/nquireAttribute, waarmee een attribuut van een
object kan worden opgevraagd. o IBGetObjectlnfo, waarmee alle attributen van een
object in één keer kunnen worden opgevraagd. In de appendix G met de MODULA 2 - software voor de hogere lagen van het EBIN zijn deze procedures gespecificeerd in ibproc.def en ibproc.mod.
87
Hoofdstuk 8
Toepassing van het algemeen concept op het EBIN
8.4 Gebruikte functionaliteit van lagere lagen 8.4. 1 Het aansturen van apparaten Het aansturen van apparaten geschiedt middels RC5-berichten. De RC5-bus en berichten zijn ontworpen door Philips, die het gebruikt voor het op afstand bedienen van video en audio apparatuur. In het EBIN is een interface opgenomen, waarmee RC5-berichten gegenereerd kunnen worden (WID9l). Het gebruik van RC5-codes is unidirectioneeL d.w.z. alleen naar het bediende apparaat toe. Er komen geen terugmeldingen van het apparaat. De specificaties van het gedrag volgend op de operaties die naar de desbetreffende apparatuurobjecten worden gestuurd zijn gespecificeerd in SDL. De SOL-schema's hiervoor zijn te vinden in appendix H tevens is de bijbehorende MODULA-2 software te vinden in appendix I.
8.4.2 Het manipuleren van een verbinding Voor het manipuleren van verbindingen hebben de hogere lagen beschikking over een aantal primitieven, die doorgegeven worden aan het proces BeorerControl in de lagere lagen. In de HNC kunnen de volgende primitieven gegenereerd worden: • SetupReq, waarmee een verbinding tussen twee partijen opgezet kan worden. Met parameters wordt aangegeven tussen welke partijen de verbinding komt te liggen en van welke informatiesoort de verbinding is; • DisconnectReq, waarmee een verbinding afgebroken kan worden; • AttochReq, waarmee een nieuwe party in de verbinding opgenomen kan worden; • DetochReq, waarmee een party uit de verbinding verwij-
88
Hoofdstuk 8
Toepassing van het algemeen concept op het EBIN
derd kan worden. In de lagere lagen van de HNC kunnen de volgende primitieven gegenereerd worden: • SetupResponse, waarmee een verbinding geaccepteerd kan worden; • DisconnectRequest, waarmee een bestaande verbinding wordt afgebroken. Dit gebeurt minimaal voor de tak naar het betreffende VME-systeem; • RejectRequestl waarmee een nieuwe verbinding afgewezen kan worden.
Het opzetten, uitbreiden en afbreken van een verbinding kan alleen vanuit de HNC geschieden. Het is dan ook logisch dat zich juist daar de verbindingsobjecten bevinden. De specificaties van het gedrag op de operaties die naar de desbetreffende apparatuurobjecten worden gestuurd zijn gespecificeerd in SDL. De SDL-schema' s hiervoor zijn te vinden in appendix H tevens is de bijbehorende MODULA-2 software te vinden in appendix I.
8.5 Overzicht van de hogere lagen in het EBIN In deze paragraaf wordt de verdere functionele opdeling van de MTSEen de CLSE beschreven. Zoals gezegd zijn de hogere lagen van het EBIN onderverdeeld in twee belangrijke delen te weten de CLSE en de MTSE. Deze blokken zijn op hun beurt weer onderverdeeld in verschillende functionele eenheden. I
De CLSE in onderverdeeld in de volgende functionele eenheden (processen): • RS2321ntertacel in het VME-systeem waarop een macintosh is aangesloten die zorgt voor de communicatie met de Macintosh; I
89
Hoofdstuk 8
Toepassing van het algemeen concept op het EBIN
• Generator, in de HNC, die zorgt voor de creatie van objecten in de HNC; • Objecten, in de VME-systemen (HNC en andere). De MTSE is ondeNerdeeld in de volgende functionele eenheden: • Router, die zorgt voor het routeren van berichten in het netwerk; • ConversionSublayer, die zorgt voor het coderen c.q. decoderen van berichten en het versturen van berichten met ontvangstbevestiging; • lnit, die zorgt voor de initialisatie van de hogere lagen van het EBIN. Verder bevat de MTSE van de HNC het proces BearerReferenceManager (BrMan). Dit proces zorgt voor de associatie van verbindingen met processen. 8.5. 1 De CLSE Vanuit de CLSE wordt het huisnetwerk bestuurd, middels het uitwisselen van CCI-berichten tussen de CLSE's in het huisnetwerk. Voor het manipuleren van objecten zijn voor het EBIN de volgende berichten gedefinieerd: • CREATE, waarmee de Macintosh objecten in de CLSE van de HNC kan creëren. Het betreft hierbij objecten als verbindingen, luidsprekerparen en in een later stadium ook diensten; • DELETE, waarmee de Macintosh objecten uit de CLSE van de HNC kan verwijderen; • CLAIM, waarmee de Macintosh objecten kan opeisen. Hierdoor wordt een object exclusief manipuleerbaar vanaf één macintosh. • UNCLAIM, waarmee de Macintosh een object, na manipulatie, kan vrijgeven.
90
Hoofdstuk 8
Toepassing van het algemeen concept op het EBIN • CHANGE, waarmee de Macintosh een attribuut van een object kan wijzigen. Om een attribuut van een object te wijzigen moet het object allereerst met een CLAIM bericht exclusief manipuleerbaar worden gemaakt. Als dit niet zou gebeuren dan zou het kunnen voorkomen dat meerdere Macintoshes tegelijkertijd een object aan het manipuleren zijn. Na een manipulatie m.b.v. het bericht CHANGE kan een object worden vrijgegeven d.m.v. het UNCLAIM bericht. • NOTIFY, waarmee objecten de macintoshes op de hoogte brengen van hun meest actuele toestand. Als een object geactiveerd wordt is het versturen van een NOTIFY berjcht de eerste actie die het zal ondernemen. Een NOTIFY bericht kan ook vergezeld gaan van een resultaat, waarmee het gevolg van een manipulatie aan de manipulerende macintosh door geven kan worden.
8.5.1.1 RS232 Interface De RS232 Interface zorgt voor communicatie met de Macintosh. In de Macintosh bevindt zich de UI die, via de seriële interface, communiceert met een VME-systeem. De Macintosh codeert berichten volgens een vastgesteld formaat en stuurt deze, karakter voor karakter, naar het VME-systeem. De RS232 Interface leest de berichten, karakter voor karakter in en maakt er een bericht van dat met andere processen uitgewisseld kan worden. Dit bericht wordt vervolgens aangeboden -voor routering.
..
Na manipulatie zullen de objecten in het netwerk de moeintoshes in het netwerk informeren over hun toestand. Na routering komen deze berichten bij de RS232 Interface terecht. De RS232 Interface zal het betreffende bericht coderen en via de seriële interface naar de Macintosh sturen. In appendix J wordt de codering van de berichten tussen macintosh en VME-systeem besproken.
91
Hoofdstuk 8
Toepassing van het algemeen concept op het EBIN 8.5. 1.2 Het leggen van een verbinding Voor het leggen van een verbinding (link) stuurt de Macintosh een CREATE bericht naar de Generator in de HNC. Deze creëert een proces dat in het vervolg voor de betreffende verbinding zal zorgen. Als het linkproces gecreëerd is wordt het CREATE bericht hem nagezonden. Het CREATE bericht bevat namelijk informatie over de te leggen verbinding. Het proces zal vervolgens, m.b.v. software in de lagere lagen, een verbinding opzetten. Als de verbinding is opgezet, wordt er een terugmelding naar alle macintoshes gedaan d.m.v. een NOTIFY bericht.
8.5. 1.3 Het uitbreiden van een verbinding Verbindingen die zijn opgezet kunnen uitgebreid worden. Het uitbreiden van een verbinding geschiedt d.m.v. een CHANGE bericht. De Macintosh geeft in het CHANGE bericht mee welk object in de verbinding opgenomen moet worden. Met behulp van van de lagere lagen software wordt vervolgens de verbinding uitgebreid met het gewenste object, waarna er ook weer terugmelding plaatsvindt, middels het NOTIFY bericht.
8.5. 1.4 Het verwijderen van een verbinding Voor het verwijderen van een verbinding stuurt de Macintosh een DELETE bericht naar het betreffende verbindingsobject. Met behulp van de lagere lagen software heft het verbindingsobject de verbinding op. Het stuurt daarna een NOTIFY bericht en het heft vervolgens zichzelf op. De Macintoshes moeten uit het NOTIFY bericht opmaken dat het betreffende verbindingsobject is verdwenen.
92
Hoofdstuk 8
Toepassing van het algemeen concept op het EBIN 8.5. 1.5 Luidsprekerparen Ook luidsprekerpaarobjecten worden gecreëerd door de Generator in de HNC. De Generator start een LuidSprekerPairhendier in de CLSE van de HNC op en ook hier wordt het CREATE bericht nagezonden. Hieruit haalt het object de benodigde informatie, zoals de identiteit van de luidsprekers die het paar gaan vormen. Als de Macintosh een luidsprekerpaarobject claimt, dan claimt hij daarmee een paar luidsprekers .. Het luidsprekerpaarobject zal dus twee CLAIM berichten versturen, één naar iedere luidspreker. Als beide luidsprekers hierop positief reageren dan wordt dit middels een NOTIFY bericht aan de macintosh gemeld. Als een van beide luidsprekers niet geclaimd kan worden, dan kan ook het luidsprekerpaarobject niet geclaimd worden. Ook dit wordt middels een NOTIFY bericht gemeld aan de macintosh. Nadat een luidsprekerpaarobject in de CLSE van de HNC is geclaimd van uit een van de Macintoshes, kan het gemanipuleerd worden. Manipulaties op een luidsprekerpaarobject worden altijd vertaald in manipulaties op beide luidsprekers. D.m.v. een CHANGE bericht kan het volume van beide luidsprekers tegelijkertijd bediend worden. Het wijzigen van het attribuut balans resulteert in twee berichten waarmee het volume verschillend voor beide luidsprekers wordt ingesteld. Dit komt bij de gebruiker over als het instellen van de balans.
8.5. 1.6 Manipulatie van objecten Voor het manipuleren van een object stuurt de Macintosh een CHANGE berichten, waarmee attributen van een object veranderd worden. Om te voorkomen dat meerdere Macintoshes tegelijkertijd een object manipuleren moet het object geclaimd worden, d.m.v. het CLAIM bericht. Een object dat geclaimd is zal alleen manipulatie toelaten door de Macintosh die het object geclaimd heeft.
93
Hoofdstuk 8
Toepassing van het algemeen concept op het EBIN Als een object een CHANGE bericht ontvangt zal het dus eerst controleren of de Macintosh het object opgeëist heeft. Is dat niet het geval dan wordt een NOTIFY met negatief resultaat en reden van het mislukken teruggestuurd. Is het CHANGE bericht uitgevoerd, dan wordt een NOTIFY bericht met positief resultaat teruggestuurd. Het NOTIFY bericht bevat tevens de meest actuele objectinformatief waarmee de kopie-informatie van het betreffende object elders in het netwerk, wordt bijgewerkt. I
Objecten in de VME-systemen die geactiveerd worden zullen een Object/dl aanvragen bij het proces BrMan. Zodra zij over een Objectld beschikken zullen zij zichzelf in het netwerk kenbaar maken d.m.v. het versturen van een NOTIFY bericht. Tevens zal hierdoor objectinformatie in de IB's bij de Macintoshes worden aangebracht.
8.5.1.7 Aansluiten van VME-systemen Bij het aansluiten van een nieuwe VME-systeem sturen de apparatuurobjecten, van de apparatuur aangesloten aan het VME-systeem, NOTIFY-berichten naar alle Macintoshes aangesloten aan het huisnetwerk. De NOTIFY-berichten stellen de Macintosh op de hoogte van de nieuw aangesloten apparatuur aan het EBIN.
8.5. 1.8 Aansluiten van een Macintosh Bij het aansluiten van een nieuwe Macintosh verstuurd deze een UPDATE die door het EBIN wordt vermenigvuldigd en naar alle originele objecten wordt gerouteerd. De originele objecten versturen daarna een NOTIFY-bericht naar de aangesloten Macintosh. De Macintosh verzamelt deze informatie in de lnformation Base en kan op de monitor een actueel beeld van het huisnetwerk presenteren met alle aangeslot- en apparaten, opgezette verbindingen en diensten.
94
Hoofdstuk 8
Toepassing van het algemeen concept op het EBIN
8.5.2 De MTSE 1 8.5.2.1 Het routeren van CCI-berichten 8.5.2.1.1 Unieke objecten
Om routering van berichten naar objecten mogelijk te maken, is het van belang dat zij uniek identificeerbaar zijn. In het EBIN is gekozen voor het toekennen van een Object ldentiteitsnummer aan een object. Deze Objectld is uniek binnen een objectsoort. De combinatie (ObjectSoort,Objectld) is uniek binnen het EBIN. Objecten in de VME-systemen kunnen, bij het aansluiten van het VME-systeem, een Objectld aanvragen bij het proces lnit in de MTSE. lnit beschikt over het PartyNumber van het VME-systeem, welke uniek is voor iedere VME-systeem. Met dit PartyNumber kan op eenvoudige wijze een unieke Objectld worden gegenereerd. De Object/d's van de objecten in de HNC worden vastgesteld door de macintosh. Hij stuurt deze mee in het CREATE bericht, zodat hij bij het ontvangen van NOTIFY berichten onderscheidt kan maken tussen NOTIFY berichten als gevolg van zijn acties en NOTIFY berichten als gevolg van acties door andere macintoshes. leder object is identificeerbaar door zijn Objectld. Deze identifier is echter alleen uniek binnen hetzelfde objectsoort. De combinatie (Object,Objectld) is uniek door het gehele netwerk. Op basis van dit gegeven en de semantiek van de CCI-berichten vindt routering plaats. 8.5.2.1.2 Berichten en bestemmingen
In Tabel 8.1 zijn alle berichten en hun bestemmingen op een rijtje gezet.
1)
In mijn afstudeer periode bij PTI Research heb ik in de implementatieen specificatiefase samen gewerkt met R. Nieuwenhuizen (afstudeerder HIO Den Haag). R. Nieuwenhuizen is, voornamelijk, verantwoordelijk voor het werk aan de MTSE. 95
Toepassing van het algemeen concept op het EBIN
Hoofdstuk 8
Het bericht CREATE heeft altijd de Generator in de HNC als bestemming. Als de router in een VME-systeem een CREATE bericht ontvangt van de macintosh dan wordt dit altijd doorgestuurd naar de router in de HNC. De router in de HNC zal er vervolgens voor zorgen dat het bericht bij de Generator terecht komt. Tabel 8.1 Berichten en hun bestemming CCI - bericht CREATE
Bestemming in het EBIN
I De
Generator in de CLSE van
i de HNC
DELE TE
I Het object dat verwijderd dient te worden
CHANGE
CLAIM
Het object waarvan het attribuut veranderd dient te , worden j Het object dat men wil claimen
1
I UNCLAIM
I Het
object dat men wil unI claimen
UPDATE
Alle originelen in het EBIN
NOTIFY
Als een responce op een UPDATE gericht aan de zender van de UPDATE, anders aan alle UI's
De berichten CLAIM, UNCLAIM en CHANGE hebben een gespecificeerd object als bestemming. Als de router in een VME-systeem een CLAIM, UNCLAIM of CHANGE bericht ontvangt, dan bepaalt hij of het object, waarvoor het bericht bestemd is, hem bekend is. Als dit het geval is dan stuurt hij het bericht door, anders wordt het bericht naar de router in de HNC gestuurd. De router in de HNC zorgt er vervolgens voor dat het bericht terecht komt bij het object, hetzij direct, hetzij indirect via de router van het VME-systeem waar het object zich bevindt. UPDATE berichten worden altijd verstuurd door macintoshes die geïnformeerd willen worden over de toestand van de objecten in het netwerk. Het UPDATE bericht komt dus allereerst terecht in de router van de nieuw aangesloten VME-systeem. De router stuurt het UPDATE bericht naar de router van de HNC. De router van de HNC stuurt het UPDA-
96
Hoofdstuk 8
Toepassing van het algemeen concept op het EBIN TE bericht vervolgens door naar alle objecten die in de CLSE van de HNC aanwezig zijn en naar allerouters van de overige VME-systemen. De router van de VME-systemen zullen als laatste het UPDATE bericht doorsturen naar alle hun bekende objecten. Het NOTIFY bericht kan op twee manieren verzonden worden, namelijk gericht en ongericht. Een ongericht NOTIFY bericht is bestemd voor alle gebruikerinterfaces in het netwerk. Een gericht NOTIFY bericht is bestemd voor de macintosh bij, de in het NOTIFY bericht, gespecificeerd VME-systeem.
8.5.2.1.3 Het verzamelen van routeringsinformatie De routers moeten op een of andere manier informatie, met betrekking tot paden naar objecten, verzamelen. Deze informatie wordt ontleend aan NOTIFY berichten. De router is slechts geïnteresseerd in twee dingen, namelijk: • wie stuurde het NOTIFY bericht, dus welk object? • via welk proces heeft het NOTIFY bericht de router bereikt? Om erachter te komen welk object het bericht verstuurd heeft wordt naar het NOTIFY bericht gekeken. Het object dat het NOTIFY bericht verzonden heeft heeft hierin zijn identificatie achtergelaten, namelijk (Object,Objectld). In de HNC kunnen NOTIFY berichten van meerdere kanten de router de HNC bereiken, te weten: • van de diverse ConversionSublayers (van de VME-systemen), • van objecten in de HNC. Van objecten in de HNC is een directe route bekend. De routes naar objecten in de VME-systemen bestaan voor de router in de HNC uit routes naar ConversionSublayers. De router in de VME-systemen zal ervoor zorgen dat een be-
97
Hoofdstuk 8
Toepassing van het algemeen concept op het EBIN
richt, afkomstig van de router van de HNC, naar het juiste object wordt gerouteerd. Als de router in een VME-systeem een bericht moet sturen naar een object dat hem niet bekend is dan wordt dit bericht naar de router in de HNC gestuurd. De router in de HNC moet er dus voor zorgen dat het bericht bij een object in de HNC terecht komt of bij een router in een ander VMEsysteem. Het routeren van een bericht naar een object is nu slechts een kwestie van het 'backtracen' van een pad. Als de router een bericht doorgestuurd krijgt, dan zoek hij, aan de hand van de combinatie (Qbject,Objectld), op welk proces hij een voorgaand NOTIFY bericht heeft ontvangen. Hier wordt vervolgens het bericht naar toe gestuurd. De macintosh kan alleen berichten sturen naar objecten die zich, aan hem, bekend hebben gemaakt, zodat paden naar objecten altijd traceerbaar zijn. Het op deze manier verzamelen van routerings-informatie is simpel en krachtig. 8.5.2.2 Het associëren van verbindingen en processen
In de CLSE van de HNC zijn verschillende processen aanwezig die ieder een verbinding beheren. Bij het ontwerpen van de lagere lagen is uitgegaan van slechts één proces voor het beheer van verbindingen in de hogere lagen. Het probleem dat hierdoor onstoot is opgelost door de implementatie van het proces BrMan. BrMan zorgt voor de associatie van een proces met een verbinding. Als een proces een verbinding wil gaan beheren dan moet het allereest een BearerReference aanvragen bij BrMan waarmee de verbinding uniek geidentificeerd wordt. Bij het aanvragen van een BearerReference vindt ook de associatie, met de unieke identificatie, plaats. Vervolgens kan het proces met behulp van de identifier een verbinding manipuleren, d.w.z. opzetten, uitbreiden, verwijderen, e.d.
De bovenkant van BrMan voorziet dus in gewenste functie-
98
Hoofdstuk 8
Toepassing van het algemeen concept op het EBIN naliteit voor de hogere lagen, terwijl de onderkant aansluit bij de functionaliteit geleverd door de lagere lagen.
8.5.2.3 Coderen en decoderen van cel-berichten De uitwisseling van Cel-berichten tussen VME-systemen en HNC vindt plaats d.m.v. UnitData pakketten. Het proces ConversionSublayer zorgt o.a. voor de codering en decodering van CCI-berichten op UnitData pakketten. De te coderen berichten worden door de router aan de ConversionSublayer aangeboden. Gedecodeerde berichten worden door de ConversionSub/ayer aan de router aangeboden.
8.5.2.4 Versturen van berichten met ontvangstbevestiging In de lagere lagen is geen functionaliteit aanwezig die voorkomt dat UnitData pakketten verloren gaan. Om ervoor te zorgen dat UnitData pakketten altijd de overliggende ConversionSublayer (de bestemming) bereiken, wisselen de ConversionSublayers ontvangstbevestigingen uit. Dit gaat als volgt: l De ConversionSublayer accepteert een CCI-bericht en slaat dit vervolgens op in een buffer. Deze buffer heeft een nummer, te weten RequestNumber.
2 Uit het CCI-bericht wordt een UnitData pakket samengesteld, dat tevens wordt voorzien van het RequestNumber en een ToggleBit. Het ToggleBit wordt gebruikt om onderscheid te kunnen maken in oude en nieuwe UnitData berichten. Dit UnitData pakket wordt vervolgens aan de lagere lagen aangeboden, zodat het in de andere ConversionSublayer aankomt. Daarna start deze ConversionSublayer een klok, die na verloop van tijd zal afloopt. Als de klok afloopt wordt aangenomen dat het UnitData pakket de overkant niet heeft gehaald en wordt deze stap herhaald. 3 De overliggende ConversionSublayer ontvangt het UnitData pakket en decodeert het. Tijdens het decoderen komen RequestNumber en ToggleBit beschikbaar. In een
99
Hoofdstuk 8
Toepassing van het algemeen concept op het EBIN tabel wordt vervolgens opgezocht of het betreffende UnitDato pakket nieuw is door het ToggleBitin de tabel te onderzoeken. Als het UnitDato pakket nieuw is dan wordt het aan de Router aangeboden, die het vervolgens zal routeren. Ook wordt het ToggleBit in de tabel aangepast. Daarna wordt er een UnitDato pakket dat fungeert als ontvangstbevestiging samengesteld en teruggestuurd. In dit UnitDato pakket zijn ondermeer het RequestNumber en het ToggleBit opgenomen. 4 Bij ontvangst van de ontvangstbevestiging decodeert de Conversion-Subfoyer het UnitDato pakket. Hierdoor komen RequestNumber en ToggleBit weer vrij. Als de buffer met nummer RequestNumber in gebruik is en het ToggleBit heeft de verwachte waarde, dan wordt de betreffende buffer vrijgegeven. Dit protocol heeft overeenkomsten met het l-bit sliding window'-protocol, zoals beschreven in (TAN8l). Echter er zijn qua implementatie wel enige wijzigingen op toegepast zoals het gebruik van buffers. I
I
8.5.2.5 Het wijzigen van de netwerkconfiguratie Onder het wijzigen van de netwerkconfiguratie wordt verstaan het installeren c.q. verwijderen van VME-systemen uit het netwerk. Het installeren van VME-systemen en het verwijderen hiervan heeft grote gevolgen voor diverse onderdelen van het netwerk, zoals Ul's en de reuters in het netwerk.
8.5.2.5.1 Het installeren van VME-systemen Het aansluiten van een VME-systeem op het netwerk wordt opgemerkt door de lagere lagen in de HNC. Deze zullen hierdoor een bericht sturen naar het proces lnit in de MTSE van de HNC die vervolgens zorgt voor de installatie van het VME-systeem in het netwerk. Als een nieuw VME-systeem in het netwerk wordt aangesloten dan zorgt de MTSE van de HNC allereerst voor dat een bidirectionele verbinding met de MTSE van het VME-systeem wordt opgezet. Deze verbinding wordt opgebouwd tussen
100
Hoofdstuk 8
Toepassing van het algemeen concept op het EBIN twee ConversionSubloyers, waarvan de ene zich in het VME-systeem bevindt en de andere in de MTSE van de HNC. In eerste instantie bevat de MTSE van de HNC geen ConversionSubloyers. Pas bij het installeren van een VME-systeem wordt er een Convers/onSubfoyer in de MTSE van de HNC opgestart. Vervolgens wordt de bidirectionele verbinding tussen deze nieuwe Convers/onSubfoyer en de Con versionSubfoyer in de MTSE van het geinstalleerde VME-systeem opgezet. Objecten in het VME-systeem moeten bij installatie een identifier aanvragen bij de MTSE van het desbetreffende VME-systeem. Deze aanvragen worden vastgehouden, totdat de Convers/onSubfoyer verbonden is met de Convers/onSubfoyer in de MTSE van de HNC. Als deze staat dan worden de aanvragen afgehandelt, waarna de objecten zichzelf aan het netwerk kenbaar maken d.m.v. NOTIFY berichten. Hierdoor weten de macintoshes van het bestaan van deze objecten. Tevens kunnen de diverse reuters hierdoor routeringsinformatie verzamelen. Als er op een monitor een UI zichtbaar is dan zal deze een UPDATE bericht versturen, waardoor hij informatie over andere objecten in het netwerk verzamelt.
8.5.2.5.2 Het verwijderen van VME-systemen Naast het installeren van VME-systemen kunnen VME-systemen ook verwijderd worden. Als een VME-systeem verwijderd wordt verdwijnen ook alle objecten van de apparatuur aangesloten op het VME-systeem. Ze zijn echter niet in staat om dit te melden aan de macintoshes in het netwerk. Het verdwijnen van een VME-systeem uit het netwerk wordt opgemerkt door de lagere lagen in de HNC. Deze sturen een bericht naar de MTSE van de HNC die vervolgens stappen zal ondernemen om het verdwijnen van de objecten kenbaar te maken aan de macintoshes. Tevens wordt de routeringsinformatie van de betreffende objecten uit de reuters verwijderd.
lOl
9. CONCLUSIES
Hoofdstuk 9
Conclusies
9.1 Inleiding In hoofdstuk 8 is gesproken over de toepassing van het concept in het EBIN. Het EBIN heeft als doel de principes van een huisnetwerk te demonstreren. Het EBIN netwerk wordt dan ook in een huiskamer, met bankstel, planten etcetera, gedemonstreerd. In dit hoofdstuk wil ik een overzicht geven van de status van het EBIN en een evaluatie van mijn afstuderen.
9.2 Status van het EBIN 9.2.1 Hordware In het EBIN draait de software op de VME-systemen, zie 3.5 "VME-systeem". De informatiestromen binnen het EBIN vloeien over een passieve optische boom. Tevens is het transporteren van audio en video, middels ATM, mogelijk.
9.2.2 De logere logen software De functionaliteit van de lagere lagen software in het EBIN komt overeen met de "Functionaliteit van de lagere lagen" zoals beschreven in hoofdstuk 3.4. De lagere lagen software is klaar en getest. Tevens is er een demonstratie programma geschreven waarmee de werking van de lagere lagen software gedemonstreerd kan worden. Ronging en Conneetion Control wordt middels deze demonstratie software gedemonstreerd.
9.2.3 De hogere logen software De hogere lagen software (voor de besturing en het beheer) ondersteunt de hierna volgende acties: • Het leggen van verbindingen tussen de apparatuur van het EBIN. • Het veranderen van verbindingen; het toevoegen van
103
Hoofdstuk 9
Conclusies een verbinding met een outputdevice of het verwijderen van een outputdevice uit een verbinding. • Het verwijderen van verbindingen. • Het besturen van apparatuur voor zover het specifieke apparaat dit toelaat. • Het aansluiten van nieuwe apparatuur aan het EBIN. • Het aansluiten van een nieuwe Macintosh aan het netwerk. Deze functionaliteit van de besturing en het beheer is nog niet volledig operationeel, daar de software in de Macintosh nog veranderd dient te worden. Tevens moet de software module die gebruikt wordt voor het aansturen van de apparatuur, middels RC5 (WID90L nog worden uitgebreid. In het voorgaande is opgesomd wat de besturing en het beheer van het EBIN ondersteunt. Echter de implementatie van het luidsprekerpaarobject en de dienstobjecten in het EBIN zijn nog niet voltooid. De implementatie van de diensten (audiodistributie, surveillance, videodistributie), waar geen interactie tussen gebruikers moet worden gepleegd, vraagt weinig tijd. Deze objecten hebben als meerwaarde dat op de Macintosh aangegeven kan worden waarvoor de opgezette verbindingen en apparaten worden gebruikt. De diensten waar wel interactie tussen gebruikers moet worden gepleegd (telefonie en videofonie) vragen om een CaliControl-protocoL Het CaliControl-protocol moet eerst worden uitgewerkt alvorens de diensten kunnen worden geïmplementeerd.
9.3 Demonstratie ruimte van het EBIN Oorspronkelijk wilde men het EBIN demonstreren door het inrichten van meerdere ruimtes. In het huidige ontwerp van de demonstratie ruimte is men uitgegaan van twee ruimtes
104
Hoofdstuk 9
Conclusies die gescheiden worden door een glasplaat, zodat de bezoekers overzicht houden over de ruimtes. De bezoekers kunnen nu ook vanuit de woonkamer de gehele demonstratie volgen. De bezoekers van bij het EBIN krijgen een demonstratie van de diensten die een huisnetwerk kan bieden. Afhankelijk van het soort publiek ("leken" of "techneuten") wordt er daarop volgend een technische demonstratie gegeven. Een overzicht van de ruimte is te zien in figuur 9.1 .
• /•
:
..•..... ~.. JJ
0
0
I
'f ~-·····---------------------~ 650
Figuur 9.1 Demonstratieruimte van het EBIN
ptt,research .
~
. .
~
105
Hoofdstuk 9
Conclusies
9.4 Conclusies De afstudeeropdracht bestond uit twee delen; het opstellen van een algemeen model en het toepassen van dat algemeen model op het EBIN. Bij de eerste taak van mijn opdracht is gekozen voor een object-georiënteerde (0-0) oplossing, waarbij de principes van Telecommunication Management Netwerk (TMN) zijn gebruikt. Tevens heb ik in dit algemeen model gekozen voor distributie van informatie over het huisnetwerk, waarbij als uitgangspunt geldt dat op de plaats waar het object zich bevindt (apparaat) danwel opgezet afgebroken of uitgebreid (verbindingen en diensten) de originele informatie aanwezig is. Kopieën van deze objecten bevinden zich bij de User Interface. Op deze kopie-informatie wordt analyse gepleegd waardoor het netwerk niet belast wordt met het versturen van operaties, waarbij men van te voren weet dat deze operaties niet uitgevoerd kunnen worden. Er kunnen momenten zijn dat de kopie-informatie niet aktueel is, daardoor zullen echter geen fouten optreden daar de operatie pas worden uitgevoerd na controle bij het originele-object. Het concept in zijn geheel biedt de mogelijkheid om bij standaardisatie van de Camman Control and lnformation berichten apparatuur van verschillende fabrikanten aan te sluiten op een huisnetwerk. De betreffende fabrikanten van apparatuur (witgoed, bruingoed, grijsgoed, beveiligingsapparatuur en de meters van nuts-bedrijven) moeten dan zorgen dat bij het ontvangen van de desbetreffende operaties de juiste acties op de apparaten worden uitgevoerd en de afgesproken notificaties worden verstuurd. De infrastructuur kan tevens worden gestandariseerd met als eis dat de data op juiste manier gerouteerd en gecodeerd wordt in het huisnetwerk. Voor het tweede deel van de opdracht geldt dat in de MODULA 2 - software variabelen gecopieërd worden in andere structuren, hetgeen niet afdoet aan de functionaliteit van de software, enkel de performance van de software drukt.
106
Hoofdstuk 9
Conclusies Er kan gesteld worden dat met de implementatie van de software voor de besturing en het beheer een goede demonstratie van de mogelijkheden van huisnetwerken mogelijk is.
107
LITERATUURLIJST
Literatuurlijst (MEZ91)
Gebouwen en Home Electronic Systems Ministerie van Economische zaken januari 1991
(TEL91)
Zeven miljoen en verder? Plannen van PTI Telecom voor de jaren negentig 18 februari 1991, PTI Telecom Den Haag
(ATM91)
ir R.J.F. de Vries ATM: A status Report -Issue 2januari 1991, PTI Research
(B0089)
drs. A.K. van den Boogaart, Communicatietechniek (CT) Common Management lnformation Service, een inleiding. september 1989, PTI Research
(BAN89)
Bang & Olufsen A/S Jydsk Telefon S0ren T.Lyngs0Home lnformation Netwerk (HIN) November 1989, ISBN:87-983125-2-9
(HS91)
Home System Specificatien (HS) January 1991, ESPRIT-HS Consortium
(TMN90)
Opleidingshandboek Beheer ProjectGroep Telecommunicatie Management 29 oktober 1990, PTI Research
(ZWE90)
Alexander Zwennes Gebruikersinterface voor een inhuisnet juli 1990, PTI Research
(BAA91)
M. Baan en P.M. Hofman Tele-lnformatica, Standaardisatie van huis- en gebouwbeheersystemen februari 1991, PTI Research
103
Literatuurlijst (KEY90)
M. Key, S. Leasken A. Oshisanwo ROSA: An object-oriented architecture for open seNices Br Telecom Technol J Vol 8 No 4 October 1990
(SHA90)
Y,-P Shan An object-oriented UIMS for rapid prototyping Interact '90, IFIP p.633
(BLA91)
Frits de Blauw De woning van morgen staat al om de hoek PTI Nieuwsblad, personeelskrant, 23 januari 1991 jrg 2 nr. 27
(GER91)
Van knoppenwoud naar eenvoud De Volkskrant, 12 januari 1991 Gerard Geradts
(TIT90)
Welkom in de Toekomst Chriet Titulaer 1990,p.18-33
(BRE90)
Breedband ISDN, t.b.v. geïntegreerde telecommunicatie TUE college diktaat, vakcode 5N270
(ISDN86)
ISDN, lntegrated Service Digital Networks PTI Research verslag 547 DNL/86
(LOE90)
C.R. Loesener, M.Azmoodeh, J.Bigham, B.Stahl The use of advanced information processing techniques in maintenance systems Interact '90, IFIP p. 160
(MUL90)
Sape J. Mullender Computers en netwerken: gedistribueerde systemen Informatie en informatiebeleid, herfst (8) 1990 No.3
(BAL88)
R.M. Bally Dornestic Premises Networks Publicotien 88 DNL/059 Boston,ll-16 september 1988
(HAR90)
J.W. van Hardeveld en AH. Zwennes Designing the user-interface for home-networks mei 1990, PTI Research Publicatie 415 RNL/90
104
Literatuurlijst (BAL87)
R.M. Bally en W. van der Bijl Home networks: today and Tomorrow september 1987, PTI Research Publicotien DNL 87/75
(SAK88)
Tetsushi Sakaguchi ea HBS Communication tunetion and routing management in various networks IEEE Transactions on Consumer Electronics, Vol. 34, No. 3, August 1988
(HAN89)
George Hannover Netwerking the intelligent home IEEE Spectrum vol.26, No. 10 p.48-9, october 1989
(TAN91)
Andrew S. Tanenbaum Computer Networks 1981 Prentice-Hall ,ISBN 0-13-164699-0
(0LS91)
Peter Oltshoorn Big brather in de meterkast Automatiserings Gids, 3 april 1991
(PAD87)
G Pradére New mediasystems in the home Conferencing home telemoties Elsevier Sience Publischer, 1988
(WID9l)
I. Widipangestu Control Language (COLA) in the EBlN model Afstudeerverslag 6/91 , Leidschendam, januari 1991
105
LIJST VAN AFKORTINGEN
L.v.A. AAL
=
ATM Adaption Layer
AF
=
Adaptor Functions
AlM
=
AlP Applicationsto IBCN Maintance
AlP
=
Advanced lnformation Processing
ATM
=
Asynchronous Transfer Mode
B-ISDN
=
Broodband lntegrated Service Digital Network
CATV
=
Community Antenna Television
CEFSM
=
Communicating Extended Finite State Machines
CCI
=
Common Control and lnformation
CCITT
=
Comité Consultative Internationale de Telegraphique et Telephonique
CLSE
=
Command Language Service Element
CM IS
=
Common Management lnformation service
CPE
Customer Premises Equipments
DCF
= =
DIN A
=
Distributed Architecture
downstream
=
Informatiestroom van de HNC af
DCPN
=
Dornestic Customer Premises Network
D2B
=
Dornestic Digital Bus
EB IN
=
Experimenteel Breedband lnHuis Netwerk
ETS I
=
Europeon Telecommunications Standards lnstitute
Data Communication Functions lnformation -processing
Network
107
L.v.A. GMSB
=
Generic Maintenance System Builder
HDTV/ATV
=
High Definition Television/Advanced Television
HS
=
Home Systems
IB
=
Intermation Base
IBCN
=
lntegrated Broodband Communication Netwerk
IBM
=
lnformation Base Manager
ICA
=
Intermation Content Architecture
ICF
=
Intermation Conversion Function
IIA
=
Intermation Content Architecture
IHS
=
lntegrated Home System
IMP
Interface Message Processors
IN
= =
IR
=
Intrared Receiver
ISDN
=
lntegrated SeNices Digital Netwerk
ISO
=
International Standardisation Organization
LAN
=
Local Area Netwerk
L.v.A.
=
Lijst van Afkortingen
MCF
=
Message Communication Functions
MF
=
Mediatien Functions
MIB
=
Management Intermation Base
MTSE
=
Message Transfer SeNice Element
NCP
=
Node Control Processors
Intelligente Netwerk
108
L.v.A. NEF
=
Netwerk Element Functions
NIM
=
Node lnitialisation Module
NNI
=
Netwerk Node Interface
OA&M
=
Operatien Administration and Maintenance
OPN
=
Open Provisioning Netwerk
00
=
Object Oriented
OSF
=
Operatien System Function
OSI
=
Open Systems lnterconnection
PF
=
Presentation Function
Pld
=
Procesindentification
PF
=
Presentation Function
PMD
=
Physical Medium Dependent-layer
QOS
=
Quality of Service
RACE
=
Research on Advanced Communications in Europe
RC
=
Remote Control
SDL
=
Specificatien and Description Language
SDL/GR
=
SDL/Graphical Representation
SDL/PR
=
SDL/Phrase Representation
SDT
=
SDL Tools
SDU
=
Service Data Unit
SMO
=
System Management Overvieuw
SPC
=
Stored Program Control
109
L.v.A. SPN
=
Subscriber Premises Netwerk
TMN
=
Telecommunication Management Netwerk
WAN
=
Wide Area Netwerk
WSF
=
Work Station Function
VP
=
Virtual Pad
UI
=
User Interface
UNMA
= =
Unified Netwerk Management Architecture
upstreem
Informatiestroom richting HNC
110
INHOUDSOPGAVE
Inhoudsopgave
BAND 2 Appendix A:
Huisnetten
Appendix B:
Functionele splitsing volgens Home Systems
Appendix C:
Recordtypes apparatuurobjecten
Appendix D:
Recordtype verbindingsobject
Appendix
Recordtype Luidsprekerpaarobject
Appendix F:
Recordtype Dienstobject
Appendix G:
IBproc.def en IBproc.mod
Appendix H:
SDI-diagrammen
Appendix 1:
MODULA 2 -software
Appendix J:
Codering berichten over RS232-poort
ii
APPENDIX A
Appendix A
Huisnettten A. 1 Inleiding Zal in de toekomst een robot huishoudelijke taken zoals stofzuigen uitvoeren? Zullen we in overleg met de huiscomputer een kleding keuze maken? Zal de huiscomputer het huishoudgeld en andere management activiteiten bijhouden? Alle industriële landen zijn op het moment druk doende met de ontwikkeling van zogenaamde huisnetwerken. In dit hoofdstuk wordt beschreven welke ontwikkelingen er zijn. A.2 Ontwikkelingen In Japan hebben sommige grote elektronica concerns reeds rapporten voorbereid met hun visie met betrekking tot huis installaties in de toekomst. •
Electronic In dusties Association of Japan, (EIAJ)' s Project, HBS
•
JEMA Home Automation Standerd
•
Super Home Bus System,S-HBS
•
NEC, Spread SpectrumforMains Transmission
In de USA hebben de grote internationale multi-produkt firma's (zoals General Electronics en Mitsubishi) systemen op de markt gebracht voor de omgeving van een huis, het huis en de veiligheid te controleren en observeren. In Europa pleegt men onderzoek in de volgende projecten: •
Electronic Industries Association, ject,CEbus
•
SMART HOUSE
(EIA)'s
Pro-
In Europa hebben gebruikers de toegang tot grote, externe databases, welke voorzien in een snelle en grote opvraag van kennis van verscheidene onderwerpen en telebanking, teleshopping etcetera. In Europa pleegt men onderzoek in de volgende projecten:
112
Appendix A
Huisnettten
•
Eureka ProjectiHS
•
Esprit 11, Home Systems Project No 2431
•
CENELEC, TC 105, Europeon Standardization
•
Bang & Olufsen Standard, MCL
•
Philips Standard, D2B
•
Siemens Installotions-Bus, I-Bus
•
Domotique
•
BAT! BUS
•
Europeon Instalation Bus (El-Bus, Duitsland)
•
ISDN lnfluence (S-interface)
In dit verslag kunnen niet alle projecten Diegene die geïnteresseerd is in meer deze projecten wordt verwezen naar deze projecten de Europese standaard afweging worden tussen: •
BATIBUS
•
El-Bus
•
Home Systems (HS91)
worden uitgewerkt. informatie omtrent (BAA91) Welk van zal leveren zal een
113
APPENDIX B
Appendix 8
Functionele Splitsing volgens Home Systems
81. Scheiding applicatielaag volgens Home Systems In Home Systems (HS91 J staat een functionele scheiding van de hogere lagen beschreven. De scheiding bestaat uit een vier belangrijke onderdelen, te weten: •
Cammand Language Service Element CCLSE);
•
Message Transfer Service Element CMTSE);
•
Local Management Service Element CLMSE);
•
Application Title Directory CATD).
In figuur B1 wordt functionele scheiding weergegeven.
~
CLSE
-~.._t__ ~ ç z
LMSE
L-~----_.r---___
----,1
_.i..._"
~~MT_s_E__
-+·-
i
---,
A_T_o__
~ ~. APPLICATION LAYER______________________ _ ~~ QQ
NBTWORK LA YBR
zz
Figuur 81 Functionele splitsing volgens Home Systems De CLSE zorgt voor het doorsturen van diensten, objecten en data naar andere CLSE's. Dit doet hij door diensten en objecten af te beelden op een bericht dat doorgegeven wordt aan de MTSE.
ptt I research
115
Appendix B
Functionele Splitsing volgens Home Systems De MTSE zorgt voor het routeren van berichten in het netwerk. Dit wordt gedaan door aan het bericht routeringinformatie toe te voegen, waarna het wordt aangeboden aan de netwerklaag. De ATD is een functie die informatie levert over objecten die elders in het netwerk aanwezig zijn. De LMSE zorgt voor het onderhoud van de ATD.
116
APPENDIX C
Recordtypes apparatuurobjecten
Appendix C (* The MONITOR MonitorType =RECORD Objectid PowerStatus State Be Pn LastUser Service Serviceid Linkid Room Available
*)
ObjeetidType; OnOffType; StateType; BcType; PnType; UseridType; ServieeType; ObjectidType; ObjectidType; RoomType; AvailableType;
END; (* END MONITORTYPE *) CameraType
=
RECORD Objectid PowerStatus State Be Pn LastUser Zoom Service Servieeid Linkid Room Available
ObjeetidType; OnOffType; StateType; BeType; PnType; UseridType; ZoomType; ServieeType; ObjeetidType; ObjeetidType; RoomType; AvailableType;
END; (* END MICROFOONTYPE *)
MicrophoneType = RECORD Objectid PowerStatus State LastUser Be Pn Service Serviceid Linkid Room Available
ObjeetidType; OnOffType; StateType; UseridType; BcType; PnType; ServieeType; ObjeetidType; ObjectidType; RoomType; AvailableType;
END; (*
ptt research
END MICROFOONTYPE *)
118
Appendix C
Recordtypes apparatuurobJecten
CdPlayerType = RECORD Object!d State LastUser Be Pn PowerStatus Track Repeat, Pause Toggle Service Service!d Link!d Room LsPairid Available
ObjectidType; StateType; UseridType; BcType; PnType; OnOffType; TrackType; OnOffType; ToggleType; ServiceType; ObjectidType; ObjectidType; RoomType; ObjectidType; AvailableType;
END; (* END CD-PLAYER RECORD *) LoudSpeakerType = RECORD Objectid PowerStatus State Be Pn LastUser Volume LowTones HighTones Service Serviceid Link!d Room LsPairid Available
ObjectidType; OnOffType; StateType; BcType; PnType; UseridType; VolumeType; TonesType; TonesType; ServiceType; ObjectidType; ObjectidType; RoomType; ObjectidType; AvailableType;
END; (* END LOUDSPEAKERTYPE RECORD *)
ptt research
119
APPENDIX D
Appendix D
Recordtype verblndingsobject
LinkType = RECORD Objectld OrigPn DestPnl DestPn2 DestPn3 DestPn4 Be State LastUser Available END;
ObjectidType; PnType; PnType; PnType; PnType; PnType; BcType; StateType; UseridType; AvailableType;
( * END LINK RECORD*)
121
APPENDIX E
Appendix E
Recordtype Luidsprekerpaarobject
LsPairType
= RECORD
END;
ptt research
LastUser Objectid LeftLsid RightLsid State Balance Volume Service Serviceid Available : (* END LSPAIRTYPE RECORD *)
UseridType; ObjectidType; ObjectidType; ObjectidType; StateType; BalanceType; VolumeType; ServiceType; ObjectidType; AvailableType;
123
APPENDIX F
Appendix F
Recordtypes Dienstobjecten
AudioDistributionType = RECORD Objectld LastUser State Available Linkidl END;
(* END AUDIODISTRIBUTIONTYPE RECORD *)
VideoDistributionType = RECORD Objectld LastUser State Available Linkidl END; VideoPhonyType
(*
TelePhonyType
= RECORD
(*
ptt!resemch •
•
~
»
~
ObjectidType; UseridType; StateType; AvailableType; ObjectldType; ObjectldType; ObjectidType; ObjectldType;
END VIDEOPHONYTYPE RECORD *)
= RECORD Objectld LastUser State Available Link! dl Linkid2
END;
ObjectidType; UseridType; StateType; AvailableType; ObjectldType;
END VIDEODISTIRBUTIONTYPE RECORD *)
Objectld LastUser State Available Link! dl Linkid2 Linkid3 Linkid4 END;
ObjectldType; UseridType; StateType; AvailableType; ObjectidType;
(*
END TELEPHONYTYPE RECORD *)
ObjectidType; UseridType; StateType; AvailableType; ObjectidType; ObjectidType;
Appendix F
Recordtypes Dienstobjecten
SurveillanceType = RECORD Objectid LastUser State Available Linkidl Linkid2 END; BabyPhonyType
(*
END SURVEILLANCETYPE RECORD *)
= RECORD Objectid LastUser State Available Link! dl
END;
ptt research ~
.
.
.
"
ObjectidType; UseridType; StateType; AvailableType; ObjectidType; ObjectidType;
(*
ObjectidType; UseridType; StateType; AvailableType; ObjectidType;
END BABYPONYTYPE RECORD *)
2
APPENDIX G
1
2
3 4 5 6 7
(************************************************************************) (* (* (*
8 9
(* (* (* (* (*
10
(*
11
(* (* (*
12 13 14 15 16 17 18 19 20 21
(* (*
.
PTT NEDERLAND NV PTT Research Dr Neher Laboratories Leidschendam - The Netherlands Copyright (c) 1991 by PTT NEDERLAND NV
(*
(* (*
*) *) *) *) *)
*) *) *)
All rights strictly reserved. No part of this document may be reproduced in any form or by any means without written permission from the publisher.
(*
(*
*) *) *)
*) *) *) *)
Alle rechten uitdrukkelijk voorbehouden. Vermenigvuldiging of mededeling aan derden in welke vorm ook, is zonder schriftelijke toestemming van PTT NEDERLAND NV niet geoorloofd.
*) *)
*) *)
(*
*)
22
(*
*)
23
(*
**************************************************************** *)
(*
*)
24
25 26 27 28 29 30 31 32 33 34
(*
35 36 37 38 39 40
(* (* (* (* (* (* (* (* (*
41 42
43 44 45
46 47 48
(* (* (*
(*
(* (* (*
(* (*
*)
AUTHORS CREATION DATE
M.C.M. Peeters 15-7-91
COMPILER SYST.ENVIRONMENT VERSION ERROR CONDITIONSAND HANDLING FILES USED
ACE 68000 of LOGITECH VAX/VMS 1.0
*)
*) *) *)
*) *) *)
*) *) *) *) *) *) *) *)
(*
(*
*)
*) *)
(*
(* (*
*) *)
DESIGN DOCUMENT TESTSPEC'S
ban 91
.0 ID
PROGRAM DESCRIPTION:
modula 2 definition for the Total Information Base
*) *) *)
49 50 51 52
(* (* (*
*)
53
(*
**************************************************************** *)
(* (*
*) *)
54
55 56 57 58 59 60 61 62
(*
63
(************************************************************************)
64 65 66
C HANGE
(*
(* (*
<* (* <*
(*
Date
L0 G
*) *)
*)
I Name
I Description
I
I
*)
*) *)
----------+-------------+-----------------------------------I I *) ----------+-------------+------------------------------------ *) *)
*)
67 68 69 70 71
DEFINITION TOTAL INFORMATION BASE
(*
*)
72
DEFINITION MODULE IBProc;
73 74 75 76
(*
DEFINITION OBJECT TYPES
FROM SDLM
IMPORT
ProcessiD;
FROM EbinTypes
IMPORT
PnType,BcType,AvailableType,ObjectidType,StateType, UseridType,DeviceType,OnOffType,TrackType, VolumeType,TonesType,ZoomType,BalanceType, AttributeType,RoomType,ObjectType,HlResultType, ToggleType;
FROM SYSTEM
IMPORT
SHORTCARD;
*)
77
78 79
80 81 82 83 84 85 86 87 88 89 90 91
CON ST MaxLinks= MaxAudLink= MaxVideoLink= MaxVideoPLink= MaxTeleLink= MaxSurvLink= MaxBabyLink= MaxMonitor= MaxCd = MaxLs MaxMic MaxCam = MaxLsPair= MaxAudd = MaxVidd = MaxVidfo= MaxTel = MaxSur = MaxBaby = MaxChar =
92
93 94 95
96 97
98 99 100 101 102 103 104 105 106 107 108 109 110 111 112 113 114 115 116 117 118 119 120 121 122 123 124 125 126 127 128 129 130
131 132
4;(* Maximaal aantal verbindingen per dienst *) 4;(* Maximaal aantal verbindingen per dienst *) 4;(* Maximaal aantal verbindingen per dienst *) 4;(* Maximaal aantal verbindingen per dienst *) 4;(* Maximaal aantal verbindingen per dienst *) 4;(* Maximaal aantal verbindingen per dienst *) 4;(* Maximaal aantal verbindingen per dienst *) 2;(* Maximaal aantal monitors *) 2;(* Maximaal aantal Cd-spelers *) 4;(* Maximaal aantal LuidSprekers *) 2;(* Maximaal aantal Microfoons *) 2;(* Maximaal aantal Camera's *) 8;(* Maximaal aantal LuidSpreker-paren *) 3;(* Maximaal aantal op te zetten Audio Diensten*) 2;(* Maximaal aantal op te zetten Video Diensten*) 1;(* Maximaal aantal op te zetten Videofonie Diensten 2;(* Maximaal aantal op te zetten Telefonie Diensten* 2;(* Maximaal aantal op te zetten Bewakings Diensten* 2;(* Maximaal aantal op te zetten Babyfonie Diensten * 1 10;(* Maximaal aantal letters waaruit een woord kan bestaan *)
TYPE ARRAY [1 .. MaxChar] OF CHAR;
StringType TimeType
RECORD Hour Minute Second END;
(*
[0
23];
[0 [0
59]; 59];
(* END TIMETYPE RECORD *)
The module of TE must have a adress definition of the adress which saves the value For example VAR Hour TimeType[adress]
*)
ValueType = INTEGER; (* This ValueType will for TYPE CONVERSION. For Example: At the Receving Side LsCol[Objectid].Volume:=VolumeType(Value);
133 134 135 136 137 138 139 140 141 142 143 144 145 146 147 148 149 150 151 152 153 154 155 156 157 158 159 160 161 162 163 164 165 166 167 168 169 170 171 172 173 174 175 176 177 178 179 180 181 182 183 184 185 186 187 188 189 190 191 192 193 194 195 196 197 198
At the Sending Side Value:=ValueType(x); *) (*
x is of the type VolumeType
ServiceType CreateDataType
*)
[AudioDistribution =
BabyPhony];
RECORD InputObject InputObjectld OutputObject OutputObjectid Be LeftLsld RightLsld Linkld1 Linkld2 Linkld3 Linkid4
ObjectType; PnType; ObjectType; PnType; BcType; ObjectidType; ObjectidType; Obj ec tidType; ObjectidType; ObjectidType; Obj ec tidType;
Object Objectld OutputObject OutputObjectid Inpu tObj ec t InputObjectid Be OrigPn, DestPn1, DestPn2, DestPn3, DestPn4, Pn State LastUser Available Repeat, Pause, PowerStatus Time Track Toggle Service Serviceld Linkld Room LsPairld Volume LowTones HighTones Zoom LeftLsld RightLsld Balance Linkld1 Linkld2 Linkid3 Linkid4
ObjectType; ObjectldType; ObjectType; ObjectldType; ObjectType; Obj ec tidType; BcType;
END; ObjectinfoType
=
END; LinkType • RECORD
RECORD
PnType; StateType; UserldType; AvailableType; OnOffType; TimeType; TrackType; ToggleType; ServiceType; Obj ec tidType; ObjectidType; RoomType; ObjectldType; VolumeType; TonesType; TonesType; ZoomType; ObjectidType; ObjectidType; BalanceType; ObjectidType; ObjectidType; ObjectldType; ObjectidType;
199 200 201 202 203 204 205 206 207 208 209 210 211 212 213 214 215 216 217
218 219 220 221 222 223 224 225 226 227 228 229 230 231 232 233 234 235 236 237 238 239 240 241 242 243 244 245 246 247 248 249 250 251 252 253 254 255 256 257 258 259 260 261 262 263 264
Objectld OrigPn DestPn1 DestPn2 DestPn3 DestPn4 Be State LastUser Available END;
(* END LINK RECORD*)
AudioDistributionType = RECORD Objectld LastUser State Available Linkid1 END;
END;
Obj ec tidType; UseridType; StateType; AvailableType; ObjectidType;
(* END VIDEODISTIRBUTIONTYPE RECORD *)
= RECORD
Objectid LastUser State Available Linkid1 Linkid2 Linkid3 Linkid4
END; TelePhonyType
ObjectidType; UseridType; StateType; AvailableType; ObjectidType;
(* END AUDIODISTRIBUTIONTYPE RECORD *)
VideoDistributionType = RECORD Objectid LastUser State Available Linkid1
VideoPhonyType
Obj ec tidType; PnType; PnType; PnType; PnType; PnType; BcType; StateType; UseridType; AvailableType;
Obj ec tidType; UseridType; StateType; AvailableType; ObjectidType; ObjectidType; Obj ec tidType; ObjectidType;
(* END VIDEOPHONYTYPE RECORD *)
= RECORD
Objectid LastUser State Available Linkid1 Linkid2
END;
ObjectidType; UseridType; StateType; AvailableType; ObjectidType; ObjectidType;
(* END TELEPHONYTYPE RECORD *)
= RECORD Objectid LastUser State Available Linkid1 Linkid2
SurveillanceType
END;
Obj ec tidType; UseridType; StateType; AvailableType; ObjectidType; Obj ec tidType;
(* END SURVEILLANCETYPE RECORD *)
265 266 267 268 269 270 271 272 273 274 275 276 277 278 279 280 281 282 283 284 285 286 287 288 289 290 291 292 293 294 295 296 297 298 299 300 301 302 303 304 305 306 307 308 309
= RECORD
BabyPhonyType
Objectld LastUser State Available Linkid1 END; CdPlayerType
(* END BABYFONYTYPE RECORD *) =
(* CdPlayerid is the array index (* END CD-PLAYER RECORD *) LoudSpeakerType
312 313
323
324 325 326 327 328
329 330
RECORD Objectld State LastUser Be Pn PowerStatus Track Repeat, Pause Toggle Service Service!d Linkid Room LsPairid Available
Obj ec tidType; StateType; UseridType; BcType; PnType; OnOffType; TrackType; OnOffType; ToggleType; ServiceType; ObjectidType; ObjectidType; RoomType; ObjectidType; AvailableType;
END;
310 311
314 315 316 317 318 319 320 321 322
ObjectidType; UseridType; StateType; AvailableType; Obj ec tidType;
= RECORD Objectld PowerStatus State Be Pn LastUser Volume LowTones HighTones Service Service!d Linkid Room LsPairid Available
*)
ObjectidType; OnOffType; StateType; BcType; PnType; UseridType; VolumeType; TonesType; TonesType; ServiceType; ObjectidType; ObjectidType; RoomType; Obj ec tidType; AvailableType;
END; (* The loudSpeakeid is the array index (* END LOUDSPEAKERTYPE RECORD *)
HicrophoneType
*)
= RECORD
Objectld PowerStatus State LastUser Be Pn Service Serviceid
ObjectidType; OnOffType; StateType; UseridType; BcType; PnType; ServiceType; Obj ec tidType;
331 332 333 334 335 336 337 338 339 340 341 342 343 344 345 346 347 348 349 350 351 352 353 354 355 356 357 358 359 360 361 362 363 364 365 366 367 368 369 370
Linkld Room Available
Obj ec tldType; RoomType; AvailableType;
END; (* The Hield is the array index (* END MICROFOONTYPE *)
MonitorType
=
(* The MONITOR RECORD Objectld PowerStatus State Be Pn LastUser Service Serviceld Linkld Room Available
*) Obj ec tidType; OnOffType; StateType; BcType; PnType; UserldType; ServiceType; Obj ec tldType; ObjectldType; RoomType; AvailableType;
END; (* END MONITORTYPE *) CameraType
= RECORD Objectld PowerStatus State Be Pn LastUser Zoom Service Serviceld Linkld Room Available
371
.
372
373 374 375 376 377 378 379 380 381 382 383 384 385 386 387 388 389 390 391 392 393
394 395 396
*)
'
ObjectidType; OnOffType; StateType; BcType; PnType; UseridType; ZoomType; ServiceType; Obj ec tidType; ObjectldType; RoomType; AvailableType;
END; (* The Camerald is the array index *) (* END MICROFOONTYPE *)
LsPairType
= RECORD
END;
LastUser Objectld LeftLsld RightLsld State Balance Volume Service Serviceld Available (* END LSPAIRTYPE RECORD *)
UseridType; ObjectldType; ObjectidType; ObjectidType; StateType; BalanceType; VolumeType; ServiceType; Obj ec tidType; AvailableType;
VAR LinkCollection AudioDis VideoDis TelePhonyDis
ARRAY ARRAY ARRAY ARRAY
[1 [1 [1 [1
MaxLinks] OF LinkType; MaxAudd] OF AudioDistributionType; MaxVidd] OF VideoDistributionType; MaxTel] OF TelePhonyType;
VideoPhonyDis SurveillanceDis BabyPhonyDis CdCollection LsCollec t ion MicCollection CamCollection LsPairCollection: MonitorCollection:
397 398 399 400 401 402 403 404 405 406 407 408 409
(* (* (*
ARRAY ARRAY ARRAY ARRAY ARRAY ARRAY ARRAY ARRAY ARRAY
[1 [1 {1 [1 [1 [1 [1 [1 [1
MaxVidfo] OF VideoPhonyType; MaxSur] OF SurveillanceType; MaxBaby] OF BabyPhonyType; MaxCd] OF CdPlayerType; MaxLs] OF LoudSpeakerType; MaxMic] OF MicrophoneType; MaxCam] OF CameraType; MaxLsPair] OF LsPairType; MaxMonitor] OF MonitorType;
An Integrated videophone is not available in EBIN An Integrated Monitor is not available in EBIN, The Monitor is a part of the Macintosh
*) *) *)
410
411
412 413 414 415 416 417 418 419 420 421 422 423 424 425 426 427 428 429 430 431 432 433 434 435 436 437 438 439 440 441 442 443 444 445 446 447
448 449 450 451 452 453 454 455 456 457
458 459 460 461 462
Userid:UseridType; Object:ObjectType; Objectid:ObjectldType; VAR Result:HlResultType); SuccessFull, Possible Values Result: ClaimedByOtherUser,ObjectUnknown,
PROCEDURE IBClaim(
(* *)
PROCEDURE IBUnClaim(
(*
Userid:UseridType; Object:ObjectType; Objectld:ObjectidType; VAR Result:HlResultType); Possible Values Result: SuccessFull, ClaimedByOtherUser,ObjectUnknown,
*) PROCEDURE IBCreateObject( Userid:UseridType; Object:ObjectType; Objectid:ObjectidType; Objectinfo:ObjectinfoType; VAR Result:HlResultType); (* Possible Values Result: SuccessFull, TooManyinstances,ObjectUnknown, *) PROCEDURE IBDeleteObject( Object:ObjectType; Objectid:ObjectidType; VAR Result:HlResultType );
PROCEDURE IBChangeAttribute( Userid:UseridType; Object:ObjectType; Objectid:ObjectidType; Attribute:AttributeType; Value:ValueType; VAR Result:HlResultType); (* Possible Values Result: SuccessFull,ClaimedByOtherUser, ObjectUnknown,AttributeUnknown, ValueOutOfRange *)
PROCEDURE InquireAttribute( Object:ObjectType; Objectid:ObjectldType; Attribute:AttributeType; VAR Value:ValueType; VAR Result:HlResultType);
463 464 465 466 467 468 469 470 471 472
473 474
(*
Possible Values Result:
SuccessFull,ObjectUnknown, AttributeUnknown
*)
PROCEDURE IBGetObjectlnfo( Object:ObjectType; Objectid:ObjectidType; VAR Objectinfo:ObjectinfoType; VAR Result:HlResultType );
END IBProc.
(************************************************************************)
1 2
(*
3 4 S 6 7
(* (* (* (* (*
8 9
(* (*
10
(*
11
(* (*
12 13 14 1S 16 17 18 19 20 21
(* (* (*
*) *)
PTT NEDERLAND NV PTT Research Dr Neher Laboratories Leidschendam - The Netherlands
*)
*) *) *) *)
Copyright (c) 1991 by PTT NEDERLAND NV
*) *) *)
All rights strictly reserved. No part of this document may be reproduced in any form or by any means without written permission from the publisher.
(*
(* (* (* (*
*)
*) *) *) *)
Alle rechten uitdrukkelijk voorbehouden. Vermenigvuldiging of mededeling aan derden in welke vorm ook, is zonder schriftelijke toestemming van PTT NEDERLAND NV niet geoorloofd.
*) *) *)
22
(* (*
*) *) *)
23
(*
**************************************************************** *)
(* (*
*) *)
24
2S 26 27 28 29 30 31 32 33 34 3S 36 37 38 39
(* (* (* (*
(* (*
(* (*
(*
4S
(* (* (* (* (* (* (* (* (* (* (*
46 47
(* (*
48
(*
49 SO S1 S2 S3
(* (*
40
41 42
43 44
S4
SS S6 S7 S8 s9
60 61 62 63 64 65 66
AUTHORS CREATION DATE
M.C.M. Peeters 1S-7-91
COMPILER SYST.ENVIRONHENT VERSION ERROR CONDITIONSAND HANDLING FILES USED
ACE 68000 of LOGITECH VAX/VHS 1.0
*) *) *)
*) *) *)
*) *)
*) *) *) *)
*) *) *) *) *) *) *) *)
DESIGN DOCUMENT TESTSPEC'S
ban 91
.0 ID
PROGRAM DESCRIPTION:
modula 2 implementation for the Information Base
*) *) *)
*) *)
(*
*)
(*
**************************************************************** *)
(* (*
(* (* (* (*
<* (* <* (*
*) *)
C HANGE Date
I Name
L0 G
*)
I Description
*) *) *)
----------+-------------+-----------------------------------I I *> ----------+-------------+------------------------------------ *) I I *> *)
(************************************************************************)
67
IMPLEMENTATION TOTAL INFORMATION BASE
68 69 70 71
(*
72 73
IMPLEMENTATION MODULE IBProc;
74 75
(*
76 77
FROM
DEFINITION OBJECT TYPES EbinTypes
IMPORT
78 79
80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96
*)
ObjectType,ObjectidType,UseridType, AttributeType,HlResultType,BcType, StateType,AvailableType,OnOffType, TrackType,PnType,RoomType,TonesType, VolumeType,NOPN,ToggleType;
PROCEDURE IBClaim(
(*
Userid:UseridType; Object:ObjectType; Objectid:ObjectidType; VAR Result:HlResultType); Possible Values Result: SuccessFull, ClaimedByOtherUser,ObjectUnknown,
*)
BEGIN; END IBClaim; PROCEDURE IBUnClaim(
97
98 99 100 101 102 103 104 105 106 107 108 109 110 111 112 113 114 115 116 117 118 119 120 121 122 123 124 125 126 127 128 129 130 131 132
*)
(*
Userid:UseridType; Object:ObjectType; Objectid:ObjectidType; VAR Result:HlResultType); Possible Values Result: SuccessFull, ClaimedByOtherUser,ObjectUnknown,
*) BEGIN; END IBUnClaim; PROCEDURE IBCreateObject( Userid:UseridType; Object:ObjectType; Objectid:ObjectidType; Objectinfo:ObjectinfoType; VAR Result:HlResultType); (* Possible Values Result: SuccessFull, TooManyinstances,ObjectUnknown, *) VAR INTEGER;
n
BEGIN n
:=
1;
CASE Object OF Link: VHILE (n <= MaxLinks) DO IF LinkCollection[n].Available = TRUE THEN LinkCollection[n].Objectid:=Objectid; LinkCollection[n).OrigPn:= Objectinfo.OrigPn; LinkCollection[n].DestPn1:= Objectinfo.DestPn1; LinkCollection[n].Bc:= Objectinfo.Bc; LinkCollection(n].State:= Objectinfo.State;
133 134 135 136 137
138 139 140 141 142 143 144 145 146 147 148 149 150 151 152 153 154 155 156 157 158 159 160 161 162 163 164 165 166 167 168 169 170 171 172 173
ELSE END; END; (* *)
ILoudSpeakerPair: ELSE END;
Result := (* CASE *)
ObjectUnknown;
END IBCreateObject; PROCEDURE IBDeleteObject( Object:ObjectType; Objectid:ObjectidType; VAR Result:HlResultType );
VAR INTEGER;
n
BEGIN n
==
1;
CASE Object OF Link: YHILE (n <= MaxLinks) DO IF LinkCollection[n].Objectid = Objectid THEN LinkCollection[n].Available LinkCollection[n].OrigPn LinkCollection[n].DestPn1 LinkCollection[n].DestPn2 LinkCollection(n].DestPn3 LinkCollection[n].DestPn4 n := MaxLinks + 1; ELSE n := n + 1; Result := ObjectUnknown; END; (* IF *) END; (* YHILE *) END; (* CASE *)
174
175 176 177 178 179 180 181 182 183 184 185 186 187 188 189 190 191 192 193 194 195 196 197 198
LinkCollection[n].Last,User:=Userid; LinkCollection[n].Available:=FALSE; Result == SuccesFull; n == MaxLinks + 1; n := n + 1; TooManyinstances; Result == (* IF *) (* YHILE *)
TRUE; NOPN; NOPN; NOPN; := NOPN; := NOPN; := := := :=
END IBDeleteObject; PROCEDURE IBChangeAttribute( Userid:UseridType; Object:ObjectType; Objectid:ObjectidType; Attribute:AttributeType; Value:ValueType; VAR Result:HlResultType); (* Possible Values Result: SuccessFull,ClaimedByOtherUser, ObjectUnknown,AttributeUnknown, ValueOutOfRange
*)
VAR n
INTEGER;
199 200 201 202 203 204 205 206 207 208 209 210 211 212 213 214 215 216 217 218 219 220 221 222 223 224 225 226 227 228 229 230 231 232 233 234 235 236 237 238 239 240 241 242 243 244 245 246 247 248 249 250 251 252 253 254 255 256 257 258 259 260 261 262 263 264
BEGIN n:=1; CASE Object OF Link: VHILE ( n <= MaxLinks ) DO IF (LinkCollection[n].Objectid = Objectid) THEN IF (LinkCollection[n].LastUser = Userid) THEN CASE Attribute OF !AttrBc: LinkCollection[n].Bc:= BcType(Value); IAttrDestPn1: CASE PnType(Value) OF NOPN: LinkCollection[n].DestPn1:= NOPN; ELSE LinkCollection[n].DestPn1:= PnType(Value); END; (* CASE *) !AttrDestPn2: CASE PnType(Value) OF NOPN: LinkCollection[n].DestPn2:= NOPN; ELSE LinkCollection[n).DestPn2:= PnType(Value); END; (* CASE *) lAttrDestPn3: CASE PnType(Value) OF NOPN: LinkCollection[n].DestPn3:= NOPN; ELSE LinkCollection[n].DestPn3:= PnType(Value); END; (* CASE *) IAttrDestPn4: CASE PnType(Value) OF NOPN: LinkCollection[n].DestPn4:= NOPN; ELSE LinkCollection[n].DestPn4:= PnType(Value); END; (* CASE *) lAttrState: LinkCollection[n].State:=StateType(Value); IAttrLastUser: LinkCollection[n).LastUser:=UseridType(Value); IAttrAvailable: LinkCollection(n].Available:=AvailableType(Value); END;(* CASE*) Result:=SuccesFull; n == MaxLinks +1; ELSE Result:=ClaimedByOtherUser; n := MaxLinks + 1; END; (* IF *) ELSE n:=n+1; END; (* IF *) END; (* VHILE*) ICdPlayer: VHILE ( n <= MaxCd ) DO IF (CdCollection[n].Objectid = Objectid) THEN CASE Attribute OF IAttrTrack:
265 266 267 268 269 270 271 272
273 274 275 276 277
278 279 280 281 282 283 284 285 286 287 288 289 290 291 292 293 294 295 296 297 298 299 300 301 302 303 304 305 306 307 308 309 310 311 312 313 314 315 316 317 318 319 320 321 322 323 324 325 326 327 328 329 330
CdCollection[n].Track:=TrackType(Value); IAttrPowerStatus: · CdCollection[n].PowerStatus:=OnOffType(Value); IAttrService: CdCollection[n].Service:=ObjectType(Value); IAttrLinkid: CdCollection[n].Linkid:=ObjectidType(Value); IAttrServiceid: CdCollection[n].Serviceid:=ObjectidType(Value); IAttrBc: CdCollection[n].Bc:=BcType(Value); IAttrRepeat: CdCollection[n].Repeat:=OnOffType(Value); IAttrPause: CdCollection[n].Pause:=OnOffType(Value); !AttrToggle: CdCollection[n].Toggle:=ToggleType(Value); IAttrPn: CdCollection[n].Pn:=PnType(Value); IAttrState: CdCollection[n].State:=StateType(Value); !AttrLastUser: CdCollection[n].LastUser:=UseridType(Value); IAt trAvailable: CdCollection[n].Available:=AvailableType(Value); IAttrRoom: CdCollection[n].Room:=RoomType(Value); IAttrLsPairid: CdCollection[n].LsPairid:=ObjectidType(Value); END;(* CASE*) n:=MaxCd + 1; ELSE n:=n+1; END;(* IF *) END;(* YHILE *) !LoudSpeaker YHILE ( n <= MaxLs ) DO IF (LsCollection[n].Objectid = Object!d) THEN CASE Attribute OF AttrPowerStatus: LsCollection[n].PowerStatus:=OnOffType(Value); IAttrVolume: LsCollection[n].Volume:=VolumeType(Value); IAttrLowTones: LsCollection[n].LowTones:=TonesType(Value); !AttrHighTones: LsCollection[n].HighTones:=TonesType(Value); IAttrService: LsCollection[n].Service:=ObjectType(Value); !AttrLinkid: LsCollection[n].Linkid:=ObjectidType(Value); !AttrServiceid: LsCollection[n].Serviceid:=ObjectidType(Value); !AttrBc: LsCollection[n].Bc:=BcType(Value); !AttrPn: LsCollection[n].Pn:=PnType(Value); !AttrState: LsCollection[n].State:=StateType(Value); IAttrLastUser: LsCollection[n].LastUser:=UseridType(Value); IAttrAvailable: LsCollection[n].Available:=AvailableType(Value); IAttrRoom:
331 332 333 334 335 336 337 338 339 340 341 342 343 344 345 346 347 348 349 350 351 352 353 354 355 356 357 358 359 360 361 362 363 364 365 366 367 368 369 370 371 372
373 374 375 376 377
378 379 380 381 382 383 384 385 386 387 388 389 390 391 392 393
394 395 396
LsCollection[n].Room:=RoomType(Value); jAttrLsPairid: LsCollection[n].LsPairid:=ObjectidType(Value); END;(* CASE *) n:= MaxLs + 1; ELSE n:=n+1; END;(* IF *) END;(* VHILE *) jMicroPhone VHILE ( n <= MaxMic ) DO IF (MicCollection[n].Objectid = Object!d) THEN CASE Attribute OF AttrPowerStatus: MicCollection[n].PowerStatus:=OnOffType(Value); IAttrService: MicCollection[n].Service:=ObjectType(Value); IAttrLinkid: MicCollection[n].Linkid:=ObjectidType(Value); IAttrServiceid: MicCollection[n].Serviceid:=ObjectidType(Value); jAttrPn: MicCollection[n].Pn:=PnType(Value); jAttrState: MicCollection[n].State:=StateType(Value); IAttrLastUser: MicCollection[n].LastUser:=UseridType(Value); IAttrAvailable: MicCollection[n].Available:=AvailableType(Value); IAttrRoom: MicCollection[n].Room:=RoomType(Value); END;(* CASE*) n:= MaxMic + 1; ELSE n:=n+1; END;(* IF *) END;(* VHILE *) !Camera VHILE ( n <= MaxCam ) DO IF (CamCollection[n].Objectid = Object!d) THEN CASE Attribute OF AttrPowerStatus: CamCollection[n].PowerStatus:=OnOffType(Value); IAttrService: CamCollection[n].Service:=ObjectType(Value); IAttrLinkid: CamCollection[n].Linkid:=ObjectidType(Value); IAttrServiceid: CamCollection[n].Serviceid:=ObjectidType(Value); IAttrPn: CamCollection[n].Pn:=PnType(Value); IAttrState: CamCollection[n].State:=StateType(Value); IAttrLastUser: CamCollection[n].LastUser:=UseridType(Value); IAttrAvailable: CamCollection[n].Available:=AvailableType(Value); IAttrRoom: CamCollection[n].Room:=RoomType(Value); END;(* CASE *) n:= MaxCam + 1; .ELSE
n:=n+1; END;(* IF *) END;(* YHILE *) !Monitor YHILE ( n <= MaxMonitor ) DO IF (MonitorCollection[n].Objectid = Objectid) THEN CASE Attribute OF AttrPowerStatus: MonitorCollection[n].PowerStatus:=OnOffType(Value); IAttrService: MonitorCollection[n].Service:=ObjectType(Value); IAttrLinkid: MonitorCollection[n].Linkid:=ObjectidType(Value); IAttrServiceid: MonitorCollection[n].Serviceid:=ObjectidType(Value); IAttrPn: MonitorCollection[n].Pn:=PnType(Value); IAttrState: MonitorCollection[n].State:=StateType(Value); IAttrLastUser: MonitorCollection[n].LastUser:=UseridType(Value); IAttrAvailable: MonitorCollection[n].Available:=AvailableType(Value); IAttrRoom: MonitorCollection[n].Room:=RoomType(Value); END;(* CASE*) n:= MaxMonitor + 1; ELSE n:=n+l; END;(* IF *) END;(* YHILE *) END; (* CASE *)
397 398 399 400 401 402 403 404 405 406 407 408 409 410
411
412 413 414 415 416 417 418 419 420 421 422 423 424 425 426 427 428 429 430 431 432 433 434 435 436 437 438 .439 440 441 442 443 444 445 446 447 448 449 450 451 452 453 454 455 456 457 458 459 460 461 462
END IBChangeAttribute; PROCEDURE InquireAttribute( Object:ObjectType; Objectid:ObjectidType; Attribute:AttributeType; VAR Value:ValueType; VAR Result:HlResultType); (* (*
Possible Values Result:
SuccessFull,ObjectUnknown, AttributeUnknown
VAR n
INTEGER;
BEGIN n:=l; CASE Object OF Link: YHILE ( n <= MaxLinks ) DO IF (LinkCollection[n].Objectid = Objectid) THEN CASE Attribute OF IAttrOrigPn: Value:= ValueType(LinkCollection[n).OrigPn); IAttrDestPnl: Value:= ValueType(LinkCollection[n].DestPnl); IAttrDestPn2: Value:= ValueType(LinkCollection[n].DestPn2);
*)
*)
463 464 46S 466 467 468 469 470 471 472
473 474 47S 476 477
478 479 480 481 482 483 484 48S 486 487 488 489 490 491 492
493 494 49S 496 497 498 499
soo
S01 S02 S03 S04 SOS S06 S07 S08 S09 S10 Sll S12 S13 S14 S1S S16 S17 S18 S19 S20 S21 S22 S23 S24 S2S S26 S27 S28
1AttrDestPn3: Value:= ValueType(LinkCollection[n].DestPn3); IAttrDestPn4: Value:= ValueType(LinkCollection[n].DestPn4); IAttrBc: Value:= ValueType(LinkCollection[n].Bc); IAttrState: Value:= ValueType(LinkCollection[n].State); IAttrLastUser: Value:= ValueType(LinkCollection[n].LastUser); IAttrAvailable: Value:= ValueType(LinkCollection[n].Available); END;(* CASE*) SuccesFull; Result := n := MaxLinks + 1; ELSE n:=n+1; END; (* IF *) END; (* YHILE*) jCdPlayer: YHILE ( n <= MaxCd ) DO IF (CdCollection[n].Objectid Objectid) THEN CASE Attribute OF IAttrTrack: Value:= ValueType(CdCollection[n].Track); IAttrService: Value:= ValueType(CdCollection[n].Service); IAttrBc: Value:= ValueType(CdCollection[n].Bc); IAttrPn: Value:= ValueType(CdCollection[n].Pn); IAttrState: Value:= ValueType(CdCollection[n].State); IAttrPowerStatus: Value:= ValueType(CdCollection(n].PowerStatus); IAttrLastUser: Value:= ValueType(CdCollection[n].LastUser); IAttrAvailable: Value:= ValueType(CdCollection[n].Available); IAttrRoom: Value:= ValueType(CdCollection[n].Room); IAttrLsPairid: Value:= ValueType(CdCollection[n].LsPairid); IAttrServiceid: Value:= ValueType(CdCollection[n].Serviceid); END;(* CASE*) Result := SuccesFull; 1·, MaxCd + n == ELSE n:=n+1; END;(* IF *) END;(* YHILE *) !LoudSpeaker YHILE ( n <= MaxLs ) DO IF (LsCollection[n].Objectid = Objectid) THEN CASE Attribute OF AttrPowerStatus: Value:= ValueType(LsCollection(n].PowerStatus); IAttrVolume: Value:= ValueType(LsCollection[n].Volume); IAttrLowTones: Value:= ValueType(LsCollection[n].LowTones);
529 530 531 532 533 534 535 536 537 538 539 540 541 542 543 544 545 546 547 548 549 550 551 552 553 554 555 556 557 558 559 560 561 562 563 564 565 566 567 568 569 570 571 572
573 574 575 576 577
578 579 580 581 582 583 584 585 586 587 588 589 590 591 592 593 594
IAttrHighTones: Value:= ValueType(LsCollection[n].HighTones); IAttrService: Value:= ValueType(LsCollection[n].Service); IAttrBc: Value:= ValueType(LsCollection[n].Bc); IAttrPn: Value:= ValueType(LsCollection[n].Pn); IAttrState: Value:= ValueType(LsCollection[n].State); IAttrLastUser: Value:= ValueType(LsCollection[n].LastUser); IAttrAvailable: Value:= ValueType(LsCollection[n].Available); IAttrRoom: Value:= ValueType(LsCollection[n].Room); IAttrLsPairid: Value:= ValueType(LsCollection[n].LsPairid); IAttrServiceid: Value:= ValueType(LsCollection[n].Serviceid); END;(* CASE *) Result := SuccesFull; n := MaxLs + 1; ELSE n:=n+l; END;(* IF *) END;(* YHILE *) !MicroPhone YHILE ( n <= MaxMic ) DO IF (MicCollection[n].Objectid = Object!d) THEN CASE Attribute OF AttrPowerStatus: Value:= ValueType(MicCollection[n].PowerStatus); jAttrService: Value:= ValueType(MicCollection[n].Service); IAttrBc: Value:= ValueType(MicCollection[n].Bc); jAttrPn: Value:= ValueType(MicCollection[n].Pn); IAttrState: Value:= ValueType(MicCollection[n].State); !AttrLastUser: Value:= ValueType(MicCollection[n].LastUser); IAttrAvailable: Value:= ValueType(MicCollection[n].Available); IAttrRoom: Value:= ValueType(MicCollection[n].Room); IAttrServiceid: Value:= ValueType(MicCollection[n].Serviceid); END;(* CASE *) Result := SuccesFull; n := MaxMic + 1; ELSE n:=n+1; END;(* IF *) END;(* YHILE *) !Camera YHILE ( n <= MaxCam ) DO IF (CamCollection[n].Objectid = Objectid) THEN CASE Attribute OF AttrPowerStatus: Value:= ValueType(CamCollection[n].PowerStatus);
595 596 597 598 599 600 601 602 603 604 605 606 607 608 609 610 611 612 613 614 615 616 617 618 619 620 621 622 623 624 625 626 627 628 629 630 631 632 633 634 635 636 637 638 639 640 641 642 643 644 645 646 647 648 649 650 651 652 653 654 655 656 657 658 659 660
IAttrService: Value:= IAttrBc: Value:= IAttrPn: Value:= IAttrZoom: Value:= IAttrState: Value:= IAttrLastUser: Value:= IAttrAvailable: Value:= IAttrRoom: Value:= IAttrServiceid: Value:= END;(* CASE*) Result == n := ELSE n:=n+1; END;(* IF *) END;(* YHILE *)
ValueType(CamCollection[n].Service); ValueType(CamCollection[n].Bc); ValueType(CamCollection[n].Pn); ValueType(CamCollection[n].Zoom); ValueType(CamCollection[n].State); ValueType(CamCollection[n].LastUser); ValueType(CamCollection[n].Available); ValueType(CamCollection[n].Room); ValueType(CamCollection[n].Serviceid); SuccesFull; MaxCam +
1;
!Monitor YHILE ( n <= MaxMonitor ) DO IF (MonitorCollection[n].Objectid = Objectid) THEN CASE Attribute OF AttrPowerStatus: Value:= ValueType(MonitorCollection[n].PowerStatus); IAttrService: Value:= ValueType(MonitorCollection[n].Service); IAttrBc: Value:= ValueType(MonitorCollection[n].Bc); IAttrPn: Value:= ValueType(MonitorCollection[n].Pn); IAttrState: Value:= ValueType(MonitorCollection[n].State); IAttrLastUser: Value:= ValueType(MonitorCollection[n].LastUser); IAttrAvailable: Value:= ValueType(MonitorCollection[n].Available); IAttrRoom: Value:= ValueType(MonitorCollection[n].Room); IAttrServiceid: Value:= ValueType(MonitorCollection[n].Serviceid); END;(* CASE *) Result := SuccesFull; n := MaxMonitor + 1; ELSE n:=n+1; END;(* IF *) END;(* YHILE *) ELSE Result := ObjectNotAvailable; END; (* CASE *) END InquireAttribute; PROCEDURE IBGetObjectinfo( Object:ObjectType; Objectid:ObjectidType; VAR Objectinfo:ObjectinfoType; VAR Result:HlResultType );
661 662 663 664 665 666 667 668 669 670
VAR n BEGIN n
671
672 673 674 675 676 677
678 679 680 681 682 683 684 685 686 687 688 689 690 691 692
693 694 695 696 697 698 699 700 701 702 703 704 705 706 707 708 709 710 711
712 713 714 715 716
717 718 719
720 721 722 723 724 725 726
(*
INTEGER; :=
1;
CASE Object OF Link: VHILE (n <= MaxLinks) DO IF LinkCollection[n].Objectid = Objectid THEN Objectinfo.Objectid:= LinkCollection[n].Objectid; Objectinfo.OrigPn:= LinkCollection[n].OrigPn; Objectinfo.DestPn1:= LinkCollection[n].DestPn1; Objectinfo.DestPn2:= LinkCollection[n].DestPn2; Objectinfo.DestPn3:= LinkCollection[n].DestPn3; Objectinfo.DestPn4:= LinkCollection[n].DestPn4; Objectinfo.Bc:= LinkCollection[n].Bc; Objectinfo.State:= LinkCollection[n].State; Objectinfo.LastUser:= LinkCollection[n].LastUser; Objectinfo.Available:= LinkCollection[n].Available; Result := SuccesFull; n := MaxLinks + 1; ELSE n := n + 1; Result := LinkUnknown; *) END; (* IF *) END; (* VHILE *) ICdPlayer: VHILE ( n < MaxCd ) DO IF (CdCollection[n].Objectid = Objectid) THEN Objectinfo.Toggle := CdCollection[n].Toggle; Objectinfo.Track := CdCollection[n].Track; Objectinfo.Pause == CdCollection[n].Pause; Objectinfo.PowerStatus := CdCollection[n].PowerStatus Objectinfo.Repeat == CdCollection[n].Repeat; Objectinfo.Service := CdCollection[n].Service; Objectinfo.Linkid := CdCollection[n].Linkid; Objectinfo.Serviceid := CdCollection[n].Serviceid; Objectinfo.Bc := CdCollection[n].Bc; Objectinfo.Pn == CdCollection[n].Pn; Objectinfo.State == CdCollection[n].State; Objectinfo.LastUser == CdCollection[n].LastUser; Objectinfo.Available == CdCollection[n].Available; Ob jee tinfo .Room := CdCollection[n].Room; Objectinfo.LsPairid := CdCollection[n].LsPairid; n:= MaxLs + 1; ELSE n:=n+1; END;(* IF *) END;(* VHILE *) !LoudSpeaker: VHILE ( n DO
< MaxLs )
727 728 729 730 731 732 733 734 735 736 737 738 739 740 741 742 743 744 745 746 747 748 749 750 751 752 753 754 755 756 757 758 759 760 761 762 763 764 765 766 767 768 .769 770 771 772 773 774 775 776 777 778 779 780 781 782 783 784 785 786 787 788 789 790 791 792
IF (LsCollection[n].Objectid = Objectid) THEN Objectinfo.PowerStatus := LsCollection[n].PowerStatus; Objectinfo.Volume := LsCollection[n].Volume; Objectinfo.LowTones := LsCollection[n].LowTones; Objectinfo.HighTones := LsCollection[n].HighTones; Objectinfo.Service := LsCollection[n].Service; Objectinfo.Linkid == LsCollection[n].Linkid; Objectinfo.Serviceid := LsCollection[n].Serviceid; Objectinfo.Bc := LsCollection[n].Bc; Objectinfo.Pn := LsCollection[n].Pn; Objectinfo.State == LsCollection[n].State; Objectinfo.LastUser == LsCollection(n].LastUser; Objectinfo.Available := LsCollection[n].Available; Objectinfo.Room == LsCollection[n].Room; Objectinfo.LsPairid == LsCollection[n].LsPairid; n:= MaxLs + 1; ELSE n:=n+1; END;(* IF *} END;(* VHILE *} IMicroPhone: !Camera: !Monitor: ELSE Result == ObjectUnknown; END; (* CASE *} END IBGetObjectinfo;
VAR
INTEGER;
n
BEGIN (*
INITIALISATIE VAN DE INFORMATION BASE TEN BEHOEVE VAN TEST DOELEINDEN *}
(* LINKS *) n := 1;
VHILE n <= HaxLinks DO LinkCollection[n].State LinkCollection[n].Available LinkCollection[n].OrigPn LinkCollection[n].DestPn1 LinkCollection[n].DestPn2 LinkCollection[n].DestPn3 LinkCollection[n].DestPn4 (*
==
==
:=
InActive; TRUE; NOPN; NOPN; NOPN; NOPN; NOPN;
Een User met Userid=O bestaat niet
*} LinkCollection[n].LastUser
0;
n := n + 1;
END;
(*
VHILE
*}
(* CD Player *} n := 1;
VHILE n < HaxCd DO CdCollection[n).State CdCollection[n].Available CdCollection[n].Bc CdCollection[n].Track
==
==
InActive; TRUE; HQAudio;
:=
1;
793 794 795 796 797 798 799 800 801 802 803 804 805 806 807 808 809 810 811 812 813 814 815 816 817 818 819 820 821 822 823 824 825 826 827 828 829 830 831 832 833 834 835 836 837 838 839 840 841 842 843 844 845 846 847 848 849 850 851 852 853 854 855 856
CdCollection[n].Service CdCollection[n].Serviceid CdCollection[n].Linkid CdCollection[n].Room CdCollection[n].LsPairid CdCollection[n].PowerStatus CdCollection[n].Pause CdCollection[n].Repeat CdCollection[n].Toggle
(*
!= !=
!=
==
!= != != != !=
AudioDistribution; 0; 0; Living; 0; Off; Off; Off; Stop;
Een User met Userld=O bestaat niet
*) CdCollection[n].LastUser n:= n + 1; END; (* VHILE *)
:=
0;
(* LOUDSPEAKERS *) n := 1;
VHILE n < MaxLs DO LsCollection[n].State == LsCollection[n].Available == LsCollection[n].Bc == LsCollection[n].PowerStatus == LsCollection[n].Volume == LsCollection[n].LowTones == LsCollection[n].HighTones == (* Vaardes voor TestDoeleinden LsCollection[n].Service == LsCollection[n].Linkid == LsCollection[n].Serviceid := LsCollection[n].Room := LsCollection[n].LsPairid :=
(*
InActive; TRUE; HQAudio; Off; 0; 0;
0;
*) AudioDistribution; 1;
1;
Living; 1;
Een User met Userld=O bestaat niet
*)
LsCollection[n].LastUser
==
1·,
n := n + 1;
END;
(*
VHILE
*)
(*
TEST
VAARDES *)
(* CD Player 1 *) CdCollection[1].0bjectid CdCollection[1].Pn (* CD Player 2 *) CdCollection[2].0bjectid CdCollection[2].Pn
!=
(* LoudSpeaker 1 *) LsCollection[1].0bjectid LsCollection[1].Pn
:= :=
1;
:= :=
2; 1;
EINDE TEST VAARDES
*)
!= != !=
1; 1;
2; 2·,
2;
(* LoudSpeaker2 *)
LsCollection[2].0bjectid LsCollection[2].Pn
(* END IBProc.
APPENDIX H
Appendix H
SOL-diagrammen
INHOUDSOPGAVE
•
HNC 0
CLSEBLOC.SBK (Indeling hogere lagen CLSE HNC)
0
GENER.SPR (Generator)
0
LINKHAND.SPR Clinkhandler)
•
VME-systeem met Macintosh: o
APMACVME.SSY (Indeling hogere lagen VME- systeem met Macintosh)
o
READWRIT.SBK CRead/Write RS232)
o
READRS23.SPD (ReadRS232)
•
VME-systeem zonder Macintosh: o
CLSEBLOC.SBK (Indeling CLSE VME-systeem zonder Macintosh)
o
CLSETE.SPR (Apparatu urhandler)
1
System ApplLaagVrneMac/Page 1, HL Ma, sheet 1 of 2 APMACVME.SSY
l
SYSTEM ApplLaagVrneMac !~
1, HL Ma (1)
:n the Read/Writ.e RS232
I
Unit.Data /* Including [ *I ACKNOWLEDGEMENT
translate the messages ~ form the UI-Controller into mèssages for the
the Custorner Premrolses netwerk and the ether
Mtse-To-Network
way around *I
UnitDat.a I* Including
~
[ */ ACKNOWLEDGEMEN
Clse-to-EqColA_RCS '\
I* The following messages
Peer-to-peer L
Cl se
/
CHANGE~ CLAIM UNCLAI UPDATE
~
are not for the Macintosh, but for the
ether objec~s attached to the !erml.nal Endpoint which are not a part of t.he Macintosh.
*I
EqCoLaMessage
Mtse
~
CI\EATE~
CHANGE DELETE
CLAIM UNCLAI
~OTIF~
UI Controller-RS232
-
L
'
'\. /
Read/Write RS232
/
"
NOTIFY
UilDATE
' /
Read/Write Rs232 Mtse
I
1
Block ReadWriteRS232/Page 1 READWRIT. SBK
BLOCK ReadWriteRS232
1
r"J CLAIM UNCLAI UPDATE CREATE DELE'l'E
Re ad RS232 - Mtse
( 1, 1)
Read RS232
UI-Controller Read RS232
-
[f7aractn1 ( 1, 1)
Mtse Write RS232
-
Write RS232 ~OTIF~
~?aracterj
UI-Controller
(1)
1
Procedure Read RS232/Page 1, sheet 1 of 2 READRS23. SPD -
PROCEDURE Read RS232
1 ( 1)
• <'
NOT('<')
.R&adPort3(Ch)~------------------------~
1:::.
Ch•*D'
,R~)
Ch•'L~
Ch• 1 H'
Ch-'R'
I
;-:/; -rt -rs- ÖbVióuS-------"' 1 i 1
1
t 1
I* I
that the Message trom the UI-Controller is a CREATE-message for • LoudSpeakerPair, a Link or a services of any kind
L-------------------
:
ï/*-it-rs-ÖbVI;-us--&
I
I
----: I
I
r•;
that the Message trom the UI-Controller is a CHANGE-message
L--------------
:
ï;-:;;-Ït-fst;bVIóuS ___ _
I
I
----: I* I
tha t the Message frcm the UI-Controller is a CLAIM-message
L---------------
2
Procedure Read_RS232/Page 1, sheet 2 of 2 READRS23. SPD
Ch•'N'
Ch-'P'
I I
I
I I I
I I I
L.' __ (r-----------------~~a~\~~v~:~:age from the UI-controller
1
is a UNCLAIM-message
'*I
L-------------
~/* __________ t
,.
-rt -rs-ÖbVIöuä-- -----that the Message from the or-controller
~*Ït-G-öovr;~-------
1
I
--,
is a DELETE-message
:
for a LoudSpeakerPair, a Link or a servic•s of any kind
1
L------------------·
1
l•f
that the Message from the UI-Controller
is a UPDATE-message for •very original object in the network
L---------------
'I
Block Clse/Page 3a, Hnc .CLSEBLOC.SBK I
3a, Hnc (5)
BLOCK Clse [NoTu~
Service_Mtse&LL
~--~~~---------------------------------------------------, SetUpR•q DisconReq AttachRec
Service Be
DetachRe~
Link Mtse
SetUpReq Di•con!l.eq AttachReq DetachReq
Link Be
LCHANGf9
~
SetUpConf
rNOTIFYj
LsP Mtse
CHANGE
CLAIM UNCLAU UPDATE DELETE
/
(( , 16)
'"'
-
CHANGEj
~
CLAIM UNCLAI UPDATE DELE TE:
(0, 16) "'
SetUpConf
~
"I'
I I I I
I I I
'
I I
I I I I I
,L-
I I I I
' I I
,1...
TelephoneHafrdler
I I I I
[cREAT~
[cREAT5
'I I I I
I I
I I I
I I I I I I I I
~~PDATE J ~ELETEJ CHANGE CLAIM UNCLAI
( 0, 8)
Link- Router
I
l
Releaseind Disconind ReleaseCent AttachRejéct AttachConf Detachind DetachConf
LinkHandler
LsPHandler
[cREAT~
1
Releaseind Disconind !l.eleaseConf AttachReject AttachConf Oetachind DetachConf
I
~irth]
I I I I I
( 1, 1)
I
I
1----------- --
------
'
--- J
Generator
LsPHandler
~irth
J
AddinRouterTabel /* Complete Router with new Pid
[ *I
Generator Router
~irth
J
Telephone_Generator
Block Clse/Page 3b, Hnc .CLSEBLOC.SBK I
BLOCK Clse
3b, Hne (5) VideoDis Mtse
~OTIF~
VideoDis_EqCola VideoDis Be
~
SetUpReqi
DiseonRe
AttaehRe DetaehRe
AudioDis Mtse ~OTIF~
AudioDis Be SetUpReqi
~
DisconRe AttaehRe DetaehRe
BabyPhonie_Mtse
~OTIF~
BabyPhonie_Be
~
SetUpReqi
DiseonRe
AttaehRe DetachRe
~
SetUpConf
l~
Releaseind Diseonind ReleaseConf AttaehRejeet AttaehConf Detachind DetachConf
CHANGE1
CLAIM UNCLAI QPDATE DELETE
~
SetUpConf Releaseind Diseonind Releaseconf AttachRejee AttaehConf Detachind DetaehConf
j
CHANGE~
~
CLAIM UNCLAI UPDATE DELETE
(u, !:l)
( 0, 8)
"!'.
[cREAT~
I I I
I
:
I
I
I I I I I
I I I I I
I'
I
' I
AudioDisHandler .Jlbirth
~
CHANGE~
CLAIM UNCLAI UPDATE DELE TE
(u, !:l)
[cREAT~
J
I
( 1 r 1)
1- - - - - - - - - - - - -
~
l
VideoDisHandler
AudioDisHandler
BabyPhoneHandler
SetUpeonf
Releaseind Disconind ReleaseConf AttachReject AttachConf Detachind DetachConf
I I I I I I I
I I
I
------- _,
I
Generator /
BabyPhoneHandler ~irth] AddinRouterTabel
1• Complete Router with new Pid
[ •;
Generator Router
VideoDisHandler
Block Clse/Page 3c, Hnc _CLSEBLOC.SBK
I
BLOCK Clse
3c, Hnc
J
L L
L
J
J
Surveillance Mtse Surveillance Be
J
L
VideoPhonie Mtse
L
-
J
VideoPhonie- Be
L
J
~r
1
L
J
'I'
?!?!?!?!?!
I I I I I
I I I I
I
I I I I
I
I
[cREAT~
I
I I
I
I I I I I I I
I I I I I I I I I
[birth
I I
'l.t
I
I I I I I I I I I I I I I I I I
I
J
I I I
I I I
( 1, 1)
I
I
---------1
I I
1-------------
Generator
', [birth
J
1/
I' [birth
'I"
[cREAT~
L
J
'
I
I
I I
[
J
'"'
'I/
Surveillance
I I I I I I I
[cREAT~
J
'
/
VideoPhonie
'I'
J
[
li J
[
[
J
[cREAT~
J
( 5)
Process Generator/Page 1 .·GENER. SPR 11
PROCESS Generator
1
(2)
WaitForCREATE
>
~ ~----)--------CREATE (CreateKind, Id, Userid 1
L-----~----~
~----------~
CreateData
ELSE
Link
~------~ccreateKind~-------------------------,
Lsl?air
ELSE
Telephony Linkl!andler
r---------ccreateKind~-------------------------,
Lsl?air
Babyl?hone
Telephone-111 Handler 11
l!abyl?honeHandler
AudioDis ,.-------CCreateKind
ELSE
>------...,
VideoDis
AudioDisHandler
'
' WaitForl!irth
VideoDisHandlar
2 (2)
Proeen Generator/Page 2
.· GENER.SPR
11
PROCESS Generator
2
Surveillance
VideoFonie
Birth
SI!:ND >----ICREATE (CreateKind,
Id,
Userid,
createData )
TO SENDER
( 2)
Proeeos
Generator/Pa~
1
1
Il. GENER.SPR
11
PROCESS Generator
1 ( 2)
(
WaitForCil.EATE
> Link
CREATE(CreateKind, Id, Oserid, CreateOata I
ELSE
.------< CreateKin LsPair
Telephony LinkHandier
ELSE
~-----
--------------,
Lsl'air
Babyl'hone
~~
11
TelephoneHandler
Babyl?honeHandler
AudioDis r------
ELSE
>---------,
VideoDis
AudioOisHandler
'
/
;
(waitForBirth
11
VideoOisHandler
2 (21
2
Process Generator/Page 2 . GENER.SPR
II
11
PROCESS Generator
2
Surveillance
VideaFonie
Birth
SEND
}----!CREATE (CreateKind, Id, User!d, CreateData )
TO SENDER
(2)
1
Process LinkHand/Page 1, sheet 1 of 3 LINKHAND.SPR
PROCESS LinkHand
1 ( 6)
SEND birth
TO Generator
CREATE(Link,
DELE TE (Link, Objeetid, Userld
Objeetid,
OrigPn, Déstl?nl, Be,
)
Userld )
Sav
SEND BrResReq TO HClE!rMan
SEND
ro
DisconneetReq
HClBrMan
2
Process LinkHand/Page 1, sheet 2 of 3 LINKHAND.SPR
>
UI?DATii:(Dastl?n)
IBGetObjeetinfo (Link, Objactid, Object Info, Result
>
CI!ANGii:(Objec:t, Objec:tid, Attribute,
l?n, Userid )
Save CI!ANG&
)
SEND NOTIFY (Link, Objectid,
l?n
SuceesFull, Userid, State,
Origl?n, Destl?nl, Destl?n2, DestPn3,
NOI?N IBG•tObj•ctinfo "(Link, Objectid, Objectinfo, Result
DestPn4,
Be )
TO !!ClRoutar
)
Zoek uit mat welke put van de bestaande verbinding moet worden verwijderd
Sli:ND DetachReq(Pn,Br) TO !!ClBrMan
-
( WaitDetach
3
Process LinkHand/Page 1, sheet 3 of 3 LINKHAND.SPR
I
SEND >--~ ~; taehReq
l!ClBrMan
( WaitAttaeh
I
(l?n, Br)
ïl
Process LinkHand/Page 2
.. LINKHAND. SPR
11
PROCESS LinkHand
(
WaitBr
2
)
>
>
Br~•sAeo (Br)
BrR6sDn
I
Get
Get SavedMessage
Saved.Message
Save Br
SEND NO'I'IrY (Link, Objeotid,
I
I
UnSucoessFullCreate, Usèrid,
State, OrigPn, Destl?nl, Destl?n2, Destl?n3,
SEND Set!JpReq (OrigPn,Destl?n,Be,Br) 'I'O HClBrMan
'\:/
WaitSetup
DestPn4,
Be )
TO HelRouter
'
('laiti"orl?eerToP eerMessage
( 6)
5
Process LinkHand/Page 3, sheet 1 of 2 LINKHAND. SPR
PROCESS LinkHand
3 ( 6)
SetUpConfirm
SEND
IBCreateObject (LasUser,
)-........~NOTIFY(Link, Objectid, UnSuccessFullCreate, Us•rid, stat&, Origl?n, Dèstl?nl,
Link, Linkid, Objeotinfo,
Rèsult )
DestPn2, DestPn3, DêSt5?n4, Be )
TO HelRouter
TooManyinstances
lllrR.,sRel (lllr)
lllrResR•l (lllr)
Di$OOnn•c::tRe (!lr)
ELSE
SEND )-----~NOTIFY(Link,
Obieotid, SuécessFullCreate, Userid, state, OrigPn, DestPnl,
\'------'
DestPn2,
DestPn3, Destl?n4, Be )
TO HClRouter
7
Process LinkBand/Page 4
. LINKHAND. Sl?R 11
11
l?ROCESS LinkHand
4
( WaitD
)D•tachConf
Get Sa veelMessage
ISChangeAttribute(LastUs•r, Link, Objectid, Attribute, l?n, Result )
SENO NOTIFY(Link, Obj•ctid, SuccessFullDetach, Userid, State, OrigPn, DestPnl, DestPn2,
Oestl?n3, Destl?n4, Be
l TO HClRout.,r
(
WaitForPee4ToPeerMessage
( 6)
Process LinkHand/Page 5
11
. LINKHAND. SPR
II
PROCESS LinkHand
5 ( 6)
WaitJ\.ttach
)AttachRej
>ttachConf
Get SavedHessage
Saved.Message
Get
IBGetObjectinfo(Link, Objectid, Object Info, Result)
IBChangeAttribute(LastUser, Link,
Objectld, Attribute,
l?n, Result )
SEND NOTIFX (Link, Objectld, UnSuccessFullAttach, Userid, State, origt>n, DestPnl, DestPn2,
Destl?n3, DestPn4,
Be )
TO HClRouter
IBGetObjectinfo(LastUser, Link, Objectid, Attribute, l?n, R
SEND NOTIFY (Link, Objectld, SuccessFullAttach, Userld, State, OrigPn, DestPnl,
Dest>•n2, DestPn3, Destl?n4, Be
/
I"
)
TO HClRouter ,~;
(
WaitFor-
PeerToPeer-
Message
ïl
Process LinkHand/Page 6
. LINKHAND. SI?R
11
I?ROCESS LinkHand
6 ( 6) WaitDiseonnect
1
~~ IBDeleteObject (Link,
Objectid,
Re sult 111 U----,----~
l
)
SEND >----;NOTIFY (Link, Objectid, SuccessFullDelete,
Userid, State, Origl?n,
D•stl?nl, Destl?n2, Destl?n3, Dastl?n4, Be )
TO
HClRouter
Sloek Clse/Page 2, Te _CLSEBLOC.SBK
li
BLOCK Clse
( 1, 1)
( 1, 1)
MicrophoneHandler
CameraHandler
"'~CHANGEj
'!'~CHANGE~ CLAIM UNCLAI
CLAIM UNCLAI
UPDATE
UPDATE
( 1, 1)
( 1, 1)
CdHandler
LsHandler
~
CHANGEj CLAIM
Cd Router
( 1, 1)
MonitorHandler
CHANI#Ej
~
~
CHANGEj
UNCLAI
CLAIM UNCLAI
UPDATE
CLAIM UNCLAI
UPDATE
UPDATE
Microfoon Router
Ls Router
~OTIF~
Camera Router I* The handlers are availabl;le in the VME-system when TE is conneeted
•!
Monitor Router
1
Process ClseTe/Page 1, sheet 1 of 2 CLSECLTE.SPR
PROCESS ClseTe
1
(5)
I* De CHANGE-berichten in dit SDL diagram zijn niet geheel uitgewerkt per object en per attribuut. Wel wordt er duidelijk aangegeven welke acties er per attribuut verandering moet worden ondernomen '*/
CHANGE (Object, Objectid, Userid, Attribute, NewValue )
InquireAttribute (Obiect, ob]ectid, Userid, AttrLastUser, Value,
Result)
UseridType(Value) TRUE
FALSE GetObjectinfo(Object, Objectid, Objectinfo, Result l
CoLaMessage.TYPE :•Objectinfo.Type; CoLaMessage.FUNCTION :•Function[Attribute]; ColaMessage.VALUE :•BITSET(NewValue); NewValue heeft een waarde tussen de 0 en 255 welke in de UI
reeds is bepaald
Sl!.ND ColaMessage
TO EqCola
CLAIM(Object, Objectid, Userid )
2
Process ClseTe/Page 1, sheet 2 of 2 CLSECLTE.SPR
UNCLAIM (Object, Objectià, IJserià )
1-----iiJPDATE (Pn)
Proeeos ClseTe/Page 2 .· CLSECLTE. SPR
Il
PROCESS ClseTe
2 ( 5)
2b(5)
2a (5)
!----
11
IBChangaAttribute(Oserrd, Object, Objectid, Attribute,
NewValue,. P.esult )
1------1
.
Objectinfo.Attribute~· MessagePtr~.NewValue
SEND NOTIFY (Object, Objectid, Objectinfo, ünSuccessFullChange I TO
SEND NOTIFY(Object, Objectid, Objectinfo, SuccessFullChange )
TO
Router
Router
(
'.a/ -
ïl
Process ClseTe/Page 3 .· CLSECLTE. SPR
11
3 ( 5)
PROCESS ClseTe 3 (5)
InquireAttribute (Obj
Userid,
AttrState, Value,
Result)
Inactiv• OR ActiveFree
y">---~StateType (Val u<~)
ActiveOccupied
IBChangeAttribute( tJserid, Object, Objectid, AttrState,
ValueType(Activeoccupied), Result)
I
IBGetObjectinfo( Object, Objectid, Object Info, Result}
SEND
SEND >----iNOTIFY (Object, Objectid, Objectin!o, SuccessFullClaim) TO
>----1 NOTIFY
(Object, Objectid, Objectin!o, UnSuccessFullClairnl
TO
Router
Router
)
îl
Process ClseTe/Page 4 .· CLSECLTE. Si?R
II
i?ROCESS ClseTe
4 ( 5)
4 (5)
Inquir6Attribut•( Obj•ct, Objectid, Userid,
Value, Result)
TROE
MessagePtrA.Userid
-
y
ValueType(Useridl
fALSE IBChangeAttribute( Userid, Object, Objectid, AttrState, ValueType(InActive), Re sult)
IBDetObjectinfo(Object, Objectid, Objectinfo, Result )
SEND NOTH'Y (Object, Objectid, Objectinfo, successFullOnClaim) TO Router
'
/
,!....
-
NOl'IFY (Object, Objectid, Objectinfo, UnSucces•fullUnClaim) TO Router
APPENDIX I
Appendix H
SOL-diagrammen
INHOUDSOPGAVE •
hncclse .def (definitie module van de onderdelen van de CLSE van de HNC)
•
hncclse .mod (implementatie module van de onderdelen van de CLSE van de HNC)
•
linkiwu.def (definitie module van de InterWerkingUnit tussen VME-systeem)
•
linkiwu.mod (implementatie module van de InterWerkingUnit tussen VMEsysteem)
•
tehand.def (definitie module van de objecten)
•
tehand.mod (implementatie module van de objecten)
•
monitor.def (definitie module van het monitorobject)
•
monitor.mod (implementatie module van het monitorobject)
1
2 3 4 5 6 7 8 9 10 11
12 13 14 15 16 17 18 19 20 21 22 23 24 25
26 27 28 29 30 31 32 33 34 35 36 37 38 39
40
41 42 43 44 45 46 47
(************************************************************************) (*
*)
(*
*)
(* (* (* (* (* (* (*
(* (* (*
(* (*
(* (*
(* (* (* (* (*
*)
PTT NEDERLAND NV PTT Research Dr Neher Laboratories Leidschendam - The Netherlands
*) *) *)
Copyright (c) 1991 by PTT NEDERLAND NV
*) *) *)
All rights strictly reserved. No part of this document may be reproduced in any form or by any means without written permission from the publisher. Alle rechten uitdrukkelijk voorbehouden. Vermenigvuldiging of mededeling aan derden in welke vorm ook, is zonder schriftelijke toestemming van PTT NEDERLAND NV niet geoorloofd.
*) *) *)
*) *)
*) *)
*) *) *) *) *)
(*
**************************************************************** *)
(* (*
*) *)
(* (*
AUTHORS CREATION DATE
M.C.M. Peeters 14-7-91
*) *)
COMPILER SYST.ENVIRONMENT VERSION ERROR CONDITIONSAND HANDLING FILES USED
ACE 68000 of LOGITECH VAX/VMS 1.0
*) *)
(*
(* (* (*
(* (* (*
*)
*)
*) *) *)
(*
*)
(* (* (* (* (*
*) *) *) *) *)
(*
*)
(*
*)
(*
*)
(* (*
*) *)
(*
DESIGN DOCUMENT TESTSPEC'S
ban 91
.0 ID
PROGRAM DESCRIPTION:
modula 2 definition of the SOL-Diagram Generator and LinkHandler
*)
48
(* (*
49 50 51
(* (*
52
(*
**************************************************************** *)
(* (*
*) *)
53 54 55 56 57 58 59
60 61 62 63 64 65 66
(*
(*
C HANGE
(*
(* (*
<*
(*
<*
Date
I Name
*) *)
L0 G
*) *)
*)
I Description
----------+-------------+-----------------------------------I ----------+-------------+------------------------------------
(*
*)
I
*)
*) *)
*>
*)
*>
*)
(************************************************************************) DEFINITION MODULE HncClse;
67
FROM SDLM
68 69 70
VAR
71 72
HClGenerator, HClRouter, HClBrMan
IMPORT
ProcessiD;
ProcessiD;
73 74 75
PROCEDURE ProcessHClGenerator;
76
END HncClse.
1
2
3 4 5 6 7 8 9
10 11
12 13 14 15 16 17 18 19 20 21 22
23 24 25
26 27 28 29 30 31 32 33 34
(************************************************************************) (* (* (*
PTT NEDERLAND NV PTT Research Dr Neher Laboratories Leidschendam - The Netherlands
(* (* (* (* (* (* (* (*
(* (* (*
Copyright (c) 1991 by PTT NEDERLAND NV
(* (* (*
*) *) *) *) *) *) *) *)
All rights strictly reserved. No part of this document may be reproduced in any form or by any means without written permission from the publisher.
*) *) *)
Alle rechten uitdrukkelijk voorbehouden. Vermenigvuldiging of mededeling aan derden in welke vorm ook, is zonder schriftelijke toestemming van PTT NEDERLAND NV niet geoorloofd.
*) *) *)
(*
(* (* (*
*) *) *)
*)
*) *) *)
(*
**************************************************************** *)
(* (*
*) *)
(* (* (* (* (*
(* (*
AUTHORS Generation DATE
M.C.M. Peeters 14-7-91
COMPILER SYST.ENVIRONMENT VERSION ERROR CONDITIONSAND HANDLING FILES USED
ACE 68000 of LOGITECH VAX/VMS 1.0
DESIGN DOCUMENT TESTSPEC'S
ban 91
PROGRAM DESCRIPTION:
modula 2 implementation of the SOL-Diagram Generator and TeHandler
*) *) *) *) *)
*) *)
45
(* (* (* (* (* (* (* (* (* (* (* (* (*
46 47
(* (*
48
(*
49 50 51
(* (* (*
52
(*
**************************************************************** *)
(* (*
*) *)
35
36 37
38 39 40
41 42 43 44
53 54
55 56 57 58 59
60 61 62 63 64 65 66
(*
(*
<* (* <* (*
.0 ID
*) *) *)
C HANGE
(*
(*
*) *) *) *) *) *) *) *) *) *) *) *) *)
Date
L0 G
I Name
*) *) *)
*)
I Description
*)
*) *)
----------+-------------+-----------------------------------I I *> ----------+-------------+------------------------------------ *) I I *> *)
(************************************************************************) IMPLEMENTATION MODULE HncClse;
FROM SDLM
IMPORT
StartProcessinstance, TypePriority,KillProcess, ProcessiD, NOPROCESS, SENDER, PARENT, SendMessage, ReceiveMessage, Consume, Ignore, Save, PutMemoryElement, GetMemoryElement, State;
FROM EbinTypes
IMPORT
PnType, NOPN, BrType, ObjectType, ObjectidType, UseridType, StateType, HlResultType;
FROM EbinMess
IMPORT
SIGNALS,AttributeType, TypeMessagePtr,MESSAGES;
85 86 87 88 89 90 91
FROM IBProc
IMPORT
ObjectinfoType, IBCrea teObj ec t, IBDeleteObject, IBGetObj ec tinfo, IBChangeAttribute, ValueType;
92
FROM Tools
67 68 69 70 71 72
73 74 75
76 77
78 79
80 81 82 83 84
93 94 95 96 97
98 99 100 101 102 103 104 105 106 107 108 109 110 111 112 113 114 115 116
IMPORT
(*************************************************************************) (*************************************************************************) (** **) (** LinkHandler **) (** **) (*************************************************************************) (*************************************************************************)
PROCEDURE ProcessLinkHandler; TYPE NextStateType = (YaitForPeerToPeerMessage, YaitSetup, YaitDisconnect, YaitBr, YaitDetach, YaitAttach); VAR MessagePtr, SavedMessage1, SavedMessage2: TypeMessagePtr; Linkid Obj ec tidType; UseridType; User Br BrType; Objectinfo ObjectinfoType; NextStateType; NextState HlResultType; Result
117
PROCEDURE SendNotify(
118 119
VAR
120 121 122 123 124 125 126 127 128 129 130 131 132
VarState;
DestPn HlResult
PnType; HlResultType);
MessagePtr TypeMessagePtr; Result HlResultType; BEGIN IBGetObjectinfo( Link, MessagePtrA.Objectid, Objectinfo, Result )i
GetMemoryElement(MESSAGES,MessagePtr); MessagePtrA.Signal := NOTIFY; HessagePtrA.HlResult := HlResult; HessagePtrA.DestPn := DestPn; MessagePtrA.Object := Objectinfo.Object;
133 134 135 136 137 138 139 140 141 142 143 144 145 146 147 148 149 150 151 152 153 154 155 156 157 158 159 160 161 162 163 164 165 166 167 168 169 170 171 172 173 174 175 176 177 178 179 180 181 182 183 184 185 186 187 188 189 190 191 192 193 194 195 196 197 198
MessagePtrA .Objectid := Objectinfo.Objectld; MessagePtrA.LastUser := Objectlnfo.LastUser; MessagePtrA.State := Objectlnfo.State; MessagePtrA.Available := Objectlnfo.Available; MessagePtr".Bc := Objectlnfo.Bc; MessagePtr".OrigPn := Objectinfo.OrigPn; MessagePtr".DestPn1 := Objectinfo.DestPn1; MessagePtr".DestPn2 := Objectlnfo.DestPn2; MessagePtrA.DestPn3 := Objectinfo.DestPn3; MessagePtr".DestPn4 := Objectinfo.DestPn4; SendMessage('NOTIFY',MessagePtr,HClRouter); END SendNotify; BEGIN GetMemoryElement(MESSAGES,MessagePtr); MessagePtr".Signal := Birth; SendMessage('Birth ',MessagePtr,PARENT()); Br := MIN(BrType); NextState == VaitForPeerToPeerMessage; State('VPtoPM'); LOOP CASE NextState OF VaitForPeerToPeerMessage: ReceiveMessage(MessagePtr); CASE MessagePtr".Signal OF CREATE: State('CREATE'); Consume; SavedMessage1 := MessagePtr; Linkld := MessagePtr".Objectid; User := MessagePtr".LastUser; GetMemoryElement(MESSAGES,MessagePtr); MessagePtr".Signal := BrResReq; SendMessage('BrRsRq',MessagePtr,HClBrMan); NextState := VaitBr; State('VBrRs '); DELETE: State('DELETE'); IF (Br # MIN(BrType)) THEN Consume; MessagePtr".Signal := DisconnectReq; MessagePtr".Br := Br; SendMessage('DisReq',MessagePtr,HClBrMan); NextState := VaitDisconnect; State('VDisco'); ELSE State('Ignor1'); State('Ignore'); Ignore; PutMemoryElement(MESSAGES,MessagePtr); END; (* IF *) CHANGE: State('CHANGE'); Consume; GetMemoryElement(MESSAGES,SavedMessage2); SavedMessage2" := MessagePtr"; IF (MessagePtr".Pn = NOPN) THEN IBGetObjectinfo( Link,MessagePtr".Objectid,
199 200 201 202 203 204 205 206 207 208 209 210 211 212 213 214 215 216 217 218 219 220 221 222 223 224 225
226 227 228 229 230 231 232 233 234 235 236 237 238 239 240 241 242 243 244 245 246 247 248 249 250 251 252 253 254 255 256 257 258 259 260 261 262 263 264
Objectinfo,Result); CASE HessagePtr-.Attribute OF AttrDestPn1: HessagePtr·.Pn := Objectinfo.DestPn1; !AttrDestPn2: HessagePtr·.Pn := Objectinfo.DestPn2; IAttrDestPn3: HessagePtr·.Pn := Objectinfo.DestPn3; 1AttrDestPn4: HessagePtr·.Pn := Objectinfo.DestPn4; END; (* CASE *) HessagePtr·.signal == DetachReq; HessagePtr·.ar == Br; SendHessage('DetReq',HessagePtr,HClBrHan); NextState := YaitDetach; State('YDisco'); ELSE HessagePtr·.signal := AttachReq; HessagePtr·.ar :=Br; SendHessage('AttReq',HessagePtr,HClBrHan); (* (*
HessagePtr·.Pn bevat de waarde van het Pn waarmee de link moet worden uitgebreid NextState := YaitAttach; State('YDisco'); END; (* IF *)
ELSE Save; END; (* CASE *) YaitBr: ReceiveMessage(HessagePtr); CASE HessagePtr-.Signal OF BrResAcc: Consume; State('BrRsAc'); Br := HessagePtr·.ar; HessagePtr·.signal := SetupReq; HessagePtr·.ar == Br; HessagePtr·.origPn == SavedHessage1·.origPn; HessagePtr·.DestPn == SavedHessage1·.DestPn1; HessagePtr·.ac := SavedHessage1·.ac; := NOPROCESS; HessagePtr •• Pid SendHessage('SetReq',HessagePtr,HClBrHan); NextState := YaitSetup; State('YSetup'); BrResDen: Consume; State('BrRsDn'); PutHemoryElement(HESSAGES,HessagePtr); HessagePtr := SavedHessage1; HessagePtr •• HlResult := UnSuccessFullCreate; HessagePtr·.state := InActive; HessagePtr·.Available := TRUE; HessagePtr·.signal := NOTIFY; HessagePtr·.DestPn := NOPN; HessagePtr·.DestPn1 == NOPN; HessagePtr·.DestPn2 := NOPN; HessagePtr·.DestPn3 := NOPN; HessagePtr·.DestPn4 := NOPN; SendHessage('NOTIFY',HessagePtr,HClRouter); NextState == YaitForPeerToPeerHessage;
*)
*)
265 266 267 268 269 270 271 272
273 274 275 276
277 278 279 280 281 282 283 284 285 286 287 288 289 290 291 292 293 294 295 296 297 298 299 300 301 302 303 304 305 306 307 308 309 310 311
312 313 314 315 316 317 318 319 320 321 322 323 324 325 326 327 328 329 330
State('VPtoPM'); ELSE State('Ignor2'); State('Ignore'); Ignore; PutMemoryElement(MESSAGES,MessagePtr); END; (* CASE *) VaitSetup: ReceiveMessage(MessagePtr); CASE MessagePtrA.Signal OF SetupConf: Consume; PutMemoryElement(MESSAGES,MessagePtr); MessagePtr := SavedMessage1; Object!nfo.Object == Link; Object!nfo.Object!d := Linkld; Objectinfo.DestPn1 == MessagePtr·.oestPn1; Object!nfo.DestPn2 := NOPN; Objectinfo.DestPn3 := NOPN; Object!nfo.DestPn4 := NOPN; Objectinfo.OrigPn := MessagePtr·.origPn; Obj ec tlnfo. Be == MessagePtr·.ac; Objectinfo.LastUser := User; Object!nfo.State := ActiveOccupied; Object!nfo.Available := FALSE; IBCreateObject( User, Link, Link!d, Obj ec tlnfo, Result); IF (Result = TooManylnstances) THEN GetMemoryElement(MESSAGES,MessagePtr); MessagePtr·.signal == BrResRel; MessagePtr·.ar := Br; SendMessage('BrRsRl',MessagePtr,HClBrMan); State('VBrRs '); GetMemoryElement(MESSAGES,MessagePtr); MessagePtr·.signal := DisconnectReq; MessagePtr·.ar := Br; SendMessage('DiCoRe',MessagePtr,HClBrMan); State('DiCoRe'); ReceiveMessage(MessagePtr); CASE MessagePtr·.signal OF Disconnect!nd: State('DiColn'); IBDeleteObject(Link,Linkid,Result); MessagePtr·.signal := NOTIFY; MessagePtrA.DestPn := NOPN; MessagePtr·.object ==Link; MessagePtr·.objectld := Linkld; MessagePtr·.oestPn := NOPN; MessagePtr·.oestPn1 := Objectinfo.DestPn1; MessagePtr·.oestPn2 == Objectinfo.DestPn2; MessagePtr·.oestPn3 == Objectinfo.DestPn3; MessagePtr·.oestPn4 := Objectlnfo.DestPn4; MessagePtr·.origPn := Objectinfo.OrigPn; MessagePtr·.ac := Objectlnfo.Bc; MessagePtr·.LastUser := Objectlnfo.LastUser; MessagePtr·.state := Objectlnfo.State; MessagePtr·.Available:= Objectlnfo.Available; MessagePtr-.HlResult := Result; SendMessage('NOTIFY',MessagePtr,HClRouter);
331 332 333 334 335 336 337 338 339 340 341 342 343 344 345 346 347 348 349 350 351 352 353 354 355 356 357 358 359 360 361 362 363 364 365 366 367 368 369 370 371 372
373 374 375 376 377
378 379 380 381 382 383 384 385 386 387 388 389 390 391
392 393 394 395 396
State('ToMain'); KillProcess; ELSE State('Ignor3'); State('Ignore'); Ignore; PutMemoryElement(MESSAGES,MessagePtr); END; (* CASE *) ELSE MessagePtr".HlResult := SuccessFullCreate; MessagePtr".Signal != NOTIFY; MessagePtr·.DestPn := NOPN; MessagePtr·.DestPn1 := NOPN; MessagePtr·.DestPn2 := NOPN; MessagePtr·.DestPn3 := NOPN; MessagePtr·.DestPn4 == NOPN; MessagePtr•.state == ActiveOccupied; MessagePtr·.Available == FALSE; SendMessage('NOTIFY',MessagePtr,HClRouter); NextState := VaitForPeerToPeerMessage; State('VPtoPM'); END; (* IF *) Releaseind: Consume; PutMemoryElement(MESSAGES,MessagePtr); MessagePtr == SavedMessage1; MessagePtr .. HlResult := UnSuccessFullCreate; MessagePtr".State == InActive; MessagePtr·.Available := TRUE; MessagePtr".Signal := NOTIFY; MessagePtr".DestPn == NOPN; MessagePtr·.DestPn1 := NOPN; MessagePtr".DestPn2 == NOPN; MessagePtr".DestPn3 == NOPN; MessagePtr·.DestPn4 := NOPN; SendMessage('NOTIFY',MessagePtr,HClRouter); GetMemoryElement(MESSAGES,MessagePtr); MessagePtr".Signal == BrResRel; MessagePtr".Br := Br; SendMessage('BrRsRl',MessagePtr,HClBrMan); State('KillPr'); KillProcess; ELSE State('Ignor4'); State('Ignore'); Ignore; PutMemoryElement(MESSAGES,MessagePtr); END; (* CASE *) VaitDetach: ReceiveMessage(MessagePtr); CASE MessagePtr".Signal OF DetachConf: Consume; PutMemoryElement(MESSAGES,MessagePtr); MessagePtr == SavedMessage2; State('DetCon'); CASE MessagePtr•.Attribute OF AttrDestPn1: IBChangeAttribute( MessagePtr".LastUser, Link, MessagePtr".Objectid, AttrDestPn1,
397 398 399 400 401 402 403 404 405 406 407 408 409 410
ValueType(MessagePtr".Pn), Result); IAttrDestPn2: IBChangeAttribute( MessagePtr".LastUser, Link, MessagePtr •. Objectid, AttrDestPn2, ValueType(MessagePtr".Pn), Result); IAttrDestPn3: IBChangeAttribute( MessagePtr".LastUser, Link, MessagePtr".Objectid, AttrDestPn3, ValueType(MessagePtr".Pn), Result);
411
412 413
414 415 416 417 418 419 420 421 422 423 424 425 426 427 428 429 430 431 432 433 434 435 436 437 438 439 440 441 442 443 444 445 446 447 448 449 450 451 452 453 454 455 456 457 458 459 460 461 462
1AttrDestPn4: IBChangeAttribute( MessagePtr".LastUser, Link, MessagePtr".Objectid, AttrDestPn4, ValueType(MessagePtr".Pn), Result); END; (* CASE *) IBGetObjectinfo( Link, MessagePtr".Objectid, Objectinfo, Result );
MessagePtr .• HlResult := SuccessFullDetach; MessagePtr".Signal := NOTIFY; MessagePtr".DestPn := NOPN; MessagePtr".Object := Objectinfo.Object; MessagePtr".Objectid == Objectinfo.Objectid; MessagePtr".DestPn1 := Objectinfo.DestPn1; MessagePtr·.DestPn2 := Objectinfo.DestPn2; MessagePtr".DestPn3 := Objectinfo.DestPn3; MessagePtr".DestPn4 == Objectinfo.DestPn4; MessagePtr".OrigPn := Objectinfo.OrigPn; MessagePtr".Bc := Objectinfo.Bc; MessagePtr".LastUser := Objectinfo.LastUser; MessagePtr".State := Objectinfo.State; MessagePtr".Available:= Objectinfo.Available; SendMessage('NOTIFY',MessagePtr,HClRouter); NextState := YaitForPeerToPeerMessage; State('YPtoPM'); ELSE State('Ignor5'); State('Ignore'); Ignore; PutMemoryElement(MESSAGES,MessagePtr); END; (* CASE *) Yai tA t tach: ReceiveMessage(MessagePtr); CASE MessagePtr".Signal OF AttachRej: Consume; PutMemoryElement(MESSAGES,MessagePtr); MessagePtr := SavedMessage2; State('AttRej'); IBGetObjectinfo( Link, MessagePtr".Objectid,
463 464 465 466 467 468 469 470 471 472
473 474 475 476 477
478 479 480 481 482 483 484 485 486 487 488 489 490 491 492 493 494 495 496 497 498 499 500 501 502 503 504 "505 506 507 508 509 510 511
512 513 514 515 516 517 518 519 520 521 522
523 524 525 526 527 528
Objectinfo, Result );
HessagePtr".HlResult :a UnSuccessFullAttach; HessagePtr".Signal := NOTIFY; HessagePtr".DestPn :a NOPN; HessagePtr".Object := Objectinfo.Object; HessagePtr".Objectid := Objectinfo.Objectid; HessagePtr".DestPn1 := Objectinfo.DestPn1; HessagePtr".DestPn2 := Objectinfo.DestPn2; HessagePtr".DestPn3 := Objectinfo.DestPn3; HessagePtr".DestPn4 := Objectinfo.DestPn4; HessagePtr".OrigPn := Objectinfo.OrigPn; HessagePtr".Bc := Objectlnfo.Bc; HessagePtr".LastUser := Objectinfo.LastUser; HessagePtr".State := Objectlnfo.State; HessagePtr".Available:= Objectlnfo.Available; SendHessage('NOTIFY',HessagePtr,HClRouter); NextState := VaitForPeerToPeerHessage; State('YPtoPH'); At tachConf: Consume; PutHemoryElement(HESSAGES,HessagePtr); HessagePtr := SavedHessage2; State('AttCon'); CASE HessagePtr".Attribute OF AttrDestPn1: IBChangeAttribute( HessagePtr".LastUser, Link, HessagePtr".Objectid, AttrDestPn1, ValueType(HessagePtr".Pn), Result); 1AttrDestPn2: IBChangeAttribute( HessagePtr".LastUser, Link, HessagePtr".Objectid, AttrDestPn2, ValueType(HessagePtr".Pn), Result); IAttrDestPn3: IBChangeAttribute( HessagePtr".LastUser, Link, HessagePtr".Objectid, AttrDestPn3, ValueType(HessagePtr".Pn), Result); IAttrDestPn4: IBChangeAttribute( HessagePtr".LastUser, Link, HessagePtr".Objectid, AttrDestPn4, ValueType(HessagePtr".Pn), Result); END; (* CASE *) IBGetObjectlnfo( Link, HessagePtr".Objectid, Objectinfo, Result );
HessagePtr".HlResult == SuccessFullAttach; HessagePtr".Signal := NOTIFY;
529 530 531 532 533 534 535 536 537 538 539 540 541 542 543 544 545 546 547 548 549 550 551 552 553 554 555 556 557 558 559 560 561 562 563 564 565 566 567 568 569 570 571 572 573 574 575 576 577 578 579 580 581 582 583 584 585 586 587 588 589 590 591 592 593 594
MessagePtrA.DestPn == NOP.N; MessagePtrA.Object := Objectlnfo.Object; MessagePtrA.Objectld := Objectlnfo.Objectld; MessagePtrA.DestPn1 := Objectlnfo.DestPn1; MessagePtrA.DestPn2 == Objectinfo.DestPn2; MessagePtr".DestPn3 := Objectinfo.DestPn3; MessagePtrA.DestPn4 := Objectlnfo.DestPn4; MessagePtr".OrigPn == Objectlnfo.OrigPn; MessagePtr".Bc := Objectinfo.Bc; MessagePtr".LastUser := Objectinfo.LastUser; MessagePtrA.State == Objectinfo.State; MessagePtrA.Available:= Objectinfo.Available; SendMessage('NOTIFY',MessagePtr,HClRouter); NextState := VaitForPeerToPeerMessage; State('VPtoPM'); ELSE State('Ignor6'); State('Ignore'); Ignore; PutMemoryElement(MESSAGES,MessagePtr); END; (* CASE *) VaitDisconnect: ReceiveMessage(MessagePtr); CASE MessagePtrA.Signal OF ReleaseConf: Consume; IBDeleteObject(Link,Linkid,Result); MessagePtrA.Signal := NOTIFY; MessagePtr".DestPn := NOPN; MessagePtr".Object :=Link; MessagePtrA.Objectld := Linkld; MessagePtr".DestPn == NOPN; MessagePtr".DestPn1 == Objectinfo.DestPn1; MessagePtr".DestPn2 == Objectinfo.DestPn2; MessagePtr".DestPn3 == Objectinfo.DestPn3; MessagePtr".DestPn4 := Objectinfo.DestPn4; MessagePtr".OrigPn == Objectlnfo.OrigPn; MessagePtr".Bc := Objectinfo.Bc; MessagePtr".LastUser ~= Objectlnfo.LastUser; MessagePtrA.State := Objectinfo.State; MessagePtr".Available:= Objectinfo.Available; MessagePtr".HlResult := Result; SendMessage('NOTIFY',MessagePtr,HClRouter); NextState := VaitForPeerToPeerMessage; State('VPtoPM'); ELSE State('Ignor7'); State('Ignore'); Ignore; PutMemoryElement(MESSAGES,MessagePtr); END; (* CASE *) END; (* CASE *) END; (* CASE *) END ProcessLinkHandler;
(*************************************************************************) (*************************************************************************) (** **) (** HelGenerator **) (** **) (*************************************************************************)
595 596 597 598 599 600 601 602 603 604 605 606 607 608 609 610 611 612 613 614 615 616 617 618 619 620 621 622 623 624 625 626 627 628 629 630 631 632 633 634 635 636 637 638 639 640 641 642 643 644 645 646 647 648 649 650 651 652 653 654 655 656 657 658 659 660
(*************************************************************************) TYPE GenerationindexType = [1 .. 20]; VAR Generation : ARRAY GenerationindexType OF RECORD Handier ProcessiD; MessagePtr : TypeMessagePtr; END; PROCEDURE InitGenerator; VAR Index : GenerationindexType; BEGIN FOR Index == MIN(GenerationindexType) TO MAX(GenerationindexType) DO Generation[Index].Handier := NOPROCESS; END; (* FOR *) END InitGenerator; PROCEDURE FindGenHandier( Handier ProcessiD; VAR BOOLEAN; Index GenerationindexType) VAR Idx GenerationindexType; BEGIN FOR Idx := MIN(GenerationindexType) TO MAX(GenerationindexType) DO IF (Generation[Idx].Handler = Handler) THEN Index := Idx; RETURN (TRUE); END; (* IF *) END; (* FOR *) RETURN (FALSE); END FindGenHandler; PROCEDURE ProcessHCIGenerator; VAR MessagePtr TypeMessagePtr; Index : GenerationindexType; BEGIN InitGenerator; LOOP ReceiveMessage(MessagePtr); CASE MessagePtrft.Signai OF CREATE: State('CREATE'); IF (FindGenHandler(NOPROCESS,Index)) THEN CASE MessagePtrft.Object OF Link: Consume; Generation[Index].MessagePtr := MessagePtr; StartProcessinstance(ProcessLinkHandier,'LnkHlr', Normal,Generation[Index].Handier); I LsPair: I TelePhony: I BabyPhony: I AudioDistribution: I VideoDistribution: I VideoPhony: I Surveillance: ELSE
661 662 663 664 665 666 667 668 669 670 671 672 673 674 675 676 677 678 679 680 681 682 683 684 685 686 687 688 689 690 691 692 693 694 695 696 697 698
(********************************)
ERROR *) (* Kan geen handler genereren *) (* voor het betreffende object. *) (*
(********************************)
State('Ignor8'); State('Ignore'); Ignore; PutMemoryElement(MESSAGES,MessagePtr); END; (* CASE *) ELSE
(*****************************************)
(* Bewaar alle CREATE berichten die niet *) (* direct afgehandeld kunnen worden. *)
(*****************************************)
Save; END;
Birth: State('Birth '); Consume; IF (FindGenHandler(SENDER(),Index)) THEN SendMessage('CREATE',Generation[Index].MessagePtr, Generation[Index].Handler); Generation[Index].Handler := NOPROCESS; END; (* IF *) PutMemoryElement(MESSAGES,MessagePtr); ELSE State('Ignor9'); State('Ignore'); Ignore; PutMemoryElement(MESSAGES,MessagePtr); END; (* CASE *) END; (* LOOP *) END ProcessHClGenerator; END HncClse.
1
(************************************************************************)
3
(* (* (*
2 4 5 6 7 8 9
(*
10
(* (*
11
12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66
PTT NEDERLAND NV PTT Research Dr Neher Laboratories Leidschendam - The Netherlands
(* (* (* (*
(*
(* (* (* (*
(*
(*
(* (* (* (*
(* (*
(* (* (* (*
(* (*
*) *) *) *) *)
Copyright (c) 1991 by PTT NEDERLAND NV
(*
(* (* (* (*
*) *) *)
*) *) *)
All rights strictly reserved. No part of this document may be reproduced in any form or by any means vithout vritten permission from the publisher. Alle rechten uitdrukkelijk voorbehouden. Vermenigvuldiging of mededeling aan derden in welke vorm ook, is zonder schriftelijke toestemming van PTT NEDERLAND NV niet geoorloofd.
*) *) *) *) *)
*) *) *) *)
*)
**************************************************************** *) *)
*)
AUTHORS CREATION DATE
M.C.M. Peeters 14-7-91
COMPILER SYST.ENVIRONMENT VERSION ERROR CONDITIONSAND HANDLING FILES USED
ACE 68000 of LOGITECH VAX/VMS 1.0
*) *)
*) *) *) *) *) *)
*) *)
(*
*)
(*
*) *) *)
(* (* (*
*)
(*
*)
(*
*)
(*
*)
(*
*)
(* (* (* (* (* (*
*) *) *) *) *) *)
DESIGN DOCUMENT TESTSPEC'S
ban 91
.0 ID
PROGRAM DESCRIPTION:
modula 2 implementation of the SOL-Diagram Read/Yrite RS232
(*
*)
(*
**************************************************************** *)
(*
(* (*
*) *)
C HANG E
(* (* (*
<* (* <*
(*
Date
I Name
L0 G
*)
I Description
*) *)
----------+-------------+------------------------------------ *) I *> ----------+-------------+------------------------------------ *) I *> *)
(************************************************************************) DEFINITION MODULE Linkiwu;
67
definition module
Inter Yorking Unit
68 69 70
FROM SDLM
IMPORT
ProcessiD;
71 72
FROM EbinTypes
IMPORT
PnType, ObjectType, ObjectidType, HlResultType;
FROM IBProc
IMPORT
ObjectinfoType;
(*
73 74 75 76 77
78 79 80 81
PROCEDURE Createid(
Pn VAR Teller VAR Id
link
PnType; INTEGER; Obj ec tidType
);
82
83 84
85 86 87 88 89
PROCEDURE HexToDec( VAR PROCEDURE DecToHex( VAR
Dec Ch1,Ch2,Ch3,Ch4
Obj ec tidType; CHAR
);
PROCEDURE SendMNotify
(
93
94 95 96 97 98 99 100 101 102
CHAR; INTEGER
);
90
91 92
Ch Dec
VAR
Object Objectid Objectinfo Result
);
PROCEDURE ProcessReadRS232; PROCEDURE ProcessLinkiwu; VAR
103
IwuRouter
104 105
END Linkiwu.
ProcessiD;
ObjectType; Obj ec tidType; ObjectinfoType; HlResultType
*)
1
2 3 4 S 6 7 8
(************************************************************************) (* (* (*
10
(* (* (* (*
11
(*
12 13 14 1S 16 17 18 19 20 21 22 23 24 2S 26 27 28 29 30 31 32 33 34 3S 36 37 38 39 40 41 42 43 44 4S 46 47 48 49 SO S1 S2 S3 S4 SS S6 S7 S8
(*
9
s9
60 61 62 63 64 6S 66
PTT NEDERLAND NV PTT Research Dr Neher Laboratories Leidschendam - The Netherlands
(* (*
(* (* (* (*
(* (* (* (* (* (*
Copyright (c) 1991 by PTT NEDERLAND NV All rights strictly reserved. No part of this document may be reproduced in any form or by any means without written permission from the publisher. Alle rechten uitdrukkelijk voorbehouden. Vermenigvuldiging of mededeling aan derden in welke vorm ook, is zonder schriftelijke toestemming van PTT NEDERLAND NV niet geoorloofd.
*) *) *) *) *) *) *) *) *) *) *) *) *) *) *) *) *) *) *) *) *)
(*
**************************************************************** *)
(*
*) *) *)
(* (* (* (* (* (*
(* (* (* (*
AUTHORS CREATION DATE
M.C.M. Peeters 14-7-91
COMPILER SYST.ENVIRONMENT VERSION ERROR CONDITIONSAND HANDLING FILES USED
ACE 68000 of LOGITECH VAX/VMS 1.0
*)
*)
(* (* (* (* (*
(*
*)
*) *) *) *)
(* (* (*
(* (*
*) *) *) *) *)
(* (* (*
(*
*) *)
*) *)
*) *) *)
DESIGN DOCUMENT TESTSPEC'S
ban 91
.0 ID
PROGRAM DESCRIPTION:
modula 2 implementation of the SOL-Diagram Read/Vrite RS232
*) *) *)
(* (*
*) *) *)
(*
**************************************************************** *)
(*
*) *) *) *) *)
(* (* (* (*
(*
<* (* <* (*
C HANGE Date
L0 G
I Name
I Description
----------+-------------+------------------------------------ *) I I *> ----------+-------------+------------------------------------ *) I I *> *)
(************************************************************************) IMPLEMENTATION MODULE Linkiwu;
67
68 69 70
Inter Yorking Unit
(*
link
*)
FROM
SDLM
IMPORT
ProcessiD, SENDER, SELF, SendMessage, ReceiveMessage, Consume, Ignore, PutMemoryElement,State,GetMemoryElement;
FROM
EbinMess
IMPORT
SIGNALS, TypeMessagePtr,MESSAGES, OnOffType,VolumeType,TonesType;
FROM
EbinTypes
IMPORT
PnType,ObjectType,ObjectidType,BcType, AttributeType,AvailableType,NOPN, StateType,UseridType,DeviceType,HlResultType, NOUSERID,TrackType,ToggleType;
FROM
IBProc
IMPORT
ValueType,InquireAttribute,ObjectinfoType, IBCreateObject,IBDeleteObject;
FROM
SYSTEM
IMPORT
SHORTCARD;
FROM
Vrtx:M2
IMPORT
Byte;
FROM
InOutPort3
IMPORT
ReadPort3,YritePort3;
CONST
Userid
71 72
73 74
75 76
77 78 79 80 81 82 83
84 85 86 87 88 89 90 91
=
92
(*
93 94 95
96 97 98 99
*)
VAR
100
101 102 103 104 105 106 107 108 109 110 111 112 113 114
132
Pn VAR Teller VAR Id
INTEGER; PnType; INTEGER; CHAR; ValueType; HlResultType; TypeMessagePtr; ProcessiD; Obj ec t!dType; BcType; ObjectinfoType;
:PnType; :INTEGER; :ObjectidType
);
BEGIN
119
130 131
Teller Pn,Pn1,Pn2 Dec1,Dec2,Dec3,Dec4 Ch,Ch1,Ch2,Ch3,Ch4,Ch5,Ch6 Value,Value1,Value2 Result,Result1,Result2 SaveHessage,MessagePtr Pid Linkid Be Objectinfo
PROCEDURE Createid (
115 116 117 118 120 121 122 123 124 125 126 127 128 129
1;
Eigenid Van de Macintosh waaraa de Inter Yorking Unit is aangesloten
Id
:= ObjectidType((ObjectidType(Teller) + 256*0bjectidType(Pn) )
Teller
:=Teller+1;
END Createid; PROCEDURE Hex:ToDec( VAR );
BEGIN CASE Ch OF "0":Dec:=0; I"1":Dec:=1; I"2":Dec:=2; I"3":Dec:=3;
Ch Dec
:CHAR; :INTEGER
133 134 135 136 137 138 139 140 141 142 143 144 145 146 147 148 149 150 151 152 153 154 155 156 157 158 159 160 161 162 163 164 165 166 167 168 169 170
171 172 173 174 175 176
177 178 179 180 181 182 183 184 185 186 187 188 189 190 191 192 193 194 195 196 197 198
I"4":Dec:=4; I"5":Dec:=5; I"6":Dec:=6; 1"7":Dec:=7; I"8":Dec:=8; I"9":Dec:=9; I"A":Dec:=10; I"B":Dec:=ll; I"C":Dec:=12; I"D":Dec:=13; I"E":Dec:=14; I"F":Dec:=15; ELSE END; (*
CASE
*)
END HexToDec; PROCEDURE DecToHex( VAR
Dec :ObjectidType; Ch1,Ch2,Ch3,Ch4 :CHAR
);
BEGIN IF Dec THEN CASE 0: 11: 12: 13: 14:
< 65516
END;
Dec DIV (16*16*16) OF Ch1:="0"; Ch1:="1"; Ch1:="2"; Ch1:="3"; Ch1:="4"; Ch1:="5"; Ch1:="6"; Ch1:="7"; Ch1:="8"; Ch1:="9"; Ch1:="A"; Ch1:="B"; Ch1:="C"; Ch1:="D"; Ch1:="E"; Ch1:="F"; (* CASE *)
Dec
:=
CASE 0: 11: 2: 3: 4: 5: 6: 7: 8: 9: 10: 12: 13: !14: j15: END;
(Dec DIV (256)) OF Ch2:="0"; Ch2:="1"; Ch2:="2"; Ch2:="3"; Ch2:="4"; Ch2:="5"; Ch2:="6"; Ch2:="7"; Ch2:="8"; Ch2:="9"; Ch2:="A"; Ch2:="B"; Ch2:="C"; Ch2: ="D"; Ch2:="E"; Ch2:="F"; (* CASE *)
Dec
:=
IS:
16: 17: 18: 19: 110: 111: 112: 113: 114: 115:
11:
(Dec MOD (16*16*16))
(Dec MOD (256))
199 200 201 202 203 204 20S 206 207 208 209 210 211 212 213 214 21S 216 217 218 219 220 221 222 223 224 22S 226 227 228 229 230 231 232 233 234 23S 236 237 238 239 240 241 242 243 244 24S 246 247 248 249 2SO 2S1 2S2 2S3 2S4 2SS 2S6 2S7 2S8 2S9 260 261 262 263 264
CASE 0: 11: 12: 13: 14: IS: 16: 18: 19: 110: 111: 112: 113: 114: I1S: END;
(Dec DIV (16)) OF Ch3:="0"; Ch3:="1"; Ch3:="2"; Ch3:="3"; Ch3:="4"; Ch3:="S"; Ch3:="6"; Ch3:="7"; Ch3:="8"; Ch3:="9"; Ch3:="A"; Ch3:="B"; Ch3:="C"; Ch3:="D"; Ch3:="E"; Ch3:="F"; CASE (* *)
Dec
:= (
CASE 0: 11: 12: 13: 14: IS: 16:
Dec OF Ch4:="0"; Ch4:="1"; Ch4:="2"; Ch4:="3"; Ch4:="4"; Ch4:="S"; Ch4:="6"; Ch4:="7"; Ch4:="8"; Ch4:="9"; Ch4:="A"; Ch4:="B"; Ch4:="C"; Ch4:="D"; Ch4:="E"; Ch4:="F"; CASE (*
17:
17:
18: 19: 110: 111: 112: 113: 114: I1S: END; END; END DecToHex;
(*
PROCEDURE SendHNotify
Dec HOD (16)
);
*)
IF
*)
(
Object Objectid Objectinfo Result
VAR
: ObjectType; : Obj ec tidType; : ObjectinfoType; :HlResultType
);
BEGIN 'WritePort3('<');
(*
NOTIFY
'Wri tePort3( 'N'); 'WritePort3('0'); 'Wri tePort3( 'T'); 'WritePort3(','); CASE Object OF Link: 'WritePort3('L'); 'WritePort3('i');
*)
(*
*)
265 266 267 268 269 270 271 272 273 274 275 276 277 278 279 280 281 282 283 284 285 286 287 288 289 290 291 292 293 294 295 296 297 298 299 300 301 302 303 304 305 306 307 308 309 310 311 312 313 314 315 316 317 318 319 320 321 322 323 324 325 326 327 328 329 330
YritePort3(',');
(*
*)
DecToHex(Objectid,Ch1,Ch2,Ch3,Ch4); YritePort3(Ch1); YritePort3(Ch2); YritePort3(Ch3); YritePort3(Ch4); YritePort3(',');
(*
*)
DecToHex(Objectinfo.DestPn1,Ch1,Ch2,Ch3,Ch4); YritePort3(Ch3); YritePort3(Ch4); YritePort3(','); DecToHex(Objectinfo.DestPn2,Ch1,Ch2,Ch3,Ch4); Yri tePort3(Ch3); YritePort3(Ch4); YritePort3(','); DecToHex(Objectinfo.DestPn3,Ch1,Ch2,Ch3,Ch4); YritePort3(Ch3); YritePort3(Ch4); Yri tePort3(','); DecToHex(Objectinfo.DestPn4,Ch1,Ch2,Ch3,Ch4); YritePort3(Ch3); YritePort3(Ch4); YritePort3(','); (*
Bearer Capability
*)
CASE Objectinfo.Bc OF HOAudio: YritePort3('H'); YritePort3('A'); IHOVideo: YritePort3('H'); YritePort3('V'); !Video: YritePort3('V'); YritePort3('i'); END; CASE (* *) (*
Result
YritePort3(','); CASE Result OF SuccessFullCreate YritePort3('S'); YritePort3('F'); YritePort3('C'); jSuccessFullDelete YritePort3('S'); YritePort3('F'); YritePort3('D'); IUnSuccessFullCreate YritePort3('U'); YritePort3('S'); YritePort3('C'); !UnSuccessFullDelete
*) (*
*)
331 332 333 334 335 336 337 338 339 340 341 342 343 344 345 346 347 348 349 350 351 352 353 354 355 356 357 358 359 360 361 362 363 364 365 366 367 368 369 370 371 372 373 374 375 376 377 378 379 380 381 382 383 384 385 386 387 388 389 390 391 392 393 394 395 396
YritePort3('U'); YritePort3('S'); YritePort3('D'); IUnSuccessFullAttach YritePort3('U'); YritePort3('S'); YritePort3('A'); ISuccessFullAttach Yri tePort3(' S'); YritePort3('F'); YritePort3('A'); IUnSuccessFullDetach YritePort3('U'); YritePort3('D'); YritePort3('A'); ISuccessFullDetach YritePort3('S'); YritePort3('D'); YritePort3('A'); END;
(*
CASE
*)
Yri tePort3(',');
(*
*)
(*
*)
(*
*)
(*
*)
CASE Objectinfo.Available OF TRUE :YritePort3('T'); IFALSE :YritePort3('F'); END; CASE (* *) YritePort3(',');
(*
LastUser
*)
CASE Objectinfo.LastUser OF 1:YritePort3('1'); I2:YritePort3('2'); END; CASE (* *) YritePort3(','); Status *) (* CASE Objectinfo.State OF InActive: YritePort3('I'); YritePort3('A'); IActiveOccupied:YritePort3('A'); YritePort3('0'); IActiveFree: END; (* YritePort3('>');
(*
YritePort3('A'); YritePort3('F'); CASE *)
END OF LINK NOTIFY
!LoudSpeaker: YritePort3('L'); YritePort3('s'); YritePort3(',');
*)
DecToHex(Objectid,Ch1,Ch2,Ch3,Ch4);
397 398 399 400 401 402 403 404 405 406 407 408 409 410 411 412 413 414 415 416 417 418 419 420 421 422 423 424 425 426 427 428 429 430 431 432 433 434 435 436 437 438 439 440 441 442 443 444 445 446 447 448 449 450 451 452 453 454 455 456 457 458 459 460 461 462
VritePort3(Ch1); VritePort3(Ch2); VritePort3(Ch3); Vri tePort3(Ch4); VritePort3(',');
(*
(*
Bearer Capability
*)
*)
CASE Objectinfo.Bc OF HQAudio: VritePort3('H'); VritePort3('A'); IHOVideo: VritePort3('H'); VritePort3('V'); IVideo: VritePort3('V'); VritePort3('i'); END; CASE (* *)
(*
Result
*)
VritePort3(',');
(*
*)
(*
*)
CASE Result OF SuccesFull VritePort3('S'); VritePort3('F'); Vri tePort3( 'L'); jSuccessFullChange VritePort3('S'); VritePort3('C'); VritePort3('H'); !UnSuccessFullChange VritePort3('U'); VritePort3('C'); VritePort3('H'); !SuccessFullCreate VritePort3('S'); VritePort3('F'); VritePort3('D'); jUnSuccessFullCreate VritePort3('U'); VritePort3('S'); VritePort3('C'); jUnSuccessFullDelete VritePort3('U'); VritePort3('S'); VritePort3('D'); END; CASE (* *) VritePort3(','); CASE Objectinfo.PowerStatus OF On :VritePort3('A'); :VritePort3('U'); IOff END; CASE (* *)
463 464 465 466 467 468 469 470
YritePort3(',');
*)
DecToHex(ObjectidType(Objectinfo.Volume),Ch1,Ch2,Ch3,Ch4); YritePort3(Ch3); YritePort3(Ch4); YritePort3(','); (* *) DecToHex(ObjectidType{Objectinfo.LowTones),Ch1,Ch2,Ch3,Ch4); YritePort3(Ch3); YritePort3(Ch4); YritePort3(','); (* *)
471 472
473 474 475 476
DecToHex(ObjectidType(Objectinfo.HighTones),Ch1,Ch2,Ch3,Ch4); YritePort3(Ch3); YritePort3(Ch4); YritePort3(','); (* *)
477
478 479 480 481 482 483 484 485 486 487 488 489 490
CASE Objectinfo.Available OF TRUE :YritePort3('T'); IFALSE :YritePort3('F'); END; (* CASE *) YritePort3(',');
(*
(*
LastUser
*)
*)
CASE Objectinfo.LastUser OF NOUSERID :YritePort3('0'); 11 :YritePort3('1'); 12 :YritePort3('2'); END; (* CASE *)
491
492 493 494 495 496 497 498 499 500 501 502 503 504 505 506 507 508 509 510
YritePort3(','); CASE Objectinfo.Pn OF NOPN:YritePort3('0'); 11 :YritePort3('1'); 12 :YritePort3('2'); END; (* CASE
(*
*)
(*
*)
*)
YritePort3(' ,');
(* Status *) CASE Objectinfo.State OF InActive: YritePort3('I'); YritePort3('A'); IActiveOccupied:YritePort3('A'); YritePort3('0');
511
512 513 514 515 516 517 518 519 520 521 522 523 524 525 526 527 528
(*
IActiveFree: END; (* YritePort3('>'); (*
YritePort3('A'); YritePort3('F'); CASE *)
END OF LOUDSPEAKER NOTIFY
ILsPair: !CdPlayer: YritePort3('C'); YritePort3('d'); YritePort3(',');
*)
(*
DecToHex(Objectid,Ch1,Ch2,Ch3,Ch4); YritePort3(Ch1); YritePort3(Ch2);
*)
529 530 531 532 533 534 535 536 537 538 539 540 541 542 543 544 545 546 547 548 549 550 551 552 553 554 555 556 557 558 559 560 561 562 563 564 565 566 567 568 569 570 571 572 573 574 575 576 577 578 579 580 581 582 583 584 585 586 587 588 589 590 591 592 593 594
TJritePort3(Ch3); TJri tePort3(Ch4); TJritePort3(',');
(*
(*
Bearer Capability
*)
*)
CASE Objectinfo.Bc OF HQAudio: TJritePort3('H'); TJritePort3('A'); IHOVideo: lJritePort3('H'); TJritePort3('V'); IVideo: TJritePort3('V'); TJritePort3('i'); END; CASE (* *)
(*
Result
*)
TJritePort3(',');
(*
*)
(*
*)
(*
*)
CASE Result OF SuccesFull lJritePort3('S'); Wri tePort3( 'F'); TJritePort3('L'); ISuccessFullChange lJritePort3('S'); Wri tePort3( 'C'); lJritePort3('H'); IUnSuccessFullChange lJritePort3('U'); TJritePort3('C'); \lri tePort3( 'H'); ISuccessFullCreate TJri tePort3 ( 'S'); lJritePort3('F'); TJritePort3('D'); IUnSuccessFullCreate lJritePort3('U'); lJritePort3('S'); TJritePort3('C'); jUnSuccessFullDelete TJritePort3('U'); TJritePort3('S'); TJritePort3('D'); END; CASE (* *) TJritePort3(','); CASE Objectinfo.Toggle OF Play :lJritePort3('P'); !Stop :TJritePort3('S'); END; CASE (* *) TJritePort3(',');
595 596 597 598 599 600 601 602 603 604 605 606 607 608 609 610 611 612
CASE Objectinfo.Repeat OF On :VritePort3('A'); IOff :VritePort3('U'); END; (* CASE *) Vri tePort3(',');
(*
*)
(*
*)
CASE Objectinfo.Pause OF On :VritePort3('A'); IOff :VritePort3('U'); END; (* CASE *) Vri tePort3(',');
DecToHex(ObjectidType(Objectinfo.Track),Ch1,Ch2,Ch3,Ch4); Vri tePort3(Ch3); VritePort3(Ch4); VritePort3(','); (* *)
613
614 615 616 617 618 619 620 621 622 623 624 625 626 627 628 629 630 631 632 633 634 635 636 637 638 639 640 641 642 643 644 645 646 647 648 649 650 651 652 653 654 655 656 657 658 659 660
DecToHex(ObjectidType(Objectinfo.LowTones),Ch1,Ch2,Ch3,Ch4); VritePort3(Ch3); VritePort3(Ch4); VritePort3(','); (* *) DecToHex(ObjectidType(Objectinfo.HighTones),Ch1,Ch2,Ch3,Ch4); VritePort3(Ch3); VritePort3(Ch4); VritePort3(','); (* *) CASE Objectinfo.Available OF TRUE :VritePort3('T'); IFALSE :VritePort3('F'); END; (* CASE *) VritePort3(','); (*
(*
LastUser
*)
*)
CASE Objectinfo.LastUser OF NOUSERID :VritePort3('0'); 11 :VritePort3('1'); 12 :VritePort3('2'); END; (* CASE *) VritePort3(','); CASE Objectinfo.Pn OF NOPN:VritePort3('0'); 11 :VritePort3('1'); !2 :VritePort3('2'); END; (* CASE
(* Status *) CASE Objectinfo.State OF InActive: VritePort3('I'); VritePort3('A');
IActiveOccupied:VritePort3('A'); VritePort3('0');
END; (* VritePort3('>');
*)
(*
*)
*)
VritePort3(',');
IActiveFree:
(*
VritePort3('A'); VritePort3('F'); CASE *)
661 662 663 664 665 666 667 668 669 670 671 672 673 674 675 676 677 678 679 680 681 682 683 684 685 686 687 688 689 690 691 692 693 694 695 696 697 698 699 700 701 702 703 704 705 706 707 708 709 710 711 712 713 714 715 716 717 718 719 720 721 722 723 724 725 726
(*
END OF CD PLAYER NOTIFY *)
IHicroPhone: !Camera: !Monitor: VritePort3('H'); VritePort3('o'); VritePort3(',');
(*
*)
DecToHex(Objectld,Ch1,Ch2,Ch3,Ch4); VritePort3(Ch1); VritePort3(Ch2); VritePort3(Ch3); VritePort3(Ch4); VritePort3(' ,'); (*
(*
Bearer Capability
*)
*)
CASE Objectlnfo.Bc OF HQAudio: VritePort3('H'); VritePort3('A'); IHOVideo: VritePort3('H'); VritePort3('V'); !Video: VritePort3('V'); VritePort3('i'); CASE END; (* *) (*
Result
*)
VritePort3(',');
(*
*)
(*
*)
CASE Result OF SuccesPull VritePort3('S'); Vri tePort3(' F'); · VritePort3('L'); ISuccessFullDelete VritePort3('S'); VritePort3('F'); VritePort3('D'); IUnSuccessFullCreate VritePort3('U'); VritePort3('S'); VritePort3('C'); IUnSuccessFullDelete VritePort3('U'); VritePort3('S'); VritePort3('D'); END; CASE (* *) VritePort3(','); CASE Objectlnfo.Available OF TRUE :VritePort3('T'); IFALSE :VritePort3('F'); END; (* CASE *)
727 728
YritePort3(',');
729 730 731 732 733 734 735 736 737 738 739 740 741 742 743 744 745 746 747 748 749 750 751 752 753 754 755 756 757 758 759 760 761 762 763 764 765 766 767 768 769 770 771 772 773 774 775 776 777 778 779 780 781 782 783 784 785 786 787 788
(*
(*
LastUser
*)
*)
CASE Objectinfo.LastUser OF NOUSERID :YritePort3('0'); 11 :YritePort3('1'); 12 :YritePort3('2'); END; (* CASE *) YritePort3(','); CASE Objectinfo.Pn OF NOPN:YritePort3('0'); 11 :YritePort3('1'); 12 :YritePort3('2'); END; (* CASE
(*
*)
(*
*)
*)
YritePort3(','); Status *) (* CASE Objectinfo.State OF InActive: YritePort3('I'); YritePort3('A'); IActiveOccupied:YritePort3('A'); YritePort3('0'); IActiveFree: END; (* Yri tePort3( '>');
YritePort3('A'); YritePort3('F'); CASE *)
(*
END OF MONITOR NOTIFY
END;
(*
CASE
*)
*)
END SendMNotify; PROCEDURE ReadObjectid(VAR Val:ValueType); VAR Cha,Chb,Chc,Chd CHAR; Decl,Dec2,Dec3,Dec4 INTEGER; BEGIN ReadPort3(Cha); ReadPort3(Chb); ReadPort3(Chc); ReadPort3(Chd); HexToDec(Cha,Decl); HexToDec(Chb,Dec2); HexToDec(Chc,Dec3); HexToDec(Chd,Dec4); Val
:= (
( Deel * 16*16*16) ( Dec2 * 256) + ( Dec3 * 16) + Dec4 );
+
END ReadObjectid; PROCEDURE ProcessReadRS232;
789
TYPE
Stat es
790 791 792
VAR
NextState
=
(YaitForRS232Message); States;
793 794 795 796 797 798 799 800 801 802 803 804 805 806 807 808 809 810 811
BEGIN (*
Initialiaeren van de Teller per Userinterface
Teller
:=1;
(*
Initiele waarde voor Ch, hetgeen schijnbaar nodig is voor de goede werking van de Module InOutPort3 en de daarin gedefinieerde modules
*)
*) Ch
:='I';
(*
Inlezen van berichten van de RS 232 poort
*)
(*
Dit is een vast gegeven voor de Interworking Unit
*)
Userid komt overeen met Eigenid
(*
*)
812 813
814 815 816 817 818 819 820 821 822 823 824 825 826 827 828 829 830 831 832 833 834 835 836 837 838 839 840 841 842 843 844 845 846 847 848 849 850 851 852 853 854 855 856 857 858
NextState := YaitForRS232Message; State('MRS232'); LOOP ReadPort3(Ch);
(*
TEST
*)
State('Daaaag');
(*
TEST
*)
IF Ch = '<' THEN GetMemoryElement(MESSAGES,MessagePtr); MessagePtrA.LastUser:=Userid; ReadPort3(Ch1); CASE Ch1 OF 'C':ReadPort3(Ch); CASE Ch OF 'RI :
MessagePtr".Signal:=CREATE; ReadPort3(Ch);(* , *) ReadPort3(Ch); (*
Object
*)
CASE Ch OF 'L':ReadPort3(Ch); CASE Ch OF , i, :
MessagePtr".Object:=Link; ReadPort3(Ch);(* , *) (*
Ik verwacht nu een objectid de is van het type SHORTCARD Aan Mac zijde is deze in twee Bytes gesplits die als CHAR verzonden zijn. In de IYU moet de Objectid nu weer als zijnde een SHORTCARD worden samen Gesteld
*)
ReadObjectid(Value); MessagePtrA.Objectid:=ObjectidType(Value); ReadPort3(Ch);(* , *) (*
Originating Partynumbeer
ReadObjectid(Value); MessagePtr".OrigPn:=PnType(Value); ReadPort3(Ch);(* ,*)
*)
859 860 861 862 863 864 865 866 867 868 869 870 871 872
873 874 875 876 877
878 879 880 881 882 883 884 885 886 887 888 889 890 891 892
893 894 895 896 897 898 899 900 901 902 903 904 905 906 907 908 909 910 911 912 913 914 915 916 917 918 919 920 921 922
923 924
(*
Originating Partynumbeer
*)
ReadObjectid(Value); MessagePtr~.DestPn1:=PnType(Value);
ReadPort3(Ch);
(* , *)
(* BearerCapability*) ReadPort3(Ch); CASE Ch OF 'A':
(*Speech, Audio3Khz, Audio7Khz etc is hier nog niet meegenomen *) MessagePtrA.Bc:=HQAudio; I'V': (*Video etc is hier nog niet mee genomen *) MessagePtrA.Bc:=HOVideo; END; (* CASE *) ReadPort3(Ch);(* > *)
END; (* CASE END; (* CASE I , H, : ( * CHANGE*) State('Change');
*) *)
MessagePtr~.Signal:=CHANGE;
ReadPort3(Ch);
(*
, *)
(*
TEST
*)
(* (*
TEST Object
*) *)
ReadPort3(Ch);
CASE Ch OF 'L':ReadPort3(Ch2); CASE Ch2 OF , i, :
I , s, : I , C' :
MessagePtr~.Object:=Link;
State('loudSp'); MessagePtrA.Object:=LoudSpeaker; END; (*CASE *) ReadPort3(Ch2); CASE Ch2 OF f
dI :
State('CDPlay'); MessagePtr~.Object:=CdPlayer;
(*
I' a, :
CDPLAYER
*)
MessagePtr~.Object:=Camera;
I, w:
(* (*
END;
Camera CASE
*) *)
ReadPort3(Ch); CASE Ch OF I
i '
!
I' o' :
MessagePtrA.Object:=MicroPhone; (* Microfoon
*)
MessagePtr~.Object:=Monitor;
Monitor *) (* CASE *) (* CASE *) (* , *) (* Objectid (*
END; END; ReadPort3(Ch); ReadObjectid(Value);
*)
925 926 927 928 929 930 931 932 933 934 935 936 937 938 939 940 941 942 943 944 945 946 947 948 949 950 951 952 953 954 955 956 957 958 959 960 961 962 963 964 965 966 967 968 969 970
MessagePtr".Objeetid:=ObjeetidType(Value); (* , *) ReadPort3(Ch); (* Attribute ReadPort3(Ch5); State('GetAtt'); CASE ChS OF , p, :
State('Attrib'); ReadPort3(Ch6); CASE Ch6 OF '1, : MessagePtr".Attribute:=AttrDestPnl; ReadPort3(Ch); (* ReadPort3(Chl); ReadPort3(Ch2); IF ((Chl='N') AND (Ch2='P')) THEN MessagePtr".Pn:=NOPN; ELSE HexToDee(Chl,Deel); HexToDee(Ch2,Dee2); MessagePtr".Pn:=PnType( ( Deel * 16) + ( Dee2 ) ); END; (* IF
I,2
*)
*)
I :
I 3' :
MessagePtr".Attribute:=AttrDestPn2; ReadPort3(Ch); (* ReadPort3(Chl); ReadPort3(Ch2); IF ((Chl='N') AND (Ch2='P')) THEN MessagePtr".Pn:=NOPN; ELSE HexToDee(Chl,Deel); HexToDee(Ch2,Dee2); MessagePtr".Pn:=PnType( ( Deel * 16) + ( Dee2 ) ); END; (* IF
*)
*)
I
971 972
973 974 975 976 977
978 979 980 981 982 983 984 985 986 987 988 989 990
*)
I , 4' :
MessagePtr".Attribute:=AttrDestPn3; ReadPort3(Ch); (* ReadPort3(Chl); ReadPort3(Ch2); IF ((Chl='N') AND (Ch2='P')) THEN MessagePtr".Pn:=NOPN; ELSE HexToDee(Chl,Deel); HexToDee(Ch2,Dee2); MessagePtr".Pn:=PnType( ( Deel * 16) + ( Dee2 ) ); END; (* IF MessagePtr".Attribute:=AttrDestPn4; ReadPort3(Ch); (* ReadPort3(Chl); ReadPort3(Ch2); IF ((Chl='N') AND (Ch2='P')) THEN MessagePtr".Pn:=NOPN; ELSE HexToDee(Chl,Deel); HexToDee(Ch2,Dee2);
*)
*)
*)
991 992 993 994 995 996 997 998 999 1000 1001 1002 1003 1004 1005 1006 1007 1008 1009 1010 1011 1012 1013 1014 1015 1016 1017 1018 1019 1020 1021 1022 1023 1024 1025 1026 1027 1028 1029 1030 1031 1032 1033 1034 1035 1036 1037 1038 1039 1040 1041 1042 1043 1044 1045 1046 1047 1048 1049 1050 1051 1052 1053 1054 1055 1056
I' o' :
I 'a' :
MessagePtrA.Pn:=PnType( ( Deel * 16) ( Dee2 ) END;
+
);
(* IF
*)
MessagePtrA.Attribute:=AttrPowerStatus; ReadPort3(Ch); (* *) ReadPort3(Ch6); CASE Ch6 OF 'A': (* ON *) MessagePtrA.PowerStatus:=On; I 'u' : (* OFF *) MessagePtrA.PowerStatus:=Off; END; (* CASE *) MessagePtrA.Attribute:=AttrPause; ReadPort3(Ch); (* *) ReadPort3(Ch6); CASE Ch6 OF I
(~
A':
I , U' :
MessagePtrA.Pause:=On; (*
OFF *)
(* (*
CASE *) CASE *)
MessagePtrA.Pause:=Off; END; END;
I 'B, : ReadPort3(Ch6); CASE Ch6 OF
'e, :
I , a,: END;
I , s, :
MessagePtrA.Attribute:=AttrBe; MessagePtrA.Attribute:=AttrBalanee; (* CASE *)
ReadPort3(Ch6); CASE Ch6 OF , a, : MessagePtrA.Attribute:=AttrState; I , e': MessagePtr".Attribute:=AttrServiee; END; (* CASE *)
I , T' :
ReadPort3(Ch3); CASE Ch3 OF , r, : State('TRACKS'); MessagePtrA.Attribute:=AttrTraek; ReadPort3(Ch); (* *) ReadPort3(Chl); ReadPort3(Ch2); HexToDee(Chl,Deel); HexToDee(Ch2,Dee2); MessagePtrA.Traek:=TraekType( ( Deel * 16) + ( Dee2 ) ); I , o, : MessagePtr•.Attribute:=AttrToggle; ReadPort3(Ch); (* *) ReadPort3(Ch6); CASE Ch6 OF 'P': (* Play *) MessagePtrA.Toggle:= Play; I'S': (* Stop *) MessagePtrA.Toggle:= Stop; END; (* CASE *)
ON *)
1057 1058 1059 1060 1061 1062 1063 1064 1065 1066 1067 1068 1069 1070 1071 1072 1073 1074 1075 1076 1077 1078 1079 1080 1081 1082 1083 1084 1085 1086 1087 1088 1089 1090 1091 1092 1093 1094 1095 1096 1097 1098 1099 1100 1101 1102 1103 1104 1105 1106 1107 1108 1109 1110 1111 1112 1113 1114 1115 1116 1117 1118 1119 1120 1121 1122
END;
CASE
*)
ReadPort3(Ch); (* ReadPort3(Chl); ReadPort3(Ch2); HexToDee(Chl,Deel); HexToDee(Ch2,Dee2); MessagePtr·.LowTones:=TonesType( ( Deel * 16) ( Dee2 )
*)
(*
I , L' :
ReadPort3(Ch3); CASE Ch3 OF , a, :
I , s, : I , o, :
MessagePtr~.Attribute:=AttrLastUser; MessagePtr~.Attribute:=AttrLsPairid; MessagePtr~.Attribute:=AttrLowTones;
I , e' :
+
);
MessagePtr •. Attribute:=AttrLeftLsid; END;
(*
I , R, :
CASE
*)
ReadPort3(Ch3); CASE Ch3 OF , o' :
I,i
MessagePtr•.Attribute:=AttrRoom; I :
I , e' :
I , Z' :
I' H' :
MessagePtr".Attribute:=AttrRightLsid;
State('REPEAT'); MessagePtr".Attribute:=AttrRepeat; ReadPort3(Ch); (* ReadPort3(Ch4); CASE Ch4 OF , A' : (* ON *) MessagePtr·.Repeat:=On; I , U' : (* OFF *) MessagePtr-.Repeat:=Off; END; (* CASE *) END; (* CASE *) ReadPort3(Ch6); CASE Ch6 OF , o' : MessagePtr •• Attribute:=AttrZoom; END; (* CASE *) ReadPort3(Ch6); CASE Ch6 OF I
I 'V' :
*)
i
I :
MessagePtr".Attribute:=AttrHighTones; ReadPort3(Ch); (* ReadPort3(Chl); ReadPort3(Ch2); HexToDee(Chl,Deel); HexToDee(Ch2,Dee2); MessagePtr •• HighTones:=TonesType( ( Deel * 16) ( Dee2 ) END; (* CASE *) ReadPort3(Ch6); CASE Ch6 OF I
0
I
!
State('VOLUHE'); MessagePtr".Attribute:=AttrVolume;
*
+
1123 1124 1125 1126 1127 1128 1129 1130 1131 1132 1133 1134 1135 1136 1137 1138 1139 1140 1141 1142 1143 1144 1145 1146 1147 1148 1149 1150 1151 1152 1153 1154 1155 1156 1157 1158 1159 1160 1161 1162 1163 1164 1165 1166 1167 1168 1169 1170 1171 1172 1173 1174 1175 1176 1177 1178 1179 1180 1181 1182 1183 1184 1185 1186 1187 1188
ReadPort3(Ch); ReadPort3(Ch1); ReadPort3(Ch2); HexToDec(Ch1,Dec1); HexToDec(Ch2,Dec2);
(*
MessagePtr~.Volume:=VolumeType(
END;
I , L' :
END; ReadPort3(Ch)
( Deel * 16) ( Dec2 ) (* CASE *) (* CASE *) (* (* (*
END;
I' D' :ReadPort3(Ch);
*)
CLAIM
>
CASE
MessagePtr~.Signal:=DELETE;
(* (*
CASE Ch6 OF 'L':ReadPort3(Ch); CASE Ch OF
'
*)
Object
*)
CASE
*)
CASE
*)
, i, :
I , sI :
MessagePtr~.Object:=Link;
MessagePtr~.Object:=LoudSpeaker;
END; I'C':ReadPort3(Ch); CASE Ch OF
(*
, d, :
I , a, :
MessagePtr~.Object:=CdPlayer;
MessagePtr·.object:=Camera; END;
(*
I'M':ReadPort3(Ch); CASE Ch OF I
i
I :
I , o' :
MessagePtr·.object:=MicroPhone;
MessagePtr·.object:=Monitor; (* CASE *) END; (* CASE *) Ik verwacht nu een object!d deze is van het type SHORTCARD Aan Mac zijde is deze in twee Bytes gesplits die als CHAR verzonden zijn. In de !VU moet de Object!d nu weer als zijnde een SHORTCARD worden samen Gesteld END;
(*
*)
(* Object!d (* , *)
ReadPort3(Ch); ReadObjectid(Value);
*)
MessagePtr~.Objectid:=Object!dType(Value);
(* > *)
ReadPort3(Ch); END;
(* MDELETE
I'U':ReadPort3(Ch);(* UNCLAIH, UPDATE *) END; (* VAlT FOR PEER TO PEER (* State('VStart'); (* (*
CASE
Het Peer to peer bericht is in deze Module gecreeerd *) *) ReceiveHessage(MessagePtr);
CASE *) *)
) *);
*)
CASE Ch OF 'E': (* DELETE *) ReadPort3(Ch6);
+
*)
*)
1189 1190 1191 1192 1193 1194 1195 1196 1197 1198 1199 1200 1201 1202 1203 1204 1205 1206 1207 1208 1209 1210 1211 1212 1213 1214 1215 1216 1217 1218 1219 1220 1221 1222 1223 1224 1225 1226 1227 1228 1229 1230 1231 1232 1233 1234 1235 1236 1237 1238 1239 1240 1241 1242 1243 1244 1245 1246 1247 1248 1249 1250 1251 1252 1253 1254
CASE MessagePtr·.signal OF CREATE: State('Create');
(*
TEST
*)
CASE HessagePtr·.object OF Link: State('ObLink'); (* TEST *) HessagePtr·.LastUser == Userld; State('SendHe'); SendHessage('CREATE',MessagePtr,IwuRouter); NextState == WaitForRS232Message State('WtFNot'); END; (* CASE *); ICHANGE: State('CHANGE'); SendHessage('CHANGE',HessagePtr,IwuRouter); NextState :=WaitForRS232Hessage; State('VtFNot'); IDELETE: VITH MessagePtr· DO InquireAttribute(Object,Objectid, AttrLastUser,Value,Result1); END; (* VITH *) IF (UseridType(Value) = Userld) THEN MessagePtr·.signal ::DELETE; SendHessage('DELETE',MessagePtr,IwuRouter); NextState ==VaitForRS232Hessage; State('VtFNot'); ELSE Objectinfo.InputObject
==
HessagePtr·.rnputObject; Objectlnfo.InputObjectld == HessagePtr·.rnputObjectid; Objectlnfo.OutputObject := HessagePtr·.outputObject; Objectlnfo.OutputObjectld := MessagePtr·.outputObjectld; Objectinfo.Bc == HessagePtr·.Bc; Objectinfo.LastUser != HessagePtr·.LastUser; Objectlnfo.Available := FALSE; Objectlnfo.State == ActiveOccupied; SendHNotify(
(*
*)
NextState ·State('UNSucc'); END; (* IF *) ELSE END; (*
VaitForRS232Hessage;
Ignore; PutHemoryElement(MESSAGES,HessagePtr); State('Ignore'); CASE *)
ELSE END; (* END; (*
Link, MessagePtr·.objectid, Objectlnfo, UnSuccessFullDelete);
State('<expec'); IF *) LOOP *)
1255 1256 1257 1258 1259 1260 1261 1262 1263 1264 1265 1266 1267 1268 1269 1270 1271 1272 1273 1274 1275 1276 1277 1278 1279 1280 1281 1282 1283 1284 1285 1286 1287 1288 1289 1290 1291 1292 1293 1294 1295 1296 ·1297 1298 1299 1300 1301 1302 1303 1304 1305 1306 1307 1308 1309 1310 1311 1312 1313 1314 1315 1316 1317 1318 1319 1320
END ProcessReadRS232; PROCEDURE ProcessLinkiwu; TYPE
Stat es
VAR
NextState
=
(YaitForPeerToPeer); States;
BEGIN State('NextSt'); NextState :=
YaitForPeerToPeer;
LOOP State('YaitMe'); ReceiveMessage(MessagePtr); CASE MessagePtrA.Signal OF NOTIFY: CASE MessagePtrA.Object OF Link: Consume; CASE MessagePtrA.HlResult OF SuccessFullCreate,SuccessFullAttach: YITH MessagePtrA DO Objectinfo.OrigPn Objectinfo.DestPn1 Objectinfo.DestPn2 Objectinfo.DestPn3 Objectinfo.DestPn4 Object!nfo.Bc Objectinfo.LastUser Object!nfo.Available Objectinfo. State
:=OrigPn; :=DestPn1; ==DestPn2; :=DestPn3; :=DestPn4; :=Be; :=LastUser; := FALSE; == ActiveOccupied;
END; (* YITH *) SendMNotify( Link,MessagePtrA.Objectid,Objectinfo, MessagePtrA.HlResult); NextState State('Sucess');
:=
ISuccessFullDelete: YITH MessagePtrA DO Objectinfo.OrigPn Objectinfo.DestPn1 Objectinfo.DestPn2 Objectlnfo.DestPn3 Objectinfo.DestPn4 Objectlnfo.Bc Objectinfo.LastUser Objectinfo.Available Objectlnfo.State END; (* YITH *) SendMNotify( NextState State('Sucess');
YaitForPeerToPeer;
:=OrigPn; ==DestPn1; :=DestPn2; :=DestPn3; :=DestPn4; :=Be; ==LastUser; :=TRUE; :=ActiveOccupied;
Link,MessagePtrA.Objectld,Objectinfo, SuccessFullDelete); :=
YaitForPeerToPeer;
(* Result == HessagePtrA.HlResult *) IUnSuccessFullCreate: IF (MessagePtrA.LastUser = Userld)
1321 1322 1323 1324 1325 1326 1327 1328 1329 1330 1331 1332 1333 1334 1335 1336 1337 1338 1339 1340 1341 1342 1343 1344 1345 1346 1347 1348 1349 1350 1351 1352 1353 1354 1355 1356 1357 1358 1359 1360 1361 1362 1363 1364 1365 1366 1367 1368 1369 1370 1371 1372 1373 1374 1375 1376 1377 1378 1379 1380 1381 1382 1383 1384 1385 1386
THEN VITH MessagePtrA DO Objectinfo.OrigPn Objectinfo.DestPn1 Objectinfo.DestPn2 Objectinfo.DestPn3 Objectinfo.DestPn4 Objectinfo. Be Objectinfo.LastUser Objectinfo.Available Objectinfo.State END;
(*
SendMNotify(
VITH
:=OrigPn; :=DestPn1; :=DestPn2; :=DestPn3; :=DestPn4;
:=Be;
: =LastUser; :=TRUE; :=ActiveOccupied;
*)
Link,MessagePtrA.Objectid,Objectinfo, UnSuccessFullCreate);
NextState := VaitForPeerToPeer; State('Sucess'); END; (* IF *) END; (* CASE *) IMonitor: CASE MessagePtrA.HlResult OF SuccesFull: Consume; Objectinfo.PowerStatus:=MessagePtrA.PowerStatus; Objectinfo.State:=MessagePtrA.State; Objectinfo.Pn:=MessagePtrA.Pn; Objectinfo.Bc:=MessagePtrA.Bc; Objectinfo.LastUser:=MessagePtrA.LastUser; Objectinfo.Service:=MessagePtrA.Service; Objectinfo.Serviceid:=MessagePtrA.Serviceid; Objectinfo.Linkid:=MessagePtrA.Linkid; Objectinfo.Room:=MessagePtrA.Room; Objectinfo.Available:=MessagePtrA.Available; SendMNotify(
Monitor,MessagePtrA.Objectid,Objectinfo, SuccesFull);
PutMemoryElement(MESSAGES,MessagePtr); NextState == VaitForPeerToPeer; END; (* CASE *) !LoudSpeaker: Consume; Objectinfo.PowerStatus:=MessagePtrA.PowerStatus; Objectinfo.State:-MessagePtrA.State; Objectinfo.Pn:=MessagePtrA.Pn; Objectinfo.Bc:=MessagePtrA.Bc; Objectinfo.Volume:=MessagePtrA.Volume; Objectinfo.HighTones:=MessagePtrA.HighTones; Objectinfo.LowTones:=MessagePtrA.LowTones; Objectinfo.LastUser:=MessagePtrA.LastUser; Objectinfo.Service:=MessagePtrA.Service; Objectinfo.Serviceid:=MessagePtrA.Serviceid; Objectinfo.Linkid:=MessagePtrA.Linkid; Objectinfo.Room:=MessagePtrA.Room; Objectinfo.Available:=MessagePtrA.Available; SendMNotify(
LoudSpeaker,MessagePtrA.Objectid,Objectinfo, MessagePtrA.HlResult);
PutMemoryElement(MESSAGES,MessagePtr); NextState := VaitForPeerToPeer;
1387 1388 1389 1390 1391 1392 1393 1394 1395 1396 1397 1398 1399 1400 1401 1402 1403 1404 1405 1406 1407 1408 1409 1410 1411 1412 1413 1414 1415 1416 1417
ICdPlayer: Consume; Objectinfo.LsPairid:=HessagePtr".LsPairid; Objectinfo.State:=HessagePtr".State; Objectinfo.Pn:=HessagePtr".Pn; Objectinfo.Bc:=HessagePtr".Bc; Objectinfo.Repeat:= HessagePtr".Repeat; Objectinfo.Track:=HessagePtr".Track; Objectinfo.Toggle:=HessagePtr".Toggle; Objectinfo.Pause:=HessagePtr".Pause; Objectinfo.LastUser:=HessagePtr".LastUser; Objectinfo.Service:=HessagePtr".Service; Objectinfo.Serviceid:=HessagePtr".Serviceid; Objectinfo.Linkid:=HessagePtr".Linkid; Objectinfo.Room:=HessagePtr".Room; Objectinfo.Available:=MessagePtr".Available; SendMNotify(
CdPlayer,MessagePtr".Objectid,Objectinfo, HessagePtr".HlResult);
PutMemoryElement(MESSAGES,MessagePtr); NextState == VaitForPeerToPeer; END; (* CASE *) ELSE Ignore; PutMemoryElement(MESSAGES,MessagePtr); State('Ignore'); END; (* CASE *) END; (* LOOP*) END ProcessLinkiwu; END Linkiwu.
1 2
3 4 5 6 7 8 9
10 11 12
(************************************************************************) (* (*
*) *)
(* (* (*
PTT NEDERLAND NV PTT Research Dr Neher Laboratories Leidschendam - The Netherlands
(* (* (* (* (* (*
Copyright (c) 1991 by PTT NEDERLAND NV
*) *) *) *) *) *) *) *)
13 14 15 16 17 18 19 20
(*
21 22
(* (*
*) *)
23
(*
**************************************************************** *)
(* (* (* (* (* (* (* (*
*) *) *) *) *) *) *) *)
24 25
26 27 28
29 30 31 32 33 34 35 36
37 38 39
40 41 42
43 44 45
46 47 48 49 50 51 52
53 54
55 56 57
(* (* (* (*
(* (*
(*
(* (*
(*
All rights strictly reserved. No part of this document may be reproduced in any form or by any means without written permission from the publisher.
*)
Alle rechten uitdrukkelijk voorbehouden. Vermenigvuldiging of mededeling aan derden in welke vorm ook, is zonder schriftelijke toestemming van PTT NEDERLAND NV niet geoorloofd.
AUTHORS CREATION DATE
M.C.M. Peeters 14-7-91
COMPILER SYST.ENVIRONMENT VERSION ERROR CONDITIONSAND HANDLING FILES USED
ACE 68000 of LOGITECH VAX/VHS 1.0
*) *)
*)
*)
*) *) *) *) *) *) *) *) *) *) *) *)
DESIGN DOCUMENT TESTSPEC'S
ban 91
.0 ID
PROGRAM DESCRIPTION:
modula 2 Definition of the SOL-Diagram TeHandler
(*
(* (*
*) *) *) *)
*)
(* (* {* {* {* (* (* (* (* (* (*
(* (*
*)
*) *) *)
*) *)
(*
*)
(*
**************************************************************** *)
(* (* (* (*
*) *) *) *)
(*
C HANGE Date
I Name
L0 G
I Description
----------+-------------+-----------------------------------I I ----------+-------------+------------------------------------
*)
58 59
(*
60 61 62
(*
63
(************************************************************************)
64 65 66
<*
<*
I
(*
DEFINITION MODULE TeHand;
I
*)
*) *)
*>
*)
67 (*
definition module
Terminal
FROM
SDLM
IMPORT
ProcessiD, SENDER, SendMessage, ReceiveMessage, Consume, Ignore, PutMemoryElement;
FROM
EbinMess
IMPORT
SIGNALS;
76 77
FROM
EbinTypes
IMPORT
PnType, BcType, ObjectidType;
78
PROCEDURE ProcessTeHand;
79 80 81
VAR
68 69 70 71 72
Handler
73 74
75
82
83
END TeHand.
EqCola TeHandRouter
ProcessiD; ProcessiD;
*)
1
2 3 4 S 6 7 8 9
10 11
12 13 14 1S 16 17 18 19 20 21 22 23 24 2S 26 27 28 29 30 31 32 33 34 3S 36 37 38 39 40 41 42 43 44 4S 46 47 48 49 SO S1 S2 S3 S4 SS S6 S7 S8 s9
60 61 62 63 64 6S 66
(************************************************************************)
(*
*)
(* (* (*
*)
PTT NEDERLAND NV PTT Research Dr Neher Laboratories Leidschendam - The Netherlands
(* (* (* (* (* (*
Copyright (c) 1991 by PTT NEDERLAND NV
(*
(* (*
(* (* (* (* (*
(* (* (*
(*
(* (* (*
(*
*)
All rights strictly reserved. No part of this document may be reproduced in any form or by any means without written permission from the publisher. Alle rechten uitdrukkelijk voorbehouden. Vermenigvuldiging of mededeling aan derden in welke vorm ook, is zonder schriftelijke toestemming van PTT NEDERLAND NV niet geoorloofd.
(*
(* (* (* (*
*) *)
*) *) *) *) *)
*) *) *)
**************************************************************** *) AUTHORS CREATION DATE
M.C.M. Peeters 14-7-91
COMPILER SYST.ENVIRONMENT VERSION ERROR CONDITIONSAND HANDLING FILES USED
ACE 68000 of LOGITECH VAX/VMS 1.0
*) *) *)
*) *)
(*
(* (* (* (*
*) *) *) *) *) *) *) *)
*) *) *) *)
*) *) *) *) *)
(*
*)
(* (*
*) *)
(*
*)
(*
*)
(* (* (*
*) *)
(* (* (* (*
(* (*
(* (* (* (* (*
(* (*
<* (* <* (*
DESIGN DOCUMENT TESTSPEC'S
ban 91
.0 ID
PROGRAM DESCRIPTION:
modula 2 Implementaion module of the SOL-Diagram TeHandler
*) *) *) *) *)
*) *)
**************************************************************** *)
*) *)
C HANG E
Date
L0 G
I Name
I Description
*) *)
*)
----------+-------------+------------------------------------ *) I I *> ----------+-------------+------------------------------------ *) I *> *)
(************************************************************************)
IMPLEMENTATION MODULE TeHand;
67 68 69 70
(*
definition module
FROM
SDLM
IMPORT
ProcessiD, SENDER, SendMessage, ReceiveMessage, Consume, Ignore, PutMemoryElement,State,GetMemoryElement;
FROM
IBProc
IMPORT
ObjectinfoType,IBChangeAttribute, IBGetObjectinfo,ValueType;
FROM
EbinMess
IMPORT
SIGNALS,ObjectType,AttributeType,UseridType, TypeMessagePtr,MESSAGES;
FROM
EbinTypes
IMPORT
PnType, BcType, ObjectidType,HlResultType,NOPN, ToggleType,NOUSERID,StateType,VolumeType;
FROM
ColaRcS
IMPORT
ColaToRcS;
FROM
ColaMes
IMPORT
Cola;
87
VAR
88 89 90 91 92 93
MessagePtr Value
PROCEDURE ProcessTeHand;
71 72
TE
Handler
*)
73 74
75 76 77 78
79 80 81 82 83 84 85 86
TYPE
Stat es DifType
VAR
Objectinfo NextState Result ColaMessage Dif
94
95 96 97 98 99 100 101 102 103 104 105 106 107 108 109 110 111 112
TypeMessagePtr; ValueType;
=
(VaitForPeerToPeerMessage); [-255 •• 255]; ObjectinfoType; States; HlResultType; Cola; DifType;
BEGIN NextState := VaitForPeerToPeerMessage; GetMemoryElement(MESSAGES,MessagePtr); State('NOTIFY'); LoudSpeaker, IBGetObjectinfo( 1, Objectinfo, Re sult );
:=LoudSpeaker;
113 114
MessagePtr~.Object
115
MessagePtr·.signal := NOTIFY; MessagePtr".DestPn := NOPN; MessagePtrA.PowerStatus == Objectinfo.PowerStatus; MessagePtr~.State == Objectinfo.State; MessagePtr".LastUser := Objectinfo.LastUser; MessagePtr".Pn := Objectinfo.Pn; MessagePtr".Bc := Objectinfo.Bc; MessagePtrA.Service := Objectinfo.Service; MessagePtr".Serviceid := Objectinfo.Serviceid; MessagePtr".Volume := Objectinfo.Volume; MessagePtr~.LowTones := Objectinfo.LowTones; MessagePtr".HighTones := Objectinfo.HighTones; MessagePtr".Linkid := Objectinfo.Linkid; MessagePtr·.Room := Objectinfo.Room; MessagePtr".LsPairid := Objectinfo.LsPairid; MessagePtr".Available := Objectinfo.Available; MessagePtr".HlResult :=SuccesFull;
116 117 118 119 120 121 122 123 124 125 126 127 128 129 130 131
132
MessagePtr~.Objectid
133 134 135 136 137 138 139 140 141 142 143 144 145 146 147 148 149 150 151 152 153 154 155 156 157 158 159 160 161 162 163 164 165 166 167 168 169 170 171 172 173 174 175
176 177 178 179 180 181 182 183 184 185 186 187 188 189 190 191 192 193 194 195 196 197 198
SendMessage('NOTIFY',MessagePtr,TeHanqRouter);
GetMemoryElement(MESSAGES,MessagePtr); State('NOTIFY'); IBGetObjectinfo( CdPlayer, 2, Obj ec t!nfo, Result );
MessagePtr·.object MessagePtr·.objectid MessagePtr·.signal MessagePtr·.oestPn MessagePtr·.state MessagePtr·.LastUser MessagePtr·.Pn MessagePtr·.Bc MessagePtr·.Track MessagePtr·.Toggle MessagePtr·.Pause MessagePtr·.PowerStatus MessagePtr·.Repeat MessagePtr·.service MessagePtr·.serviceid MessagePtr •• Linkid MessagePtr·.Room MessagePtr·.LsPairid MessagePtr·.Available MessagePtr .. HlResult
:=CdPlayer; := NOTIFY; := NOPN; := Objectinfo.State; == Objectinfo.LastUser; := Objectinfo.Pn; := Objectinfo.Bc; == Objectinfo.Track; := Objectinfo.Toggle; == Object!nfo.Pause; := Objectinfo.PowerStatus; == Object!nfo.Repeat; == Objectinfo.Service; := Objectinfo.Serviceid; == Objectinfo.Linkid; == Object!nfo.Room; == Objectinfo.LsPairid; == Object!nfo.Available; :=SuccesFull;
SendMessage('NOTIFY',MessagePtr,TeHandRouter); State ('VStart'); LOOP ReceiveMessage(MessagePtr); CASE MessagePtr·.signal OF CHANGE : CASE MessagePtr".Object OF
(*
TE
Handler
*)
CdPlayer
(* Aan iedere TE is maar een 1 CD-Player aangesloten *)
IBGetObjectinfo( MessagePtr·.object, MessagePtr".Objectid, Objectinfo, Result );
(* voor testdoeleinden gelijkgesteld
*)
MessagePtr".LastUser Objectinfo.LastUser
1·,
==
IF MessagePtr".LastUser
=
Objectinfo.LastUser
1;
265 266 267 268 269 270 271
ColaMessage.Type :=
BITSET(40);
ColaToRc5(ColaMessage); CASE MessagePtrA.Attribute OF AttrTrack:
272
273 274 275 276
(*
Na het instellen van de gevraagde Track moet de CD speler het nummer afspelen, dus play wordt geactiveerd
*)
277
278 279 280 281 282 283 284 285 286 287 288 289 290 291 292 293 294 295 296 297 298 299 300 301 302 303 304 305 306 307 308 309 310 311 312
ColaMessage.Function := BITSET(24); := BITSET(O); ColaMessage.Value IBChangeAttribute(MessagePtrA.LastUser, MessagePtrA.Object, MessagePtrA.Objectid, MessagePtrA.Attribute, ValueType(Play), Result );
ColaMessage.Type := BITSET(40); ColaToRc5(ColaMessage); ELSE END; CASE (* *)
);
MessagePtr·.signal MessagePtrA.DestPn MessagePtrA.State MessagePtr·.LastUser MessagePtrA.Pn MessagePtr·.Bc MessagePtrA.Track MessagePtrA.Toggle MessagePtrA.Repeat MessagePtr·.Pause MessagePtrA.PowerStatus MessagePtrA.Service MessagePtrA.Serviceld MessagePtr •. Linkld MessagePtrA.Room MessagePtrA.LsPairld MessagePtrA.Available MessagePtrA.HlResult
313
314 315 316 317 318 319 320 321 322 323 324 325 326 327 328 329 330
MessagePtrA.Object, MessagePtrA.Objectid, Objectinfo, Result
IBGetObjectlnfo(
:=
:= :=
:= := := := :=
:. := !=
:= :=
:= := := :=
:=
ELSE State('sFALSE'); END; (* IF
*)
MicroPhone
*)
(*
NOTIFY; NOPN; Objectlnfo.State; Objectlnfo.LastUser; Objectlnfo.Pn; Objectinfo.Bc; Objectlnfo.Track; Objectlnfo.Toggle; Objectlnfo.Repeat; Objectlnfo.Pause; Objectlnfo.PowerStatus; Objectinfo.Service; Objectlnfo.Serviceid; Objectlnfo.Linkld; Objectlnfo.Room; Objectlnfo.LsPairid; Objectinfo.Available; SuccessFullChange;
IMicroPhone (*
Aan iedere TE is maar een 1 MicroPhone aangesloten *)
(* Tijdelijk
IBGetObjectinfo(
MessagePtrA.Object,
331 332 333 334 335 336 337 338 339 340 341 342 343 344 345 346 347 348 349 350 351 352 353 354 355 356 357 358 359 360 361 362 363 364 365 366 367 368 369 370
MessagePtr~.Objectld,
Objectlnfo, Result );
IF MessagePtrA.LastUser =
Objectinfo.LastUser THEN ColaMessage.Type := ColaMessage.Function
BITSET(MessagePtr·.NevValue);
ColaToRc5(ColaMessage); IBChangeAttribute(MessagePtrA.LastUser, MessagePtr·.object, MessagePtrA.Objectid, MessagePtrA.Attribute, MessagePtrA.NevValue, Result );
MessagePtr·.signal MessagePtr·.DestPn MessagePtr·.PoverStatus MessagePtr·.state MessagePtr·.LastUser MessagePtr·.Pn MessagePtr·.ac MessagePtrA.Service MessagePtr·.serviceid MessagePtr •• Linkid MessagePtr·.Room MessagePtr·.LsPairid MessagePtr·.Available
371
377
Function[MessagePtr •• Attribute];
:=
ColaMessage.Value :=
372 373 374 375 376 378 379 380 381 382 383 384 385 386 387 388 389 390 391 392 393 394 395 396
Object!nfo.Type;
:= NOTIFY; := NOPN; := Objectinfo.PowerStatus; == Object!nfo.State; := Objectinfo.LastUser; := Objectinfo.Pn; := Objectinfo.Bc; := Objectinfo.Service; := Objectlnfo.Service!d; := Object!nfo.Linkid; == Objectinfo.Room; := Objectinfo.LsPairid; :. Object!nfo.Available;
CASE MessagePtr•.Attribute OF PoverStatus MessagePtrA.PoverStatus (*
:= MessagePtrA.NevValue
PowerStatus is het enige attribuut dat gewijzigd kan worden in een Microfoon *) END; (* CASE ELSE State('sFALSE'); END; (* IF
*)
*)
Tijdelijk *) (*
Loudspeaker
*)
!LoudSpeaker (*
Aan de MultiFunctionele Terminal zijn twee Luidsprekers aangesloten *)
Consume; IBGetObjectinfo(
MessagePtrA.Object,
397 398 399 400 401 402 403 404 405 406 407 408 409 410 411
412 413
414 415 416 417 418 419 420 421 422 423 424 425 426 427 428 429 430 431 432 433 434
435 436 437 438 439 440 441 442 443 444 445 446 447 448 449 450 451 452 453 454 455 456 457 458 459 460 461 462
HessagePtr".Objectid, Objectinfo, Result );
IF HessagePtr".LastUser
=
Objectinfo.LastUser THEN CASE HessagePtr".Attribute OF AttrPowerStatus: ColaHessage.Function := BITSET(10); IF NOT(HessagePtr".PowerStatus = Objectinfo.PowerStatus THEN ColaMessage.Value := BITSET(O); HessagePtr·.PowerStatus := Objectinfo.PowerStatus; IBChangeAttribute(HessagePtr".LastUser, HessagePtr".Object, HessagePtr".Objectid, HessagePtr".Attribute, ValueType(HessagePtr".PowerStatus), Result
);
END; (* IF *) IAttrVolume Dif :=( DifType(MessagePtr".Volume) DifType(Objectinfo.Volume)); IF Dif > 0 THEN ColaHessage.Function := BITSET(12); ELSIF Dif < 0 THEN Dif := (-1) * Dif; ColaHessage.Function := BITSET(13); ELSE ColaHessage.Function := BITSET(12); END; (* IF *) ColaHessage.Value := BITSET(VolumeType(Dif)); IBChangeAttribute(HessagePtr".LastUser, HessagePtr".Object, MessagePtr".Objectid, HessagePtr".Attribute, ValueType(MessagePtr".Volume), Result );
IAttrLowTones IF HessagePtr·.LowTones
>
Objectinfo.LowTones THEN ColaMessage.Function := BITSET(14); ELSE ColaHessage.Function := BITSET(l5); END; (* IF *) ColaHessage.Value := BITSET(HessagePtr".LowTones); IBChangeAttribute(HessagePtr".LastUser, HessagePtr".Object, HessagePtr·.objectid, HessagePtr".Attribute, ValueType(HessagePtr".LowTones), Result );
463 464 46S 466 467 468 469 470
IAttrHighTones IF HessagePtr .. HighTones
>
Objectinfo.HighTones THEN ColaHessage.Function == BITSET(16); ELSE ColaHessage.Function == BITSET(17); END; (* IF *) ColaHessage.Value == BITSET(HessagePtr •• HighTones); IBChangeAttribute(HessagePtr·.LastUser, HessagePtr •• Object, HessagePtr·.objectid, HessagePtr •• Attribute, ValueType(HessagePtr".HighTones), Result
471 472
473 474 47S 476 477 478 479 480 481 482 483 484 48S 486 487 488 489 490 491
);
ELSE Result END;
==
CASE
*)
:=
BITSET(48);
ObjectUnknown
ColaHessage.Type
ColaToRcS(ColaHessage); IBGetObjectinfo(
492
493 494 49S 496 497 498 499
HessagePtr".Object, HessagePtr".Objectid, Objectlnfo, Result );
HessagePtr·.signal HessagePtr·.DestPn HessagePtr·.PowerStatus HessagePtr·.state HessagePtr".LastUser HessagePtr".Pn HessagePtr".Bc HessagePtr".Service HessagePtr".Serviceid HessagePtr".Volume HessagePtr".LowTones HessagePtr".HighTones HessagePtr".Linkid HessagePtr".Room HessagePtr".LsPairid HessagePtr".Available HessagePtr".HlResult
soo
S01 S02 S03 S04 SOS S06 S07 S08 S09 S10 Sll S12 S13 S14 S1S S16 S17 S18 S19 S20 S21 S22 S23 S24 S2S S26 S27 S28
(*
:= :=
:= :=
==
:= := :=
:= :=
:= := := :=
== == ==
NOTIFY; NOPN; Objectinfo.PowerStatus; Objectinfo.State; Objectinfo.LastUser; Objectlnfo.Pn; Objectlnfo.Bc; Objectlnfo.Service; Objectinfo.Serviceid; Objectlnfo.Volume; Objectinfo.LowTones; Objectinfo.HighTones; Objectlnfo.Linkld; Objectlnfo.Room; Objectinfo.LsPairid; Objectlnfo.Available; SuccessFullChange;
SendHessage('NOTIFY',HessagePtr,TeHandRouter); ELSE State('sFALSE'); END; (* IF
*)
ICamera (* (*
Tijdelijk
Camera
*)
IBGetObjectinfo( HessagePtr".Object, HessagePtr".Objectid, Objectinfo,
529 530 531 532 533 534 535 536 537 538 539 540 541 542 543 544 545 546 547 548 549 550 551 552 553 554 555 556 557 558 559 560 561 562 563 564 565 566 567 568 569 570 571 572
573 574 575 576 577
578 579 580 581 582 583 584 585 586 587 588 589 590 591 592
593 594
Result );
IF MessagePtrA.LastUser Objectinfo.LastUser THEN CASE MessagePtrA.Attribute OF AttrPowerStatus: ColaMessage.Function :=
BITSET(16);
==
BITSET ( 28) ;
:=
BITSET(29);
!AttrVolume IF MessagePtr".NewValue
>
Objectinfo. Zoom THEN ColaMessage.Function ELSE ColaMessage.Function END; (* IF
*)
ELSE Result END;
(*
ObjectUnknown CASE
*)
:=
BITSET(18);
ColaMessage.Type ColaMessage.Value :=
BITSET(MessagePtr·.NewValue);
ColaToRc5(ColaMessage); IBChangeAttribute(MessagePtrA.LastUser, MessagePtrA.Object, MessagePtr".Objectid, MessagePtr".Attribute, MessagePtr·.NewValue, Result );
MessagePtr".Signal := NOTIFY; MessagewPtrA.DestPn == NOPN; MessagePtr".PowerStatus := Objectinfo.PowerStatus; MessagePtr".State := Objectinfo.State; MessagePtr".LastUser == Objectinfo.LastUser; MessagePtr".Pn == Objectinfo.Pn; MessagePtr".Bc == Objectinfo.Bc; MessagePtr".Service == Objectlnfo.Service; MessagePtrA.Serviceid := Objectinfo.Serviceid; MessagePtr".Linkid := Objectinfo.Linkid; MessagePtr".Room := Objectinfo.Room; MessagePtr".Zoom == Objectinfo.Zoom; MessagePtr".Available := Objectlnfo.Available; CASE MessagePtr".Attribute OF AttrPowerStatus: MessagePtr".PowerStatus !AttrZoom MessagePtr".Zoom END; (* CASE *) ELSE State('sFALSE'); END; (* IF
*)
:= MessagePtr".NewValu
== MessagePtr".NewValu
595 596 597 598 599 600 601 602 603 604 605 606 607 608 609 610 611 612 613 614 615 616 617 618 619 620 621 622 623 624 625 626 627 628 629 630 631 632 633 634 635 636 637 638 639 640 641 642 643 644 645 646 647 648 649 650 651 652 653 654 655 656 657 658 659 660
!Monitor (* Monitor *) GetObjectinfo( MessagePtr·.object, MessagePtr·.objectid, Objectinfo, Result );
IF MessagePtr·.LastUser
=
Objectinfo.LastUser THEN CASE MessagePtr-.Attribute OF AttrPowerStatus: ColaMessage.Function :=
IAttrBrightness : IF MessagePtr·.NewValue
BITSET(6);
>
Objectinfo.Brightness THEN ColaMessage.Function := ELSE ColaMessage.Function := END; (* IF *)
BITSET(12); BITSET ( 13) ;
IAttrContrast IF MessagePtr·.NewValue
>
Objectinfo.Contrast THEN ColaMessage.Function ELSE ColaMessage.Function END; (* IF
:=
BITSET(14);
==
BITSET ( 15) ;
*)
IAttrHighTones IF MessagePtr·.NewValue
>
Objectinfo.ColourSatr THEN ColaMessage.Function == ELSE ColaMessage.Function == END; (* IF *)
BITSET( 16);
Result
ObjectUnknown
BITSET( 17);
ELSE END;
(*
!=
CASE
*)
:=
BITSET(7);
ColaMessage.Type ColaMessage.Value :=
BITSET(MessagePtr·.NewValue);
ColaToRc5(ColaMessage); IBChangeAttribute(MessagePtr·.LastUser, MessagePtr·.object, MessagePtr·.objectid, MessagePtr•.Attribute, MessagePtr·.NewValue, Result );
MessagePtr·.signal
:= NOTIFY;
661 662 663 664 665 666
MessagePtrA.DestPn := NOPN; MessagePtr~.PowerStatus
MessagePtr·.state MessagePtrA.LastUser MessagePtr~.Pn
MessagePtr~.Bc
667 668 669 670 671 672 673 674 675 676
MessagePtr".Brightness MessagePtr~.Contrast MessagePtr~.ColourSatr
MessagePtr".Service MessagePtrA.Service!d MessagePtr".Link!d MessagePtr".LsPairid MessagePtrA.Available
Objectinfo.PowerStatus;
:= Objectinfo.LastUser; == Objectinfo.Pn; := Object!nfo.Bc; == Objectlnfo.Brightness; == Object!nfo.Contrast; := Objectinfo.ColourSatr; := Object!nfo.Service;, == Object!nfo.Service!d; := Object!nfo.Link!d; == Objectinfo.LsPair!d; := Object!nfo.Available;
CASE MessagePtr~.Attribute OF AttrPowerStatus: MessagePtrA.PowerStatus IAttrBrightness : MessagePtrA.Brightness IAttrContrast
677
678 679 680 681 682 683 684 685 686 687 688 689 690 691 692 693 694 695 696 697 698 699 700 701 702 703 704 705 706 707 708 709 710 711 712 713 714 715 716 717 718 719 720 721 722 723 724 725 726
:=
:= Objectlnfo.State;
MessagePtr~.Contrast
IAttrColourSatr : MessagePtrA.ColourSatr END; (* CASE *)
Tijdelijk *) END;
ELSE State('sFALSE'); END; (* IF (*
CASE
*)
*)
ICLAIM CASE MessagePtr".Object OF CdPlayer IMicroPhone !LoudSpeaker !Camera !Monitor END; CASE (* *) IUNCLAIM: CASE MessagePtr".Object OF CdPlayer IMicroPhone !LoudSpeaker !Camera !Monitor END; CASE (* *) !UPDATE: CASE MessagePtr~.Object OF CdPlayer IMicroPhone !LoudSpeaker !Camera !Monitor END; CASE (* *) ELSE
Ignore; PutMemoryElement(MESSAGES,MessagePtr); State('Ignore');
END; END;
(* (*
CASE LOOP
*) *)
== MessagePtr".NewValue ==
MessagePtr~.NewValue
== HessagePtr".NewValue == MessagePtr".NewValue
727 728 729 730
END ProcessTeHand; END TeHand.
1 2 3 4 5
6 7
8 9
DEFINITION MODULE Monitor; FROM SDLM
ProcessiD;
PROCEDURE ProcessMonitor;
VAR Moninitl, MonRouterl
10 11
IMPORT
END Monitor.
ProcessiD;
133 134 135 136 137 138 139 140 141 142 143 144 145 146 147 148 149
*) ELSE (* Attribuut bestaat niet *) END; (* CASE *) Result := SuccesFull; END; (* IF *) PutMemoryElement(MESSAGES,MessagePtr); SendNotify(NOPN,Result);
ELSE Ignore; PutMemoryElement(MESSAGES,MessagePtr); END; (* CASE *) END; (* LOOP *) END ProcessMonitor; END Monitor.
APPENDIX J
Appendix J.
Communieatle over de RS232-poort
J. 1 Common Control and lnformation-berichten Het CCI-protocol in EBIN maakt gebruik van de volgende CC I-berichten: • Met behulp van het CREATE-bericht kan men in de HNC een link- en luidsprekerpaar-en dienstobjecten creëren. Het luidsprekers-paar object wordt gecreëerd als men gebruik maakt van stereo muziek. Als meri nu de bolanee van een luidspreker wil manipuleren die opgenomen is in een luidspreker-paar, gebeurt dit door het luidspreker-paar object te manipuleren. In het luidsprekerpaar-object wordt dan de benodige actie ondernomen om de desbetreffende luidsprekers te manipuleren. I
CREATE
(
Object Ob}ectld, LeftLoudSpeakerObjectld, RightLoudSpeakerObjectld, Balance, Userld
)
Voor het leggen van een verbinding wordt het volgende gespecificeerde CCI-bericht verstuurd naar de HNC:
CREATE
(
Object, Objectld, OrigPn, DestPn 1, Be, Userld
)
Tevens bestaat de mogelijkheid om diensten te creëren. Diensten bestaan uit meerdere links, er zijn de volgende Telephonie, dienstobjecten in een EBIN mogelijk: Babyphoniel AudioDistributie, VideoDistributie Videafonie en I
Appendix J.
Communicatie over de RS232-poort de Macintosh die het object manipuleert ook het object geclaimd moet hebben. De macintosh die een object creëert, heeft tevens het object geclaimd. • De CLAIM en UNCLAIM berichten zien er als volgt uit:
CLAIM
(
Object, Objectld, Userld
)
UNCLAIM
(
Object, Objectld, Userld
)
• Bij het aansluiten van een nieuwe UI informatie over het netwerk en de daaraan aangesloten randapparatuur bekend zijn. De nieuwe UI verstuurd daarvoor een UPDATE bericht waarop alle objecten in het huisnetwerk informatie over hun toestand versturen.
UPDATE
(
DesPn
)
• Een NOTIFY bevat alle informatie van het originele object. In de Macintosh bevinden zich enkel kopieën van object. De originelen bevinden zich in de HNC (link-, LuidSprekerpaar- en DienstObjecten) en in de TE' s (randapparatuur objecten). Aan de waarde van Result kan men zien wat de oorzaak van het versturen van de NOTIFY.
NOTIFY
(
Object, Objectld, "Objectlnfo", Result
)
Deze berichten worden uitgewisseld tussen de applicatielaag entiteiten. De CREATE, CHANGE en DELETE berichten hebben hun oorsprong in de Macintosh. Voor de UPDATE, CLAIM en UNCLAIM berichten is de oorsprong ook de Ma-
3
Appendix J.
Communicatie over de RS232-poort cintosh, hoewel het hierbij nog mogelijk is om deze vanuit het VME-systeem van de macintosh te versturen en te claimen. De NOTIFY berichten tengevolge van een verandering in het huisnetwerk of ten gevolge van een aan gevraagde UPDATE worden naar de Macintosh door gestuurd, zodat het UI-beeld overeen komt met de toestand van het netwerk.
J.2 Communicatie tussen Macintosh en VME-systeem Macintosh. · In de voorgaande paragraaf is beknopt duidelijk gemaakt hoe de communicatie tussen de hogere lagen werkt. Hieronder maak ik duidelijk maken hoe op zeer eenvoudige manier de communicatie tussen macintosh en VME-systeem bij de macintosh in zijn werk gaat. Allereerst wil de hogere lagen graag weten om welke operatie het gaat. De macintosh verstuurt daaNoor een afkorting van de bericht soort, zie tabel J.l.
T&bal J.l Coàerinq berichten soort over RS232-poort
ptt! research
CCI-berichten
Codering over RS232-poort
C!U!:.ATE
CR
CHANGE
CR
CLAIM
CL
tl'NCLAIM
ON
OP
'DA'l'E ELETE
OB
NOTil!'Y
NO'l'
4
Communieatle over de RS232-poort
Appendix J.
De verschillende objecten worden ook op een dergelijke wijze aangeduid, zie tabel J.2. Tabel J.2 Coderinq object soort. over
RS232~poort
Objecten
Coderinq over RS232-poort
Link
Li
Loudspeaker
La
CD-player
cd
Camera
Ca
Microfoon
Mi
Monitor
Ho
Zo kun je aUe mogelijke attributen afkorten, zie tabel J.3.
ptt l rfl ~e drr.h
Attributen
Coderinq over
Deatination Party Number 1
Pl
Deatination Party Number 2
P2
Deatination Party Number 3
P3
Deatination Party Nuaber 4
P4
Powerstat u•
Po
Pauae
Pa
!earer Capability
Sc
Salance
Ba
State
Sa
Service
Se
Track
~r
Toqqle
To
LaatUaer
La
Loudspeakerpair Identiti er
La
Low Tonea
Lo
Lett Loudspeaker Identitier
Le
Room
Ro
Riqht Loudapeaker Identitier
Ri
Repeat
Re
Zoom
zo
Hiqh Tonea
Hi
Volume
Vo
RS2~2-poort
5
Appendix J.
Communicatie over de RS232·poort In tabel J.4 zien we de codering voor de informatiesoort (Bearer Capability).
Tabe~
11
J.4 Codering informatie soort over ftS232•poort
Bearer Capability Type
~~ehstrDiqinfo
1Goderinq over ftS232-poort Sp un
RestrOiqinfo
Re
Audio3Khz
A3
Audio7Khz
A7
Video
Vi
HQAudio
HA
HQVideo
HV
RCS
Re
Siqnallinq
Si
Null
Nu
In tabel J.S is de codering voor de variabele Result samengevat, Result is een parameter die met een NOTIFY wordt meegezonden. Result geeft wat het resultaat van een operatie was. Tabe~
J.5 Codering reault over ftS232-poort
Result Type
Codering- over ftS232-poort
SueeessFullCreate
SFC
~eeessFullOelete
SFD
UnSuecessFullCreate
usc
UnSueeessFullOelete
uso
unsuccessFullAttaeh
USA
SuccessFullAttach
SI!'A
unsueeessFullOetach
rmA
SuceessFullDetaeh
SOA
1
pttlresearr:h . .
SuccesFull
SI!'L
SuccessFullChanqe
sca
UnSuccessFullChanqe
IJCS
6
Appendix J.
Communieatle over de RS232-poort In Tabel J6 wordt de codering van mogelijke waardes voor de variabele state gegeven. Het attribuut State geeft aan in welke toestand het object zich. bevindt. 'l'al:lel J.6 Codering State over RS232-poort Coderingover !UI232-poort
!I State Type
IA
!nActive
!1
!i ActiveOccupled
AO
,I Actl.veE'ree
Al'
In Tabel J7 wordt de codering van mogelijke waardes voor de variabele powerstatus gegeven. Dit attribuut geeft aan of een apparaat aan/uit is. 'l'al:lel. J. 7 Codu'ill9 li'OWU"IIt&t:ua
! PowerStatus 1
~
COdering over RS232-poort
Type
On
A
! Off
u
i
JUt232-poor:t:
In Tabel J8 wordt de codering van mogelijke waardes voor de variabele Avoilobie gegeven. Het attribuut geeft aan of een object beschikbaar is of niet. 'l'al:lel VXIl'l'al:lel J.8 Codering Available ove:rt !UI232-poo:rt Availa.ble Type
I TRUE
!'ALSE
Codering over RS232 'l' !'
In de voorgaande paragraaf is sprake geweest van Objectld, .. etcetera. De ldentîfiers van de Link-, Luidsprekerpaar-en dienstobjecten worden in de macintosh bepaald. Een ld is van het type Shortcard de eerste byte bestaat uit de Userld van de macintosh en de tweede byte bestaat uit een teller die wordt opgehoogd om het aantal link-, Luidsprekerpaaren dienstobjecten bij te houden. Er worden dus vier karakters verstuurd die de hexadecimale waarde van die ld representeren.
J.3 Voorbeelden
ptt. rese;,rch
7
Appendix J.
Communicatie over de RS232-poort
In deze paragraaf wil ik enkele voorbeelden geven hoe de berichten er uitwisseling eruit komt te zien: Voorbeeld 1
Op de UI wordt een verbinding gelegd tussen de CD-speler, aangesloten op een VME-systeem met PartyNumber= 1, en een Luidspreker, aangesloten op een VME-systeem met PartyNumber=2. Het gaat om een High Quality Audio verbinding. De opdracht is afkomstig van de macintosh met Userld= 1. Het bericht afkomstig van de macintosh heeft dan de volgende vorm:
Het CREATE-bericht dat door de Macintosh naar de HNC wordt verstuurd, heeft een NOTIFY tot gevolg. De Objectinfo van bestaat uit de opeenvolgende onderdelen: OrigPn, DestPn 1, Be, Result, Available, LastUser en Status Hierop volgt dan Notify in de vorm van
ptt research )
a
~
.,
*
"
8
